UI toolkits for Python

[Michael Ekstrand]

1) A real word processor.

Difficult. Not necessarily impossible. Would require much cleverness.
And it wouldn't be capable of everything Word can do.

2) Keybindings in a web application

Not sure here, but JavaScript may be able to do something to accomplish
some of this. A web-delivered XUL app can definitely do this. But
that's pushing the limits of what can be considered a web application.

3) Drag and drop

JavaScript can definitely do this. AFAIK Zimbra (http://www.zimbra.com)
does this. D&D w/ the desktop environment may not be supported though.

4) Resizable windows (i.e. not the browser window) within the
application.

Possible, but difficult. I believe that some great cleverness with
JavaScript and absolutely-positioned DIV's can probably come pretty
stinking close, and Flash can definitely do this (but that doesn't
really count). Not tested.

5) Anything other than absolutely trivial graphical programs.

Correct there.

- Michael

 

[Jason Stitt]

Web interfaces are missing a lot more than this. Here are just a
few things that cannot be done with web-based interfaces (correct
me where I'm wrong):

1) A real word processor.
2) Keybindings in a web application
3) Drag and drop
4) Resizable windows (i.e. not the browser window) within the
application.
5) Anything other than absolutely trivial graphical programs.

State is a very small part of the whole thing. Progress is being
made, but web interfaces are still basically forms that can contain
buttons, checkboxes, text fields, and a few other basic controls. I
wish it were otherwise.

Drag-and-drop within a page can be done. Drag-and-drop between pages
is the only thing on that list I think is outright impossible.
Everything else is a matter of overcoming difficulty (well, 5 might
be close enough to qualify as impossible, if you're thinking Photoshop.)

Thing is, as Web applications continue to increase in complexity,
they're going to resemble desktop apps more and more, not just on the
front end but in back as well. So the "advantage" of Web apps being
simpler to program will probably go away. Right now, they're only
simpler because people are doing simpler things with them (and
browsers only let you do so much.)

The extra complexity you get with desktop app toolkits is overkill
for many purposes. HTML is often "good enough" in a lot less time.
But if we get to the point where browsers are implementing inter-page
drag-and-drop (probably differently!) and so forth, some of us might
well decide it's simpler to go back to wxPython, etc.

Then again, maybe we'll live to see the W3C standardize the desktop
environment... <g>

-Jason

 

[Paul Rubin]

Not sure here, but JavaScript may be able to do something to accomplish
some of this. A web-delivered XUL app can definitely do this. But
that's pushing the limits of what can be considered a web application.

All this extreme use of JS misses the point, it's client side
programming all over again, not really what most of us think of as a
web interface which puts all the hair on the server side. If you want
to program on the client, why not use a reasonable language like
Python instead of a monstrosity like JS?

 

[Torsten Bronger]

Hallöchen!

All this extreme use of JS misses the point, it's client side
programming all over again, not really what most of us think of as
a web interface which puts all the hair on the server side. If
you want to program on the client, why not use a reasonable
language like Python instead of a monstrosity like JS?

Because everybody is capable of running a JS engine, even on
computers on which you don't have rights to install something.

(Not that I like those JS ideas though ...)

Tschö,
Torsten.

 

[Paul Rubin]

Because everybody is capable of running a JS engine, even on
computers on which you don't have rights to install something.

I don't think using JS so heavily without a compelling reason is
really in the WWW spirit. Lots of browsers don't have JS. And lots
of JS is so annoying that some users like to turn it off even in
browsers that have it.

 

[Richie Hindle]

[Ken]

Web interfaces are missing a lot more than this. Here are just a few
things that cannot be done with web-based interfaces (correct me
where I'm wrong):

1) A real word processor.
http://www.writely.com/
http://www.goffice.com/

2) Keybindings in a web application

http://rememberthemilk.com/
Google Keys (but what happened to it? It's disappeared!)

3) Drag and drop

http://www.walterzorn.com/dragdrop/dragdrop_e.htm

http://qooxdoo.oss.schlund.de/demo/release/public/test/user/Index.html
(pick "Drag and Drop N" from the dropdown on the right hand side of the top
bar)

4) Resizable windows (i.e. not the browser window) within the
application.

http://qooxdoo.oss.schlund.de/demo/release/public/test/user/Index.html
(pick "Window N" from the dropdown on the right hand side of the top bar)

http://www.bindows.net/ (click "Click for a quick DEMO")

5) Anything other than absolutely trivial graphical programs.

Not sure what you mean by this... Google maps?

web interfaces are still basically forms that can contain
buttons, checkboxes, text fields, and a few other basic controls. I
wish it were otherwise.

It *is* otherwise. You should follow the Ajaxian weblog here:
http://www.ajaxian.com/

 

[Alex Martelli]

