Comparioson of purpose for PyGUI and AnyGUI ???

[Ron Stephens]

Can anyone give me a brief comparison of the purposes of these two
projects (AnyGUI and pyGUI)? In other words, how are the motivations
and goals for each project different?

Ron Stephens

 

[=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta]

And wax ?

 

[Alex Martelli]

layer). The real challenge is to make the devlopers of the various
extensions agree on the 'best' GUI API.

Even though a while ago I participated in the design of AnyGUI's API, I
believe Greg has the makings of a better API in PyGUI. And if you can
get one designer of a "competing" API to say that, there may be some
hope for a wider consensus;-).

A meta-consensus should be on the point that we need a Benevolent
Dictator, rather than pure design-by-committee, for this API -- Magnus
roughly played that BD role for AnyGUI, and Greg would be the natural
candidate for BD of a GUI based on PyGUI. The DB API has a committee
approach, but, while that may make it easier to reach consensus, it does
have its downsides. A BD can ensure progress at a more sensible pace
and architectural integrity. The fact that applications using the DB
API are a mess to make portable, because of the DB API's "politically
abstruse compromise" to allow DB modules to adopt very different
parameter substitution syntaxes, is an example of what I have in mind...


Alex

 

[Magnus Lie Hetland]

Even though a while ago I participated in the design of AnyGUI's API, I
believe Greg has the makings of a better API in PyGUI. And if you can
get one designer of a "competing" API to say that, there may be some
hope for a wider consensus;-).

I haven't examined Greg's API in detail lately, but the original
Anygui API was inspired by it. I do think Greg seems to have a knack
for simple and pragmatic solutions, while I may have a weakness for
'clever' and 'cute' (c.f. Anygui

There have been comments about elsewhere in this thread about a
fundamental issue in Anygui: The need to support many toolkits. This
was the raison d'être for Anygui in the first place -- it was supposed
to be a pure-Python module that would run (almost) anywhere,
regardless of which GUI toolkit the user/admin happened to have
installed.

Anygui succeeded as a proof of concept, but the burden of sustained
support and development for many toolkits did make it very impractical
to keep things going. At the moment the project is effectively on ice.

If Greg can make a reasonably full-featured system (which isn't too
hard to install/compile and has a native look on the major platforms)
I think that would be a major step toward a 'standard' GUI package for
Python. If not, there are existing packages (e.g. wx) that work very
well -- perhaps there really isn't a need for anything more standard
than that?

 

[Carlos Ribeiro]

Anygui succeeded as a proof of concept, but the burden of sustained
support and development for many toolkits did make it very impractical
to keep things going. At the moment the project is effectively on ice.

It's a shame. I've looked at it a few days ago, and I was actually
wondering if the development had stopped -- the newest news on the
site are quite old, in fact.

If Greg can make a reasonably full-featured system (which isn't too
hard to install/compile and has a native look on the major platforms)
I think that would be a major step toward a 'standard' GUI package for
Python. If not, there are existing packages (e.g. wx) that work very
well -- perhaps there really isn't a need for anything more standard
than that?

I'm hedging my bets on a related (but different) approach. I'm writing
business apps, and the style of interaction that I'm using doesn't
require a high degree of customization. It's a subset of the full GUI
approach, using simple data-entry forms and very little "live"
features. I want to be able to provide both native and browser based
frontends. The two versions do not need to work exactly the same way;
for example, some features may only be available on the native
front-end, but the API must degrade nicely in the case of unsupported
features.

How is it going to work? My idea is to have some kind of form
description API, with hooks for validation and live data lookups. The
engine will take care of the rendering either any of the frontends.
I'm doing some experiments with wxPython and DHTML, and the results
are promising. In a way, it's AnyGUI revisited with a web twist

The biggest problem with this kind of approach is not handling the
visual differences between different toolkits. There are workable
solutions for automatic layout, or to port common widgets between the
wxWidgets and the browser-based versions. The biggest issue is how to
handle architectural differences between a browser based app -- where
there is a clear separation betwen the server and client code -- and
the wxWidgets version, where no such separation is assumed. My
intention is to make the wxWidgets version mimic the browser-one in
this respect. For simple apps this is not as big an issue as one might
think, but for more complex ones, it may have a cost in terms of
flexibility and interactivity.

For now, I'm still experimenting. But it's being interesting to
explore both the similarities and the differences between the two
models, and what types of tricks can be used to bring the two
together.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Alex Martelli]

