[pygame] Re: GSoC Proposal: Basic gui system

2009-03-24 Thread Jug
If you all think, a lot of people would use a built-in gui but it's
not worth the work, is there a chance to put one of the existing guis
into pygame? We could poll the users on the website and/or the mailing
list about the best pygame gui. Then maybe have a look on the best 2
or 3, discuss some pros and cons and include one into pygame? Because
as I said before, one big problem of all of the existing guis is that
they are at least one more dependency. In addition, new users don't
have to test all guis and find the best but can have a look at
pygame.gui and invest more time to understand it. I'm really tired
from reading up on guis (used 2 and began to read about Albow). A
pygame.gui module would get much more support (bug fixes, new ideas/
widgets, etc.) than now, too.

Regards,
Jug


Re: [pygame] Re: GSoC Proposal: Basic gui system

2009-03-24 Thread RB[0]
I don't think incorporating an existing gui into pygame would work.
Whatever it is you decide to do - it will need to be close enough to pygame
to be worth it (ie, integrated into event loop and such, to make it easy for
new users), abstract enough to allow extendability into a wide range of
needs, and powerful enough to look good and scale to full size applications.
From my experience, none of the current pgame guis come close to having all
those attributes.
Either they are so abstract that the user has to do almost everything, they
are too powerful to easily extend, or they are just funky in their usage.

But that is yet another decision.
How will events be handled? WIll they be returned like pygame events, or
handled with callbacks? Or both and confuse people/be un-pythonic?
How will it be rendered? Will it simply be an object you send the screen to
at the end of each loop and render then update the screen?
Will it use dirty rects to make the gui fast, or not, so you can use flip?
How many/what widgets do you want to include?
You pointed out how you would take the best 2 or 3 - well that is it, there
is so much variance, and no gui I have seen that would be abstract enough to
be useable for this claims to be everything you might/will need.
I think most likely you would have a ton of different people chiming in, and
in the end you might get 2 or 3 highest rated, but none would get a majority
and it would probably fall apart before it even started...

I agree with Sky, it is simple to write basic widgets, but once you get into
more advanced stuff it takes time, and lots of it, there are just so many
things to do. It isn't particulartly hard, but time consuming, and difficult
to do right. I think though updating the pygame wiki with some of the
newer gui's, with a good comparison would probably work better - but if you
do take one and make it work, more pwoer to you, and I am sure a lot of
people will be grateful...

Good luck :)

On Tue, Mar 24, 2009 at 3:11 PM, Jug j...@fantasymail.de wrote:

 If you all think, a lot of people would use a built-in gui but it's
 not worth the work, is there a chance to put one of the existing guis
 into pygame? We could poll the users on the website and/or the mailing
 list about the best pygame gui. Then maybe have a look on the best 2
 or 3, discuss some pros and cons and include one into pygame? Because
 as I said before, one big problem of all of the existing guis is that
 they are at least one more dependency. In addition, new users don't
 have to test all guis and find the best but can have a look at
 pygame.gui and invest more time to understand it. I'm really tired
 from reading up on guis (used 2 and began to read about Albow). A
 pygame.gui module would get much more support (bug fixes, new ideas/
 widgets, etc.) than now, too.

 Regards,
 Jug



[pygame] Re: GSoC Proposal: Basic gui system

2009-03-21 Thread Jug
On 21 Mrz., 16:48, 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 :-).

Then it should be a GSoC task to search for it. Surely the existing
GUIs
(or some of them) are not completely useless, but some are not
supported/developed
any longer, some are in an pre-alpha stadium, some work fine but have
defects in their concept so that extending/writing own widgets is very
difficult.

 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.

If there were a pygame.gui module, it would be developed faster,
programmers could help with posting new widgets they made and
bugs and ideas could be handled faster.

If you think it's too much work, call a vote, take the best pygame
gui,
put it into pygame and start helping to develop and improve it. But I
think most of the work will be to think about an easy but powerful
concept for a game gui. The implementing part should be less work
and less difficult.

Regards
Jug