FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Pages: 1 2 [3] 4

Author Topic: PyChan Feedback  (Read 22873 times)

November

  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: PyChan Feedback
« Reply #30 on: March 04, 2008, 07:04:22 pm »

Oh yes I got further : the editor should be ready to use very soon.
Here is a screenshot of the actual editor : for the moment it can only visualize an existing dialogue, not create or delete one.

http://membres.lycos.fr/blackice9/dialogue_editor.JPG

I created some sort of browser-like widget to make the arborescence. I made it the more flexible possible so it could fit well, with some rework, in pychan. It's not totally finished on my side, partly due to the pychan issues listed before. See the BrowserWidget() class in extensions/editor/plugins/dialogue_editor/widgets.py in the attached diff if you are interested.

The diff is attached to this thicket
http://mirror1.cvsdude.com/trac/fife/engine/ticket/277
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #31 on: March 05, 2008, 07:09:28 am »

Hi November,

Icons and ImageButtons now set their size according to the Images you give them.
Icons now by default don't draw a border anymore.

I hope this (at least partially) fixes your issues.

The Dialog Editor looks awesome, sorry that I do not have the time
to look at it in more detail :-/

-phoku
Logged

Sadr

  • Newbie
  • Posts: 34
    • View Profile
    • Radakan
Re: PyChan Feedback
« Reply #32 on: March 07, 2008, 07:54:57 am »

Oh yes I got further : the editor should be ready to use very soon.(...)
Nicely done! Do you think someone like me, with limited programming knowledge and interest, yet a strong sense of logic, will be able to use this program for creating dialogue? Will it even be made available for me? :D
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: PyChan Feedback
« Reply #33 on: March 19, 2008, 07:58:16 am »

Copy & paste:
As I haven't worked with pychan yet I don't have a slight idea what the current status of it is. It would be good if Phoku or any developer who has worked with pychan could elaborate on the current status and on possible planned features.

Phoku recently founded his own game development project:
http://iteration-zero.blogspot.com/

Having an own project now does prolly mean Phoku will have less time for FIFE and pychan :-/ It might be a good idea if we could collect all kind of feedback and proposals in the pychan thread so in case phoku finds the time to look into pychan again later he would already know what the community would like to see in future version of pychan.

Furthermore it would be useful to know if you have any kind of roadmap for pychan in mind Phoku. In case you could list your plans for it we could create trac tickets and other developers have the changce to disburden you by implementing some of the planned features.
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #34 on: March 24, 2008, 08:58:55 am »

Current State

Hm my impression of pychan "in the wild" is that it's fairly usable already.

The main API is stable insofar, as changes will be minor and if possible
only generate a deprecation warning. If I missed an issue with the API
please comment on that!

Dark Areas