I haven't examined Greg's API in detail lately, but the original
Anygui API was inspired by it. I do think Greg seems to have a knack
for simple and pragmatic solutions, while I may have a weakness for
'clever' and 'cute' (c.f. Anygui

Yeah, I share that weakness, in terms of character, even though in my
case it's usually kept under control by a lifetime of experience (but
with Anygui we were "just having fun", so....

Anygui succeeded as a proof of concept, but the burden of sustained
support and development for many toolkits did make it very impractical
to keep things going. At the moment the project is effectively on ice.

Very good summary!

If Greg can make a reasonably full-featured system (which isn't too
hard to install/compile and has a native look on the major platforms)

I get the impression Greg isn't particularly interested in writing and
maintaining a Windows back-end (and I find hard to fault him for that: I
earn a living mostly developing for Linux, and whenever I possibly can I
use a Mac -- indeed, I deliberately walked away from years of expertise
programming for Win [[see http://www.aleax.it/TutWin32/index.htm]]
because I just couldn't stand it any more...!-). But surely _some_body
must be willing, able and motivated to work on that...? Or does
everybody in the world loathe Windows programming so much they will only
do it for financial gain?-)

I think that would be a major step toward a 'standard' GUI package for
Python. If not, there are existing packages (e.g. wx) that work very
well -- perhaps there really isn't a need for anything more standard
than that?

I think there _is_ a need for something as elegant as Greg's API to take
over, as the emerging de-facto standard, from wxWidgets' more
complicated approach (which wxPython mostly resembles). To be honest, I
am not adamant enough about it to buy a Windows computer and development
environment (when all of my computers today are Linux or Mac ones) AND
devote time and energy to Windows programming. But I do think it will
be a pity if everybody else, particularly people who _do_ like Windows,
similarly eschews involvement in PyGUI!-)


Alex

 

[John Lenton]

I'm hedging my bets on a related (but different) approach. I'm writing
business apps, and the style of interaction that I'm using doesn't
require a high degree of customization. It's a subset of the full GUI
approach, using simple data-entry forms and very little "live"
features. I want to be able to provide both native and browser based
frontends. The two versions do not need to work exactly the same way;
for example, some features may only be available on the native
front-end, but the API must degrade nicely in the case of unsupported
features.

what you describe is Cimarrón. Although there hasn't been an official
release, it is in use in a (very small) number of production
systems. Unfortunately I/we haven't had time to actually go for the
web side of the thing, but the idea is that it will (eventually) have
it.

How is it going to work? My idea is to have some kind of form
description API, with hooks for validation and live data lookups. The
engine will take care of the rendering either any of the frontends.
I'm doing some experiments with wxPython and DHTML, and the results
are promising. In a way, it's AnyGUI revisited with a web twist

we chose gtk2 instead of wx because gtk2 feels much more pythonic (to
us, at least). I'd be interested in knowing what you thought of for
the server side of the dhtml; we had thought about using twisted,
because its event-driven approach fits in very nicely with gui
programming.

Bah, dunno if there's any useful content for you in this mail...
Maybe an URL will help:

http://savannah.nongnu.org/cgi-bin/viewcvs/papo/cimarron/

Hmm, we haven't commited the last changes. I've got to tell styxman
off...

--
John Lenton ([email protected]) -- Random fortune:
El pescar con caña, requiere paciencia y maña.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBT2VPgPqu395ykGsRArmcAJ9DVThOKVoAD0sF1U+JmO5DnFQSNQCgiHD9
AaxfSH/y1c1r9ouqe33Lkt8=
=FoHK
-----END PGP SIGNATURE-----

 

[Carlos Ribeiro]

we chose gtk2 instead of wx because gtk2 feels much more pythonic (to
us, at least). I'd be interested in knowing what you thought of for
the server side of the dhtml; we had thought about using twisted,
because its event-driven approach fits in very nicely with gui
programming.

I've checked several web application environments. Just to mention a
few: Twisted, Quixote, Webware, Zope, and CherryPy. Zope is in a class
of it's own, as it's Twisted (for different reasons). For my
particular needs, I've chosen the simplest of all -- CherryPy. The
reason was the inclusion of a usable internal HTTP server option. It
eases testing, and makes possible to deploy applications almost
anywhere -- for example, any reasonably powered Windows workstation
can be a server with a surprisingly good performance. The reasoning
goes this way: for each business application where performance is a
problem, once can count a dozen of others that will have a handful of
simultaneous users, and in this scenario the hassle of running
Apache+Zope/Webware is just not worth it. Quixote was a close second:
it has a clean design, it's light, but the internal server is not as
convenient as CherryPy's one. Twisted is just too much for me: it's a
jack of all trades and a master of none, or at least that was the
impression that a reading of the documentation and other readers
experience suggested me.

p.s. CherryPy2 is still alpha, but the design rocks, in my opinion.
It's as light and pythonic as it can be.

p.s. Thanks for the pointer to Cimarron. I'll check it tonight.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Chris Barker]

in this scenario the hassle of running
Apache+Zope/Webware is just not worth it.

For what it's worth, there is a built-in server for Webware as well:

http://www.webwareforpython.org/Webware/WebKit/Docs/InstallGuide.html#built-in-web-server

There's also talk of a Twisted-Webware server, but I'm not sure
if/when that will materialize.

-Chris

 

[Carlos Ribeiro]

For what it's worth, there is a built-in server for Webware as well:

I've tried it too. It's heavier and less responsive than CherryPy's
one (at least in my machine, which is memory-and-GHz-impaired), and
less convenient. CherryPy is automatic in this regard.


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Richard Hanson]

[...] Or does everybody in the world loathe Windows
programming so much they will only do it for financial gain?-)

