[GUI] Proposal Proposal: haskell-gui addendum to haskell standard

[Krasimir Angelov]

--- Peter Achten <peter88@cs.kun.nl> wrote:
> Krasimir Angelov has 
> tried to port it to GTK, and says that the OS
> dependent layer apparantly 
> still has an OS bias that makes it less suitable for
> GTK. He mentions the 
> following differences:
> 
> [Krasimir Angelov at: 02:21 20-1-03 -0800]
> >    * The GTK cannot draw rotated text and rotated
> >elipses. This depend on restrictions imposed from X
> >server.
> >    * The Win32 backed lack powerful text formating
> >features like these given from PANGO.
> >    * The Font families given in the GTK and Win32
> are
> >rather different. The font management are still
> >similar on each platform.

The differences aren't mentioned in relation with 
ObjectIO. This is simple a list of differences which 
I found during development of HToolkit. The HToolkit 
low level uses a pieces of C code which was initially 
written for ObjectIO. When tried to extend drawing 
primitives offered from ObjectIO I found these 
limitations. I don't think that this is problematic.

> * I don't see why one would need these text
> formatting features in this 
> context. Perhaps Krasimir can explain this?

I just mentioned this to be exhaustive.

> * Font family naming conventions already depend on
> the particular set of 
> installed fonts on a machine. A decent program can
> therefore never assume 
> the existence of whatever font, and it should try to
> find out this 
> information via the OS.

I am completely agree. This is the usual behaviour
which application can have.

> The two-layered approach also 
> does not exclude a port to a platform indepent
> toolkit, so that might serve 
> as a starting point.

Absolutely. I think that it is easy to build Port and
HToolkit under Windows using GTK. 

> Finally, a well-documented and well-defined OS 
> dependent layer will ease the development of
> high-level GUI libraries. 

This was the main goal to split HToolkit in two parts:
Port and HToolkit. Thanks to Daan Leijen for Help.
Over the Port library someone can implement implement
another high-level libraries (maybe like ObjectIO).

> [Axel Simon at: 14:45 23-1-03 +0000]
> >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. 
[cut]
> This has partially been answered by Krasimir. In
> addition, I would say that 
> the answer to these differences is abstraction. As
> an example, consider 
> resizing of controls. In Object I/O, a control can
> have a resize attribute 
> that defines its size in terms of the size of (one
> of) its parent(s). When 
> put in a resizeable parent object that is resized,
> it will resize according 
> to its attribute. If the platform does not allow
> resizeable 
> dialogs/windows, then that is no problem. 

The dialogs/windows can have IsResizeable attribute
which will specify whether the window can or cannot be
resized. The default value for this attribute will
depend on OS. For windows the default will be true
under both GTK and Windows, but for dialog will be
true under GTK and false under Windows.

Cheers,
Krasimir

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com