philh at vision25.demon.co.uk
Wed Aug 25 21:05:33 CEST 1999
In article <slrn7s6o94.im.irclark at latveria.castledoom.org>
irclark at latveria.castledoom.org "Isaac" writes:
> On Wed, 25 Aug 1999 03:02:30 GMT, Christopher B. Browne
> <cbbrowne at news.brownes.org> 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
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 vision25.demon.co.uk
More information about the Python-list