[GUI] RE: GUI Library Task Force

[Manuel M. T. Chakravarty]

"Simon Peyton-Jones" <simonpj@microsoft.com> wrote,

> [replying to the GUI list]
> 
> I don't have a strong opinion myself -- I'm just advocating a little
> careful study, since Clean has a lot of experience.

Yes, definitely.

> It might be worth
> asking Peter Aachten for his advice/ideas.   Invite him to join the
> list?

True - that might be a good idea.

> | * It integrates facilities for concurrent and distributed
> |   programming (asynchronous communication via channels).  I
> |   still think, we can keep the GUI API and concurrency as
> |   two orthogonal features.  If you take these features out
> |   and use IORefs instead of MVars, you are already quite
> |   close to the model that we currently aim at.
> 
> Definitely agree to keep them separate.  But I do think the GUI
> API should perhaps conceal whether it's using IORefs or MVars,
> since in a concurrent system one will certainly want to use the latter.

The goal for the Haskell GUI is to conceal this *and* to use
neither of the two in the GUI library implementation.
That's a property that I can't yet see how it can be
realised with the Clean IO.

> | * After this, the main difference that remains is the
> |   representation of GUI components as a vanilla data type
> |   instead of opaque handles that do not make the structure
> |   of the components explicit in the types (like the TupLS
> |   does).  From the paper, it wasn't clear to me how useful
> |   that is for the application programmer.
> 
> This is indeed the most significant feature.  It has the merit
> that there is a data structure that acts as a description of the
> GUI, which has some conceptual clarity, for me anyway.
> Instead of building up a model in your head, there it is written down
> (you can presumably even print it out).
> 
> Not so good when the GUI shape is changing -- I wonder how
> Clean does that.

Another problem is extensibility, as the data declaration,
eg, commits to the possible properties and supported
callbacks of a widget.  After having used GTK+, where all
this is dynamically defined, this seems quite restrictive to
me.

But I completely agree with you.  We need to take into
account all the experience that is out there.  (It's little
enough anyway.)

Cheers,
Manuel