Re: [pygame] PyGame user interface widgets
On Sat, 2017-03-04 at 04:34 -0500, David Burton wrote: > 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 It's unfortunate you didn't take another look at sgc, as looking at your demo program and the points you listed in the above response, you actually created a toolkit with a very similar design. In fact, I'd say from the points that you list as advantages of your toolkit, pretty much everything is true of sgc as well. In addition to that, I can add OpenGL support. Compare the hello world example: http://program.sambull.org/sgc/tutorial.get_started.html And my test demo that uses most features of the toolkit: http://bazaar.launchpad.net/~dreamsorcerer/simplegc/trunk/view/head:/example/test.py signature.asc Description: This is a digitally signed message part
Re: [pygame] PyGame user interface widgets
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 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
>
>
Re: [pygame] PyGame user interface widgets
I installed python_gui on my win10 64 python 2.7.13 and it works smoothly. On 28 February 2017 at 01:20, DiliupG wrote: > I haven't used it in conjunction with Pygame yet. I will try it and post > my findings. > > On 27 February 2017 at 18:47, Yann Thorimbert > wrote: > >> Hello Diliup, >> >> >> python_gui looks very nice indeed. Do you know if it is possible/easy to >> use it with pygame ? When I learn python and pygame, I had a lot of >> difficulties to find decent GUI library that can REALLY be used in pygame, >> not like Tkinter for instance. >> -- >> *De :* owner-pygame-us...@seul.org de la >> part de DiliupG >> *Envoyé :* lundi 27 février 2017 06:47 >> *À :* pygame-users@seul.org >> *Objet :* Re: [pygame] PyGame user interface widgets >> >> http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ >> >> above is good too. Unix, Mac, Win >> >> On 27 February 2017 at 03:35, Yann Thorimbert >> wrote: >> >>> "is there a way to hook into a custom event loop?" >>> >>> ==> Yes, here is an example where one uses a pre-existing pygame code >>> with an event loop, and then add some widgets while keeping the loop >>> exactly the same, except for one line added for handling events related to >>> the new thorpy widgets : http://thorpy.org/tutorials/include.html . >>> >>> >>> Thank you for the feedback on the other points. Here are some answers: >>> >>> >>> "*The application is only referenced when it's created and destroyed. >>> This magic is puzzling to me." >>> >>> ==> I'm not sure to understand how it is not a desirable feature. Should >>> we indicate to every new object to which application it belongs ? Instead, >>> since only 1 application is running at the same time, it seemed more >>> appropriate in my opinion to implicitely use it for each created widget. >>> >>> >>> "* The application class uses the standard __init__ method for instance >>> creation, but all of the widgets use a "make" method. Could the standard >>> method be used instead?" >>> ==> With the standard method, one is free to specify or modify anything >>> about the graphics or styling of the element before it is actually >>> generated and created in memory by calling finish() method. This was really >>> crucial for performances when creating elements on the fly in some >>> situations. However, when only default styling is needed, I created the >>> make() static method in order to allow the user to create simple objects >>> without needing the 2 calls __init__() + finish(). >>> >>> >>> "* The check box should probably be called CheckBox rather than Checker." >>> ==> You are right, I will create an alias for the next version. >>> >>> >>> >>> >>> >>> >>> -- >>> *De :* owner-pygame-us...@seul.org de la >>> part de Daniel Foerster >>> *Envoyé :* dimanche 26 février 2017 19:05 >>> *À :* pygame-users@seul.org >>> *Objet :* RE: [pygame] PyGame user interface widgets >>> >>> Nice set of widgets, however I think there are some things that could be >>> changed to increase its appeal, based on the example overview anyways. >>> >>> * The application is only referenced when it's created and destroyed. >>> This magic is puzzling to me. >>> * The application class uses the standard __init__ method for instance >>> creation, but all of the widgets use a "make" method. Could the standard >>> method be used instead? >>> * The check box should probably be called CheckBox rather than Checker. >>> >>> Looks like a nice set of functionalities though; is there a way to hook >>> into a custom event loop? >>> >>> — Daniel Foerster >>> >>> On Feb 26, 2017 11:47, "Yann Thorimbert" >>> wrote: >>> Hello Irv, I wrote (and now maintain) a library called ThorPy (www.thorpy.org) that could fulfill your requirements. On the website, I focused on the examples and turoials, so I hope it would be easier for a new person to use the library quickly. However, I have to admit that the library does not seem to be used by many people... Here is an overview of some of the widgets: http://thorpy.org/examples/overview.html Examples : http://thorpy.org/examples.html Tutorials : http://thorpy.org/tutorials.html Cheers, Yann De : owner-pygame-us...@seul.org de la part de Irv Kalb Envoyé : dimanche 26 février 2017 05:21 À : pygame-users@seul.org Objet : [pygame] PyGame user interface widgets 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 explaini
