Are there any good, modern widget toolkits for Pygame? I've looked at PGU, but it's apparently unmaintained.
closed as not constructive by Sean Middleditch, bummzack, Trevor Powell, Byte56♦, Tetrad♦ Mar 21 '13 at 18:58
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
No. Every year someone makes a new Pygame UI library and then abandons it after a few versions, probably once they realize that writing button layouts is easy but writing a complete UI library is real work. The
I've added very basic GUI elements to my GameEngine library: http://aharrisbooks.net/pythonGame/ch10/ (Included in a book on game development in Python)
I built very simple GUI elements based on the standard sprite: a label, button, multi-line label, and mini-scroll-bar.
These tools are quite basic, but they are adequate for many uses. Of course, the library is completely open-source, so feel free to modify them if you wish. The one user interface element I didn't add (yet) was a text input widget. That's because the event model is much more complex for this than the other models, and I was running into a deadline.
Feel free to play with that (whether you use the book or not) and let me know if you run into any troubles. I'll try to help.
I've got videos of my course available at http://synapse.cs.iupui.edu/Mediasite/Catalog/
Look at the N451 course. That's the one on game development.
Back in January, 2011, I looked at five GUI toolkits for pygame, and tried to get all of them working with Python 3. The five were: Albow, GooeyPy, PGU, pqGUI, and sgc.
I didn't succeed with GooeyPy, but I did get the other four to work with Python 3. (I wanted to also try poutine, by Shandy Brown, but I couldn't find it, and I entirely overlooked Ocemp.)
PGU (Phil's Pygame Utilities) has been taken over and maintained by Peter Rogers, and Victor Kam converted most of it to Python 3. It was last updated January 2012, and is presumably improved since I examined it. (Note that the version of PGU at pygame.org is not the latest one.)
sgc was new and still very incomplete when I looked at it. However, it is being actively developed, and might be much improved, by now. (Note that the version of sgc at pygame.org is not the latest one.)
I ran each of the five through a simple Lines-Of-Code counter to gauge their sizes:
These were the results (in January, 2011):
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)
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 (and no docstrings, either), which is too bad, because (IMO) it made the nicest-looking GUI elements.
Major caveat: docstrings are not counted as comments! That makes PGU, sgc & GooeyPy, which have docstrings, look fatter and less well-documented than they really are, compared to Albow and pqGUI, which lack docstrings.
I liked pqGUI because I liked the look of the widgets it makes, but it is unsupported and undocumented, and I couldn't find the author.
Of the five, as of January 2011, PGU was the clear leader. But I was dissatisfied with all five, so I wrote my own. (Note: PGU & sgc have both been updated, and presumably improved, since I looked at them.)
Per Joe Wreschnig's wry observation (above), my GUI toolkit is incomplete, like all the others. But it does have a few things going for it.
However, it lacks some important controls you're likely to want, like file-open/combo-box 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 adjustable-width. The code is well-commented, and there's a demo app with usage examples, but there's no proper how-to-use documentation. Also, it's pre-beta, so everything is subject to change.
The line-of-code counter results for it are:
DavesGUI (w/ demo code) min=2267, max=3055 (max = 135% of min) (w/o demo code) min=2018, max=2644 (max = 131% of min) (w/ docstrings commented-out) min=1442, max=2644 (max = 183% of min)
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/
I have recently seen pygtk used with pygame and it works really well. Just ensure you use the expose event with the gtk drawing area widget and update pygame data on each pass through the gtk main loop. If you want a full fledged gui toolkit to work within pygame it wont happen, but if you want a full gui toolkit to use with pygame then your in luck, pygtk is it. You can even use gtk using the C programming language and still import pygame as a widget onto the drawing area and update pygame in python if that floats your boat and you want turbocharged speed. Why the fuss, just use google and find the answer then implement it, not hard and no biggy. By the way pygame is really cool. Those guys have put so much work into it, and it works so efficiently its amazing. Those pygame guys deserve kudos for the work and time put into making pygame into a super game development kit.