Tkinter or wxpython?

[Bryan Hepworth]

Chris Mellon wrote:
> On 06 Aug 2007 09:44:15 -0700, Paul Rubin
> <"http://phr.cx"@nospam.invalid> wrote:
>   
>> "Chris Mellon" <arkanes at gmail.com> writes:
>>     
>>>> Might or might not matter for the application, especially considering
>>>> that tkinter is part of the discussion.
>>>>         
>>> The point is that you have no option with the browser - even Tkinter
>>> has platform theming support now.
>>>       
>> Hmm, I don't know anything about that.  I'm taking the view that for a
>> lot of apps, the requirement is to just put some functionality on the
>> screen, with slick visual appearance having little value or even
>> negative value.
>>
>>     
>
> Define "functionality". From the rest of your posts, that seems to be
> limited to "press buttons" and "type small amounts of non-formatted
> text" on the interaction side and "display small amounts of simply
> formatted text" on the output side. I'm not denying that you can get
> by with this functionality in a large number of cases, but it's
> certainly not optimal in general. If it were, we'd all still be using
> VT100 terminals.
>
>   
>>> ...Gmail uses ajax instead of a page load when you start
>>> typing a reply,
>>>       
>> I see, the answer to what caused your problem is approximately "ajax
>> is evil", or alternatively, the gmail app attempts slickness with a
>> tool that doesn't support slickness that well.  OK, I can accept that
>> using browsers for slick interfaces has its problems, but the answer
>> (a lot of the time, not always) is to just decide you don't need
>> slickness.
>>
>>     
>
> What you're calling "slickness" is what other people call "usable".
> Obviously it could be done without the ajax, but you lose features and
> usability. It's slower, because it takes a full page load, and I lose
> the context of the discussion.
>
>   
>>>> File i/o and file system browsing are available from javascript if the
>>>> user grants permission.
>>>>         
>>> Which they won't (I don't even know how, from Firefox), so you can't
>>> rely on it working.
>>>       
>> The application javascript pops a dialog asking for permission and the
>> user clicks yes or no.  If you can get them to install a desktop app
>> (gah!!) then you can certainly get them to click yes in a browser.
>> The permission mechanism is admittedly browser dependent.
>>
>>     
>
> My out of the box firefox install simply denies the operation and
> raises a javascript error.
>
>   
>>> But not of anything else. I've often wanted to drag & drop a file onto
>>> the file upload box in gmail, for example.
>>>       
>> Well, ok, that's a slick feature that your app might need.  None of
>> mine have needed it so far.
>>
>>     
>>> How about something as simple as context menus?
>>>       
>> Unnecessary slickness for many apps.  I've never needed it.
>>
>>     
>
> How have you decided that you've never needed it? Have you ever worked
> with a UI designer or workflow expert? Or have you just never bothered
> to implement it and you never heard anything from your users? How
> closely have you worked with the users of your applications?
>
>   
>>>> Multiple windows are evil most of the time,
>>>>         
>>> Multiple windows are the common case on the mac. They're not rare on
>>> other platforms as well. The fact that your windows are constrained to
>>> the browser and can't be torn off is a large limitation. No toolbars,
>>> no palettes, no modal dialogs (except on IE, or if  you constrain them
>>> to the browser). Lots of unnecessary chrome on your extra windows, too
>>> (see below).
>>>       
>> You can get rid of the chrome with javascript, but the extra windows
>> are still usually evil and unnecessary.  Just because they get used a
>> lot doesn't change that.  A heck of a lot of deployed interfaces, web
>> or desktop, simply suck.
>>
>>     
>
> As phishing attacks become more common, browsing are restricting the
> ability to remove or modify chrome. Again, a good feature for a
> browser, not so much for an application platform.
>
>   
>>>>> More platforms to develop on and test with.
>>>>>           
>>>> Compared to a desktop app?  I don't think so.
>>>>         
>>> Did you ever try counting? X browsers * Y browser versions * Z
>>> platforms. There are javascript and CSS bugs and differences between
>>> all of these.
>>>       
>> If you can tell them to install a desktop app, you can alternatively
>> tell them what browser to use.  For example we use a complicated
>> firefox-only browser app where I work, that relies heavily on canvas
>> objects.  But if you write your application with straightforward html
>> you tend to have very few platform problems.
>>
>>     
>
> It depends on your target audience and deployment arena. The context
> is cross platform applications, so at least 2 browsers and at least 2
> platforms are required. Don't forget browser versioning, too - IE 5 is
> different than IE 6 is different than IE 7. Even "straightforward"
> HTML has non-trivial cross browser differences.
>
>   
>>> From my own professional experience, it's not any easier
>>> to account for browser differences than it is for platform
>>> differences. It's getting better as more people jump on the web
>>> bandwagon and CSS and JS abstraction libraries show up,
>>>       
>> I guess I see that stuff as mostly-evil and prefer straightforward
>> html.
>>
>>     
>
> You simply can't do much of anything beyond display text and basic
> crud with straightforward HTML without stying. If that is the sole
> limit of your UI needs, then bully for you but that's hardly the
> common case and I'd venture that you don't have the experience to
> support the rather sweeping claim you made.
>
>   
>>> I'm not talking about chrome and slickness. I'm talking about basic
>>> usability concerns like "will this work with a higher font size" and
>>> "will it reflow in a sensible way if I change the window size". The
>>> CSS box model works okay for text, it's not so good for widgets.
>>>       
>> I just haven't had this problem with HTML interfaces.  I've never even
>> used CSS, though that makes me a bit of a lamer.  An interface that
>> needs to fill the whole screen with widgets is probably too
>> complicated.
>>
>>     
>
> An application is not a book. Of course you fill the whole "screen"
> with widgets - your application is defined by the widgets that it has,
> and the amount of space those widgets take up is your screen space.
>
>   
>>> More than a few web apps end up writing their own layout engines in
>>> dynamic javascript. This is sad. While I'm talking about chrome, add
>>> "wasted screenspace due to browser chrome" to a limitation of web
>>> apps, again unless you write your own browser host. This is another
>>> example of a feature that makes a good browser (don't let arbitrary
>>> web pages mess with my web browser functionality) clashing with the
>>> desires of a good application (don't waste screen space with
>>> irrelevant functionality).
>>>       
>> I guess the term I'd use to describe all these effects is "slick" and
>> a heck of a lot of the time it's just not needed.  Anyway you can pop
>> a chromeless browser window with a simple javascript call.
>>
>>     
>>> Man, you should be in PR with the way you spin things. You can't
>>> implement anything except the most trivial of applications using only
>>> the simple, familiar web elements like HTML forms. Anything more
>>> complicated than that needs to be done with DHTML and probably AJAX,
>>> and those UI elements don't look anything like the familiar ones. You
>>> go in one breath from saying that you can implement dialogs in HTML to
>>> saying that the rich client is the *less* familiar of the interfaces?
>>>       
>> I don't see the contradiction--with HTML you have just a few widgets
>> that everyone understands and you get an interface that's almost
>> always self-explanatory.  Yes you could call those interfaces trivial,
>> but the little secret that I'm trying to convey is that very often,
>> trivial is all that's needed.
>>
>>     
>
> That's simply not true, and I don't think you can objectively justify
> it. Besides, you specifically claimed HTML dialogs as being a
> replacement for "real" ones, and that can't be done using trivial
> interfaces. It requires DHTML, sometimes ajax, and/or browser support.
>
>   
>>> If you'd said "if you're making something really simple that has
>>> limited rich UI or data entry needs, consider a web application
>>> instead" I wouldn't have posted. A web application is something you
>>> make because the deployment and access benefits outweigh the UI and
>>> integration limitations, not as your default "go to" whenever you
>>> create an application.
>>>       
>> Well, I could back off to somewhere between the two.  Like, "ask
>> yourself whether your application really needs a rich gui or complex
>> data entry features.  If you can get by with a simple HTML interface,
>> and a lot of the time you can, you'll probably have an easier time
>> doing it that way and that should be the default".
>>
>>     
>
> I would challenge the assumption that, starting from zero, it is less
> complicated to write a web application, much less a "pretend" web app
> using a local web server, than a desktop application using Tkinter
> (ick) or wxPython or pyQt. I would also challenge the assumption that
> 'a lot of the time' you can get away with a simple HTML interface, at
> least by my personal definition of 'get away with'. I've worked a lot
> with data entry people, where the actual requirements in terms of
> slickness and flash are quite small. But "basic html" simply does not
> fit the bill. There is a real cost in terms of how fast and how
> accurately they can enter data in this environment.
>
> Moreover, if you *don't* need global access or zero-deployment
> (zero-deployment is always nice but most environments where you can
> reasonably force a specific browser and version also have IT
> infrastructure), then you should ask yourself if forcing your
> application in the web app model (I haven't even touched on the whole
> stateless HTTP being mapped to a stateful environment issue, or the
> need to manage the local web server) actually buys you anything. I
> simply do not buy the claim that HTML interfaces are necessarily
> simpler in any but the most trivial of cases, and even in those
> super-trivial applications there are often hidden concerns that don't
> filter up to management.
>
>   
>>> I'd like an example you have of a desktop application that could have
>>> just as easily been a web application. Bonus points if it's not a CRUD
>>> screen, and double bonus if you don't just handwave away things like
>>> file browsing. Although there are benefits even for the crud screen -
>>> I've written screens and applications for data entry professionals and
>>> they almost always prefer the speed optimizations you can make in a
>>> client application.
>>>       
>> I guess I've written 4 or 5 nontrivial desktop gui apps and ZERO of
>> them had file browsing.  One of them did need access to the pc's
>> serial port, which means there had to be application code on the
>> desktop, but the gui could have been a browser (talking to an
>> application-embedded http server) if browsers were available in those
>> days.  Another one of them saved some state to a local file but it did
>> that without file browsing, and could have instead saved the state on
>> a remote server if it were written as a remote app.
>>
>>     
>
> Exactly how much time do you think using an HTML interface with an
> embedded server would have saved you, especially considering the
> careful care you have to take with access to the serial port? For the
> record, I've written over a dozen client applications, many of which I
> would consider trivial (but used features that would be expensive or
> impossible to implement in the browser) and probably twice that many
> web apps.
>
>   
>> I'm not saying file browsing is never needed, just that from
>> experimental observation, it's quite often not needed.
>>
>>     
>
> Plural of anecdote and all that. Make a survey of every application
> that you interact with and see how many of them need to interact with
> arbitrary files from the filesystem.
>
>   
>> Again, it all depends on what you're trying to do.  For data entry
>> stuff you probably want the data on a remote server anyway, and you
>> can do basic CRUD validation with fairly simple javascript.  Maybe
>> that departs from pure HTML but it's nothing like the ajax/dhtml
>> madness that causes the problems you've described.
>> --
>>     
>
> CRUD with javascript is something I actually have a lot of experience
> with. Deficiencies in the data entry UI have real consequences because
> you get invalid data and slow data entry speeds. The auto-completing
> combo-box, for example, is simply impossible in a browser without
> quite complicated (and slow) DHTML and is a huge boon for data entry.
>
> I'm not trying to claim that there are no benefits to web
> applications. But I often see people touting the web as a *superior
> application platform*, which is simply false, and as innately simpler
> to develop for, which is also false.
>   
I'm also in a similar predicament starting to look at Python for the 
first time.

I'd be curious to know peoples take on other GUI's like pygtk and pyqt 
for example to get a fuller picture. As a total newbie the list seems 
daunting so taking advantage of other peoples experiences seems like a 
good idea.

Bryan