Re: [pygame] Ocemp

[Phil Hassey <philhassey@xxxxxxxxx>]

I'm the author of pgu, and I think I'll weigh in here
as well...
 
Instead of quoting any, I'll just address a few of the
issues.  In general, I agree with everything Marcus
has said.

> OcempGUI or pgu

Adding either of these GUIs to pygame would roughly
double the size of the pygame API.  I've toyed with
the possibility of adding pgu to pygame for a while,
and after some considerable thought, I don't like the
idea of _any_ gui being a part of pygame for a few
reasons:

- Most pygame users don't need a GUI!

- Downloading one dependancy and including it with
your application isn't that tough.  (Whenever I
distribute a game that depends on pgu, I include pgu
as part of the game, so my users don't have to care
about it.)

- Not everyone agrees what a GUI should be (Marcus and
I actually have fairly similar GUIs API-wise, but at
the same time they still have some fairly fundamental
differences in approach.)

- pygame already includes "general purpose" GUI stuff.
 Between Surfaces, Sprites, and the Event system --
you've got all the basics already.  Beyond that is
speculation.  Especially for games -- a GUI is often a
per-game deal.

- If you are developing a serious non-game
application, you might want to consider using GTK / Qt
/ wxWidgets / Tcl.  They have all the features you
want.

> paraGUI?

Although it is a pretty extensive GUI, it would add
dependancy upon C++ and paragui to pygame.  (See above
objects for more. ;)

Anyway, both OcempGUI and pgu are pretty snappy, I
don't think having a C++ backend for the GUI would
really do anything to increase application speed.

In addition, pgu and OcempGUI are both "pythonic" in
nature.  Built in python, they have APIs that reflect
their "python-ness"

Anyway, just my 2c.  

Phil


		
__________________________________________ 
Yahoo! DSL ? Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com