Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any good, modern widget toolkits for Pygame? I've looked at PGU, but it's apparently unmaintained.

share|improve this question

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.

up vote 11 down vote accepted

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 gui tag on the Pygame site chronicles some of these.

share|improve this answer

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.)

Unfortunately, Albow and Ocemp seem pretty much dead. Albow was last updated in 2009, and Ocemp was last updated in 2008. (Note that the version of Albow at is not the latest one.)

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 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 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          min=1586, max=1834    (max = 116% of min)        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.

  • It works with Python 2.6, 2.7, 3.1, 3.2, & presumably 3.3.
  • It is sprite-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. Widgets are subclassed from pygame.sprite.Sprite.
  • It supports forms, buttons, check-boxes, modal & non-modal message boxes & dialog boxes, vertical menus, text-entry boxes, and sliders (scroll bars).
  • It smoothly handles overlapping controls/widgets, moving & resizing widgets, and forms within forms.

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:

share|improve this answer
Thanks, Laurent! – Dave Burton Nov 26 '12 at 22:27

I've added very basic GUI elements to my GameEngine library: (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

Look at the N451 course. That's the one on game development.

share|improve this answer
Really? "The one user interface element"? What about trees, lists, menu bars, sliders, progress bars, spinners, combo boxes, resizable windows, resizable panes, rich-text widgets, and tabs, just to name a few? Your library is no different than the half dozen other also-never-finished ones on – user744 Nov 21 '10 at 9:55
Wow. That was a touch angry, huh? That's the one user element that I want that I didn't add. I can build anything I want. I haven't built the other things because I don't need them. You're free to add your own tools to my framework (which is designed to be expandable), or build your own toolkit. If you want to support me to finish this project, I'm willing to talk about it. However, like most developers, I have to pay the bills, so the projects I can earn a living on get the highest priority. – Two pi Nov 21 '10 at 21:13
It's not angry. I'm just pointing out your project is no different than PyUI or PGU. It's an unmaintained API to lay out simple buttons. It's not a "good, modern widget toolkit". – user744 Nov 22 '10 at 11:07
I'm agreeing with you that the complete library doesn't exist (and I thought the others were too complex) I think the answer is for you to build the library you want rather than to dismiss the efforts of those who have freely given their work to the community. My library is admittedly tiny, because I didn't need anything else. I'd love it if you wanted to add the features you desire to this or any other library, because I agree a 'full-fledged' GUI library could be useful. However, games usually don't have the same needs as other GUI apps. – Two pi Nov 24 '10 at 16:37

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.

share|improve this answer

Google summer of code added a new GUI:

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.