UI toolkits for Python

Claudio Grondi claudio.grondi at freenet.de
Sun Oct 16 20:42:00 EDT 2005


"Steve Holden" <steve at holdenweb.com> schrieb im Newsbeitrag
news:mailman.2128.1129455388.509.python-list at python.org...
> Claudio Grondi wrote:
> > "Kenneth McDonald" <kenneth.m.mcdonald at sbcglobal.net> wrote in
> > news:mailman.2032.1129236372.509.python-list at python.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       +44 150 684 7255  +1 800 494 3119
> Holden Web LLC                     www.holdenweb.com
> PyCon TX 2006                  www.python.org/pycon/
>






More information about the Python-list mailing list