--- Axel Simon
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.
The Dialogs in Windows also can be resizeable. See: http://www.codeproject.com/dialog/cresizeablefiledialog.asp for example. The example is for MFC but the principle it is also usable with raw Win32 API.
Buttons on Aqua cannot have icons in them, scrap icons in Gtk and Windows button.
The buttons in Windows has BS_OWNERDRAW style. Using this style the programmer can draw its own content inside the control. This allows to implement "Icon Button" and there are many examples how to make this.
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.
There are two solutions: - The library can support two widget types: 1) ListView - multicolumn view without hirerarhical view 2) TreeView - single column hirerarhical view This reduces advantages of multicolumn GtkTreeView under GTK. I think that is not good idea. - Development of custom multicolumn TreeView under Windows and using GtkTreeView under GTK. There are many already developed multicolumn TreeView controls for MFC. The best implementation which I know is a Stingray CTreeView control. Unfortunately the Stingray Objective Studio isn't freeware and also it requires MFC. Scrap Window's concept of
groups in dialog and keyboard accelerators in general since Aqua doesn't know about hotkeys.
I haven't any experience with MAC platform and don't know any workaroud. Is it too important?
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).
The only real MFC control is CSplitterWnd control. All the rest MFC controls are just wrappers around standard "Common Controls" implemented in "comctl32.dll".
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:
I think that the reduction can be minimalized.
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.
I completely agree, support for single backend is easier than support of the three: GTK, Win32 and Aqua. Best wishes, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com