[GUI] Re: Know you backends

[Daan Leijen]

Dear Axel,

> > I am also in favor of a medium level GUI interface. If I gave another
> > impression, that is my fault.
> Well, Ports is very low level like gtk2hs, since it is merely a wrapper
> around the C functions of HToolkit.

Well, the Port library is still medium-level. For example, the call "createWindow :: IO
WindowHandle",
basically creates a window with a working event loop, default handlers, a canvas,
automatic scroll bars and a seperate world and view domain. It basically provides
the core-functionality needed for ObjectIO (or something) but no utility functions
type safety, or abstraction.

> but if the Clean low level layer (L) which is written in C was
> portable, why don't we use that layer directly? Why did Krasismir start
> with HToolkit?

That is a good question. Personally, I would have preferred to see a GTK port
of the low-level layer of Clean  This would also allow us to work together
with the Clean people, they have an excellent compiler and lots of experience with
GUI's, and it could foster more exchange of knowledge between both communities.

Maybe Krasimir can tell us more about the issues involved?

(However, I can also live with Port since it seems much smaller and more tractable than the Clean
layer.)

This actually brings me to another issue I have been wondering about.
Why don't we use the GTK library as our portable GUI library directly?
I may have missed some discussions about this, but if it is a really portable
library, we can use the fruits of their labor. (Of course, it does need to
give a native look and fool, I wonder whether GTK does that?)

> I do not like the evolutionary approach. It will lead to an API which
> changes a lot.

Well, we both started out as amoebes but evolutionized into beings that use
electrical signals to exchange opinions about how to create specific patterns on
cathode ray tubes :-)


But seriously. We are trying to create a medium-level interface. The Port
approach is to create that using two layers: one core medium-level interface
(Port) and a convenience layer on top of that, using abstraction, overloading
etc (GIO/Htoolkit). The advantage is off course that more work is shared
and less work is needed for a different platform. Furthermore, the design of the
convenience layer is seperated from the implementation of the core functionality.
This is more important than it looks -- I think many truly useful libraries have
failed because they didn't have this distinction. This made it too hard to port
the library since there were too many dependencies on the platform. I think
this happened for example with TkGofer and Haggis  (still a wonderfully
complete and documented! library)

The disadvantage might be that Port is too low-level to bind to the GTK+HS
binding but I don't think that this is the case. Maybe you can say more
about this later.

> And the reason I'd like to have (A) as the common layer is:
> - We could both put an Object I/O layer on top of our libraries. If we use
> the same core functionality, it would enable people to easily migrate
> their applications from one specific backend to the common API.


The other approach, that you are proposing, is to define just one medium
level interface (with abstraction and all) and to implement backends for
each platform directly. The advantage is that it probably easier to support
more backends. The disadavantage is that you need to do more work
for a port.

However, it is not yet clear how that level should look like. We could take
the ObjectIO interface as our layer but I would not recommend that.
Note, this is not a critique on the ObjectIO library, I highly respect the work
of the Clean people, and Peter van Achten in particular. However, the Haskell
ObjectIO interface should be heavily revised to fit better in the style of Haskell.
Right now, it is still influenced by the non-monadic uniqueness style of Clean.
For example, the generation of identifiers (openId) is quit unsafe. In the Haskell
tradition we would use a monadic bind to name widgets.  ie.

>  w <- window []

instead of

>   w <- openId
>   openWindow ... [ WindowId w, ...]

Other things are the widget attributes that are specified using constructors. A more Haskellish
style
would use function names instead of constructors (as to be able to abstract from them) and use type
classes for grouping them (as to prevent using illegal attributes on a certain widget). i.e.

>  w <- window [title =: "My window" ]

instead of

>   w <- openId
>   openWindow ... [ WindowId w,  WindowTitle w...]

This is basically what I am trying to do in the GIO library. However, even than, there
are still tons of other design decisions to make, I wonder whether consensus can ever
be reached.

All the best,
    Daan.

ps. I am quite curious about what you think of Port. If it is high-level enough, it
may serve the role of a core-functionality interface and you could create a
port layer on top of gtk2hs.  You can browse the interface directly at:
http://htoolkit.sourceforge.net