GUIs - A Modest Proposal
in [Python]
|
From: Adam Tauno Williams on 7 Jun 2010 06:18 On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote: > On 06/07/10 12:18, Adam Tauno Williams wrote: > > On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote: > >> On 06/07/10 10:48, Adam Tauno Williams wrote: > >>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote: > >>>> On Jun 7, 10:55 am, ant <shi...(a)uklinux.net> wrote: > >>>>> My concern is simple: I think that Python is doomed to remain a minor > >>>>> language unless we crack this problem. > >>>> I'm curious why you think fragmented GUI choices is a particular > >>>> problem for Python compared to other languages? Or why this is the > >>>> main issue holding Python back? > >>> The base assumption is: there is some core issue holding Python back? > >>> Nah. > >> Any thought about drag-and-drop GUI builder in IDLE? > > Sure; someone should write one, or several. That isn't a toolkit issue. > Sure it is, if it's concerning ease of writing a GUI-based program using > that particular toolkit. Yes, because the IDE (toolchain) is lacking. Which isn't about the underlying toolkit - both Qt and Gtk provide the ability to load a UI from an XML file. Then the IDE needs to understand relating GUI events to signal handlers in the code. AFAIK, that doesn't exist for Python. However the underlying functionality *does* exist, and work, and has for some time. I can assign a method to an event in Glade - but it is still entirely up to the programmer to create a method with the same name and the correct signature in the correct class - which is entirely automated in Java / .NET IDEs. That is a big deal as applications become larger and more sophisticated, it removes an enormous amount of tedium. <http://www.pygtk.org/articles/pygtk-glade-gui/Creating_a_GUI_using_PyGTK_and_Glade.htm> NOTE: Glade is obsolete, GtkBuilder is the replacement, but I can't find anything on GtkBuilder + Python. > > 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. > 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. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Simon Hibbs on 7 Jun 2010 06:25 On 6 June, 23:55, ant <shi...(a)uklinux.net> wrote: >If we are to make progress, I can see two obvious approaches: >1) Improve Tkinter to the point where it is supportable and supported >by a good fraction of Python programmers >or >2) Drop Tkinter as the default and use something else. IIRC Guido has ruled out officialy adopting a full-bore GUI toolkit such as WxPython or PyQT, or even a supercharged verison of Tkinter, into the standard library. There are two main reasons. One is that doing so would more than double the standard Python distribution's disk footprint, to no advantage for non-graphical target systems or developers wanting to use native GUI APIs. Another is that it wouldn't make any of the other options go away, so e.g. if PyQT were chosen, anyone wanting to use WxPython would have to install it as well, creating even more bloat. GUI toolkits are major projects with their own development cycles and roadmaps that may not match with that of the standard library. They are also still rapidly evolving. The standard library should only contain stable, mature code bases. Furthermore the core Python dev team have limited resources. Increasing the officialy maintained code base by 2x or more just isn't supportable. Tkinter is perfectly adequate for basic GUIs. If you want something more sophisticated there are plently of high quality, well documented alternatives to match your platform or functionality requirements. Simon Hibbs
From: Ben Finney on 7 Jun 2010 08:52 ant <shimbo(a)uklinux.net> writes: > 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'. In that case, you have rather a misconception about how these things progress. The PtB in Python won't be saying anything normative on the matter unless there is an established code base to inspect, preferably with an established user base of that code. There's not a lot of point in pronouncing either way on vapourware. If you claim it would be a useful thing to have, let's see the tangible demonstration of that claim in the form of Python libraries. -- \ “The most common way people give up their power is by thinking | `\ they don't have any.” —Alice Walker | _o__) | Ben Finney
From: Steven D'Aprano on 7 Jun 2010 09:50 On Mon, 07 Jun 2010 03:08:19 -0700, ant wrote: > 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'. You have the process backwards there. The Python-Dev team isn't going to push one GUI toolkit as the One True Toolkit unless the wider community standardises on it first. Consider the plight of the Python developers. They're an all-volunteer effort, and although a handful of them are partially funded by the PSF or other companies like Google, they're still chronically undermanned and overworked. Just go and look at the bug tracker and see how many bugs languish for want of somebody to work on them. The last thing they're going to do is take on a project of the magnitude of creating a new GUI toolkit. A full-featured toolkit is a project at least as big as the rest of Python plus the standard library, and probably bigger. You're asking them to double their work load to suit your aesthetic judgement that none of the existing toolkits are good enough. [...] > Third: "I'm curious why you think fragmented GUI choices is a particular > problem for Python compared to other languages? Or why this is the main > issue holding Python back? " > It's not a particular problem for Python compared to other languages. > It's a general problem for all programming languages. I don't see why you think so. Well, Apple believes so, and twenty years ago I agreed with them, but having looked at how Macintosh and it's consistent look-and-feel has repeatedly failed to set the world alight against Windows and its multitude of inconsistent GUIs, I'm no longer convinced by Steve Jobs' argument. It's 2010 and despite all of Apple's marketing, design excellence and consumer mindshare, their share of the PC market is still about the same as it was in the mid-80s and well under their peak of 12% in 1993. (Depending on who is doing the reporting and how they calculate the numbers, Apple Macintosh has anything from 3% to 8% market share, not that much better than Linux at 1-2%. And the Linux figure is for sales, not installations). It seems to me that a consistent, best-of-breed look-and-feel is good for creating a brand, but flexibility and choice is good for capturing a market. Consistency carries it's own dangers, and what you call "fragmentation" simply means that GUI toolkits exist in a free market of ideas rather than a centrally-planned monopoly. For idiots^W those who like Gnome, there is PyGTK; for those who prefer their window manager to be perpetually in pre-beta, there is PyKDE; if you like QT, there is PyQt; if you have no aesthetic sense at all, there is tkinter; if you have a hankering for the Good Old Days programming in Hypercard on a Mac SE, there is Pythoncard; if you've drunk the corporate Koolaid, there are Jython and IronPython with their own GUI widgets; if you want the choice of developing for the desktop or the web, you might choose Pyjamas; and so on. There is, hopefully, a GUI toolkit for everyone, and no best-of-breed because people will never agree on what best-of-breed would mean. You call this fragmentation -- I call it freedom of choice. -- Steven
From: Mark Lawrence on 7 Jun 2010 10:53
On 06/06/2010 22:11, rantingrick wrote: > On Jun 6, 2:06 pm, Mark Lawrence<breamore...(a)yahoo.co.uk> wrote: >> On 06/06/2010 16:31, rantingrick wrote: >> >> >> >>> On Jun 5, 9:22 pm, ant<shi...(a)uklinux.net> wrote: >> >>>> 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 >> >>> Yes i one hundred percent agree! The only problem is i am the only >>> one! Good luck finding others to climb into this boat. From the >>> beginning there has has been this really weird love-hate relationship >>> with Tkinter in the Python community. I myself experience this >>> emotional attachment every day as i wish for Tkinter to be more >>> "pretty" and "feature-rich" whilst at the same time loving it's >>> simplicity. Tkinter seems to be Python's whipping boy and nobody wants >>> to whip another, so we are stuck in limbo with a lobotomy. >> >>> Heres an idea though, why not expand Tkinter with some new really cool >>> widgets...? Hmmm...? That TIX package is a real PITA and could use a >>> re-write. Can you believe it took until py3.0 for Tkinter to get a >>> combobox :-O! Yea i know! :'-( >> >> Patches are welcome at any time. I look forward to seeing your first >> contribution. >> >> Kindest regards. >> >> Mark Lawrence. > > Hello Mark, > > Are you maintaining Tkinter or Tix or both? There is a nagging issue > with Tix that needs fixing. Upon subbclassing some widgets and when > using the import Tix and import Tix as *. Maybe it is already fixed in > 3.0 (i have not checked) but we need to fix it. > > I am still currently rewriting Tkinter Tix and IDLE in my spare time > but got a bit busy lately. Anyhoo, i would really like to bring some > patches, upgrades, and just a general spit shining to the entire three- > plexx so let me know. I don't maintain either, I'm looking forward to seeing you do it. Regards. Mark Lawrence. |