Tkinter or wxpython?

[Paul Rubin]

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

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

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

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

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

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

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

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

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

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

I'm not saying file browsing is never needed, just that from
experimental observation, it's quite often not needed.

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.