FIFE forums

FIFE Development => Framework development => Topic started by: phoku on January 18, 2008, 02:16:31 pm

Title: PyChan Feedback
Post by: phoku on January 18, 2008, 02:16:31 pm
PyChan aims to be an extension to FIFE, which simplifies GUI creation (not necessarily for games) by introducing the following features:

But you can have a look at the demo client under clients/pychan_demo and especially
how totally and utterly the code and gui specs are decoupled.

You can edit the xml files - move around some VBoxes and see how the interface changes.


Think about what features you want (Tabs?)

So please go ahead, comment, cheer, complain and come up with suggestions!


Title: Re: PyChan Feedback
Post by: November on January 18, 2008, 04:04:02 pm
I was planning on writing a line or two about XML interfaces definition in the editor requests. So I guess this would be a very nice improvement. Mainly because interfaces can be considered as moddable content and therefore should be disjointed from the client and ruleset scripts. The result would be that "content-only" modders could use a ruleset and still change the interfaces without having to look into bunchs of python scripts.

In the long run, a basic interface (pre)viewer integrated to the editor could be really useful. It could be just a text/XML editor and a small window in which the interface is rendered.

I know this isn't fundamental at all, i'm just putting it in the "could be done if engine and editor are already fully functionnal and team doesn't know what to implement next" :)

Just my two cents :)
Title: Re: PyChan Feedback
Post by: jwt on January 18, 2008, 04:58:19 pm
Excellent progress with pychan.

Think about what features you want (Tabs?)

I've been telling people in the map editor thread that tabs are too difficult to create in guichan. Tabs would be awesome!

Actually, here's a thread full of gui wishlist items:

Seems like the biggest item in that topic is tabs. But there are some other features implied in those pictures that guichan doesn't quite support "out of the box".
Title: Re: PyChan Feedback
Post by: phoku on January 18, 2008, 05:11:34 pm
Currently the code aims at the FIFEdit coder :-) - so the extra bling that is necessary for game GUIs
will lack for some time, since a stable sane foundation is needed here.

But yes, if this gets adopted, then there's no block to have XML files for GUIs in games and
a preview feature shoudn't be difficult at all. Basically the demo application already provides that
functionality - you just have to edit the XML outside.

Tabs are basically buttons and a "StackWidget" which displays different contents depending on
a flag - so that should be possible to wrap rather easily.

The biggest problem to implement are now reactions to - for example a changing selection.
Or hovering over a widget notifies some callback. Basically everything that's not a basic WidgetAction...

Also drawing GuiChan can not be modified so easily... so the default look will not be that awesome ...

So I think it's TapWidget and IconBox on the wishlist?
Title: Re: PyChan Feedback
Post by: jwt on January 23, 2008, 02:18:08 pm
One more for the wishlist: real menus. :)
Title: Re: PyChan Feedback
Post by: phoku on January 25, 2008, 02:42:20 pm
Quirks and issues found by jwt:

Code: [Select]
[17:47] <jwt> phoku, does mapEvents override a previous mapEvents call? Or merge with it?
[17:47] <phoku> mergeing it
[17:47] <phoku> hm, that is definitely missing: unmapEvent
[17:47] <phoku> oh
[17:47] <phoku> wait
[17:47] <phoku> i think it does override
[17:48] <jwt> ok, doesn't really matter either way. But it should probably be added to the docs
[17:48] <phoku> yep =)
[17:48] <jwt> also, I think merge leads to nicer end-user code, if that wouldn't be too difficult to change
[17:49] <phoku> hm it merges different events
[17:49] <phoku> but overrides events/names which are same
[17:49] <jwt> oh, ok. So it does do what I want :)
[17:49] <phoku> though i am unsure whether the old event get's actually unmapped
[17:50] <phoku> i do think the old handler still gets called!
[17:50] <phoku> this behaviour will change.

