+-------------------------------------------------------+ | ANNOUNCEMENT: HToolkit 1.0 released | +-------------------------------------------------------+ | author: Krasimir Angelov | | www : http://htoolkit.sourceforge.net | | forum : mailto://htoolkit-users@lists.sourceforge.net | +-------------------------------------------------------+ The HToolkit is a package primary intended for development and designing of platform independent graphical user interface. The package gives you an abstract API for many platforms while for each platform are used only libraries which are native for the platform. This release supports only Windows and Linux platforms, but the chosen model allows support for other platforms. Under Windows the package use only native Win32 API and under Linux are used GTK/GNOME libraries. The difference between HToolkit and most of other libraries is that the latter uses only controls and dialog elements which are native under target plaform. The advantage of this is that the application looks like more native. Similar model is chosen from wxWindows for C++ and SWT for Java. The disadvantage of this libraries is that they are written in high level languages and this makes difficult to use them from other languages. The main part of HToolkit is written in C and the used model simplifies FFI interface between the HToolkit core and high level languages (most languages proposes only FFI to C). The current release gives only interface to Haskell. There is plan to build GUI libraries based on HToolkit core for C#, SmallTalk and Python. HToolkit for Haskell -------------------- HToolkit �� Haskell is divided in two libraries: GIO and Port. The Port library is a low level interface and it is not intended to be used for development. Port includes modules written in C and FFI for them written in Haskell. GIO is a high level API intended for application development. The HToolkit is divided in high and low level in order to allow development of experimental high level interfaces without sacrifice of low level API. For the time beings HToolkit gives all features proposed from ObjectIO with exception of ToolBar and CustomControl. Many of ObjectIO features are extened, but there are also many new features which does't exists in ObjectIO. Relatively all controls supported from wxHaskell are supported from HToolkit. Still missing controls like Panel, Gauge and Notebook but they are planned for the next release of HToolkit. Currently the HToolkit is the only package for Haskell which allows to create, load, edit and save images at runtime. Another interesting feature is that the toolkit allows to display icons in menu items. The feature is native under GTK/GNOME but is hard to implement under Windows. NOTE: The ToolBar support is included in the package but still doesn't work. This is because under Windows it still requires a bit of development while under GTK/GNOME the package uses the new API for GtkToolbar which will be part of the next GTK release. Krasimir Angelov __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Tuesday, 2003-07-22, 20:42, CEST, Krasimir Angelov wrote:
[...]
The HToolkit is a package primary intended for development and designing of platform independent graphical user interface. The package gives you an abstract API for many platforms while for each platform are used only libraries which are native for the platform. This release supports only Windows and Linux platforms, but the chosen model allows support for other platforms. Under Windows the package use only native Win32 API and under Linux are used GTK/GNOME libraries. The difference between HToolkit and most of other libraries is that the latter uses only controls and dialog elements which are native under target plaform. The advantage of this is that the application looks like more native.
Hello Krasimir, good work! I like the direction you go with your library.
[...]
The current release gives only interface to Haskell. There is plan to build GUI libraries based on HToolkit core for C#, SmallTalk and Python.
Oh, this is exactly what I proposed with Ada in mind: a platform independent C interface to which one can create bindings from different programming languages. By the way, are you still using functions with an arbitrary number of arguments? (I mean those declared with the ellipsis, like printf.) This would be a problem when creating Ada bindings. But meanwhile I'm not so interested in Ada bindings anymore, but rather am looking for a good Haskell GUI library ;-).
[...]
Krasimir Angelov
Wolfgang Jeltsch
--- Wolfgang Jeltsch
[...] Oh, this is exactly what I proposed with Ada in mind: a platform independent C interface to which one can create bindings from different programming languages.
By the way, are you still using functions with an arbitrary number of arguments? (I mean those declared with the ellipsis, like printf.) This would be a problem when creating Ada bindings. But meanwhile I'm not so interested in Ada bindings anymore, but rather am looking for a good Haskell GUI library ;-).
The functions with an arbitrary number of arguments are problem for both Haskell and Ada. I use only functions constant number of arguments and the arguments are always of scalar types (int, BOOL, char *, ...). Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
On Wednesday, 2003-07-23, 10:11, CEST, Krasimir Angelov wrote:
[...]
By the way, are you still using functions with an arbitrary number of arguments? (I mean those declared with the ellipsis, like printf.) This would be a problem when creating Ada bindings. But meanwhile I'm not so interested in Ada bindings anymore, but rather am looking for a good Haskell GUI library ;-).
The functions with an arbitrary number of arguments are problem for both Haskell and Ada. I use only functions constant number of arguments and the arguments are always of scalar types (int, BOOL, char *, ...).
Ok, I probably mixed something up here. GTK+ uses functions with an arbitrary number of arguments but you didn't use them in HToolkit. The problem for creating Ada bindings is that there is no standard mapping of (void *) to an Ada type. But if you want to handle pointers to values of arbitrary type but not to functions, you can use (char *) instead of (void *) like malloc etc. do. Besides that this allows portable Ada bindings, it has the advantage that on some platforms the pointer may take less space. If you have, e.g, one code and one data segment, a function pointer and a char pointer each have to store only the offset address while a void pointer has to store also the kind of segment.
Krasimir
Wolfgang
Dnia czw 24. lipca 2003 12:18, Wolfgang Jeltsch napisał:
The problem for creating Ada bindings is that there is no standard mapping of (void *) to an Ada type. But if you want to handle pointers to values of arbitrary type but not to functions, you can use (char *) instead of (void *)
Using void * for function pointers in C is non-portable. There is no reason a C implementation could represent char * and void * differently, where there existed (or still exist?) implementations which represented other pointers differently (word-addressed Crays where char * and void * need to store a small byte offset in addition to the native pointer). -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
Dnia czw 24. lipca 2003 12:35, Wolfgang Jeltsch napisał:
There is no reason a C implementation could represent char * and void * differently,
But it's not guaranteed by the ANSI standard that they are represented the same way, is it?
I think it's not guaranteed. I said only "there is no reason to do otherwise", i.e. there are no constraints which would make having different representations an advantage, and thus they should be equally easy or hard to wrap in a foreign language. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
--- Wolfgang Jeltsch
The problem for creating Ada bindings is that there is no standard mapping of (void *) to an Ada type. But if you want to handle pointers to values of arbitrary type but not to functions, you can use (char *) instead of (void *) like malloc etc. do. Besides that this allows portable Ada bindings, it has the advantage that on some platforms the pointer may take less space. If you have, e.g, one code and one data segment, a function pointer and a char pointer each have to store only the offset address while a void pointer has to store also the kind of segment.
HToolkit doesn't handle any function pointers. The C-level API uses only data pointers. When an event is raised then all parameters of the event are passed to its corresponding function. For example lets assume that we have "command" event. The only parameter for the event is a handle of the sender. The C code calls function named handleControlCommand with signature: void handleControlCommand(WindowHandle control). The WindowHandle is just data pointer (HWND under Windows and (GtkWidget *) under GTK). The handleControlCommand is written in Haskell and it is exported with "foreign export" declaration to C. The current Haskell implementation simple look at hash table for appropriate callback function in the Haskell level. The implementation for Ada can use similar solution. Krasimir __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
participants (3)
-
Krasimir Angelov -
Marcin 'Qrczak' Kowalczyk -
Wolfgang Jeltsch