Phil Hunt philh at
Wed Aug 25 21:05:33 CEST 1999

In article < at>
           irclark at "Isaac" writes:
> On Wed, 25 Aug 1999 03:02:30 GMT, Christopher B. Browne 
> <cbbrowne at> wrote:
> >This of course has the classic problem that
> >
> >  You can only usefully include things in "Parrot" that are
> >  expressible in all of the GUI systems, thereby reducing Parrot to a
> >  Lowest Common Denominator.
> >
> >That's not 100% true; there *could* be Parrot features that would be
> >ignored on platforms that did not support them.  Some danger lies down
> >that road...
> As long as they weren't silently ignored,

Errors, and features not implemented on the particular backend
chosen, will be written to a log file, and to stdout.

> it wouldn't really be dangerous.
> The least common denominator for say GTK and motif is actually fairly
> useful. 

Indeed; most GUIs are based on CUA -- a 1987 specification -- and
there's been little innovation in the last 10 years. Tabbed dialogs
are an obvious exception to that rule.

> What really makes this kind of tool hard to write is the differing 
> component placement algorithms from one toolkit to the next.   You
> probably won't easily be able to support all of the options for a
> every toolkit.  Phil's syntax for parrot suggests a certain type
> of geometry manager.  Toolkits that won't support that manager
> will probably be the most difficult to support with Parrot.

This is true. If a GUI toolkit doesn't have an analog of rowLayout
or colLayout, a Parrot backend for that GUI would have to include
an implementation of those layout managers.

Phil Hunt....philh at

More information about the Python-list mailing list