Code: [Select]
[17:58] <jwt> any ideas ?
[18:00] <phoku> hm
[18:00] <phoku> try:
[18:00] <phoku> button = Button(...)
[18:00] <phoku> = key
[18:01] <jwt> ha, there we go!
[18:01] <phoku> hmmm.... the self.gui is already shown?
[18:02] <phoku> try leaving out the button,show()
[18:02] <phoku> but call gui.adaptLayout -
[18:02] <jwt> ok, will do
[18:03] <jwt> hey, it works! Now if I just had a way to pick which side of the Spacer to put the button on ;)
[18:04] <phoku> that won't work until refinements

Edit: I think both are fixed now.
Title: Re: PyChan Feedback
Post by: jwt on January 31, 2008, 12:08:01 pm
I've got a bug report for you.

In the pychan_test client, if I scroll to the bottom of the contributors list in the redzone style the client crashes with a segfault. Happy debugging :)
Title: Re: PyChan Feedback
Post by: phoku on February 02, 2008, 06:34:50 am
Fixed - or better - worked around. Was an obscure bug in freetype  ;)
Title: Re: PyChan Feedback
Post by: jwt on February 05, 2008, 09:19:34 am
Another bug.

Create a ListBox. Map an event to it. In the event function, hide the widget the listbox is part of (possibly this works just hiding the listbox itself). Clicking on the listbox will cause a crash, throwing a gcn::Exception.
Title: Re: PyChan Feedback
Post by: phoku on February 05, 2008, 09:41:41 am
You are really torturing pychan and guichan  these days ;D

Fixed by working around: (
Title: Re: PyChan Feedback
Post by: November on February 05, 2008, 03:50:01 pm
I've found out that the min_width attribute, after it has been parsed from a file, is of type 'str'.
This could be the case with others attributes (I tested only this one)

Correct me if I'm wrong, but I think it's a pretty important issue : shouldn't the parser make the conversion for numerical attributes ?
Title: Re: PyChan Feedback
Post by: phoku on February 05, 2008, 04:25:28 pm
Hi November jwt has already pointed me to the issue ... but it's a different one:

There IS no min_width attribute, just "min_size" ...
But currently the parser does not enforce using the correct attributes, this will be changed, but for now
if something behaves strange be sure to check you didn't misspell something or used an undocumented attribute.

Sorry for the inconvenience.
Title: Re: PyChan Feedback
Post by: November on February 05, 2008, 04:49:45 pm
I don't know why, I figured out that there was a min_width attribute... Sorry for pointing out a non-bug !
Title: Re: PyChan Feedback
Post by: phoku on February 05, 2008, 05:14:08 pm
No need to be sorry, thanks for pointing out that there should be one  8)
Title: Re: PyChan Feedback
Post by: mvBarracuda on February 06, 2008, 03:47:22 am
Just received a PM concerning pychan and a possible dialogue system approach by November. He did originally send the message to phoku but sent me a copy as well. My mailserver reported that the PM reminder couldn't get delivered to phoku via mail.

Therefore I post November's PM in here so the others can comment on it. I hope I don't upset anyone by posting this specific personal message in here. These kind of discussions should be posted on the forums IMO so that every developer can comment on them.

Here is a whole diff containing what I worked on the two last days, attached to the ticket :

I've had a hard time dealing with creating proper pychan interface for the dialog system, and it still has a lot of bugs, the principal being in the display of the multiline widgets I implemented in the core.
Since you (phoku) have a better view of how pychan works it should be easier for you to wrap them correctly, because the way I did it is very "primitive" since I didn't fully apprehend the whole funtionning of pychan.
If you think there may be an issue in the core part of the displaying, it's probably located in the drawString function of GuiFont.

Other display bugs are :
- Speech lines aren't always displayed in the same order. Ultimately they should always be displayed in the order in which they are declared in the node definition.
- Speech lines that aren't used again for the following node get their height set to 0, but they still are visible as a border under the other speech lines.
- Other minor visual defaults

On the other side, the dialog system itself and the logic seems to works fine. I think it's pretty easy to mod, as the dialog logic files just require to fill the functions with ruleset/dialog related conditions to line display/node picking and consequences of line picking/node showing.

