November 2003 - GUI - Haskell.org

Re: Gtk and Object I/O
by Axel Simon 23 Jan '06

23 Jan '06

Good day, and apologies for this very long message. On Mon, Jan 20, 2003 at 09:38:41AM -0000, Simon Peyton-Jones wrote: > I don't think we are waiting for critical user mass. We're waiting for > critical *designer/developer* mass! Yes, I guess that's what I wanted to say. So it is all about acceptance of a toolkit by the programmer. I think a GUI toolkit is more acceptable to a programmer if it fulfills the following (highest priority first): a) it is portable, i.e. programs written to use the GUI library should behave the same on Win32/X/Aqua (MacOS) b) it is functional, i.e. the programmer finds all GUI elements a modern application needs and has the ability to create custom widgets c) it is stable, i.e. the library's API doesn't change too quickly, ideally not at all d) it looks as if written with the native API of the platform I thought b) came before a), but due Simon's comment I swapped them: > Speaking as a potential user of such a library, I would absolutely love > to have a Haskell GUI library that > was available in some form on each major platform > was supported by a bunch of people, so I could have > some confidence in its continued existence > Its exact capabilities are less important: (a) I'd adapt my program to > fit what was available, and (b) I'm sure it would evolve in response to > user feedback. I'd accept compromises in functionality to gain > portability; it'd be OK to have > some platform-specific sexy bits. Worse is better. Let's assume we have a lot of time and nobody is in need of a GUI library right now. For a portable library, we need some layer which is common to all OSes. The question is thus: Where shall we have the common interface between a fixed Haskell API and the specific OS API if we want to minimize the penalty for b) functionality, c) stability and d) look-and-feel. Two main proposals are: 1) Create a common high level layer on top of all native OSes (in C) and then bind to Haskell. Example: HToolkit+Ports 2) Use the native OS functions just for drawing. Create every UI item from scratch. Example: Gtk and gtk+hs/gtk2hs regarding 1): This proposal is geared towards d), look-and-feel. It is nice to have a program which looks as if written with the native API. I think it's impossible, some flame: 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. Buttons on Aqua cannot have icons in them, scrap icons in Gtk and Windows button. 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. Scrap Window's concept of groups in dialog and keyboard accelerators in general since Aqua doesn't know about hotkeys. 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). I know that these are all minor issues which could be circumvented, but where does the native look-and-feel go? Furthermore, this "finding the common subset" approach will certainly lead to a reduction in b) functionality. Simon PJ said: > (a) I'd adapt my program to fit what was available I wouldn't even start a *bigger* project if I would know that I hit some limits later in the development, but that's my view. > (b) I'm sure it would evolve in response to user feedback This could mean a reduction in c) stability. A major point is that you need to consider *all* platforms before you create any abstraction layer. Otherwise you will have a serious problem with stability. It would be very advisable to use a library of people who have successfully found a common subset of all OSes instead of reinventing the wheel. If we need to do it from scratch, then that could indicate that nobody has ever managed to find this common subset. Well, Sengan said: > I have seen many positive comments about IBM's SWT which > works on the following platforms: > <...everything you ever wished for...> So maybe this is such a library. Is it complete? How is the look-and-feel? -------------------------------------------------------------------------- regarding 2): Using a layer which only builds on the native drawing capabilities is surely easier to port. The b) functionality is quite good in the case of Gtk. It lacks support for sound, but supplies most UI elements known from e.g. Windows. The c) stability is not so much of a concern as the primitive drawing functions will not change that quickly. I would like to apply the "Worse is Better" principle to d) look-and-feel. In the example of Gtk, the inventors have gone through quite some hassle to make the UI changeable. You can tweak the buttons to have the same color and fonts as on Windows, though you cannot change the fact that dialogs are resizable or that buttons have no icons and flash blue if they are the default buttons (Aqua). Gtk is not ported to Aqua but runs under the XonX port of Windows. Last but not least any GUI library has to be maintained. Win32/MFC, Gtk (or Qt) and Aqua will all evolve over time. Using a single library like Gtk reduces the burden of keeping the Haskell library up to date to a single backend. Gtk has many more users as it has bindings to many other languages besides C. Thus the amount of people who can iron out problems with the ports to other platforms is much bigger. ------------------------------------------------------------------------ I did not discuss the issue of how much time it needs to implement the different concepts, that could be another email. Hope these arguments are not too biased, Axel.

9 21

"(±¤°í)´ëÇÑ¹Î±¹-ÀÎÅÍ³ÝÀÇ ÁöÃàÀ» Èçµé°ÔµÉ ¸Å¿ì ³î¶ó¿î»ç½Ç ÇÑ°¡Áö¸¦ ÀüÇÕ´Ï´Ù.@"
by ��ģ�� 23 Nov '03

23 Nov '03

1 0

Announce: Gtk2hs version 0.9.4
by Axel Simon 19 Nov '03

19 Nov '03

