Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Comparioson of purpose for PyGUI and AnyGUI ???

Reply
Thread Tools

Comparioson of purpose for PyGUI and AnyGUI ???

 
 
Ron Stephens
Guest
Posts: n/a
 
      09-16-2004
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
 
Reply With Quote
 
 
 
 
=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta-galactique_non_trivial?==?iso-8859-1?Q?e_en_fuite
Guest
Posts: n/a
 
      09-16-2004
And wax ?


 
Reply With Quote
 
 
 
 
Alex Martelli
Guest
Posts: n/a
 
      09-18-2004
Francesco Bochicchio <(E-Mail Removed)> wrote:
...
> 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
 
Reply With Quote
 
Magnus Lie Hetland
Guest
Posts: n/a
 
      09-18-2004
In article <1gkb1xb.13ayfy1rayeymN%(E-Mail Removed)>, Alex Martelli wrote:
>Francesco Bochicchio <(E-Mail Removed)> wrote:
> ...
>> 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.




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?

--
Magnus Lie Hetland Fallen flower I see / Returning to its branch
http://hetland.org Ah! a butterfly. [Arakida Moritake]
 
Reply With Quote
 
Carlos Ribeiro
Guest
Posts: n/a
 
      09-18-2004
On Sat, 18 Sep 2004 12:26:29 +0000 (UTC), Magnus Lie Hetland
<(E-Mail Removed)> wrote:
> 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: http://www.velocityreviews.com/forums/(E-Mail Removed)
mail: (E-Mail Removed)
 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      09-18-2004
Magnus Lie Hetland <(E-Mail Removed)> wrote:
...
> 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
 
Reply With Quote
 
John Lenton
Guest
Posts: n/a
 
      09-20-2004
On Sat, Sep 18, 2004 at 10:13:53AM -0300, Carlos Ribeiro wrote:
>
> 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/v...papo/cimarron/

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

--
John Lenton ((E-Mail Removed)) -- Random fortune:
El pescar con caña, requiere paciencia y maña.

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

iD8DBQFBT2VPgPqu395ykGsRArmcAJ9DVThOKVoAD0sF1U+JmO 5DnFQSNQCgiHD9
AaxfSH/y1c1r9ouqe33Lkt8=
=FoHK
-----END PGP SIGNATURE-----

 
Reply With Quote
 
Carlos Ribeiro
Guest
Posts: n/a
 
      09-21-2004
On Mon, 20 Sep 2004 20:18:39 -0300, John Lenton <(E-Mail Removed)> wrote:
> 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 Removed)
mail: (E-Mail Removed)
 
Reply With Quote
 
Chris Barker
Guest
Posts: n/a
 
      09-21-2004
Carlos Ribeiro <(E-Mail Removed)> wrote in message

> 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/Webw...-in-web-server

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

-Chris
 
Reply With Quote
 
Carlos Ribeiro
Guest
Posts: n/a
 
      09-21-2004
On 20 Sep 2004 23:21:03 -0700, Chris Barker <(E-Mail Removed)> wrote:
> Carlos Ribeiro <(E-Mail Removed)> wrote in message
>
> > 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:


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 Removed)
mail: (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
PyGUI - Couple of questions - TextField callbacks and drop downlist.... Hugh Python 2 10-21-2008 09:16 AM
A problem while using anygui Johnny Lee Python 0 09-30-2005 08:08 AM
anygui,anydb, any opinions? rzed Python 38 06-11-2005 11:14 PM
Fontproblems with PyGUI and gtk 2.4.10 Marc Christiansen Python 0 09-21-2004 09:29 PM
Re: Comparioson of purpose for PyGUI and AnyGUI ??? Simon John Python 5 09-18-2004 07:53 AM



Advertisments