FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  


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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - phoku

Pages: [1] 2
Framework development / [Roadmap] Update
« on: August 25, 2009, 06:20:38 am »

I took the liberty to move a few Trac tickets around.

2009.1 now contains those pesky compile/build problems we need to solve. I also added a ticket for the light branch - i think we should be able to merge that one in unless some showstoppers show up.

2009.2 now contains the tickets we agreed upon some time ago or which should get another review.

Deleted is now nearly empty, the last one being the rotation ticket. I have no idea about the state of that,
but after that is reviewed the milestone can be closed.

I think we should go with 2009.1 being the 0.3.0 FIFE release and 2009.2 being the 0.4 one.
But we can have a short chat on that coming meeting.


Framework development / [Light] Review
« on: August 25, 2009, 02:14:18 am »

I'll dump my review of the light branch here.

First impressions are - compiles, code looks clean, no problems in tests and rio de hola.
My only complain in that regard would be 'Too Many Classes in one File' - but personally
I'm fine with that.

  • LightRenderer.getgloballight/setgloballight need to be renamed.
  • I'm sure getgloballight doesn't work as intended.
  • setgloballight pushes a new Global Light info every time it's called. That's odd as it's a global (read one time) thing.
  • What's the rationale behind the grouping?
  • There seems to be a subtle interaction between the OpenGL renderbackend and the light renderer (e.g. the OpenGL state is assumed to be GL_LIGHTING is enabled and other stuff) - care to explain?
  • Needs more documentation :)
  • A demo of it's use is necessary - add that to rio de hola?

... so I think we can merge this - given that helios intends to
maintain it a bit more until it's use has trickled through and other devs
have a bit more knowledge.

All in all great work!


Framework development / [PyChan] Perfomance bottlenecks
« on: August 21, 2009, 02:51:29 am »
Good morning FIFE,

I browsed through IRC logs and noticed some performance complaints
about pychan. Since in the beginning only few widgets were used
this didn't show up. However the editor uses massive amounts of
widgets and I'll have to start to optimize.

I think the following parts are bottlenecks:
  • findChild
  • distributeData, distributeInitialData
  • event callbacks
  • adaptLayout

For adaptLoyut I knew that this would be slow, that's the reason you
have to call it explicitly once you change the widgets.

The events do some silly things (like creating a timer for each new event you capture)
which need a bit of work.

findChild mostly needs a fastpath for the common findChild(name="XYZ") case
and the distribute functions can be optimized.

Is there anything I forgot? What feels sluggish?


Framework development / Python (License) Header
« on: August 20, 2009, 03:59:35 pm »
I guess we need one.

Let's use this:


I'll paste that into the .py s in install_target/


General discussion / FIFE Version Scheme
« on: August 16, 2009, 06:10:31 am »
FIFE has accumulated enough changes to warrant a new release.
However this brought up the question of using a more standard
versioning scheme.

Discussion on next release.

I personally think we should start with 0.1.0 and go from there.
But that's another poll :-)



in our last meeting we discussed the need to
have a sane install target.

Dear packagers!

This is the place to add requirements and complaints for that.


Framework development / May Meeting
« on: April 05, 2009, 02:14:25 am »
Hi there,

please just vote for the dates which aren't good for you for some reason.
In case none of the above dates works for you, just discuss here in the thread.


Framework development / [FIFEdit] and [PyChan] - Widget phasing
« on: March 26, 2009, 07:02:02 am »
Hi there.

I have read the editor redesign and begin to like it more and more. In particular taking ideas from the way Qt is used (e.g. actions) and proposing new widgets for pychan make a lot of sense to me.


Pychan lacks in the pre-made widget department and that shows. On the other hand adding new widgets is always a bit of a problem as as soon something is in svn people will use it and then changes are difficult as avoiding api & layout breakage is a important (to me :)).

For that i propose that I'll split up into:
Code: [Select]
widgets/, etc.
   ext/ (etc.)

That done in a way that pychan.widgets still contains all widgets used to date, while pychan.widgets.ext contains
experimental widgets in development.



I think there's another feature that's needed. The current layout engine only ever shrinks widgets, which was nice for the start, but a 'greedy' layouting algorithm is really needed. The code for that already exists and should work after some adaption, but that will of course break existing layouts.

That's a bit harder. A compatibility switch can be added, but I think that would be too difficult to maintain.
So what do you think? Shall we branch pychan+layout+editor for some time?


Framework development / PyChan will get factored out.
« on: October 21, 2008, 02:58:03 am »
Hi there.  I hope I have your attention  8)