I don't think using JS so heavily without a compelling reason is
really in the WWW spirit. Lots of browsers don't have JS. And lots
of JS is so annoying that some users like to turn it off even in
browsers that have it.

I don't have the exact numbers, and I'm pretty certain they'd be
confidential if I did, but I believe the factors you mention (browsers
completely lacking JS, and users turning JS off), *combined*, still
allow JS-rich interfaces to run for well over 95% of visitors to our
sites. Maybe that's the key difference between the mindset of a
mathematician and that of an engineer -- I consider reaching over 95% of
visitors to be _quite good indeed_, while you appear to disagree because
of "WWW spirit" issues. Is making a rapidly responsive site (not
requiring roundtrips for every interaction) a "compelling reason"? It
seems to me that it is -- and why else would one use ANY Javascript,
after all?

My one issue with the JS/AJAX mania is that I really dislike JS as a
language, particularly when you take the mixed mongrel dialect that you
do need to reach all the various browsers and releases needed to make
that 95% goal. But, alas, there is really no alternative!-(


Alex

 

[Mike Meyer]

Maybe that's the key difference between the mindset of a
mathematician and that of an engineer -- I consider reaching over
95% of visitors to be _quite good indeed_,

Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that
rejected 5% of the systems connecting to be _quite good indeed_? I
think I'm glad that the internet wasn't built by people who agreed
with that.

If you know what you're doing, you can have the best of both worlds
for a lot of web applications. Yes, it won't be as rich or functional
for the five percent who worry about security (or whatever), but it'll
still work. And yes, you can't do it for every application. For those,
anyone vaguely competent will add a warning.

What surprises me is that marketing types will accept turning away -
what's the current internet user base? 200 million? - 10 million
potential customers without a complaint. Or maybe they just don't get
told that that's what's going on.

<mike

 

[Mark Roseman]

what's the current internet user base? 200 million? - 10 million
potential customers without a complaint. Or maybe they just don't get
told that that's what's going on.

Obviously we all agree the effort to support both is significant. The
question is not so much "do we turn away 5%" as "do we use the effort we
do have to provide a better experience for the 95%, or to provide a
slightly worse experience for the 95%, and an ok experience for the 5%".

If you're a business, the question then becomes, does the incrementally
better experience produce a higher conversion rate (i.e. more sales), in
which case it may well be a better investment to focus there and ignore
the 5%. It's but one perspective, but depending on your goals, can be a
reasonable choice to make.

Mark

 

[Christophe]

Mike Meyer a écrit :

Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that
rejected 5% of the systems connecting to be _quite good indeed_? I
think I'm glad that the internet wasn't built by people who agreed
with that.

If you know what you're doing, you can have the best of both worlds
for a lot of web applications. Yes, it won't be as rich or functional
for the five percent who worry about security (or whatever), but it'll
still work. And yes, you can't do it for every application. For those,
anyone vaguely competent will add a warning.

What surprises me is that marketing types will accept turning away -
what's the current internet user base? 200 million? - 10 million
potential customers without a complaint. Or maybe they just don't get
told that that's what's going on.

<mike

Last time I checked, it was only 60% of the users with Javascript
enabled. Not sure about the current ratio but with the various locked
down IE installs it doesn't surprise me too much.

 

[Christophe]

Mike Meyer a écrit :

Oh? So you'd consider an SMTP/IMAP/POP/DNS/NFS/etc server that
rejected 5% of the systems connecting to be _quite good indeed_? I
think I'm glad that the internet wasn't built by people who agreed
with that.

If you know what you're doing, you can have the best of both worlds
for a lot of web applications. Yes, it won't be as rich or functional
for the five percent who worry about security (or whatever), but it'll
still work. And yes, you can't do it for every application. For those,
anyone vaguely competent will add a warning.

What surprises me is that marketing types will accept turning away -
what's the current internet user base? 200 million? - 10 million
potential customers without a complaint. Or maybe they just don't get
told that that's what's going on.

<mike

Last time I checked, it was only 60% of the users with Javascript
enabled. Not sure about the current ratio but with the various locked
down IE installs it doesn't surprise me too much.

 

[Paul Boddie]

All this extreme use of JS misses the point, it's client side
programming all over again

This is so true, although I don't expect those people relentlessly
hyping "AJAX" to either realise the significance of that observation or
to necessarily make an accessible Web site for those people who, for
whatever reason, can't use the mountains of JavaScript that perform the
fancy fades and colour flashes that seem "de rigeur" in their "Web 2.0"
applications.

Here's an interesting perspective from outside the "AJAX clique":

http://aseigo.blogspot.com/2005/10/web-office-suites-rofl.html

(It even has a Monty Python reference, too.)

Paul

 

[Alex Martelli]

What surprises me is that marketing types will accept turning away -
what's the current internet user base? 200 million? - 10 million
potential customers without a complaint. Or maybe they just don't get
told that that's what's going on.

In firms where marketing has lots of power, they may indeed well decide
to pursue those "10 millions" by demanding an expenditure of effort
that's totally out of proportion (to the detriment of the other "190
millions", of course, since there IS a finite amount of development
resources to allocate). Maybe that's part of the explanation for the
outstanding success of some enterprises founded by engineers, led by
engineers, and staffed overwhelmingly with engineers, competing with
other firms where marketing wield power...?