Or -- financial loss?


loading-RH9-tomorrow'ly y'rs,
Richard Hanson

 

[Andrea Griffini]

loading-RH9-tomorrow'ly y'rs,
Richard Hanson

OT but I can't resist.

Pay attention to what you're doing and please be sure
you're installing a very current very patched system.
I installed RH9 on a server (to replace an old machine
running RH6) and to my great surprise it lasted to the
wind of the internet about 6 hours before being rooted
by a romanian idiot.

Is it only the brand name the part I don't like in
windows ? I would say not.

Andrea

 

[Richard Hanson]

[I'm not aware of the local customs re CC'ing the poster being
replied to when changing the subject line to start a new thread. I'd
welcome advice if such is desired. So far, I've only replied
in-group.]

OT but I can't resist.

Glad you didn't resist!

Pay attention to what you're doing and please be sure
you're installing a very current very patched system.
I installed RH9 on a server (to replace an old machine
running RH6) and to my great surprise it lasted to the
wind of the internet about 6 hours before being rooted
by a romanian idiot.

Thanks very much for the heads-up.

As it happens, RH9 is the only relatively new distro I have CDs for.
(I'm on dialup, so DL'ing other distros is a bit onerous.) But, thanks
to your "JIT" warning, I shall immediately see about ordering a
different distro on CD from some online outlet and will forestall the
RH9 installation for the interim.

Can you or anyone recommend a better distro for an HP Omnibook 900B
laptop?

I currently have only a CardBus Xircom combo modem and ethernet card
(RBEM56G-100) for this machine -- do any distros support this card?
Or, can a different combo card be recommended? Perhaps a
recommendation for just a modem card?

Thanks for any advice!

(Email replies are welcome, if you wish. I apologize for the munged
email address in my sig, but I think spam tastes like crap and am
trying to avoid such. :-/ )

BTW: I'm not running a server (that I know of... -- I *am* still using
Windows... ). I'm looking for a decent Linux (or other Unix) for
personal use -- usenet, email, webbrowsing, and offline
personal-productivity stuff.

Is it only the brand name the part I don't like in
windows ? I would say not.

I'm getting *so* tired of spending my limited time and energy on just
*rebuilding* Windows machines. (I had to stick with Windows for some
time due to a family reunion book project I was working on -- the apps
I had available at the time were Windows-only, and the other
contributors were also using Windows-only software. Thankfully, that
seven-year project is now finally done -- so I can move on to a "real"
OS. Hardware reliability remains a problem, though.)

However, I also immensely dislike the ad-hoc and quite baroque Windows
et al GUIs. I think that the HCI problem has not been adequately
addressed on *any* of the popular platforms (to my knowledge). See my
soon-to-be-posted thread titled "[OT] 'Pre-announcement' of
Python-based 'computing appliance' project" for further info about my
work-in-progress.

Thanks again for the warning re RH9!


off-to-CheapBytes'ly y'rs,
Richard Hanson