[GUI] Re: Gtk and Object I/O

[Krasimir Angelov]

--- Axel Simon <A.Simon@ukc.ac.uk> wrote:
> 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