Alex

 

[Mike Meyer]

Obviously we all agree the effort to support both is significant. The
question is not so much "do we turn away 5%" as "do we use the effort we
do have to provide a better experience for the 95%, or to provide a
slightly worse experience for the 95%, and an ok experience for the 5%".

You elided the paragraph where I pointed out the third alternative:
provide a better experience for the 95%, and an ok experience for the
5%. WWW technologies are designed to degrade gracefully - it's easy to
take advantage of that.

<mike

 

[Mike Meyer]

In firms where marketing has lots of power, they may indeed well decide
to pursue those "10 millions" by demanding an expenditure of effort
that's totally out of proportion

What makes you think that the expenditure of effort is "totally out of
proportion"? In my experience, that isn't the case - at least if you
go into it planning on doing things that way. Retrofitting a site that
was built without any thought but "make it work in my favoriter
browser in my favorite configuration" can be a radically different
thing.

Maybe that's part of the explanation for the
outstanding success of some enterprises founded by engineers, led by
engineers, and staffed overwhelmingly with engineers, competing with
other firms where marketing wield power...?

You mean like google? Until recently, they're an outstanding example
of doing things right, and providing functionality that degrades
gracefully as the clients capabilities go down.

<mike

 

[Mark Roseman]

You elided the paragraph where I pointed out the third alternative:

provide a better experience for the 95%, and an ok experience for the
5%. WWW technologies are designed to degrade gracefully - it's easy to
take advantage of that.

What I'm suggesting is taking the effort you'd put to the 5%, and
applying that effort instead to making the 95% even better. If that
extra effort would affect conversion rates, it's a justifiable option.

 

[Claudio Grondi]

[Claudio]

I don't fully understand your attitude here. The Web Browser interface
has

all I can imagine is required for a GUI, so what is missing when you
consider, that you can generate custom images on the fly on the server
and

let the user shape the page without requesting CPU power from the server
using JavaScript.

In this case then, I'm afraid the failure is in your imagination

Any useful hints towards enlightenment except criticism?

Perhpas the mistake I made was bearing in mind the title of the thread,
and the fact that this is a Python newsgroup.

as a



The cause of confusion here is, that HTML interfaces don't necessary need a
web server and HTTP to work. I mean, that Internet Browsers
have an API which allow access to them directly, so they can be used without
a server as a kind of GUI library supporting widgets programmed
in HTML and JavaScript (I haven't used them yet in this form, but I think
it should be no problem - right or not?).

You are perfectly correct that interfaces can be programmed in the
browser. As has already been said, with the adoption of standards like
CSS2, it's even possible to make such stuff run across multiple browser
platforms (at the moment, though, just try writing an interface that
makes table rows appear and disappear in a cross-browser fashion: you'll
find the stylesheet techniques you need to use for Mozilla and IE are
very different). But this doesn't help you at all if you are trying to
interface to Python logic.

Complex and dynamic is in my eyes possible with HTML and JavaScript, so I
still don't see where is a problem with this approach. I have programmed
already a HTML and JavaScript driven server platform and know about (the
solvable) problems with the back-button and sessions (it is sure not the
easiest way of programming a GUI).
The only disadvantage of not using plugins or Java is, that real time
interactions are not possible, but this is in my eyes usually not the
requirement for a standard kind of GUI with no gaming, no Virtual Reality
and no timing of user response down to milliseconds (but consider, that with
a good speed of connection it is even possible to play blitz chess over the
Internet).

So, back to the subject: with an HTML/Javascript interface, how do you
propose to bolt Python logic into the same process? Or do you admit that
the application that interacts with such an interface either has to be
all JavaScript or in a separate process?

I haven't used it in such configuration yet, but I mean, that it is not a
bad idea to use local DHTML files (i.e. HTML with JavaScript) combined with
a Python driven HTTP server like e.g. Karrigell which makes it possible to
access local files by executing Python scripts triggerred by demand raised
by submitting to it DHTML form data resulting from user input.
So mixing JavaScript in local DHTML files for performing what can be done
with JavaScript inside HTML and a HTTP server capable of executing Python
scripts will do the job which JavaScript alone can't because of lack of
access to the local file system and another parts of the computer system on
which such kind of UI is executed.
Another possible scenario I have in mind is to control the Internet browser
directly from a Python script using DHTML as a language for definition of
appearance and specification of necessary data processing of in the browser
displayed UI. This way the Internet browser and HTML with JavaScript can be
considered an UI toolkit for use in Python.
Hope with this above to have got Python back on topic.

