GUIs - A Modest Proposal
in [Python]
|
From: Steven D'Aprano on 8 Jun 2010 06:38 On Mon, 07 Jun 2010 20:07:29 -0700, rantingrick wrote: > However as i have mentioned before there will NEVER be a crowd of us > marching in the streets behind one GUI. People are just too busy to get > involved. This has to be an executive decision. The powers that be must > make the change themselves or it will never happen -- i can guarantee > that! And if this change is made python will be better off in the end. > You have my vote for change but unless someone with more influence steps > up then our laments will be but in vain. > > psst, hey Guido, it's time to make your triumphant comeback to c.l.p. We > are waiting... Hmmm... there's something terribly familiar about this style of speech... rantingrick, did you used to post under the name "r" using an gmail account starting with "rt8"? -- Steven
From: Martin P. Hellwig on 8 Jun 2010 08:31 On 06/08/10 07:59, rantingrick wrote: > On Jun 8, 1:39 am, "Martin P. Hellwig"<martin.hell...(a)dcuktec.org> > wrote: >> On 06/06/10 03:22, ant 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. >> >> Yeah I have the same problem with washing machines, I usually end up in >> one setting that works for me. But then again if Apple would make a >> washing mashing with only one button that says 'wash' everybody would be >> upset again because their favourite fabric does not have a special >> setting and users would be confused whether to put in washing powder >> before of after they have pushed the button. > > And thats exactly not what the argument is about here. Including any > GUI in any language that satisfies everyone's personal tastes is > impossible. We are not trying to please X,Y,and Z. Nor or we are > secretly scheming to win "GUI Builder of the year awards. > > Should ANY GUI be included in Python's stdlib, well probably not. > However, if you DO include a GUI it should at least be the "lightest- > weight-up-to-date-save-the-download-rate" GUI it can be! Well that is tkinter than, it is reasonably lightweight and disliked for different reasons by everyone equally. -- mph
From: Kevin Walzer on 8 Jun 2010 09:55 On 6/8/10 1:16 AM, rantingrick wrote: > On Jun 7, 11:51 pm, alex23<wuwe...(a)gmail.com> wrote: > > <snip> > > Of course i was just being theatrical alex, i hope your last post was > in the same manner. However your right about everything you said > except your accusations that i am not willing to help bring this into > reality -- i just need to find the right base... and i may have just > found it in PyGUI!! > > http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ > > My first impression of PyGUI is very good because it looks promising, > and of course has a native look and feel. Just grazing over the docs i > was very impressed. Greg has outlined some simple and clear goals > which are exactly what Python needs in a GUI. He has the vision and > quite a bit a code already written. Heck he even has an OpenGL hashed > already. From what i can see so far the API very Pythonic. I think > it's love at first sight really. I encourage others to take a look at > PyGUI and see what they think. Judge for yourself. > I have no opinion on the merits of PyGUI itself, but after taking a quick look at the site and the docs, it seems to be an abstraction API over three different, platform-specific GUI toolkits--PyObjC (Mac), PyGtk (X11) and Windows (pywin32). That means that, whatever its other virtues, it certainly is *not* a lightweight GUI toolkit that could easily be incorporated into the Python core library--it instead has rather complex dependencies on both other GUI toolkits and Python wrappers of those toolkits. (A wrapper of a wrapper of a wrapper....) In my view, any original, Python-native implementation of a GUI toolkit that is small enough to be included in the standard library will wind up looking much like Tk. Tk implements its own API on each of the major platforms, interfacing directly with the platform primitives at a low level (Xlib, Carbon or Cocoa, and win32); it uses native widgets if they map to its API and implements its own widgets in other cases. Because it sticks to a limited widget set, it's able to to be small. Since Tk already provides a basic GUI toolset, and Python can interface with it more directly than it can with other toolkits (PyGui -> PyGtk -> Gtk -> Xlib), it's not clear to me what is gained by starting from scratch here. (Is it the presence of the Tcl interpreter? I know Tcl is not to everyone's taste, but it is an amazing language...) --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
From: Adam Tauno Williams on 8 Jun 2010 10:20 On Tue, 2010-06-08 at 09:55 -0400, Kevin Walzer wrote: > Since Tk already provides a basic GUI toolset, and Python can interface > with it more directly than it can with other toolkits (PyGui -> PyGtk -> > Gtk -> Xlib), "Python can interface with it more directly" This statement is devoid of meaning. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Grant Edwards on 8 Jun 2010 10:52
On 2010-06-08, Kevin Walzer <kw(a)codebykevin.com> wrote: > Since Tk already provides a basic GUI toolset, and Python can interface > with it more directly than it can with other toolkits >(PyGui -> PyGtk -> Gtk -> Xlib), Compare that to this: TkInter -> Tcl -> Tk -> Xlib > it's not clear to me what is gained by starting from scratch here. > (Is it the presence of the Tcl interpreter? I know Tcl is not to > everyone's taste, but it is an amazing language...) It's not clear to me that Tk is any more "direct" than any of the other options. -- Grant Edwards grant.b.edwards Yow! Are we laid back yet? at gmail.com |