What I think needs improvement are in order of priority:

  • Interaction - Events generated by our current core gui system are _minmal_. Need at least onMouseEntered,Exited.
  • DND - Dungeo... eh. Drag and Drop would be very very nice.
  • More Widgets!
  • Layout Engine - Needs a notion of expanding expandable Widgets.
  • Font Handling - Needs a plan :)
  • Styling - Needs some rework. (It's not powerful enough, maybe extend to styles loaded from xml)

Don't panic!

Although I started my own project, this doesn't mean I will abandon FIFE completely!
Most of the features on the ToDo list for Pychan/FIFE GUI need some planning and thus a bit of time to work concentrated on that.
I hope that none of the above listed problems are real show-stoppers (though ZeroProject will probably disagree ^^).

Another note on the code and "hackability" of pychan.
I have documented the code extensively and I hope that anyone with a little time can understand it.
As far as having a roadmap for pychan to share with you, I am afraid that actually making that roadmap
in detail is already 80% of the work required.

Anyway. Continue to post your feedback, feature requests and especially bug reports here!

-phoku
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: PyChan Feedback
« Reply #35 on: April 09, 2008, 06:44:21 pm »

Slightly related to pychan: a new version of guichan was recently released. The release announcement says:
Quote
The new version of Guichan contains two new widgets for creating tabs, the TabbedArea widget and the Tab widget. The support for HGE has been improved along with the API documentation. Also, new listeners have been added such as the WidgetListener used for listening for changes from widgets (such as visibility) and the SelectionListener for listening for selections. As always a number of bugs have been fixed.

Perhaps a little bit more interesting is that the demos needed no changes to work out of the box with the 0.8.0 release. Finally the API is actually stabilising.

For details see:
http://guichan.sourceforge.net/wiki/index.php/Main_Page

I'll build guichan for the supported win32 compilers in the next days and let's see if the new 0.8 release works with FIFE.

EDIT: building guichan 0.8 from source worked fine with mingw. Building FIFE trunk against guichan 0.8 failed with this error message:
Quote
g++ -o engine\core\gui\console\console.o -c -Wall -O2 -DLOG_ENABLED -DHAVE_ZIP -DHAVE_OPENGL -Ibuild\win32\includes\mingw\libogg -Ibuild\win32\includes\mingw\openal-soft -Ibuild\win32\includes\mingw\sdl_image -Ibuild\win32\includes\mingw\zlib -Ibuild\win32\includes\mingw\libguichan -Ibuild\win32\includes\mingw\boost_1_35_0 -Ibuild\win32\includes\mingw\libvorbis -Ibuild\win32\includes\mingw\libpng -Ibuild\win32\includes\mingw\sdl_ttf -Ibuild\win32\includes\mingw\sdl -Ibuild\win32\includes\mingw\python25 -Iengine\core -Iengine\swigwrappers engine\core\gui\console\console.cpp
engine\core\gui\console\console.cpp: In member function `void FIFE::Console::reLayout()':
engine\core\gui\console\console.cpp:105: error: `setBorderSize' undeclared (first use this function)
engine\core\gui\console\console.cpp:105: error: (Each undeclared identifier is reported only once for each function it appears in.)
scons: building terminated because of errors.
scons: *** [engine\core\gui\console\console.o] Error 1

EDIT2: I've built libguichan with mingw, msvc2005 and msvc2008. You can download the precompiled libs here (in case anyone wants to play around with the new guichan release and try to make FIFE compatible with it):
http://members.fifengine.net/mvbarracuda/guichan_0.8.0_SDK.7z
« Last Edit: April 10, 2008, 07:25:49 am by mvBarracuda »
Logged

chewie

  • Developer
  • Full Member
  • *
  • Posts: 123
    • View Profile
    • zero-projekt.net
Re: PyChan Feedback / Behaviour of V/HBoxes
« Reply #36 on: July 27, 2008, 03:20:21 pm »

Moin phoku  :)

Let me start with telling you that I'm very satisfied with pychan so far - didn't face any problems by using it in the combination loadxml - callbacks - toggle container visible / invisible and setting some positions here and there. Even some wired combos of V/HBoxes and massive data distributions to containers were processed by pychan without a meow.  :D

After designing most of the generic gui of Zero, I came to the point where the real fun begins: fancy dynamic widgets. So I switched back to python only gui-ing and created my first project: the graphical ammo display

(The plan is to take a VBox, read out the current ammo of the players active weapon and draw green lines to indicate the percentage of the remaining ammo.)

I used this code to fill the VBox with some Icons (which all use the same green image with the size 8x1px):

Code: [Select]
bars = {}
y = 1

for i in xrange(10):
bars[i] = self.guiwrapper.widgets.Icon('gui/common/ammo_bar.png')
self.HUDammodisplay_container.addChild(bars[i])
position = (0, y)
bars[i]._setPosition(position)
tx, ty = bars[i]._getPosition()
print 'added green bar #', i, ' at: (', tx, '/', ty,')'
y = y + 1

Nearly everything worked as expected:



I planned to create 50 green bars - but the VBox won't let me by eating the available space with wired displacements of the widgets  :(.

Here comes the debug output of my code snippet - which tells me that the planned widget positions don't create any space between them:

Code: [Select]
added green bar # 0  at: ( 0 / 1 )
added green bar # 1  at: ( 0 / 2 )
added green bar # 2  at: ( 0 / 3 )
added green bar # 3  at: ( 0 / 4 )
added green bar # 4  at: ( 0 / 5 )
added green bar # 5  at: ( 0 / 6 )
added green bar # 6  at: ( 0 / 7 )
added green bar # 7  at: ( 0 / 8 )
added green bar # 8  at: ( 0 / 9 )
added green bar # 9  at: ( 0 / 10 )

