Re: Tkinter or wxpython?

Chris Mellon wrote:
On 06 Aug 2007 09:44:15 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
"Chris Mellon" <arkanes@xxxxxxxxx> 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
.