
--- Peter Achten
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).
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
[Axel Simon at: 14:45 23-1-03 +0000] 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