The question now is - why does the VBox automaticly create this space between the contained widgets - and how can I deactivate this behaviour?

Cheers,
chewie

chewie

  • Developer
  • Full Member
  • *
  • Posts: 123
    • View Profile
    • zero-projekt.net
Re: PyChan Feedback
« Reply #37 on: July 30, 2008, 10:13:33 pm »

Heureka - and shame on me  :-[

I tried and tried, read the doku again - tried again ... and found it. Vbox is initialised with padding = 5. So the solution is:


Code: [Select]
padding = 4
myVbox = pychan.widgets.VBox(padding)

... and here we go. As much space as you want :). Though I guess I found an issue here - it doesn't matter if you set padding=1,2,3 or 4 - the VBox will only stop padding the child widgets - at all.

Nevertheless - now it works :)

Here is my code - perhaps someone can use it, too :)

Code: [Select]
def setAmmoDisplay(self, player = None):
'''
draw ammo bars & update text label - according to the current ammo of the player

@param player : player instance with appended ruleset

'''
self.ammo_bar_widgets = {}
bars_to_draw = 100

if player is None:
ammo = 0
else:
ammo = player.active_weapon['ammo']
ammo_max = player.active_weapon['clipsize']

ammo_percent = 100 / ammo_max * ammo

bars_to_draw = int(round(ammo_percent * bars_to_draw / 100))

self.container.removeChild(self.ammodisplay_container)
self.ammodisplay_container = self.guiwrapper.widgets.VBox(4)
self.ammodisplay_container._setPosition((782,58))
self.ammodisplay_container._setSize((8,96))
self.ammodisplay_container._setName('ammodisplay_box')
self.container.addChild(self.ammodisplay_container)

y = 1

for i in xrange(bars_to_draw):
self.ammo_bar_widgets[i] = self.guiwrapper.widgets.Icon('gui/common/ammo_bar.png')
position = (0, y)
self.ammo_bar_widgets[i]._setPosition(position)
y = y + 1
self.ammodisplay_container.addChild(self.ammo_bar_widgets[i])

As always - there is one problem left. Normally you can use spacers to influence the order of the added Childs. Via XML I made it that the bar is growing from botton to top - with the dynamic, python only solution - it is just the opposite. Adding a Spacer to the VBox didnĀ“t help.

Well, I'll wait some days and look into the problem again. Perhaps I find a solution. Otherwise, it's a unique feature for Zero.  :D

Here's a demo gif of the code:


phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #38 on: October 13, 2008, 10:54:31 am »

Hmm. I can't confirm that padding doesn't work.

You know that paddings, margins etc. pp. only take effect
after a call to adaptLayout ? I guess I have to document
these peculiarities better  ::)

Besides it's better to write:
Code: [Select]
vbox = widgets.VBox(padding=4)

This way a reader knows what the number 4 is about.

-phoku

PS: Did you figure out why the bullet list you posted in IRC
failed to work? If not, please post the issue here again.

EDIT:
Quote
23:48 <chew-ie_> phoku, about the ScrollArea-issue - it seems that you can't place two wrapper containers into a scrollarea - as soon as I remove the VBox and all HBox-constructions but one, it "works" (remaining problem is that you can't dump more HBoxes into that ScrollArea, because then again the widgets aren't displayed.)



« Last Edit: October 13, 2008, 04:49:42 pm by phoku »
Logged

chewie

  • Developer
  • Full Member
  • *
  • Posts: 123
    • View Profile
    • zero-projekt.net
Re: PyChan Feedback
« Reply #39 on: October 13, 2008, 05:53:22 pm »

Oki, I looked into the the input_rework branch and applied some fixes to our client. DnD is still broken, but I guess I only have to change the design behind the DnD system - to follow the new eventhandling.

I've some ideas and let you now if they work. If I'm not totally wrong, it should be very easy now to implement DnD in every client  :D
« Last Edit: October 13, 2008, 05:58:21 pm by chewie »
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #40 on: October 14, 2008, 02:03:23 pm »

pychan_rework branch started.  8)

I can't help but advertise it:
  • Less ugly default style.
  • More complete layout engine.
  • Standard dialogs supplied.
  • Fixes and cleanups.



