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 <yann.thorimb...@unige.ch> 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 <owner-pygame-us...@seul.org> de la > part de Daniel Foerster <pydsig...@gmail.com> > *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" <yann.thorimb...@unige.ch> 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 <owner-pygame-us...@seul.org> de la >> part de Irv Kalb <i...@furrypants.com> >> 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 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 >> >> -- Kalasuri Diliup Gabadamudalige https://dahamgatalu.wordpress.com/ http://soft.diliupg.com/ http://www.diliupg.com ********************************************************************************************** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **********************************************************************************************