Last but not least, keep in mind that I'm a coding beginner : I choosed the design that seemed the most coherent to me, but it may be the opposite huhu.
But in the other hand, If you think FIFE can retire anything from this draft of dialogue system, it would be great.

I'll be away from the computer for two weeks, so, see you when I come back (if you haven't too much work).

PS : It could have been documented, but I didn't have the time, and I must leave tommorow morning, so, sorry. I would have liked to deliver a non buggy system before leaving my computer but well... Pychan stayed to hermetic to me.
Title: Re: PyChan Feedback
Post by: November on February 06, 2008, 03:57:40 am
Small message before I leave to catch my train :

You're right, I've nothing against it being posted here, it's just that as I was unsure of the interest of it I just sent it to the potential "checkers" who could determine it.
Title: Re: PyChan Feedback
Post by: phoku on February 06, 2008, 08:08:22 am
 :o  :o  :o huge diff!

From a first look it looks good and coherent :)

Well, sorry for your pychan problems, I'll try to figure out, what went wrong.

And thanks barra - i have no problem with posting this PM.

Title: Re: PyChan Feedback
Post by: November on February 06, 2008, 01:10:04 pm
The hugness is partly due to the uncleverness of my TortoiseSVN : it delete and add again a lot of lines that haven't changed for a slightest bit. Sometimes, entire files get deleted and added again whereas only a few lines have changed.
Title: Re: PyChan Feedback
Post by: yakslem on February 07, 2008, 03:17:29 pm
First of all, a tabbed area is included in the SVN version of Guichan and will end up in the upcoming 0.8.0 release.

Now, about the filled issue,, I've added a comment. So please read it.

I know you prefer to talk about this bug on this forum, however, I'm not entirely comfortable with that idea as other people involved with Guichan might benefit from the information about this possible bug. So I would appreciate if future communication could take place in our issue tracker as it's connected to our development mailing list making every developer notified about changes.

Finally I just want to say that the Guichan python bindings sure are interesting. I've actually been thinking about making Python bindings of my own, but never gotten around to it.

/ Olof - Guichan developer
Title: Re: PyChan Feedback
Post by: phoku on February 07, 2008, 04:12:01 pm
Hi, I am very happy for the quick reply :-) Thank you.

As I said in the Issue tracker comment, I am sorry for
forwarding you to this forum and will use the guichan
issue tracker from now on.

See my comments there.


The python bindings I think are tied to the FIFEngine
although not that deeply, as we try to follow guichans
development. As far as I can see now, they are rather
plain SWIG wrappers.

The python wrapper of the API - PyChan - is less tied to FIFE ATM.
and should be portable to any SWIG wrapped Guichan API.

You are very welcome to have a look at the code, ask questions or whatever.

- phoku
Title: Re: PyChan Feedback
Post by: chewie on February 11, 2008, 03:24:12 am
Finally, I played around with pychan, too. First of all - I'm impressed how quick & easy a gui is build with FIFE now - good work phoku :)

By working with pychan, I encountered some problems. Some of them are already solved, thanks to phokus quick reaction. :)

Here are some additional issues (I'll update it when I've found more ^^):


And as pictures say more than 1000 words, here are some examples what pychan can do for you :)