Claudio

 

[Alex Martelli]

What makes you think that the expenditure of effort is "totally out of
proportion"? In my experience, that isn't the case - at least if you
go into it planning on doing things that way. Retrofitting a site that
was built without any thought but "make it work in my favoriter
browser in my favorite configuration" can be a radically different
thing.

Why, of course -- coding a site to just one browser would be foolish
(though there exist sites that follow that strategy, it's still
despicable). What I'm talking about is sites that are _supposed_ to be
able to support a dozen browsers, in three or four versions each, not to
mention a dozen features each of which the user "might" have chosen to
disable (for a total of 2**12 == 4096 possibilities). Of course, the
site's poor authors cannot possibly have tested the 4096 * 12 * 3.5
possibilities, whence the "_supposed_ to be".

We ARE talking about moving from supporting 95% to supporting
(*supposedly*!) 100%, after all -- very much into the long, *LONG* tail
of obscure buggy versions of this browser or that, which SOME users
within those last centiles may have forgotten to patch/upgrade, etc.
And THAT is what makes the effort totally out of proportion (differently
from the effort to go from 60% to 95%, which, while far from negligible,
is well within sensible engineering parameters).

You mean like google? Until recently, they're an outstanding example
of doing things right, and providing functionality that degrades
gracefully as the clients capabilities go down.

I'm not sure what you mean by "until recently" in this context. AFAIK,
we've NEVER wasted our efforts by pouring them into the quixotic task of
supporting *100%* of possible browsers that may hit us, with the near
infinite number of combinations of browsers, versions and disabled
feature that this would require. One may quibble whether the target
percentage should be, say, 93%, 95%, or 97%, and what level of
degradation can still be considered "graceful" around various axes, but
the 100% goal which you so clearly imply above would, in my personal
opinion, be simply foolish now, just as it would have been 3 years ago.


Alex

 

[Paul Rubin]

I'm not sure what you mean by "until recently" in this context. AFAIK,
we've NEVER wasted our efforts by pouring them into the quixotic task of
supporting *100%* of possible browsers that may hit us, with the near
infinite number of combinations of browsers, versions and disabled
feature that this would require.

The non-graphics-oriented Google services like search, news, and
groups, have worked perfectly well with lynx until recently. No
javascript required, no image display required, and no cookies required.

 

[Steve Holden]

Mike Meyer <[email protected]> wrote:

[... browser audience discussion ...]

Why, of course -- coding a site to just one browser would be foolish
(though there exist sites that follow that strategy, it's still
despicable). What I'm talking about is sites that are _supposed_ to be
able to support a dozen browsers, in three or four versions each, not to
mention a dozen features each of which the user "might" have chosen to
disable (for a total of 2**12 == 4096 possibilities). Of course, the
site's poor authors cannot possibly have tested the 4096 * 12 * 3.5
possibilities, whence the "_supposed_ to be".

We ARE talking about moving from supporting 95% to supporting
(*supposedly*!) 100%, after all -- very much into the long, *LONG* tail
of obscure buggy versions of this browser or that, which SOME users
within those last centiles may have forgotten to patch/upgrade, etc.
And THAT is what makes the effort totally out of proportion (differently
from the effort to go from 60% to 95%, which, while far from negligible,
is well within sensible engineering parameters).





I'm not sure what you mean by "until recently" in this context. AFAIK,
we've NEVER wasted our efforts by pouring them into the quixotic task of
supporting *100%* of possible browsers that may hit us, with the near
infinite number of combinations of browsers, versions and disabled
feature that this would require. One may quibble whether the target
percentage should be, say, 93%, 95%, or 97%, and what level of
degradation can still be considered "graceful" around various axes, but
the 100% goal which you so clearly imply above would, in my personal
opinion, be simply foolish now, just as it would have been 3 years ago.

In mine, too. It's often useful to remember the so-called 80/20 rule
which, in software terms, I often state as "you can get 80% of the
functionality for 20% of the cost". Among other things I theorise that
this accounts for the vast numbers of abandoned open source projects
lurking on the Internet (but let's not follow that red herring any further).

Of course, if the final 20% of a project's functionality accounts for
80% of the cost then the stark arithmetical truth would be that each
functionality percentage point costs sixteen times what the first eighty
points did.

In practice the situation is never linear, and the truth is that there
is a situation of diminishing returns which rarely justifies supporting
those final additional hold-outs with obsolete platforms. This is as
much an economic decision as a marketing one, but a good engineer knows
instinctively that there is a desirable cut-off point beyond which
adding further functionality is a waste of engineering effort.

regards
Steve