Since the new layout engine might move pixels around and subtly
break existing gui layouts, it's a new branch.

Have fun.

-phoku
Logged

November

  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: PyChan Feedback
« Reply #41 on: October 14, 2008, 03:50:45 pm »

Hello Phoku !

I'm glad to see you took the time to start working on FIFE again (even a little, but it seems you already done much in these few days).

I personally don't have time to pursue what I started working on (dialogUE system and editor) because of my architecture studies.

But since you are currently working on the UI, and since I plan to get back on my editor one day, i've thought you could maybe look into adding the following feature :
It could be useful to have text selection and edition functions (cut, copy, paste) for the dialogue editor, and  probably for other tools as well.
The text selection would require some additions to the core GUI itself.

Do you think this may find a place in your todolist ?
« Last Edit: October 14, 2008, 03:52:39 pm by November »
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #42 on: October 16, 2008, 01:24:34 am »

Hi November!

Short answer: Nope. Not in this life.

Long Answer:
Text selection is quite complicated to get right. There are many many many more problems
and features that will have to be addressed first. Since for games text selection isn't really
an interesting feature this is way down on the GUI ToDo list.

So if someone comes along and fiddles text selection into TextBox/TextField - then this will
get exported. Otherwise I won't work on it.

Sorry, but that's my take on that :-/

-phoku
Logged

chewie

  • Developer
  • Full Member
  • *
  • Posts: 123
    • View Profile
    • zero-projekt.net
Re: PyChan Feedback
« Reply #43 on: March 15, 2009, 12:20:07 pm »

Moin phoku :)

I've one little issue with pychan since you made your last commits. One of my pychan applications crashed with this message:

Code: [Select]
Traceback (most recent call last):
  File "zedit.py", line 247, in <module>
    main()
  File "zedit.py", line 243, in main
    editor = Zedit()
  File "zedit.py", line 180, in __init__
    self.gui.stylize('Zedit')
  File "../../engine/extensions/pychan/widgets.py", line 495, in stylize
    self.deepApply(_restyle)
  File "../../engine/extensions/pychan/widgets.py", line 738, in deepApply
    child.deepApply(visitorFunc)
  File "../../engine/extensions/pychan/widgets.py", line 1682, in deepApply
    if self._content: self._content.deepApply(visitorFunc)
  File "../../engine/extensions/pychan/widgets.py", line 534, in deepApply
    visitorFunc(self)
  File "../../engine/extensions/pychan/widgets.py", line 494, in _restyle
    get_manager().stylize(widget,style,**kwargs)
  File "../../engine/extensions/pychan/internal.py", line 132, in stylize
    setattr(widget,k,v)
  File "../../engine/extensions/pychan/widgets.py", line 587, in _setFont
    self.real_font = get_manager().getFont(font)
  File "../../engine/extensions/pychan/internal.py", line 94, in getFont
    return fonts.parseFontSpec(name)
AttributeError: 'module' object has no attribute 'parseFontSpec'

I looked this one up in TRAC but couldn't figure out which change stole this attribute ... (nor was I able to find parseFontSpec anywhere else ^^)

Do you know what happens here?

Edit: phoku fixed this one with rev 2722 by adding better exception handling. I forgot to load a fontdef while one of my widgets demanded an unknown font
« Last Edit: March 15, 2009, 01:42:28 pm by chewie »
Logged

chewie

  • Developer
  • Full Member
  • *
  • Posts: 123
    • View Profile
    • zero-projekt.net
Re: PyChan Feedback / Background tiling
« Reply #44 on: March 24, 2009, 07:48:45 pm »

Moin phoku :)

I've a request concerning the background tiling feature:

For now, it seems that all the tiling is done automaticly - so the background is painted until it's filled (both in x and y direction).

I decided to use tiling to expand 1px images to look like separator lines. While this works vor horizontal tiling, it does not for vertical tiling.

So, I looked into the _resetTiling() method and discovered that the outer loop is the x tiling - which controls therefore the y tiling. If you have an Icon with size="1,100", the tiling stops after creating one background icon, because the algo reaches x=1.

The question / request now is: Can we introduce a tiling policy here? Like vertical, horizontal and auto?

Cheers,
chewie

Pages: 1 2 [3] 4