By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,564 Members | 810 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,564 IT Pros & Developers. It's quick & easy.

Comparioson of purpose for PyGUI and AnyGUI ???

P: n/a
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
Jul 18 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
Francesco Bochicchio <bo*****@virgilio.it> 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
Jul 18 '05 #3

P: n/a
In article <1g****************************@yahoo.com>, Alex Martelli wrote:
Francesco Bochicchio <bo*****@virgilio.it> 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]
Jul 18 '05 #4

P: n/a
On Sat, 18 Sep 2004 12:26:29 +0000 (UTC), Magnus Lie Hetland
<ml*@furu.idi.ntnu.no> 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: ca********@gmail.com
mail: ca********@yahoo.com
Jul 18 '05 #5

P: n/a
Magnus Lie Hetland <ml*@furu.idi.ntnu.no> 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
Jul 18 '05 #6

P: n/a
Alex Martelli wrote:
[...] Or does everybody in the world loathe Windows
programming so much they will only do it for financial gain?-)


Or -- financial loss? :-p
loading-RH9-tomorrow'ly y'rs,
Richard Hanson

--
sick<PERI0D>old<P0INT>fart<PIE-DEC0-SYMB0L>newsguy<MARK>com
Jul 18 '05 #7

P: n/a
On Tue, 21 Sep 2004 20:17:26 -0700, Richard Hanson <me@privacy.net>
wrote:
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
Jul 18 '05 #8

P: n/a
[I'm not aware of the local customs re [b]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.]

Andrea Griffini wrote:
On Tue, 21 Sep 2004 20:17:26 -0700, Richard Hanson <me@privacy.net>
wrote:
loading-RH9-tomorrow'ly y'rs,
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

--
sick<PERI0D>old<P0INT>fart<PIE-DEC0-SYMB0L>newsguy<MARK>com
Jul 18 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.