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 21298 times)

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
PyChan Feedback
« 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:

  • Create GUI from XML definitions.
  • Do NOT manually declare which button is located in which container!
  • Let a basic layout engine position the widgets for you!
  • Set and retrieve widget data without hassle!
  • Extensive documentation

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!

-phoku


« Last Edit: February 09, 2008, 11:02:03 am by phoku »
Logged

November

  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: PyChan Feedback
« Reply #1 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 :)
« Last Edit: January 18, 2008, 04:06:20 pm by November »
Logged

jwt

  • Developer
  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: PyChan Feedback
« Reply #2 on: January 18, 2008, 04:58:19 pm »

Excellent progress with pychan.

Quote
Think about what features you want (Tabs?)
  :o

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:
http://forums.fifengine.net/index.php?topic=13.0.

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".
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #3 on: January 18, 2008, 05:11:34 pm »

@November:
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.

@jwt:
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?
Logged

jwt

  • Developer
  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: PyChan Feedback
« Reply #4 on: January 23, 2008, 02:18:08 pm »

One more for the wishlist: real menus. :)
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #5 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 http://rafb.net/p/SFbYON74.html ?
[18:00] <phoku> hm
[18:00] <phoku> try:
[18:00] <phoku> button = Button(...)
[18:00] <phoku> button.name = 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.
« Last Edit: January 26, 2008, 01:11:05 pm by phoku »
Logged

jwt

  • Developer
  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: PyChan Feedback
« Reply #6 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 :)
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #7 on: February 02, 2008, 06:34:50 am »

Fixed - or better - worked around. Was an obscure bug in freetype  ;)
Logged

jwt

  • Developer
  • Newbie
  • *
  • Posts: 26
    • View Profile
Re: PyChan Feedback
« Reply #8 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.
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #9 on: February 05, 2008, 09:41:41 am »

You are really torturing pychan and guichan  these days ;D

EDIT:
Fixed by working around: http://code.google.com/p/guichan/issues/detail?id=24
« Last Edit: February 07, 2008, 04:26:48 am by phoku »
Logged

November

  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: PyChan Feedback
« Reply #10 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 ?
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #11 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.
-phoku
Logged

November

  • Developer
  • Newbie
  • *
  • Posts: 36
    • View Profile
Re: PyChan Feedback
« Reply #12 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 !
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: PyChan Feedback
« Reply #13 on: February 05, 2008, 05:14:08 pm »

No need to be sorry, thanks for pointing out that there should be one  8)
Logged

mvBarracuda

  • Administrator
  • Sr. Member
  • *
  • Posts: 411
    • View Profile
Re: PyChan Feedback
« Reply #14 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.

Quote
Here is a whole diff containing what I worked on the two last days, attached to the ticket :
http://mirror1.cvsdude.com/trac/fife/engine/ticket/277

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.
« Last Edit: February 06, 2008, 03:51:35 am by mvBarracuda »
Logged
Pages: [1] 2 3 4