On Sat, Jan 25, 2003 at 06:39:06PM +0100, Daan Leijen wrote:
Hi Axel,
Because gtk2hs exists and is availabe on all three platforms, everybody gets the benefit of a complete, professional interface right now, so everyone should accept it as standard and not mourn about the slight differences in UI appearnce :-)
This is actually a rather good argument in favor of GTK. However, the GTK interface does not satisfy the constraint that it must be reasonably easy to implement. It runs on the XonX implmentation of MacOS X. So one could argue that it is already implemented.
People here expressed the wish for using the native UI elements and the native way of presenting information and interaction with the user (look-and-feel). I grant that Gtk does not deliver this on Aqua and not 100% on Windows.
If someone wants a backend for Aqua or whatever, it is extremely hard to create a gtk implementation from scratch. The world would be good place when gtk would be the standard library for writing gui's, but right now, the toolkit is mainly portable across unix platforms.
Again, for the log-book: gtk2hs runs on Win32, Unix and MacOS X.
I think existance is not a very good argument.
You are right about that. I should rephrase that: "since it is implemented for two different targets, it may be a good starting point for the definition of an (L) interface" -- I think it is quite hard to even come up with some interface that is just abstract enough to be implementable by a wide range of targets and is at the same time low-level enough that it is still reasonably easy to implement.
But that is the gist of the discussion so far, if I am not mistaken. The lower the common API, the harder it is to define it. That is why I proposed to craft an Object I/O interface which enables programmers to write GUI application with a native look and feel albeit with a reduced functionality (because not everything can be expressed with the native set of UI elements). If the programmer is happy with this functionality, fine - (s)he has a portable program with the native look-and-feel. If not, then (s)he has to write non-portable code portions for hToolkit, gtk2hs, a potential Aqua binding, or whatever backends people provide. Only some backend specific code can guarantee that the application is tailored to the platforms native look-and-feel when it comes to more difficult user interfaces.
That certainly seems a good idea to me. Participation of many people with different backends is fairly essential as the (L) interface will probably change and evolve a lot when different backends are added. To get people involved though, it may be good when the 'GUI task force' is able to define some initial (L) interface that people can try to write backends for. Yes, but in my point of view this should be a medium level API like Object I/O, a bunch of IO function is doomed to be defined by the underlying backends. This certainly holds true for the Ports library.
I think Wolfgang will have a hard time making a sensible port of Ports to Aqua. The point is that the "common GUI" interface must enforce invariants such as "each application has exactly one menu bar" or "each pushbutton must have a text in it". Otherwise bindings to Aqua will not be possible. You cannot define a common abstraction without looking at all the implementations you have to do. I think we want three backends: Win32, Gtk and Aqua. So we need to look at all of them before we define the interface. Axel.