[GUI] Re: Gtk and Object I/O

[Axel Simon]

On Thu, Jan 23, 2003 at 08:26:57AM -0800, Krasimir Angelov wrote:
> 
> --- 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.
But that is not the natvie look-and-feel of Windows, is it?

> > 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.
As above, you can make Windows do these things, but that means you're 
loosing the native look-and-feel. The existence of a native look-and-feel 
under Unix is definitely questionable, but even on Windows you have Win32 
applications (most simple 3rd party stuff) and MFC applications. In the 
latter for example you have icons in buttons and menu items when these 
actions are present in the task bar. Furthermore, I think I've seen icons 
in Wizards' "Next ->" and "<- Previous" button. So it's already difficult 
to say what this native look-and-feel for Windows is.

> 
> > 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.
But why making it so difficult? Installing Gtk on Windows for development 
is already quite time-consuming. Maintaining the binding to all these 
libraries (which might not be supported after a while) will be a 
nightmare.

> 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?
How important is a native look-and-feel? It's on position 4 of my priority 
list as it is such an elusive concept.

> > 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".
Ok. I thought most of the newer UI elements were exclusivly available via 
MFC.

<snip>
> I think that the reduction can be minimalized.
<snip>
> I completely agree, support for single backend is
> easier than support of the three: GTK, Win32 and Aqua.


So I wonder: where is the advantage of writing a common-subset layer? Gtk 
applictaions look a lot like Windows and will disappoint any Aqua user. 
But its look-and-feel is closer to Windows than say Java Swing. A snapshot 
of a Gtk2hs program on Windows:
http://www.cs.ukc.ac.uk/people/staff/as49/windows.png

Cheers,
Axel.