Re: [GUI] Re: Gtk and Object I/O

On Thu, Jan 23, 2003 at 08:26:57AM -0800, Krasimir Angelov wrote:

--- Axel Simon 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.

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

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. 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.