[GUI] Towards a low level specification?

Vincenzo Ciancia ciancia@cli.di.unipi.it
Thu, 20 Mar 2003 01:29:26 +0100


On Wed, 19 Mar 2003 14:46:47 +0000
Axel Simon <A.Simon@ukc.ac.uk> wrote:

>   Gtk uses a very similar approach in that each event can have several
>   callbacks registered and you can remove each callback individually.
>   So I think my proposal serves this 1:n correspondance

I can think of many other ways to solve the problem. And, besides, I can
see many other ways to initialize, and access fields of, widgets and
things that have properties, in general.

Now I play the role you played against me last week :) : if all the
toolkits allow it, can we have function wich take no initializers, and
provide get and set functions for attributes? Other approaches are
implementable on top of this really weird interface.

This is an attempt to lower the priority of the problem of handling
local state of the widgets. 

When we have a strong basis well built, and working flawlessly on
various platforms, we can create teams to standardize the mid-level
syntax.

Now, I know that I was saying the opposite last week; you really
convinced me that it's best to solve low-level issues before mid-level
ones, and I wish people on the list to have time to elaborate what the
various alternatives can be.

Besides, I see a very clear distinction between what's low-level and
what's mid-level:

- low level is everything that needs FFI and/or writing to handles to be
implemented.

- mid level is everything that can be implemented in haskell, over the
low level ground.

So, I ask to everybody: would it be right to provide a working low-level
interface, in the IO monad, even if it sucks completely, call it "the
CGA core", and ONLY THEN think about issues as initialization syntax and
a nice way to handle local state? 

Note that this does not mean that we'll claim that our work is finished,
when we have the core. Instead, we'll really focus on the mid-level, and
produce a good one, before declaring the CGA as a standard; this is
necessary IMHO.

Let's vote for this, here are the two alternatives

1. to have at least a simple syntax wich is not like an assembly
language is good, and comfortable even when writing the low-level stuff;
so it's better to design some standard mid-level interface right now

2. by designing a weird interface in the IO monad, similar to the ones
we find in traditional imperative languages, we will produce the core
much faster; it will be minimal and open to other implementation; also,
people will have more time to think to nice syntaxen and the state
handling issues; so it's better not to do any mid-level stuff right now.

I obviously vote for 2, but I prefer to count much less than other, more
experienced people on this list.

Vincenzo