Parrot-0.0.1

[Phil Hunt]

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
> 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 vision25.demon.co.uk