GUIs - A Modest Proposal
in [Python]
|
From: python on 7 Jun 2010 11:07 Ant, Have you checked out the Dabo framework? Dabo provides a set of tools and underlying framework that makes VB style GUI development possible using Python. Dabo is designed to be GUI framework independent however it currently only supports wxPython. Dabo has a very friendly and helpful mailing list if you want to give it a try. Dabo can be found here: http://dabodev.org Malcolm
From: Mark Lawrence on 7 Jun 2010 11:16 On 07/06/2010 04:31, Carl Banks wrote: > On Jun 5, 7:22 pm, ant<shi...(a)uklinux.net> wrote: >> I get the strong feeling that nobody is really happy with the state of >> Python GUIs. >> Tkinter is not widely liked, but is widely distributed. WxPython and >> PyGtk are both >> powerful, but quirky in different ways. PyQt is tied to one platform. >> And there are >> dozens more. >> >> Whether or not we like graphics programming, it's not going to go >> away. I get the >> uneasy feeling whenever I start a new project that there should be a >> 'better' GUI >> than the ones I currently use (WxPython and PyGtk). >> >> Fragmentation is our enemy. Our resources are being dissipated. Is it >> not time to >> start again? We have shown that it is possible to do the right thing, >> by creating Python3. >> >> I ask the group; should we try to create a new GUI for Python, with >> the following >> properties?: >> >> - Pythonic >> - The default GUI (so it replaces Tkinter) >> - It has the support of the majority of the Python community >> - Simple and obvious to use for simple things >> - Comprehensive, for complicated things >> - Cross-platform >> - Looks good (to be defined) >> - As small as possible in its default form >> >> If so, what are the next steps? >> >> The Python SIG on GUIs closed years ago. Should that be revived? >> >> This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting >> that >> we eat our own babies. >> >> But don't we owe it to the community? > > Speaking for myself, PySide has resolved this issue for me. I used > PyQt for some things but didn't want to use it for everything because > of the license, but I'd be ok to use PySide for anything. It's > portable to the major systems and generally better (IMHO) than the > other toolkits. > > > Carl Banks Carl, Thanks for mentioning PySide, if I'd ever heard about it I'd forgotten. To OP. See the following link as to why you've got so many comments:) http://www.symbian-freak.com/news/009/08/first_public_release_of_pyside_for_qt_and_maemo.htm Kindest regards. Mark Lawrence.
From: Carl Banks on 7 Jun 2010 11:36 On Jun 7, 3:08 am, ant <shi...(a)uklinux.net> wrote: > I rather feel like I'm flogging a dead horse here, but time for > another mile... > > First off, I'm not volunteering to lead this effort. I don't think > anyone should > even think about that until and unless the Python Powers That Be > actually > decide that it is worth doing. That is what I meant by 'strong > leadership'. > > Second; 'A minor programming language'. According to > > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html > > Visual Basic is more popular than Python. That makes me feel that > there > is something wrong with the world. Sloth and Envy are two of the seven deadly sins. Not really a healthy attitude. Carl Banks
From: Lie Ryan on 7 Jun 2010 12:19 On 06/07/10 20:18, Adam Tauno Williams wrote: > On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote: >> On 06/07/10 12:18, Adam Tauno Williams wrote: >>> But then I don't know any of the local Python devs who use IDLE; the >>> IDE landscape for Python is very fragmented, which disincentives that >>> happening. >> I don't use IDLE either, but IDLE comes by default with standard >> distribution of python. >>>>>> .NET/C# has had preferred GUI APIs come and go and isn't exactly what >>>>>> I'd call crossplatform, >>>>> Well, if you use Gtk# for your GUI it is probably one of the [if not >>>>> "the"] most cross-platform development solution for complex fat-clients. >>>>>> Looking at the state of other languages and their GUI toolkit >>>>>> landscape, someone might even come to the conclusion that having one >>>>>> true GUI toolkit is potentially a bad thing for a language. >>>>> +1 In the end the relationships with GUI toolkits is far more about >>>>> tool-chain and documentation then it is about language. If there was an >>>>> awesome IDE that allowed RAD [of real complex applications] in toolkit X >>>>> then people will use toolkit X. [Monodevelop and it's awesome Gtk# >>>>> support for Mono/.NET is a good example; the tool makes the toolkit >>>>> east to use - people go with the toolkit]. >>>> The problem with the current GUI toolkits is their API is designed to be >>>> cross-language (i18n). I'd say, keep the current GUI toolkits, make >>>> their API easier to use (l10n). >>> Which is 'just' an implementation detail. >> Why is a GUI toolkit *API* an *implementation detail*? > > You are missing the point. PyQt, PyGtk, etc.. are wrappers/bindings > around Qt, Gtk, etc... respectively. So it *is* an implementation > detail of the wrapper/binding to make the API 'pythonic'. Changing > class names, rewriting method signatures, adding glue - is a binding > issue. binding is part of the programmer-facing API, therefore it's not an implementation detail. >> They seems to be >> contradictory to me. The simplicity and ease of use of a library depends >> on how well-designed their API is, > > Yea. Which is an implementation detail. > >> and how "pythonic" the API appears to >> a python programmer (unittest, for example, looks more Java-ish than >> pythonic). > > So... improve the binding. That is a really silly reason to develop a > new toolkit. isn't that my whole point?
From: Terry Reedy on 7 Jun 2010 14:29
Ant I agree that the current tk situation is not completely satisfactory. In particular, the IO facilities are inadequate and have not, to my knowledge, changed in a decade. Image input formats are limited. There is no canvas output as an image. (Output of the canvase display list as a dialect of postscript that not everything can read is not a substitute for this.) However... I think it important that Python come with a minimal IDE that is adequate for someone like me doing Python-only development. I thank the programmers of IDLE. So merely deleting tk/tkinter is not an option. Indeed, having something similar to and at least as good as IDLE for any candidate gui replacememt should and I think would be a requirement for consideration. The problem with the big gui application frameworks are that they are too big. The two I have glanced at -- wx... and qt -- have much more than gui stuff and duplicate parts of the Python stdlib and other 3rd party libs. As for a small gui written in Python, you seem to have ignored the link to pygui. Of course that has its own problems. Among others: it is incomplete; it ignore Python 3 (requires 2.3+ should be 2.3 to 2.6), which is the only place it could be added; the api sytle is not standard in Python (get_xx and set_xx methods instead of direct access or properties); and there is nothing yet like IDLE. What would be required is a Python3 GUI project with multiple contributors. Terry Jan Reedy |