Tkinter or wxpython?

[Paul Rubin]

"Chris Mellon" <arkanes at gmail.com> writes:
> 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.

OK, I can live with that, if you include displaying images on the
output side.

> I'm not denying that you can get
> by with this functionality in a large number of cases,

Precisely my point.

> but it's certainly not optimal in general. 
> If it were, we'd all still be using VT100 terminals.

Nah, HTML gui's are much easier to use than pure text interfaces,
because of the visual gui elements, pointing with the mouse, simple
control over fonts and color, etc.

> > > ...Gmail uses ajax instead of a page load 
> What you're calling "slickness" is what other people call "usable".

I notice google search doesn't use ajax (or didn't til recently) and
has satisfied an awful lot of users with simple html.

> My out of the box firefox install simply denies the operation and
> raises a javascript error.

Hmm, the user might have to change a setting in about:config but
that's certainly easier than installing a desktop application.  I
haven't done this with firefox.  In Communicator you'd just call
netscape.security.privilegemanager and ask for the permission that you
needed.

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

If the app has enough slickness requirements that the customer is
willing to pay for the attention of UI designers or workflow experts,
maybe it also needs context menus, I don't know.  Generally I'd say
there are several levels:

  1. In-house app that will have 1 to 10 users who run it now and
then.  Every minute of unnecessary development is wasting their money,
so they want the quickest and cheapest possible solution.  Web app is
very often an easier way to do this than desktop gui app, even if the
functionality is bare bones.  I've done several of these, either as
desktop apps or web apps, generally working closely with the user, and
nobody has said anything about context menus.  I think this case is
very common.  In some instances the sole user is me, so nobody else
has to be satisfied.

  2. Wide-use app that will have 1000's of users, including
non-in-house users who tend to distrust desktop installs.  Web app is
superior for deployment reasons even if you have to give up some ui
niceties.  This is what I do most of the time as a web developer.  I
tend to write simple html to implement functionality, then let a real
designer spiff it up to look slick on multiple browsers while I
concentrate on the backend programming.

  3. In-house app somewhere between 1 and 2, i.e. maybe there are
dozens or hundreds of users who will interact with the program all day
long.  Usability becomes more important, so this can go either way.
Maybe this is where you want to UI experts involved.  It sounds like
your CRUD apps are often in this category.  Not everybody's are.  Mine
haven't been so far.  If I were in this situation I'd consider both
the web and desktop approaches and could go either way depending on
the specific requirements.

  4. Shrink-wrap consumer app, zillions of units to ship, pizzazz
sells boxes, slickness is king.  You need a whiz-bang desktop gui done
by real artist/designers.  I'm just a coder, so my approach would be
write a slapdash tkinter or web gui to figure out the necessary
functionality in conjunction with UI specialists, then write a spec
based on the prototype and turn it over to the artistic gurus, with me
doing the backend stuff in cooperation with them.  I haven't so far
done anything like this even though I worked at a game company for a
while.  I think most of us can code our way through life without ever
doing it.

> As phishing attacks become more common, browsing are restricting the
> ability to remove or modify chrome.

I'm using firefox 2 and sites pop chromeless windows all the time, so
I'm not sure what browsers you're referring to.

> It depends on your target audience and deployment arena. The context
> is cross platform applications,

I don't see anything about cross platform in the OP's original post.
If cross platform were important I'd start asking whether the app
needed to be usable from mobile phones.  If yes, that weighs heavily
for browsers.

> 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 think it's a very common case, which is why so much stuff is being
done on the web instead of the desktop.

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

I guess I'm not sure what you mean about dialogs.  I would consider
some html input fields with a submit button to be a dialog.  Sometimes
a little client side JS can make things a bit nicer.  I guess that
technically counts as DHTML but if you keep it simple, you can avoid
most cross-browser issues.

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

Well, not everybody needs to enter data all day long.  If they need to
enter seven numbers into a form once a week and it takes them 15
seconds with a special desktop app and 17 seconds with a web app and
there are only three users, go for the web app if it saves you any
development or support time.

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

I am sure it would have saved at least half the development time of
that app.  But it's not a fair comparison since that was a 16 bit
MS-DOS app written in C.

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

OK, looking at what's on my screen during most of my workday:

 1) one or more browser windows.  No file system interaction.
 2) Several terminal windows, no file interaction from the terminal
    itself, but I run command line apps (mostly emacs) in the terminals
    and those sometimes use the file system.
 3) Text chat client, I think it can send and receive files but I never
    use that feature.  I would not run this particular app if it were
    up to me but management chose it.  But it is a sort of legitimate
    use of a desktop gui.
 4) Email client again chosen by management.  This one does use the
    file system to send and receive attachments, but that's not
    fundamentally required since webmail clients are very popular and
    effective and can upload and download.  At home I read email with
    emacs.

The only other desktop gui program I can think of that I use with any
regularity is a PDF viewer occasionally launched by the browser.  More
typically this is done with a browser plugin rather than a separate
app, but my desktop is set up to launch xpdf separately.  Under
Windows I sometimes used IDLE for Python development but under Linux I
run python inside emacs.

> 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 sure what that combo box is.  I've probably seen one but I'm
just not sure exactly what you're referring to.  Maybe it's important
if you write heavily used CRUD apps.  Not everybody who needs a gui
writes those apps.

> 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 think it is simpler until you're trying to do stuff that's both
slick and multi-platform, but not everyone cares about being both of
those things simultaneously.  I generally don't care about slickness
and accomplish multi-platform by writing dirt-simple html.