Here are my plans:

  • Drop the pychan_rework branch - the font handling code is way too complicated. Features that are standalone (like autoposition) will get backported.
  • Create a standalone version of PyChan and the corresponding Guichan wrappers. DONE
  • Create a svn repository and project page for the PyChan standalone.  STARTED
  • Make sure that PyChan standalone can be dropped in FIFE and continues to work as expected.
  • Port (or avoid if possible) FIFE modifications to the Guichan version packed with PyChan standalone. (unicode, twobutton, maybe console)
  • Remove the Guichan wrappers from FIFE and put them in ext/
  • Decouple the PyChan standalone release cycle from FIFE. (Meaning you can choose a compatible PyChan version.)

Here are my reasons:

  • I think PyChan is good enough to be presented to a larger community (for example pygame users).
  • Hopefully this will attract contributors to help maintainance (and finding and reporting bugs).
  • This will force decoupling of the GUI to the rest of FIFE.


  • While I will try to keep compatibility new contributors might not.
  • Extending PyChan is not that easy for FIFE developers.

You can get the current state here:
Code: [Select]
svn checkout
cd PyChan
cd ext
cd ..
python examples/

Okay, as allways: Comments, complains and cheers please!  ;)


Framework development / Font packs
« on: October 17, 2008, 03:38:54 am »
Here are fonts for testing Unicode support.

Unpack into clients/pychan_demo/fonts/

Contain font definition files for easy use.


EDIT: Font packs were deleted accidently.

Help and troubleshooting / Segfault in libselinux on (K)Ubuntu 8.04
« on: October 13, 2008, 09:35:19 am »
Hi there,

If you get a segfault after FIFE finishes - and you have Ubuntu 8.04, then it's not FIFE's problem.


Workaround for copy+paste:
Code: [Select]
sudo aptitude install libsepol1-dev python-all-dev python-all-dbg quilt
apt-get source libselinux1
cd libselinux-2.0.55
sudo DISABLE_SETRANS=y dpkg-buildpackage -rsudo -uc -b
cd ..
sudo dpkg -i libselinux1_2.0.55-0ubuntu4_i386.deb


Framework development / Better FIFE documentation
« on: October 13, 2008, 09:11:21 am »
Hi there,

I found this
and think that we could and should empower our epydoc documentation for
the fife module.

Any comments?


Framework development / input_rework merged!
« on: October 13, 2008, 07:21:40 am »
Hi there,

I've hijacked spq's input_rework branch. I have altered the approach
he intended to make - but I hope the design is clean enough.

Instead of redirecting events from the GUI top container to the
eventchannel, the guimanager now rejects SDL events if either
the mouse isn't above a widget or no widget has input focus.
If the GUI doesn't accept the event, it's distributed as before.
The widget events (including mouseEntered and such) are now
completely handled by the GUI and then PyChan. PyChan translates
GUIChan events to FIFE event classes by using translation functions
in the GUI manager - so that no duplicate event classes are visible.

Instead of giving a barebones list with setNonConsumableKeys
the users can now write a Key filter with any logic they want.
For transitions sake the setNonConsumableKeys function has
a compatibility version - in fife_compat.

The only thing that HAS to be changed are occurances of IWidgetListener
and such. Use PyChan's event system instead.

Speaking of that: PyChan now can capture mouseEntered events and so on.
Take a look at the pychan documentation of mapEvents/capture.

It's more complicated than that, but that's the basic behaviour.

As far as I can see it now delivers the behaviour for events as we need it.

Please check it out for your projects and comment on problems.


Framework development / [RFC] Font handling rework
« on: June 11, 2008, 06:55:00 am »
This has been on my agenda for quite some time,
but I'll start to present my ideas now.

Currently widgets have one and only one font set.
Since in our system a font doesn't include the different sizes
and variants (like bold, italic) it is not possible to have i.e.
a label with mixed bold/normal text.

To keep changes small and manageable I propose the following:

  • Implemenet a class FontSet offering the usuall Font interface
  • These FontSets have a default Font and use set under normal operation, thus they can be used as drop-in replacement of the TTF Fonts.
  • Internally the FontSet manages a map ID->Font which can be set to be the default font by some selectDefault method
  • The real interesting part is now, that the renderString method will now support TAGS for selecting another font. This can start as a very simple technique, and get really good later on.

Of course the datasets should have fontset.xml files and pychan will support both the .font attribute and .fontset.
Text bubbles will be using this new stuff, too, of course.


Framework development / Guichan Upgrade
« on: June 08, 2008, 08:13:49 am »
Hi Guys,

the guichan devs have released a new version (actually TWO)
of there library - Guichan 0.81.

We'll need to follow their development, but since broken
GUIs are allways a pain here's a peek preview how to
check the new and changed stuff.

The good news is, that PyChan didn't get any API
changes. That is all code should continue to work (or not work)
as it has before the upgrade.

The bad news is that some minor layouting issues will pop up.

In order to test this, do the following steps.

Have fun, phoku

EDIT: Fixed the attached patch to _not_ contain edits in the island_demos

Pages: [1] 2