UI toolkits for Python

[Kenneth McDonald]

Is there any emerging consensus on the "best" UI for toolkit. Tk
never quite made it but from what I can see, both qt and wxWin are
both doing fairly well in general. I'm already aware of the licensing
issues surrounding qt (fwiw, I think their license fee for commercial
use is eminently reasonable), so aside from that, I was wondering if
there was any feedback readers could provide on the following:

1) Which plays best with Python? Ideally, it would already have some
higher-level python libraries to hide the grotty stuff that is almost
never needed when actually implementing apps.

2) Reliability of each?

3) Useful external libraries for each?

4) Ease of installation/use on OS X?

Something with a genuinely useful text widget would be nice, but I
know that's too much to expect...ah, TkText widget, where are you
when I need you.
Thanks,
Ken

[Paul Rubin]

Kenneth McDonald <ke****************@sbcglobal.net> writes:

1) Which plays best with Python? Ideally, it would already have some
higher-level python libraries to hide the grotty stuff that is almost
never needed when actually implementing apps.

2) Reliability of each?

3) Useful external libraries for each?

4) Ease of installation/use on OS X?

The answer to each of those questions points to Tkinter. It comes
with Python by default (the least installation hassles of any
toolkit), is pretty reliable, has a reasonably Pythonic interface, and
I don't understand the question about external libraries.

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

That suggests you're not asking the right questions.

I use Tkinter because the Python gui's I've built so far have been for
straightforward functionality purposes without being fancy. However,
if I were doing something for wide distribution and wanted it to look
sharp, at this point I think I'd go for PyGtk despite the preference
of many for wxpython.

Finally, don't overlook the possibility of embedding a basic web
server in your app, and having the user communicate with it through a
web browser. That turns HTML into your gui, which is very easy to
program. It also lets you easily handle remote clients, multiple
concurrent clients, etc, and gives users a familiar and intuitive
interface.

[Kenneth McDonald]

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

As for Tkinter, well, sigh, I have to go into a semi-rant, semi-
eulogy right now.

Tk was, IMHO, the hands-down award winner for UI toolkit farthest
ahead of
its time. I used it for years and years and years.

Tcl, on the other had, wasn't the _worst_ scripting language of all
time, but it
was sure down in the bottom ten percent. How John Ousterhout could
come up
with Tk on one hand and the other at the same Tcl boggles my mind.

Unfortunately, while Tkinter did provide in theory full access to Tk,
it was in
practice never finished. I wrote quite a bit of code to try to add a
true pythonic
interface to Tk via Tkinter (I'm happy to give it away if anyone
wants--some of
it is actually in pretty good shape). But it's a big job, and it
became clear to me
that Tk is going the way of the dinosaurs, so I abandoned it.

Ddevelopment on the advanced features of Tk--what really made it worth
using--has languished. Both marks and tags in the Text widget have been
fundamentally broken forever (not buggy, I mean broken in the sense that
their semantics destroys a great deal of their real potential), and I
don't see
they'll ever be fixed. Same thing with tags in the Canvas widget.
Plus the
lack of well-thought-out new widgets, and various other sins of omission
and comission, and I decided that Tkinter was clearly in the last of
its days.

That said, if I was one of the founders of Google, Tk would be one of
the
projects I'd hire a lot of people to get on to and actually realize
its potential.
But I don't even buy lottery tickets :-)

Now I'm just waiting until one of the other kits becomes mature enough
(if ever) to start using it. So this is a query about that :-)
On 13-Oct-05, at 3:21 PM, Paul Rubin wrote:

Kenneth McDonald <ke****************@sbcglobal.net> writes:

1) Which plays best with Python? Ideally, it would already have some
higher-level python libraries to hide the grotty stuff that is almost
never needed when actually implementing apps.

2) Reliability of each?

3) Useful external libraries for each?

4) Ease of installation/use on OS X?

The answer to each of those questions points to Tkinter. It comes
with Python by default (the least installation hassles of any
toolkit), is pretty reliable, has a reasonably Pythonic interface, and
I don't understand the question about external libraries.

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

That suggests you're not asking the right questions.

I use Tkinter because the Python gui's I've built so far have been for
straightforward functionality purposes without being fancy. However,
if I were doing something for wide distribution and wanted it to look
sharp, at this point I think I'd go for PyGtk despite the preference
of many for wxpython.

Finally, don't overlook the possibility of embedding a basic web
server in your app, and having the user communicate with it through a
web browser. That turns HTML into your gui, which is very easy to
program. It also lets you easily handle remote clients, multiple
concurrent clients, etc, and gives users a familiar and intuitive
interface.
--
http://mail.python.org/mailman/listinfo/python-list

[Mark Roseman]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

People should probably be more aware of work that has been going on with
Tk recently (after a fairly long hiatus) in terms of greatly improving
its appearance, adding theming, and more. It's worth checking out, and
of course, if there's a way to help get some of these changes into
Tkinter, the Tk folks would I'm sure be helpful.

Here's a portion of a note that Jeff Hobbs posted to the Ruby group
recently, on a similar topic:

From: Jeff Hobbs <je***@removethis.activestate.com>
Subject: Re: The definitive GUI for Ruby
Date: Wed, 05 Oct 2005 11:02:46 -0700
Newsgroups: comp.lang.ruby
Message-ID: <43**************@removethis.activestate.com>

Eustaquio Rangel de Oliveira J wrote:

Tk is still too ugly for make programmers that are
migrating. :-)

Tk is only ugly if that's the way you like it. You have a
full set of themed widgets available now that give you
native look and feel, with all the same dynamic control and
general ease of use that Tk has always provided. All this
on Aqua, Win32 and X11 (even Windows/CE). Some screenshots
of Tk apps that try not to be ugly:

The Perl Dev Kit and Tcl Dev Kit UIs:
http://aspn.activestate.com/ASPN/doc...ild_parameters
http://aspn.activestate.com/ASPN/doc...2/TclVFSE.html

Tk on Win/CE (I know that the Perl/Tcl::Tk use this too):
http://wiki.tcl.tk/8442

Coccinella:
http://hem.fyristorg.com/matben/
http://hem.fyristorg.com/matben/examples/index.html

An installer builder:
http://installbase.sourceforge.net/screenshots.shtml

An example of improving a Tk app by "going native":
http://wiki.tcl.tk/14522

[Grant Edwards]

On 2005-10-13, Paul Rubin <> wrote:

The answer to each of those questions points to Tkinter. It comes
with Python by default (the least installation hassles of any
toolkit), is pretty reliable, has a reasonably Pythonic interface, and
I don't understand the question about external libraries.

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

Aside from the look & feel issue with Tk, the other objection
sometimes heard is that Tk is integrated into Python by
including Tcl as well (as opposed to doing an actual Tk binding
the way some other languages have done). It's an eminently
practical approach, but it sure makes you feel dirty.

--
Grant Edwards grante Yow! Hey!! Let's watch
at the' ELEVATOR go UP and
visi.com DOWN at th' HILTON HOTEL!!

[gsteff]

I've used wxpython and pygtk, and have a strong preference for pygtk.
wxpython has some advantages: it has better OSX support (widgets look
native, and it doesn't require the installation of the Fink x server),
and better win32 support (a few gtk widgets, such as menus, don't look
quite native on gtk, and multithreading with pygtk on win32 is
problematic). But pygtk has better documentation, a MUCH cleaner api,
integration with the Glade GUI designer (wxpython has wxglade, but its
not in the same league), and a richer widget set. In addition, top
itself is in the top tier of free software projects; wxwidgets is not
as mature, and its development is not as active.

So, if you're trying to choose between those two, go with wxpython if
you need OSX support, or have specific issues with pygtk's win32
support. In all other cases, I'd reccomend pygtk.

Greg

[gsteff]

Er, meant to say "In addition GTK itself is in the top tier of free
software projects"

[Fredrik Lundh]

> > However, Tkinter not most people's favorite, because the widgets look

crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

(given that the web interface is the new black, that's not much of
an argument. tkinter with the right stylesheet can look anyway you
want)

Mark Roseman wrote:
People should probably be more aware of work that has been going on with
Tk recently (after a fairly long hiatus) in terms of greatly improving
its appearance, adding theming, and more. It's worth checking out, and
of course, if there's a way to help get some of these changes into
Tkinter, the Tk folks would I'm sure be helpful.

maybe this should be reposted to tkinter-discuss ?

fwiw, I still use Tkinter for all UI:s I build, but these days, 80-90%
of the visible widgets are based on this module:

http://effbot.org/zone/wck.htm

sometimes combined with:

http://effbot.org/zone/draw-agg.htm

</F>

[Ville Voipio]

In article <ma*************************************@python.or g>,
Kenneth McDonald wrote:

4) Ease of installation/use on OS X?

There are two questions which may restrict your choice
rather a lot:

#1 Should the UI look the same on each platform or should it
look the same as all other apps on the platform?

#2 Are you trying to make a simple installation package which
includes everything needed?

With OS X compatibility you tend to come across with the
fact that many "OS X compatible" things are actually X11
things. X11 certainly looks different from Aqua (the native
interface). Also, X11 is not always installed, and some
unixish things require using Fink to install them. Not
something Joe A. User usually has on his Mac.

GTK is an example of this. There is an Aqua version of
GTK, but it seems to be rather outdated. The newer versions
run on X11 but installing them may be just laborious or
then plain pain depending on your luck. And you still need
the X11 installed.

So, if you are looking for something that looks like Mac
and works like Mac, do not touch anything with X11. OTOH,
if you just need to get something working on your own
OS X computer, then X11 is fine.

---

I have tried using wxPython for Mac/Windows cross-platform
GUIs. This far it seems to work fine, but I have not tried
anything very fancy. Mac applications have the OS X looks,
and Windows applications look Windowsish. Without having
a single line of platform-dependent code.

Making simple installation files (exe for Windows and dmg
for OS X) seems to work, as well. So, the installation should
be easy for the user.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

[dberlin]

I find wxPython to pro fill my GUI needs from python in a pretty good
way.
To show off it's capabilities - I am building a GUI editor and it
currently converts from windows forms (visual studio c# forms) to
wxPython code.
When I started programming this editor I thought I'd have major
incompatibility problems, thinking wxPython is extremely weaker than
the windows forms.
However, coding the conversion between the two proved wxPython to be
highly capable.
BTW, this GUI editor can be found here:
http://farpy.holev.com

I believe this also provides an answer to gsteff's post about not
having a normal GUI editor.

[Claudio Grondi]

"Kenneth McDonald" <ke****************@sbcglobal.net> wrote in
news:ma*************************************@pytho n.org...

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

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.
I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding to
user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser as a
GUI?
Do I miss here something?

Claudio

[Malte Clasen]

Claudio Grondi wrote:

What is that complex, that it can't be solved using an Internet Browser as a
GUI?

Nothing, but session management isn't trivial with http interfaces. You
have to deal with the back button of the browsers, bookmarks to pages
that result from posted forms, users leaving the application without
notice, etc.. And if you want to implement dialogs like the Photoshop
image resizing with automatic calculation of some widget data based on
other widgets (e.g. interlocked width and height), you have to rely on
JavaScript which isn't as platform independent as it should be and
sometimes deactivated due to security issues.

But if that doesn't bother you, you might want to have a look at
http://qooxdoo.sourceforge.net/ , "an advanced open-source javascript
based toolkit."

Malte

[Stefan Behnel]

Kenneth McDonald schrieb:

Is there any emerging consensus on the "best" UI for toolkit. Tk never
quite made it but from what I can see, both qt and wxWin are both doing
fairly well in general. I'm already aware of the licensing issues
surrounding qt (fwiw, I think their license fee for commercial use is
eminently reasonable), so aside from that, I was wondering if there was
any feedback readers could provide on the following:

[snip]

As for my experience with Python-integrated GUI toolkits: I tried
wxWidgets/Boa and had it crashing on me all over the place. I switched to
GTK/glade2 and fought with it for a couple of days until I ran away screaming.
Next, I tried Qt/Designer and the more I learned, the more I knew I'd keep
loving it. Its Python bindings are not perfect, especially QStrings will annoy
you. You will notice that it was originally designed for C++ and had to try
hard to reimplement a lot of the batteries that Python has included, so it
often uses its own concepts where Python concepts would feel a bit nicer. But
once you accept that, you will really like its clean design that helps you
with your work.

A friend of mine switched to Mac-OS X recently and I told him to use Qt for
one of his projects. He is a Debian developer and did all of his previous GUIs
with GTK. It took him only a couple of hours to fall in love with it. He was
especially mad about the fact that it looks completely like a Mac application
on Mac-OS and like a Windows application on Windows. It even felt like a
native app.

Just try it, you'll see.

Stefan

[Stefan Behnel]

Kenneth McDonald wrote:

Is there any emerging consensus on the "best" UI for toolkit. Tk never
quite made it but from what I can see, both qt and wxWin are both doing
fairly well in general. I'm already aware of the licensing issues
surrounding qt (fwiw, I think their license fee for commercial use is
eminently reasonable), so aside from that, I was wondering if there was
any feedback readers could provide on the following

Oh, one more thing with respect to web apps: There was the nufox announcement
recently, which seems to support XUL driven interfaces in Python.

http://trac.nunatak.com.au/projects/nufox

Stefan

[Steve Holden]

Claudio Grondi wrote:

"Kenneth McDonald" <ke****************@sbcglobal.net> wrote in
news:ma*************************************@pytho n.org...

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

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 :-)
I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding to
user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser as a
GUI?
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.

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.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Mike Meyer]

Malte Clasen <ma**********@arcor.de> writes:

Claudio Grondi wrote:

What is that complex, that it can't be solved using an Internet Browser as a
GUI?

Nothing, but session management isn't trivial with http
interfaces. You have to deal with the back button of the browsers,
bookmarks to pages that result from posted forms, users leaving the
application without notice, etc..

This fact seems to have escaped the notice of most developers of web
applications. They just fail and/or misbehave under all those
conditions.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Claudio Grondi]

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag
news:ma*************************************@pytho n.org...

Claudio Grondi wrote:

"Kenneth McDonald" <ke****************@sbcglobal.net> wrote in
news:ma*************************************@pytho n.org...

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

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?

I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding to user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser as a GUI?
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?).

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

Claudio
regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Robert Hicks]

Grant Edwards wrote:
<snip>

Aside from the look & feel issue with Tk, the other objection
sometimes heard is that Tk is integrated into Python by
including Tcl as well (as opposed to doing an actual Tk binding
the way some other languages have done). It's an eminently
practical approach, but it sure makes you feel dirty.

Dirty or not, it allows Python to utilitze any new features of Tk much
faster than an actual Tk binding would. That is Perl/Tk's problem...it
is slow to adopt new Tk features.

Robert

[Steve Holden]

Claudio Grondi wrote:

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag [...]
[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.

I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding
to
user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser
as a
GUI?
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?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Wolfgang Keller]

> With OS X compatibility you tend to come across with the

fact that many "OS X compatible" things are actually X11
things. X11 certainly looks different from Aqua (the native
interface).
But imho, Gnome _does_ "look and feel" quite Mac-ish in the sense that
its ergonomics has certain things in common with the Mac, even more
with the old MacOS classic than with the pretty "gadget-ish" Aqua
interface.

For example, with its hierarchical multi-column listview, Nautilus
"looks" and "feels" perfectly like the old MacOS classic Finder,
something that lots of long-time Mac users miss a lot on MacOS X.

Another example is MDI (or "windows inside windows"), which is a no-no
on the Mac (and afaik not supported by GTK), or multi-pains (sic!). As
a long-time Mac user (since system 6.0.x), I did like a lot the GUI of
WingIDE (which uses GTK) because it allows me to switch from a
multi-pain layout to a multi-window layout.
GTK is an example of this. There is an Aqua version of
GTK, but it seems to be rather outdated.
There's a new effort for a "aqua-native" implementation:

http://micke.hallendal.net/archives/...tk-macosx.html
The newer versions
run on X11 but installing them may be just laborious or
then plain pain depending on your luck. And you still need
the X11 installed.
One advantage of an X11 application is, obviously, the possibility to
use it from a different computer without the requirement to install it
there.

"Hey, my Mac can do that for free, while your Windows needs an
expensive "Server" license.!" >;-> Shhh, don't tell them about
Cygwin...
So, if you are looking for something that looks like Mac
and works like Mac, do not touch anything with X11.

As a long-time Mac user, I somewhat disagree, see above. :-)

To me, a GTK application with a really well-thought ergonomic user
interface is a lot more Mac-ish than a pile of "aqua-native" visual
gadgetry.

Sincerely,

Wolfgang Keller

[Michael Ekstrand]

On Monday 17 October 2005 12:19, Kenneth McDonald wrote:

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]

On Oct 17, 2005, at 12:19 PM, Kenneth McDonald wrote:

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]

Michael Ekstrand <me******@scl.ameslab.gov> writes:

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.

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!

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Michael Ekstrand <me******@scl.ameslab.gov> writes:

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.

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.

--
Torsten Bronger, aquisgrana, europa vetus ICQ 264-296-646

[Paul Rubin]

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

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/r...ser/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/r...ser/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/

--
Richie Hindle
ri****@entrian.com

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

Torsten Bronger <br*****@physik.rwth-aachen.de> writes:

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.

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]

al*****@yahoo.com (Alex Martelli) writes:

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mark Roseman]

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

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

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 :

al*****@yahoo.com (Alex Martelli) writes:

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

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 :

al*****@yahoo.com (Alex Martelli) writes:

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

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]

Paul Rubin wrote:

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/w...ites-rofl.html

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

Paul

[Alex Martelli]

Mike Meyer <mw*@mired.org> wrote:
...

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]

Mark Roseman <ma**@markroseman.com> writes:

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

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

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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Mike Meyer]

al*****@yahoo.com (Alex Martelli) writes:

Mike Meyer <mw*@mired.org> wrote:

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

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[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]

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag
news:ma*************************************@pytho n.org...

Claudio Grondi wrote:

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag

[...]
[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 serverusing 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.

I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding

to

user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser

as a

GUI?
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.
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]

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

Mike Meyer <mw*@mired.org> wrote:

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

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

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.

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]

al*****@yahoo.com (Alex Martelli) writes:

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.

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]

Alex Martelli wrote:

Mike Meyer <mw*@mired.org> wrote:

[... browser audience discussion ...]

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

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.

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
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Steve Holden]

Claudio Grondi wrote:

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag
news:ma*************************************@pytho n.org...

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
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Claudio Grondi]

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

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

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag
news:ma*************************************@pytho n.org... Claudio Grondi wrote:

"Steve Holden" <st***@holdenweb.com> schrieb im Newsbeitrag
news:ma*************************************@pytho n.org...

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 programmedalready a HTML and JavaScript driven server platform and know about (thesolvable) problems with the back-button and sessions (it is sure not theeasiest 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
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Ed Jensen]

Claudio Grondi <cl************@freenet.de> wrote:

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]

Mark Roseman wrote:

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]

al*****@yahoo.com (Alex Martelli) writes:

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

> Mike Meyer <mw*@mired.org> wrote:
>> 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 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.

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.

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

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
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[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
On 19-Oct-05, at 9:59 AM, Ed Jensen wrote:

Claudio Grondi <cl************@freenet.de> wrote:

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.
--
http://mail.python.org/mailman/listinfo/python-list

[Ed Jensen]

Kenneth McDonald <ke****************@sbcglobal.net> wrote:

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?