(  (
(  (

Title: Re: PyChan Feedback
Post by: phoku on February 11, 2008, 05:39:40 am
Wow, that's what I allways loved about FIFE.

Once you get something useful working, people (i.e. chewie) will take it and create something amazing from it :) . Thanks!

It also means one has to live with bug reports, though ^^

ClickLabel and Labels in general will go through a rework, that finally ClickLabel will be renamed to Label (it was a funny distinction anyway) and be able to handle multiline text with optional text-wrapping.

This is also important for November, as I ditched the idea of incorporating your patch as a whole, but will concentrate on supplying the basic Gui functionality you need and later help with using pychan.

I think this should be okay for you? Multiline Labels and text wrapping are sure needs that other Gui users have, too.

Regarding that, I hope I will be able to get an interface to the text-wrapping so that the floating text can use that, too.

I have to admit that I don't even know whether the alpha value works, but I'll make sure that it will work. (Might take some time though.)

Other stuff: FIXED/INVALID

Questions to chewie:

Title: Re: PyChan Feedback
Post by: chewie on February 11, 2008, 05:59:59 am


Good idea with the labels - in fact most scenarios where you use labels may need a callback function later. (e. g. for tooltips etc...)

As we're talking about improved labels - is there a possibility to include hover effects? (switching colors should be enough - but every additional effect like borders, background color etc. would be interesting, too ^^)


Perhaps this feature isn't necessary at all - I only try to find a way to make the background of ScrollArea / Textbox / whatever invisible. Opaque 1/0 for all widgets should work, too. (ScrollArea doesn't have this function)

XML / Styles

I'm working mostly with XML, but ATM without styles. But as I love the power of CSS I'll make heavy use of styles later.

I use the direct API to "make things dynamic" - e. g. if I paint certain labels with a different font color (like in the audioplayer, to show the active track) or if we have to update multiple labels with new values. (character screen)

In short: Basic design XML, modification with direct API.
Title: Re: PyChan Feedback
Post by: November on February 11, 2008, 11:29:05 am
Concerning labels :
I have no problem with that, since you are the GUI coder and have much more coding experience than me.
By "functionality" I suppose you mean auto text split (to label width) since this is the only real functionality my patch added. As long as you plan to implement it, I'm fine.

If you have the time to rework my gui dialog so it fits with the new features you will add to pychan it would be great. If you don't have the time I'll just do it myself when I come back in one week and a half.

Anyway, long live to pychan.

PS : Your first attempts at using pychan for your interfaces show great results, chewie.
Title: Re: PyChan Feedback
Post by: Sadr on February 13, 2008, 06:40:17 pm
Wow, those pictures look stunning! We definately gotta make sure to have some impressive interfaces to show off with in the techdemo.
Title: Re: PyChan Feedback
Post by: November on February 22, 2008, 11:40:17 am
I have two requests to make :

-Possibility to hide child widgets and not just the top container of a hierarchy : I presently need it for a browsing interface for my dialogue editor, to expand/shrink "folders", like in any explorer interface.
-Possibility to delete widgets : would be really useful for dynamic interfaces such as inventory or dialogue

EDIT : I just found out about removeChild(). I assume a removed child is totally deleted. So it only resolve my second request, but not the first one.
Title: Re: PyChan Feedback
Post by: phoku on February 23, 2008, 10:04:36 am
Heya November :)

You should be able to use removeChild in this case as well.
You'll have to call adaptLayout after removal, so that the layout

Enabling the hide()/show() methods would need some work
on the layouting code which is hard to get right. SO this won't
happen until i spend some serious time on it.

I hope you can cope with the technique layed out above.

A removed child widget is not deleted at all, this should be
handled by python garbage collection.

Title: Re: PyChan Feedback
Post by: November on March 03, 2008, 11:30:11 am
This code will cause pychan to draw the elements incorrectly :
Code: [Select]
<ImageButton up_image="path" down_image="path"/>
<Label text="Test"/>
And basically any HBox with an ImageButton in it : the ImageButton won't show, only the Label gets drawed

However if you try this code :
Code: [Select]
<ImageButton up_image="path" down_image="path"/>
<Label text="Test Label"/>
The ImageButton is drawed, but the button width is the width of the Label, whereas it should be the width of the image.

Something else : by default, it could be good if the ImageButton hadn't a border around it.

Also, concerning Icon :
Code: [Select]
<Icon image="path"/>
<Label text="Test Label"/>
Try this code : the Icon image width is set to the Label width, whereas I think it should stay to the width of the Icon. Maybe by just setting the max_size of the Icon/ImageButton automatically ?

In the case of the Icon widget, HBox layout seem to work correctly. Just the annoying border.

Also same remarks about borders : I don't think Icon should have a border by default.
Title: Re: PyChan Feedback
Post by: November on March 03, 2008, 05:31:22 pm
Another "issue" I found :
The resizing function of a HBox (resp. VBox) automatically set the height (resp. width) of any contained widget to the max height of its child widgets.

I'm not sure this behavior is really useful, but more importantly : it causes display bugs.

This happened to me : take a HBox that contain, an Icon and a VBox :
1) The Icon's height is set to the VBox height when the HBox resizing function is called. This should not happen, first because it cause strange visual appearance (an Icon's height isn't supposed to change dynamically), second because of the following :
2) When the HBox resizing function is called a second time (suppose the VBox content has changed), the VBox height is flawed : after being set to the correct height it should have based on its content, its height is then set to the Icon's height, which itself is flawed. The result is the two having a too important height coming from nowhere.

