[pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread Jug
Hi,

I would really like to have a pygame.gui module. Many/all pygame
programs need to have a user interface and often it's more than two
buttons. Thats always the same and why always reinvent the wheel?
There are some pygame guis but I neither like dependences nor I want
to redistribute external modules. In addition, I haven't yet found the
ultimate pygame gui (if there is one, include that).
So, I think it would be cool to have a well thought out, easy
extensible gui system within pygame including some basic elements like
button, label, entry, etc. and a kind of geometry manager.
Of course you can write that yourself every time you need it but (i
think) its not fun but only waste of time.

Regards
Jug


Re: [pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread Frozenball
On Sat, Mar 21, 2009 at 1:39 PM, Jug j...@fantasymail.de wrote:
 Hi,

 I would really like to have a pygame.gui module. Many/all pygame
 programs need to have a user interface and often it's more than two
 buttons. Thats always the same and why always reinvent the wheel?
 There are some pygame guis but I neither like dependences nor I want
 to redistribute external modules. In addition, I haven't yet found the
 ultimate pygame gui (if there is one, include that).
 So, I think it would be cool to have a well thought out, easy
 extensible gui system within pygame including some basic elements like
 button, label, entry, etc. and a kind of geometry manager.
 Of course you can write that yourself every time you need it but (i
 think) its not fun but only waste of time.

 Regards
 Jug


Yes, a good GUI module included by default sounds nice. I have used
Ocempgui but it was too slow for my purposes.


Re: [pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread Marcus von Appen
On, Sat Mar 21, 2009, Jug wrote:

 Hi,
 
 I would really like to have a pygame.gui module. Many/all pygame
 programs need to have a user interface and often it's more than two
 buttons. Thats always the same and why always reinvent the wheel?
 There are some pygame guis but I neither like dependences nor I want
 to redistribute external modules. In addition, I haven't yet found the
 ultimate pygame gui (if there is one, include that).

Which is why a GUI backend within pygame was never realised. There is no
ultimate design approach and having just a bunch of abstract base
classes for users to implement is not worth the work :-).

 So, I think it would be cool to have a well thought out, easy
 extensible gui system within pygame including some basic elements like
 button, label, entry, etc. and a kind of geometry manager.

If you can find some good reasons, why that system would be better,
easier and more extensible than all the solutions available, go
ahead. Be aware however, that this will probably cause a lot of
discussion about the pros and cons.

Regards
Marcus


pgppnuV8p77ZX.pgp
Description: PGP signature


Re: [pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread Ian Mallett
On Sat, Mar 21, 2009 at 8:48 AM, Marcus von Appen m...@sysfault.org wrote:

 Which is why a GUI backend within pygame was never realised. There is no
 ultimate design approach and having just a bunch of abstract base
 classes for users to implement is not worth the work :-).

I completely agree.  Arguably, making a GUI from scratch can be time
consuming, but GUI's tend to differ a lot.  For example, some games, such as
asteroids and other arcade games, need simple centered menus.   My new image
filtering program has a GUI that emphasizes linking windows and other
stuff.  It would be hard--in my view impossible--to generalize all the
possible needs down to a few classes and have it still be easier to use than
an improvised solution.
Ian


Re: [pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread RB[0]
Having written a few pygame guis, I agree with Marcus and Ian.
But, having said that, it would be possible to make a powerful enough gui
that is rather abstract, but still is useful, you just need to do it
correctly. A basic gui that fits in with the event system (to get, suppress,
and return), with app and widget classes that can handle every kind of
input/rendering would suffice for the extensibility.
Then you can add simple things like buttons/labels/etc.

I am sure a lot of people would use it - which may be reason enough to do
it. But personally I still don't think it will be worth it - simple widgets
are trivial to write...

Cheers

On Sat, Mar 21, 2009 at 4:08 PM, Ian Mallett geometr...@gmail.com wrote:

 On Sat, Mar 21, 2009 at 8:48 AM, Marcus von Appen m...@sysfault.orgwrote:

 Which is why a GUI backend within pygame was never realised. There is no
 ultimate design approach and having just a bunch of abstract base
 classes for users to implement is not worth the work :-).

 I completely agree.  Arguably, making a GUI from scratch can be time
 consuming, but GUI's tend to differ a lot.  For example, some games, such as
 asteroids and other arcade games, need simple centered menus.   My new image
 filtering program has a GUI that emphasizes linking windows and other
 stuff.  It would be hard--in my view impossible--to generalize all the
 possible needs down to a few classes and have it still be easier to use than
 an improvised solution.
 Ian



Re: [pygame] GSoC Proposal: Basic gui system

2009-03-21 Thread Greg Ewing

On, Sat Mar 21, 2009, Jug wrote:


So, I think it would be cool to have a well thought out, easy
extensible gui system within pygame including some basic elements like
button, label, entry, etc. and a kind of geometry manager.


You might like to take a look at Albow and see
whether it would meet any of your needs:

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/

--
Greg