GUIs - A Modest Proposal
in [Python]
|
From: Mark Lawrence on 10 Jun 2010 18:46 On 10/06/2010 23:24, Stephen Hansen wrote: [snip] > P.S. Considering I almost never use tkinter, I'm confused how I somehow > suddenly became a Champion of Tkinter Inclusiveness. FWIW I've never used any GUI in Python. I'd see your involvement on this thread as being more like a Champion of Common Sense. This appears to be sadly lacking from some other participants. Kindest regards. Mark Lawrence.
From: geremy condra on 10 Jun 2010 18:54 On Thu, Jun 10, 2010 at 3:24 PM, Stephen Hansen <me+list/python(a)ixokai.io> wrote: > On 6/10/10 3:17 PM, geremy condra wrote: >> I mostly agree with you, but as Stephen points out you can't exactly >> count on it being present now either, which more or less renders any >> guarantee of backwards compatibility moot IMO. Whats the practical >> difference between telling somebody that either tkinter works out of >> the box or they'll have to satisfy an extra dependency and just telling >> them that they'll have to satisfy an additional dependency in the first >> place? > > Although that is true in theory, in reality-- In my experience-- You > *can* count on it being there, except on Linux distributions which may > choose to cut it out into an optional install, and where its also > extremely trivial to add back in. Sure, and that's why I said I mostly agree. Having said that, it seems important to me to place the arguments against projects like pygui in the context of the the arguments for tkinter. The fact is that tkinter is not ubiquitous, and will on some platforms require an additional dependency, forcing those who aim for portability to take that into account. This is exactly the same situation in which pygui finds itself, with the exception that applications developed with pygui look professional, while those made in tkinter generally look like refugees from the Isle of Misfit UIs, although I'm told this has improved markedly in recent years. Geremy Condra
From: rantingrick on 10 Jun 2010 18:57 On Jun 10, 5:17 pm, geremy condra <debat...(a)gmail.com> wrote: > Whats the practical > difference between telling somebody that either tkinter works out of > the box or they'll have to satisfy an extra dependency and just telling > them that they'll have to satisfy an additional dependency in the first > place? BIG +1 It seems that removing Tkinter from the stdlib will not only benefit Python, but also Tkinter; due to the fact that Tkinter will not be confined to Python's release schedules. As we've witnessed so far almost nothing has changed since Tkinter's addition many years ago. Heck they only just recently (py30) added a ComboBox widget! This development cycle is not working for Tkinter, something must change. Tkinter is just a dead weight we're lugging around for no good reason. - lib-tk 755KB - idlelib 1.18MB - Tcl 6.57MB (+togl 51.2KB) All that footprint with such a small capability! There must be a better option out there!
From: geremy condra on 10 Jun 2010 19:07 On Thu, Jun 10, 2010 at 3:57 PM, rantingrick <rantingrick(a)gmail.com> wrote: > On Jun 10, 5:17 pm, geremy condra <debat...(a)gmail.com> wrote: > >> Whats the practical >> difference between telling somebody that either tkinter works out of >> the box or they'll have to satisfy an extra dependency and just telling >> them that they'll have to satisfy an additional dependency in the first >> place? > > BIG +1 Please don't agree with me, its almost enough to convince me I'm wrong. > It seems that removing Tkinter from the stdlib will not only benefit > Python, but also Tkinter; due to the fact that Tkinter will not be > confined to Python's release schedules. As we've witnessed so far > almost nothing has changed since Tkinter's addition many years ago. > Heck they only just recently (py30) added a ComboBox widget! This > development cycle is not working for Tkinter, something must change. > Tkinter is just a dead weight we're lugging around for no good > reason. Did you actually read what I wrote? I said nothing at all about removing tkinter and in fact oppose doing so. Geremy Condra
From: Kevin Walzer on 10 Jun 2010 19:10
On 6/10/10 5:20 PM, rantingrick wrote: > But with Tkinter there is a larger problem, > TclTk! Even Tk is not a full featured GUI library, much is to be > desired. What's your basis for saying this? I've used Tk in nearly a dozen small-to-large applications on the Mac, both in Python and Tcl, and I often compare it to PyQt and wxWidgets, as well as Cocoa, and I think it comes up short in only a few areas: 1. Printing. Tk lacks a single API for printing documents across platforms. Its canvas widget can generate PostScript, and under Unix and OS X it is easy enough to send PostScript and text to the printer via lpr, but that doesn't work on Windows--and the available printing extensions for Windows are very different in their implementation. In this regard, Tk lags behind Qt and wxWidgets, as well as Cocoa. 2. Support for parsing and displaying HTML across platforms. A couple of different Tk extensions provide support for basic HTML display, but Tk lacks a binding to a modern HTML engine like WebKit and Mozilla--something both Qt, wxWidgets and Cocoa have in one form or another, either as part of the core library or as an extension. Apart from this, Tk provides, either through its core or numerous extensions, pretty much everything you'd expect from a full-featured GUI toolkit--listboxes, buttons, entry fields, the canvas, trees, tables, plain-and-rich-text display, drag-and-drop, etc. Of course, because of its small core, you do have to install a lot of library extensions and search among various packages to find the right mix of widgets (there are, by my count, at least three major widgets for displaying trees, tables, and so on): if you want a single API to do these things then another toolkit might be better. I develop commercial desktop GUI applications for the Mac, which has the most discriminating user base of any of the major platforms in terms of UI polish and consistency, and I use Tk for my user interfaces--and I have some commercial success. I do not feel that Tk lacks anything essential, and where it has limitations, the toolkit is flexible enough to allow me to work around those limitations. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |