UI toolkits for Python

[Claudio Grondi]

"Steve Holden" <steve at holdenweb.com> schrieb im Newsbeitrag
news:mailman.2143.1129532422.509.python-list at python.org...
> Claudio Grondi wrote:
> > "Steve Holden" <steve at 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?
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