A solution would be to set the Icon max_size, but this would just be a "hack" : the fact is I hardly get the point of this automatic height/width expanding.
Title: Re: PyChan Feedback
Post by: phoku on March 04, 2008, 04:40:12 am
Hi November,

I'll address your issues hopefully this week or weekend.
I guess the first fix will be to have an Icon
set it's size fixed to the image you set.

For the other stuff I'll have to set up a test case.
Please keep in mind that the layouting code is
really simplistic for now :-|

Did you get any further with the dialog system?

Title: Re: PyChan Feedback
Post by: November 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.

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/ in the attached diff if you are interested.

The diff is attached to this thicket
Title: Re: PyChan Feedback
Post by: phoku 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 :-/

Title: Re: PyChan Feedback
Post by: Sadr 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
Title: Re: PyChan Feedback
Post by: mvBarracuda 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:

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.
Title: Re: PyChan Feedback
Post by: phoku 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:

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!

Title: Re: PyChan Feedback
Post by: mvBarracuda on April 09, 2008, 06:44:21 pm
Slightly related to pychan: a new version of guichan was recently released. The release announcement says:
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:

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:
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):
Title: Re: PyChan Feedback / Behaviour of V/HBoxes
Post by: chewie 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')
position = (0, y)
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?

Title: Re: PyChan Feedback
Post by: chewie 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
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.ammodisplay_container = self.guiwrapper.widgets.VBox(4)

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)
y = y + 1

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:

Title: Re: PyChan Feedback
Post by: phoku 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.


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

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.)

Title: Re: PyChan Feedback
Post by: chewie 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
Title: Re: PyChan Feedback
Post by: phoku on October 14, 2008, 02:03:23 pm
pychan_rework branch started.  8)

I can't help but advertise it:


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

Have fun.

Title: Re: PyChan Feedback
Post by: November 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 ?
Title: Re: PyChan Feedback
Post by: phoku 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 :-/

Title: Re: PyChan Feedback
Post by: chewie 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 "", line 247, in <module>
  File "", line 243, in main
    editor = Zedit()
  File "", line 180, in __init__
  File "../../engine/extensions/pychan/", line 495, in stylize
  File "../../engine/extensions/pychan/", line 738, in deepApply
  File "../../engine/extensions/pychan/", line 1682, in deepApply
    if self._content: self._content.deepApply(visitorFunc)
  File "../../engine/extensions/pychan/", line 534, in deepApply
  File "../../engine/extensions/pychan/", line 494, in _restyle
  File "../../engine/extensions/pychan/", line 132, in stylize
  File "../../engine/extensions/pychan/", line 587, in _setFont
    self.real_font = get_manager().getFont(font)
  File "../../engine/extensions/pychan/", 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
Title: Re: PyChan Feedback / Background tiling
Post by: chewie 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?


Title: Re: PyChan Feedback
Post by: phoku on March 25, 2009, 10:53:26 am
i'm not sure your issue is related to the x=1 issue.
the tiling is only updated when the widget is shown (atm)
so you might need to call _resetTiling explicitly.

if that doesn't help, can you post the code in question (or point me
to it if it's somewhere in e.g. zero svn)