gtk2hs - A Haskell binding for Gtk+ version 2 GUI Toolkit. This binding provides a low-level wrapper around the Gtk GUI Toolkit. It covers nearly all widgets and thus provides a stable development API. Recent additions include the SourceView widget contributed by Duncan Coutts. The library is mainly for developers targeting the Gnome platform, otherwise you might be better off with wxHaskell or HToolkit. Highlights: - hand-crafted bindings - automatic memory management - compiles out-of-the box on FreeBSD, (Redhat) Linux, Solaris, X Darwin, MinGW (with the Windows port of Gtk) - compiles with GHC 5.04.X and GHC 6.0.X Available from https://sourceforge.net/projects/gtk2hs/ Please report all problems to gtk2hs-users(a)sourceforge.net . Enjoy, Axel

2 1

Problems Compiling GTk2HS on Win32
by Chris Taylor 14 Nov '03

14 Nov '03

Hi, I'm trying to compile Gtk2Hs using Cygwin on windows 32.... It all starts to work fine, then the "make install" crashes with: c:/ghc/ghc-5.04.2/bin/hsc2hs -C -optc-fnative-struct +RTS -H180m -M350m -RTS --l flag=-lgtk-win32-2.0 --lflag=-lgdk-win32-2.0 --lflag=-latk-1.0 --lflag=-lpan gowi n32-1.0 --lflag=-lgdi32 --lflag=-lpango-1.0 --lflag=-lgdk_pixbuf-2.0 --lflag =-lg object-2.0 --lflag=-lgmodule-2.0 --lflag=-lglib-2.0 --lflag=-lintl --lflag=- lico nv --cc=c:/ghc/ghc-5.04.2/bin/ghc general/StockItems.hsc general\StockItems.hsc:132: gtk/gtk.h: No such file or directory general\StockItems.hsc:249: parse error general\StockItems.hsc:327: parse error general\StockItems.hsc:401: parse error general\StockItems.hsc:249: parse error general\StockItems.hsc:327: parse error general\StockItems.hsc:401: parse error general\StockItems.hsc:249: parse error general\StockItems.hsc:327: parse error general\StockItems.hsc:401: parse error make: *** [general/StockItems.hs] Error 1 now obviously this is because c2hs cannot find the gtk.h file, which i have installed in: C:\cygwin\usr\include\gtk, C:\cygwin\usr\local\include and C:\GTK\Dev-C++\include\gtk-2.0\gtk the C:\cygwin ones were a port of gtk2 for cygwin, wheres the one in C:\gtk is just a win32 port of gtk2 Any suggestions would be greatly appreciated, i'm a bit of a newbie when it comes to both bash-shells and haskell, and am totally stuck. Thanks Chris,

2 1

Check out this dermal patch, tbsjvj
by Template-haskell 14 Nov '03

14 Nov '03

2 1

Re: confirm d75eab912bc3d829fa0d9328f461730a3a63fb84
by Vincenzo aka Nick Name 11 Nov '03

11 Nov '03

Alle 20:37, martedì 11 novembre 2003, gui-request(a)haskell.org ha scritto: > Mailing list subscription confirmation notice for mailing list GUI > > We have received a request from 80.181.167.214 for subscription of > your email address, "vincenzo_ml(a)yahoo.it", to the gui(a)haskell.org > mailing list. To confirm that you want to be added to this mailing > list, simply reply to this message, keeping the Subject: header > intact. Or visit this web page: > > > http://www.haskell.org/mailman/confirm/gui/d75eab912bc3d829fa0d9328f4 >61730a3a63fb84 > > > Or include the following line -- and only the following line -- in a > message to gui-request(a)haskell.org: > > confirm d75eab912bc3d829fa0d9328f461730a3a63fb84 > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be subscribed from this list, please simply > disregard this message. If you think you are being maliciously > subscribed to the list, or have any other questions, send them to > gui-owner(a)haskell.org. -- First they ignore you, then they laugh at you, then they fight you, then you win. [Gandhi]

1 0

Re: confirm d75eab912bc3d829fa0d9328f461730a3a63fb84
by Vincenzo aka Nick Name 11 Nov '03

11 Nov '03

Alle 20:37, martedì 11 novembre 2003, gui-request(a)haskell.org ha scritto: > Mailing list subscription confirmation notice for mailing list GUI > > We have received a request from 80.181.167.214 for subscription of > your email address, "vincenzo_ml(a)yahoo.it", to the gui(a)haskell.org > mailing list. To confirm that you want to be added to this mailing > list, simply reply to this message, keeping the Subject: header > intact. Or visit this web page: > > > http://www.haskell.org/mailman/confirm/gui/d75eab912bc3d829fa0d9328f4 >61730a3a63fb84 > > > Or include the following line -- and only the following line -- in a > message to gui-request(a)haskell.org: > > confirm d75eab912bc3d829fa0d9328f461730a3a63fb84 > > Note that simply sending a `reply' to this message should work from > most mail readers, since that usually leaves the Subject: line in the > right form (additional "Re:" text in the Subject: is okay). > > If you do not wish to be subscribed from this list, please simply > disregard this message. If you think you are being maliciously > subscribed to the list, or have any other questions, send them to > gui-owner(a)haskell.org. -- Ho dato al mio dolore la forma di parole abusate che mi prometto di non pronunciare mai più [CSI]

1 0