UI toolkits for Python

[Steve Holden]

Claudio Grondi wrote: [...]

Do I miss here something?


While you are correct in saying (I paraphrase) that HTML interfaces
nowadays can offer a rich graphical interface, it can be quite difficult
to manage state maintenance between the two components (web server, web
client) in the system.


The cause of confusion here is, that HTML interfaces don't necessary

need a

without

think


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.

I

Reality

with

the


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.

Indeed. But this again partitions the problem into client functionality
and server functionality residing in two separate processes, albeit on
the same computer, with the previously-mentioned state maintenance
problems. This issue isn't new, you know.

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.

That is, I suppose, a possibility, but you certainly can't claim it
would be platform-independent. Unless you know of some common control
interface respected by both Internet Exploder and Firefox ;-)

regards
Steve

 

[Claudio Grondi]

Another possible scenario I have in mind is to control the Internet
browser

That is, I suppose, a possibility, but you certainly can't claim it
would be platform-independent.

I haven't seen any really platform-independent software yet and I don't
expect to see any in the future.
It is simply not possible to have one, even if much progress was done lately
in many areas in order to try to approach it as close as possible.

Claudio

Claudio Grondi wrote: [...]
Do I miss here something?


While you are correct in saying (I paraphrase) that HTML interfaces
nowadays can offer a rich graphical interface, it can be quite difficult
to manage state maintenance between the two components (web server, web
client) in the system.


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.

A "proper" GUI runs all functionality inside a single process, and
allows much easier control over complex interactions, creation of
dynamic dialogues, and so on.

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.

Indeed. But this again partitions the problem into client functionality
and server functionality residing in two separate processes, albeit on
the same computer, with the previously-mentioned state maintenance
problems. This issue isn't new, you know.

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.

That is, I suppose, a possibility, but you certainly can't claim it
would be platform-independent. Unless you know of some common control
interface respected by both Internet Exploder and Firefox ;-)

regards
Steve

 

[Ed Jensen]

I haven't seen any really platform-independent software yet and I don't
expect to see any in the future.
It is simply not possible to have one, even if much progress was done lately
in many areas in order to try to approach it as close as possible.

Java + Swing is probably as good as it gets when the goal is to write
platform independent software.

 

[Paul Boddie]

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.

Yes, but isn't this where the 90/10 rule kicks in? In other words, you
transfer the effort from the 5% of users you don't care about, but then
just end up adding polish to the "majority" solution which doesn't
significantly improve conversion rates, all because you've done the
most effective work to "convert" those users already.

In this case it's even more perilous: adding "polish" could quite
easily eliminate parts of your audience, resulting in an only slightly
more plush red carpet being offered to significantly fewer people.

Paul

 

[Paul Boddie]

Steve Holden wrote:

[80/20 rule]

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.

But Mike Meyer's point was that the Web standards are designed to allow
fancy functionality where it's available but for the experience to
degrade gracefully where such functionality isn't available. For
example, you have all the "events module" attributes in XHTML, but take
away the events capability in the browser and there's a decent chance
for the semantics of the application to remain the same: no, you don't
get instant updates of the page when you select some menu item, but the
user can still have a similar experience which involves slightly more
inconvenience - they have to submit the page and get back an updated
version from the server.

It's misleading to claim that designing in such a way requires huge
additional development, especially since the standards are constructed
in such a way to facilitate such designs. It goes without saying that
implementing advanced functionality on Netscape 3.x and NCSA Mosaic
would be a costly and ultimately non-viable burden, but that isn't the
issue for many Web applications and wasn't the point being made.

Paul

 

[Mike Meyer]

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.

I'm talking about supporting standards instead of clients, which is
how you get interoperability. You clearly can't support all the buggy
browsers that exist, especially not when even commercial browsers are
releasing betas to the public. Reality is that you *have* to support
the most popular browser(s) - except for the betas, anyway. Other
browsers that have bugs - well, you can patch around them if it's
trivial enough, and identify where the browser is out of spec
otherwise in hopes the author will fix it. Unless you're out of spec,
in which case you fix your code.

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.

Google's sites have been very good about working with many browsers
and configurations, especially when compared with the run of the mill
on the web. If that's unintentional - well, that's simply a shame.

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.

I never meant to imply that you should try and support 100% of all
browsers, merely that they should try and support every browser that
follows the specifications (and IE). I can see how what I said might
be construed to mean the latter, and I'm sorry about that.

<mike

 

[Kenneth McDonald]

I'd have to agree with this. Unfortunately, the only way to use Swing
(in a
reasonable manner) from Python is to use Jython, and Jython has other
shortcomings that make me not want to use it.

Sigh.

Ken

 

[Ed Jensen]

I'd have to agree with this. Unfortunately, the only way to use Swing
(in a
reasonable manner) from Python is to use Jython, and Jython has other
shortcomings that make me not want to use it.

What shortcomings?