All of these kits were easily integrated into my own main loop, not requiring use of their own. Each of them also allowed me to set up my own display in pygame.display and plug it into the GUI. None of them are documented to my satisfaction. ;(
Starting with the least:
Mike Leonhard’s GUI is one of two that implements a scrolling widget, but otherwise only implements a text entry widget and a button. It does handle wrapped text in labels. The biggest knock on this kit is that it overrides the keyboard repeat, and getting the keystroke entry to work is troublesome. The kit has not been maintained in two years, and Mike has moved on to other things, based on his web site.
Poutine, by Shandy Brown, separates itself from the others in that it is sprite-based. The widgets are sprites, located and drawn in the same fashion as other sprites in the game. The event loop does need to handle the various input events separately, rather than handing them off en-mass to a GUI event handler; each widget-sprite handles its own inputs. The range of widgets provided is very limited, including only buttons and text input.
The PGU GUI, part of Phil’s pyGame Utilities, is a fairly comprehensive kit, providing most of the features my sample wanted. It does not provide a scrolling widget, but it does provide fairly sophisticated text rendering functions, including the ability to display html. It also includes a menu system (unique among these GUIs), dialogue boxes, and a ‘toolbox’ feature which selects between multiple options. This GUI is the most attractive of the set, also. Some features are not completely implemented, such as the ability to disable widgets.
The Ocemp GUI is the most feature rich of the GUIs I reviewed. The only features my sample wanted that it did not provide were image maps and multi-line edit, and none of the other kits provided those either. It provides a scrolling widget. The documentation provided in the code is as good as any, and the author is promising a usage guide document. The most serious limitation I found is the drab grey blocky appearance, and that may be a matter of my not understanding how to manipulate the styles.
I have had opportunity to correspond with both Marcus von Appen (Ocemp) and Phil Hassey (PGU) in doing these evaluations, and found each of these gentlemen to be helpful and interested in furthering use of their libraries.
For more detail on each of the four GUIs and source code for the sample pages, see my prior posts. If you are evaluating GUIs for a Pygame game, please do install the Ocemp and PGU libraries, and download/copy and run my sample scripts for each, to see for yourself how they behave.
If you are reading this on the blogs native page (on iuplog.com), links to each of the libraries is found in the right side bar. Otherwise, Googling will find them.
David
13 June 2007 at 12:02 pm
Posted By: James Jeffers (28/10/2005 11:55:39 AM)
Comment: Fantastic! Given these recommendations, I think I will try both of the mentioned frameworks. I want to say thanks for spending the time to try them out. Are you going to coninue to comment on their use as your project develops?
Response:
13 June 2007 at 12:07 pm
[…] Wed 24 May 2006 Pygame GUIs Posted by dkeeney under python Now that my Pygame GUI comparison is AFAIK complete, and because this comparison accounts for a significant amount of incoming traffic, I am providing a consolidated index to all of the blog posts here on the Pitchers Duel blog regarding this GUI evaluation. The original comparison scope with Photoshop-drawn interface image . The GUI comparison Summary […]
1 February 2008 at 1:14 am
Here is another,not completed but cool GUI
Gooey http://joey101.net/gooeypy/
4 January 2011 at 3:48 pm
Ocemp and GooePy seem to be dead.
PGU is under new management, and actively supported, but only for Python 2.5 to 2.7, not for Python 3.
16 January 2011 at 10:01 pm
These are the pygame GUI toolkits that I’ve tried to get running under Python 3. (I succeeded, mostly, with all except GooeyPy.)
I ran each of them through a simple Lines-Of-Code counter
http://code.activestate.com/recipes/527746-line-of-code-counter/
to gauge their sizes:
These are the results:
Albow code min=2810, max=4551 (max = 162% of min)
Albow\demo min= 453, max= 649
GooeyPy\gooeypy min=2034, max=3941 (max = 194% of min)
GooeyPy\examples min= 178, max= 351
pgu\pgu min=2910, max=7047 (max = 242% of min)
incl. pgu\pgu\gui min=1678, max=4638 (max = 276% of min)
pgu\examples min= 822, max=2527
pqGUI.py min=1586, max=1834 (max = 116% of min)
Example.py min= 178, max= 225
sgc (incomplete) min= 889, max=1243 (max = 140% of min)
sizes of various pygame GUI toolkits
In each case, the “min” number is more representative of the “size” of the toolkit, since it doesn’t count whitespace and comments.
When the “max” number is very close to the min number, it means that there’s not much whitespace and not many comments in the code. pqGUI exemplifies that, because it has almost no comments at all, which is too bad, because (IMO) it makes the nicest-looking widgets.
Dave
12 August 2011 at 12:05 am
I’ve been rather detached from the pygame domain for a while, and hadn’t noticed your post.
But thank you for posting the update. We do get a fair number of google in-bounds even now, after years, and those folks may appreciate it.
David
28 January 2014 at 2:47 pm
In 2012, because of my dissatisfaction with the GUI toolkits that I found, I created a GUI toolkit of my own for PyGame. It is widget-based, and uses pygame events for communication, so that it can easily be dropped into an existing pygame program, without taking over the event loop. It supports forms, buttons, windows, modal & non-modal message boxes & dialog boxes, vertical menus, text-entry boxes, and sliders (scroll bars). It smoothly handles overlapping controls, and forms-within forms.
However, it’s not really complete: it lacks some controls you’re likely to want, like file-open dialogs and tables. The controls that do exist look nice, but features like title-bars & scroll bars are fixed numbers of pixels in width, rather than resizeable. The code is well-commented, and there’s a demo app with usage examples, but there’s no proper how-to-use documentation. And it’s pre-beta, so everything is subject to change.
If, in spite of those limitations, someone wants to try it out, then contact me by email. Ask about “DavesGUI.” My email address is here: http://www.burtonsys.com/email/
Another option might be a project called Stellar, byEmilio Coppola, whichg was announced here:
http://www.pygame.org/project-Stellar+-+Pygame+GUI-2293-3901.html
I haven’t tried it, though.