Hi Irv,
Back in 2012 I went down that same path, and found & evaluated the same
PyGame GUI toolkits that you found. Like you, I was disappointed with all
of them. I ended up writing one of my own, which I called DavesGUI. I
reported the results of that process here:
http://gamedev.stackexchange.com/a/44385/23295
In DavesGUI, the GUI elements ("widgets") are subclassed from regular
PyGame sprites. But, like all the toolkits you found, it is incomplete. It
needs some additional widgets which I never got around to buidling (especially
file browse/open & browse/save combobox dialogs).
Dave
---------- Begin forwarded message ----------
From: David Burton
Subject: Re: DavesGui
To: ...
...I've been meaning to get some documentation and tidier demos put
together for this thing, but it still hasn't happened. But here's what I
have:
http://www.burtonsys.com/download/DavesGUI.zip
There are a lot of comments in the source code, and the "demo" starts at
line number 2730.
Prerequisites are Python 3.1 or later, or Python 2.6 or 2.7, and pygame.
To demo it, just unzip the files into a folder, and run DavesGUI.py
Then drag things around, click them, etc.
(DavesGUIdemo1.py also runs, but it's an older & weaker demo; I just
included it so that you can see an example of the "import" statements.)
A design goal was to make it easily "drop in" to existing pygame games,
using the existing games' existing event loops. GUI elements ("widgets")
are subclassed from regular pygame sprites, and user actions generate
regular pygame events.
A widget is a sprite that can receive pygame events via its notify()
method. Unlike simpler sprites, some widgets can generate pygame events
representing things like button or menu clicks, entered text, etc.
Also, widgets can contain WidgetGroups of other widgets (as .children).
I didn't really finish it, but I implemented simple and 3D buttons,
checkboxes, vertical menus, single-line text-entry boxes, modal and
non-modal message boxes, vertical and horizontal scroll bars, and forms.
Forms can contain other widgets, including other forms, and they can be
nested to arbitrary depth. Overlapping widgets are handled properly, as are
dragging and resizing.
As a favor to me, if you try it out or use it for anything, please take
notes: a log of your frustrations, and what the documentation SHOULD HAVE
told you, and what the code SHOULD HAVE done. As you accumulate such notes,
please send them to me periodically.
Best regards,
Dave
---------- End forwarded message ----------
On Sat, Feb 25, 2017 at 11:21 PM, Irv Kalb <i...@furrypants.com> wrote:
> I teach Python programming at two different universities. At one of my
> schools, there is enough time for students to do a final project. I give
> them a background in event-driven programming, give them an overview in
> PyGame, and encourage them to build a small PyGame based project.
>
> I have just petitioned for and gotten approval to teach a new course on
> Object Oriented Programing. In that course, I will again use Python and
> focus on explaining OOP concepts using PyGame. (I'm really looking forward
> to this.)
>
> However, in order to make things easy for my students, I would like to
> supply them with a library (module) of easy to use user interface widgets.
> For example, a simple button, text display box, text input box, checkbox,
> etc. I started by giving out Al Sweigart's PygButton code to my students,
> and that worked great. Then some students asked for a text display box,
> then a text input box. I wound up building those myself. Along the way, I
> wrote additions to Al's PygButton code (for example, adding a disabled
> state).
>
> My question is: Is there any "standard" user interface widget library that
> many PyGame developers use?
>
> I have done quite a bit of research on this topic, and have found a few
> libraries of widgets like what I'm looking for. I've found:
>
> - pgu
> - pqGUI
> - sgc
> - Albow
> - gooeypy
>
> These all seem to attempt to solve the same problem (of creating a set of
> user interface widgets), but they all have different approaches. Some seem
> to take over the basic event loop. And most don't seem to be current - I
> haven't found any that have comments after around 2012.
>
> So ... is there one on this list, or one that I haven't found, that seems
> current and is simple to use? Or maybe, I'll just keep expanding my own.
>
> Thanks,
>
> Irv
>
>
