[GUI] Re: Gtk and Object I/O

[Adrian Hey]

On Friday 24 January 2003 04:43, seth@cql.com wrote:
> I, too, would have concerns about this approach, for some of the same
> reasons and for a couple of others.
>
> First, there is a proxy available for X which cuts down on the amount of
> traffic.  This ameliorates the problem of running on a slow network, but
> definitely does not eliminate it.
>
> In fact, X generates tons of clear text traffic (or gets slowed down even
> more by using an ssh tunnel, pick your poison).  I would prefer that any
> substantial development effort would eliminate this deficiency, but without
> giving up the X model where displays are independent of code.  Not trivial,
> but not impossible either.
>
> I agree with Glynn (I hope I'm paraphrasing accurately) that it is
> impractical to support look and feel modularity and also write primitive
> window management code.  It isn't that it is technically impossible, it is
> just a massive effort and one would want to see convincing evidence that
> such an effort is worthwhile.

I don't disagree, but my solution is to give up the goal of native
look and feel as part of the *standard*. If people want to put some
effort into doing this anyway, on top of the standard primitives
thats fine, it's their choice, it's *not compulsory*.

What you and Glynn seem to be suggesting is preserving native look and
feel by writing non trivial Haskell bindings, all presenting the same api,
to a variety of non trivial and completely different native gui libraries.
I think that's a huge amount of work.

My proposal is also a huge amount of work, but..

 The overwhelming bulk of any real high level gui library will be written     
 entirely in Haskell, with all the advantages that should bring.

 It only has to be written once. Not again, and again, and again..

 The only porting effort is a relatively small (IMHO) set of standard
 primitives, yet to be defined.  

I also tend to agree with Anthony's view about it being to early
to standardise a high level gui api for Haskell. In fact I'm not sure
there's a good reason to ever standardise such a thing. Why shouldn't
we have several competing "experiments" with gui's? But I think it would
assist portability of such experiments they could all rely on a well
supported and carefully chosen set of primitives.

Please also understand that I'm not suggesting that if such a standard
set of primitives defined, their use should be compulsory. If gui
library designers want to use something else, that's fine, but in
that case they'll have to address the portability issue some other
way (assuming they want portability).

Regards
--
Adrian Hey