Re: State, Attributes and Some basic widgets

Wolfgang Thaller wrote:

> >> Can this reasonably be
> >> inside the scope of a cross-platform library? (We might still have
> >> platform-specific extensions for this, but that's none of my 
> >> business).
> >
> > Yes; a platform which has no concept of separate screens will only
> > ever have screen 0 (i.e. like most of the boxes which run X).
> 
> Well, it looks like platform-specific extension to me...
> 
> You'd have
> 
> myWindow <- window DocumentWindow [... attributes ...]
> 
> ... which uses the default screen for Xt, and for Xt only, you'd have 
> something along the lines of
> 
> myWindow <- windowOnScreen_XT 2 DocumentWindow [... attributes ...]

No:

myWindow <- window DocumentWindow [ screen =: theScreen, ... attributes ...]

[Actually, you also have to force the visual and colourmap, but the
point is that it's simply a matter of setting attributes. If you
registered string-to-screen etc type converters, the user could choose
the screen via resources.]

In any case, I'm less concerned about providing a specific mechanism
to allow the use of alternate screens, and more concerned about
ensuring that the rest of the API doesn't fail badly if the windows
aren't all on the same screen.

> >> A few things that need working out are:
> >>
> >> a) What types and classes should be used to represent widgets in 
> >> Haskell?
> >
> > Even if you have specific types for specific widget classes, you
> > definitely need a generic Widget type, and any operation which could
> > reasonably be expected operate on any widget should.
> 
> Probably. The question is, to what extent do we use type classes to 
> achieve this, etc...
> I would advocate specifc types for specific widget classes (e.g. 
> Button, ScrollBar, etc.), just because it's the Haskell Way ;-) .

Unfortunately, it's not the "typical GUI toolkit" way; at least, both
Xt and Qt have an OO-style class hierarchy. While they differ on the
exact hierarchy, both have a generic "Widget" class, with operations
which apply to all widgets.

> If we also have a general Widget type, we could have functions like
> 	fromWidget :: Widget a => Widget -> Maybe a
> and
> 	toWidget :: Widget a => a -> Widget

Having a generic Widget type only helps if there are functions which
actually operate upon it.

-- 
Glynn Clements <[email protected]>