Tkinter or wxpython?

[Chris Mellon]

On 06 Aug 2007 08:20:20 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> "Chris Mellon" <arkanes at gmail.com> writes:
> > No native look and feel - constrained by the browser.
>
> 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.

> > No control over browser UI idioms. I had to write this post twice
> > because the text control lost focus and I hit backspace, going back in
> > the history and losing my work.
>
> Sounds weird, I'm used to having stuff in text boxes stay in the
> browser, and why did backspace have that effect anyway?
>

On Windows, backspace is a browser global hotkey that means "go back
once in the history". When the text box lost focus, hitting backspace
navigated back. Gmail uses ajax instead of a page load when you start
typing a reply, and the fragile tricks it uses to try to keep the
browser history and the ajax state in sync don't work in this case.
It's a specific example of the general problems of the browser as
application platform.

> > No native integration - no "open file", no "browse the filesystem", no
> > rich drag and drop, no copy/paste.
>
> 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. You can mitigate with your own browser host, or if
you write all your own file browsing in HTML and move it into your
local browser. Poor solutions all around.

> File system browsing for the limited purpose
> of file upload is available in regular html.
>Copy/paste of ordinary
> text is always available.

But not of anything else. I've often wanted to drag & drop a file onto
the file upload box in gmail, for example.

>However, this type of requirement is what I
> mean by a "good reason" to write a desktop gui.  It applies to some
> applications, not all.
>

How about something as simple as context menus? You can't reliably
override the browser context menu from a web page unless, again, you
provide your own browser host. This is a good thing, because a browser
needs to be wary of arbitrary malicious web pages. They aren't good
application hosts.

Keyboard shortcuts that happen to conflict with whatever the browser
or any of its plugins happen to use, too. Although I notice that
Firefox now allows web pages to override that, which is a little sad.

> > No or poor dialogs. Poor multiple window support.
>
> Might or might not matter depending on the application.  Most dialogs
> can be done with html.  Multiple windows are evil most of the time,
> and should instead by done with multiple panes or cells in a single
> window.
>

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).

> > 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. 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, but it's not
even good as the available platform abstraction libraries like
wxWidgets or Qt.

> > Limited to CSS box model for layout.
>
> Might or might not matter depending on the application.  If you're
> doing a consumer app that has to look slick, you have no choice but to
> use something like wxwidgets (tkinter won't cut it either).  If you're
> doing a special purpose office or industrial app, slickness isn't
> important.
>

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. 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).

> > The web is a terrible application platform. There is not a single web
> > application in existence which has even half the UI functionality of a
> > rich client application.
>
> Some of us consider simple interfaces with consistent, familiar
> (i.e. web) elements to be a good thing.  Fancy client interfaces are
> ok if you feel you need to make a style statement, but are often
> unnecessary if you just want to get something done.
>

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?

> > There are some (even many) applications for which the benefit of
> > global access and easy deployment makes up for the lack in
> > functionality, but statements like "At this point I think nobody
> > should write desktop gui apps without a good reason" are simply
> > ludicrously misguided.
>
> Well, I don't say that good reasons don't exist, I just see a lot of
> desktop apps that could be done just as well as web apps, i.e. for
> those, the good reason didn't exist.
> --

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.

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.