Good day,
and apologies for this very long message.
On Mon, Jan 20, 2003 at 09:38:41AM -0000, Simon Peyton-Jones wrote:
> I don't think we are waiting for critical user mass. We're waiting for
> critical *designer/developer* mass!
Yes, I guess that's what I wanted to say.
So it is all about acceptance of a toolkit by the programmer. I think a
GUI toolkit is more acceptable to a programmer if it fulfills the
following (highest priority first):
a) it is portable, i.e. programs written to use the GUI library should
behave the same on Win32/X/Aqua (MacOS)
b) it is functional, i.e. the programmer finds all GUI elements a modern
application needs and has the ability to create custom widgets
c) it is stable, i.e. the library's API doesn't change too quickly,
ideally not at all
d) it looks as if written with the native API of the platform
I thought b) came before a), but due Simon's comment I swapped them:
> Speaking as a potential user of such a library, I would absolutely love
> to have a Haskell GUI library that
> was available in some form on each major platform
> was supported by a bunch of people, so I could have
> some confidence in its continued existence
> Its exact capabilities are less important: (a) I'd adapt my program to
> fit what was available, and (b) I'm sure it would evolve in response to
> user feedback. I'd accept compromises in functionality to gain
> portability; it'd be OK to have
> some platform-specific sexy bits. Worse is better.
Let's assume we have a lot of time and nobody is in need of a GUI library
right now.
For a portable library, we need some layer which is common to all OSes.
The question is thus: Where shall we have the common interface between a
fixed Haskell API and the specific OS API if we want to minimize the
penalty for b) functionality, c) stability and d) look-and-feel.
Two main proposals are:
1) Create a common high level layer on top of all native OSes (in C) and
then bind to Haskell. Example: HToolkit+Ports
2) Use the native OS functions just for drawing. Create every UI item from
scratch. Example: Gtk and gtk+hs/gtk2hs
regarding 1):
This proposal is geared towards d), look-and-feel. It is nice to have a
program which looks as if written with the native API. I think it's
impossible, some flame:
Dialogs in Windows are specified in dialog units, i.e. they scale with the
font size but cannot be resized by the user: scrap Gtk's dynamic sizing
capability. Buttons on Aqua cannot have icons in them, scrap icons in Gtk
and Windows button. Scrap Aquas hierarchical view in several columns
(could be simulated if Windows supports adding columns on the fly, Gtk
would), scrap additional columns next to a hierarchical tree since Windows
doesn't support that. Scrap Window's concept of groups in dialog and
keyboard accelerators in general since Aqua doesn't know about hotkeys.
AFAIK a lot of UI elements on Windows which are considered "standard" are
implemented in the Microsoft Foundation Classes. Thus to actually use
these, one has to use the MFC written in C++ (or .net).
I know that these are all minor issues which could be circumvented, but
where does the native look-and-feel go? Furthermore, this "finding the
common subset" approach will certainly lead to a reduction in b)
functionality. Simon PJ said:
> (a) I'd adapt my program to fit what was available
I wouldn't even start a *bigger* project if I would know that I hit some
limits later in the development, but that's my view.
> (b) I'm sure it would evolve in response to user feedback
This could mean a reduction in c) stability. A major point is that you
need to consider *all* platforms before you create any abstraction layer.
Otherwise you will have a serious problem with stability. It would be very
advisable to use a library of people who have successfully found a common
subset of all OSes instead of reinventing the wheel. If we need to do it
from scratch, then that could indicate that nobody has ever managed to
find this common subset. Well, Sengan said:
> I have seen many positive comments about IBM's SWT which
> works on the following platforms:
> <...everything you ever wished for...>
So maybe this is such a library. Is it complete? How is the look-and-feel?
--------------------------------------------------------------------------
regarding 2):
Using a layer which only builds on the native drawing capabilities is
surely easier to port. The b) functionality is quite good in the case of
Gtk. It lacks support for sound, but supplies most UI elements known from
e.g. Windows. The c) stability is not so much of a concern as the
primitive drawing functions will not change that quickly.
I would like to apply the "Worse is Better" principle to d) look-and-feel.
In the example of Gtk, the inventors have gone through quite some hassle
to make the UI changeable. You can tweak the buttons to have the same color
and fonts as on Windows, though you cannot change the fact that dialogs
are resizable or that buttons have no icons and flash blue if they are the
default buttons (Aqua). Gtk is not ported to Aqua but runs under the XonX
port of Windows.
Last but not least any GUI library has to be maintained. Win32/MFC, Gtk
(or Qt) and Aqua will all evolve over time. Using a single library like
Gtk reduces the burden of keeping the Haskell library up to date to a
single backend. Gtk has many more users as it has bindings to many other
languages besides C. Thus the amount of people who can iron out problems
with the ports to other platforms is much bigger.
------------------------------------------------------------------------
I did not discuss the issue of how much time it needs to implement the
different concepts, that could be another email.
Hope these arguments are not too biased,
Axel.
