April 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

Are windows just ordinary widgets?
by Wolfgang Thaller 03 May '03

03 May '03

MacOS treats windows and "controls" (i.e. widgets inside a window) as completely different things. Most other platforms treat them as essentially the same things. Which route should the CGA go? The situation seems to be something like this: + Widget everything that occupies space within some coordinate system. Has attributes like size. - Window A toplevel Window. There will be several variants of this, for document windows, dialog boxes etc. + Pane A widget "inside" a window (a window has panes - I've seen this name somewhere, feel free to suggest a more standard one) - Button - GridBox - Label - etc. "Container" could be a class outside this hierarchy, implemented by "Window", "GridBox" and a few other widgets. A Container would only contain Panes, never other widgets. The relationship between a window and a window-modal dialog window has nothing to do with the relationship between a window and a button inside that window, IMHO, so they shouldn't be expressed using the same parent/child relationship. Now perhaps we want a common datatype "Widget" with functions toWidget :: Widget w => w -> Widget and fromWidget :: Widget w => Widget -> Maybe w Perhaps we want a datatype "Pane" (or "Control" or whatever) with toPane :: Pane p => p -> Pane and so on. If I had a "Pane" datatype, I wouldn't really need the "Widget" anymore, but of course, one can never know. The "Pane" datatype would be the natural place to implement a lot of functionality at least on Mac OS, so if it's there, I'm happy, and I could then implement a Widget datatype as a simple discriminated union datatype. If there was no Pane datatype, the implementation for the widget datatype would become slightly ugly and inelegant on Mac OS... Cheers, Wolfgang

4 11

Dynamic sizing.
by David Sankel 28 Apr '03

28 Apr '03

Hello Everyone, It seems that right now the easiest and best way to deal with dynamic sizing of widgets is as follows: -- CGA/CommonAttributes.hs class HasSize w where size :: Attr w SizeType data SizeType = Fixed (Int,Int) | Standard Where fixed is obviously the pixel size and Standard is some implementation dependant size. For example, a button would likely have a fixed height and a length based on the label size on a macintosh. What does everyone thing about this? It is pretty elegant and simple this way so it makes me think that more "stuff" needs to be added. David J. Sankel

5 17

More notes on the example implementation
by Wolfgang Thaller 28 Apr '03

28 Apr '03

*) We might need to add the parent widget as a required parameter to the constructor functions. Apple's "Carbon" API requires the toplevel window to be known at construction, the exact place in the window's widget hierarchy can be changed later. Widgets cannot be moved from one window to another. Win32 requires the parent widget to be specified at widget construction time, but it also provides a function called SetParent that's supposed to change a window's parent. Gtk doesn't seem to impose any restrictions, and neither does Apple's "Cocoa" API (formerly known as OpenStep). What about other potential backends? *) As I already said, I think toWidget should be toWidget :: Widget w => w -> Widget (not in the IO monad) *) Should windows really be widgets? At least they aren't on Mac OS, and making them look like widgets would be somehow artificial. Windows can't be added to any layout container, for example. *) I'm not entirely happy with the Has* classes. It looks like the basic attributes and methods available for all widgets have to be implemented over and over again for every widget class. Is there some way around this? *) Fltk only supports a single callback, and so does the current CGA example. To support multiple callbacks, some machinery has to be added on the Haskell side. That's all for today. I think I'll have another look at the code tomorrow. Cheers, Wolfgang

3 3

CGA-Example 1.1
by David J. Sankel 23 Apr '03

23 Apr '03

===================== CGA-example version 1.1 ===================== ===================== Overview :: This is an example of a low-level binding to a c++ GUI library and a mid-level CGA abstraction over it. This was created primarily to spark discussion in the gui(a)haskell.org mailing list and secondarily to provide a simple example that can be compiled using ghc without any language extensions. I encourage those who code, to implement their ideas for the Common GUI API using this simple framework. This would allow all reviewers to understand exactly what you are talking about by running your examples. Fltk was chosen for its simplicity and portability. I didn't use an existing library because I wanted a short example where the source code is easy to comprehend at all levels. ===================== Changes :: v1.1 -- Using Heiarchy extention for module naming. Completed CGA version of Box, Button, Window, and Widget. Now using the agreed callback format. Initial child handeling support. Using class-per-function naming. Using MVar's in example CGA application for simplicity. ===================== Questions :: 1) How does the interface look in Test_midlevel.hs? Is there any critiques in regard to using this style in CGA (Common GUI API)? 2) Haskell has one namespace, the global one. Since there would be a lot of function names and attributes in CGA, their names should be well thought out. Is there any ideas on how to handle this? 3) How should children be handled? I used both an attribute and a seperate function in this implementation. 4) What do you think is important to have in the next version of CGA-example? ===================== Running :: To run the examples, one needs a standard Haskell compiler with ffi (ghc) and fltk installed (http://www.fltk.org) run make. If necessary, change the makefile to modify for your configuration. Fl-stubs/* -- These are the stubs that are used to bind the c++ library to c functions. This is required because the Haskell ffi standard does not specify any conventions for C++. Fl.hs Fl/* -- These contain the bindings to the stub files. They also provide a low-level interface for the fltk GUI toolkit. Test_lowlevel.hs -- This is a simple program demonstrating use of the low-level binding. Attributes.hs -- This code was taken from the htoolkit cvs server. Simple modifications were made to suit our purposes. CGA.hs CGA/* -- This is the Midlevel, CGA code wrapping the low-level Fl interface. CGA/CommonAttributes.hs CGA/CommonMembers.hs CGA/CommonSignals.hs -- these are the support files for the one-class-per-function style as proposed on gui(a)haskell.org. Test_midlevel.hs -- This is the same simple program as Test_lowlevel.hs except it uses CGA instead of Fl. ===================== Cheers, David J. Sankel

4 3

State, Attributes and Some basic widgets
by Wolfgang Thaller 16 Apr '03

16 Apr '03

It seems that the discussion about how to represent widget attributes has died down again recently. I'll try to get it going again... I'll try to list a few very basic widgets and their most important attributes. I'm using Apple's terms, I don't always know the "proper" Windows, Motif or GTK terms. Push Button Read/Write attributes: Label (String), Enabled (Bool) Callbacks: onClick Check Boxes and Radio Buttons Read/Write attributes: Label (String), Enabled (Bool), Value (Bool) Callbacks: onClick Static Text (a.k.a. Labels) Read/Write attributes: Label (String), Enabled (Bool; yes, at least on Mac OS, static text can be greyed out) Scroll Bar: Read/Write attributes: Value, minimum, maximum, size of visible part, step sizes etc... Callbacks: onScrollStart onScroll onScrollFinished (or something like that) So far, I've only listed plain read/write attributes, and callbacks (I'm in favour of allowing multiple callbacks). We could add a whole lot of read-only attributes to each widget: current size, minimum size, maximum size, (platform-specific) native handle, etc. Were there any examples of write-only attributes, that can always be written, but never be read? What attributes are there that cannot be changed after creation or that have no sensible default? (Yes, I do consider "" to be a sensible default for a button label) On Widget Names: Then there is the Xt-style widget name, which would need to be specified on widget creation, and which would then be read-only. Is it really necessary to have this on all platforms? I gather it is used for looking up customization from X resources - does this make sense if the widgets have been created programmatically using a cross-platform interface? People targeting other platforms first wouldn't know what to use the name for, and why it's a good idea to specify a proper name. If the interface is loaded from an UIL file, then of course there would be a Xt widget name, but do we need it even in programs that don't care about UIL files and X resources? On linked states: a) I think that linked states and general state-change notification is outside the scope of the CGA. b) Allowing linked states would require every state change to go through the CGA; it would be more difficult to map to the underlying backend library, in case the backend library changes some state "on it's own". Cheers, Wolfgang

5 20

Recent threads
by David Sankel 16 Apr '03

16 Apr '03

Hello All, I've been silently listening to the recent threads. I feel like some of these conversations are going back to issues discussed a month or two ago. So here is a concrete proposal. Yay or nay. I suggest merging this with the standard and then changing it with other proposals. This seems to be an effective way of getting things done. 1.) class Widget where -- Some operations on widgets such as getHeight getWidth (the units of these are not yet specified) 2.) Widgets have several types of variables a) r/w variables are handled by attributes b) write only variables are passed to the constructor before the attribute list. c) read only variables are handled by functions such as (getWidth :: Widget a => a -> Int). For read only variables that do not fit into an obvious class will have their own class ( class HasGetFoobar where ... ) 3.) callbacks are not variables. Signal is a more appropriate descriptor than variable. For a given signal <A> with parameters (a1, a2, ... ) : class EmitsSignal<A> a where doOn<A> :: a -> ( a1 -> a2 -> . . . -> IO() ) -> IO() The doOn<A> function returns a function which can be used to disconnect the signal. 4.) A widget <A> with (a1, a2, ...) write only variables is created with: mk<A> :: a1 -> a2 -> ... -> [Prop <A>] -> IO <A> 5.) Issues to push back for discussion for a future CGA release: a.) Resource files. b.) Internationalization. c.) GUI designer. 6.) Position, width, and size will be able to be programmed a.) Dynamically, and b.) Concretely This proposal maintains the original goals of being typesafe and fully dynamic. As I said above, lets ratify this (yay or nay) and then consider proposals for changes and additions. Sincerely, David J. Sankel

2 1

Re: Widget Names (was: State, Attributes and Some basic widgets)
by Wolfgang Thaller 14 Apr '03

14 Apr '03

> If you want code to work on all toolkits, you have to provide it. It > would also be necessary if we wanted to implement some of Xt's > features (e.g. customisation through external files, e.g. for I18N) > for other toolkits. Hmm... Could you point me to an overview of what that X resource stuff really does and how it really works? > This also simplifies coding. The UI creation code doesn't need to > store lots of handles for later reference; code can obtain the > run-time handle using the widget's pathname. I like storing my handles because I want compile-time safety.... but it wouldn't hurt if that feature was there. One more question: what about platform-specific interface definitions (e.g. nib files on Mac OS) that don't contain textual widget names? Cheers, Wolfgang

2 1

Another RFC on setting and getting.
by Axel Simon 14 Apr '03

14 Apr '03

Hi all, it seems that there are a lot of issues left open about the following basic concepts: - The usage of (:=) and existential types instead of (=:) for turning attributes into something which can go into an argument list. Pro for := : It reflects the semantics of assigning something to an attribute. Contra for := : it might be a keyword in future Haskell, it requires non-Haskell 98 features. - The necessity of read only attributes. - The necessity of write only attributes. Or getting rid of them in favour of mandatory arguments (to the constructor). - Callbacks get separate functions which called on<WidgetName><ActionName> I would like propose the following basic setup, together with the questions how read only attribute can fit in. Write only attributes could be easily added by just supplying "pushButtonNow :: Setter Button", albeit breaking the := syntax - you'd have to say set b ["Hello" =: label, pushButtonNow] Here it is: -- An attribute is a property of a widget. It knows how to set the -- and how to read the value of this property. data WidgetClass w => Attr a w = <abstract> -- The assignment operator joins an attribute with its value. (=:) :: a -> Attr a w -> Setter w -- Set and get can be used on every widget. set :: WidgetClass w => w -> [Setter w] -> IO () get :: WidgetClass w => w -> Attr a w -> IO a -- An example for a Button widget: The constructor has one -- mandatory argument. newButton :: Container -> [Setter Button] -> IO Button -- The Button has at least this attribute. label :: Attr String Button -- This is one callback the Button provides. Note that you cannot -- attach any function at construction time or with the set -- function. The returned action is the unregister function. onClicked :: ButtonClass b => b -> IO () -> IO (IO ()) Axel.

7 29

Re: [GUI] Dynamic ... something
by Wolfgang Thaller 13 Apr '03

13 Apr '03

(arghh... I keep forgetting to fill out the To: and Cc: fields correctly...) > What are the two Ints? Pixels? Dialog units? Fractions of something? I > just wonder if it is really simple. Convince me that it is! :-) Ah those nasty dialog units. I never thought of anything else but pixels. But Windows, too, supports placement by pixel coordinates, so it's not really a problem. But I'll not insist on it for now.... > I meant that placing a widget at a specific position will be just an IO > action like "placeWidget" above. This cannot be expressed by > combinators, > otherwise you already have the dynamic version. I don't think so. I'd do it like it's done in Apple's Cocoa, i.e. specify the initial coordinates + a few flags that specify resizing behaviour. I'd use the same combinator or whatever mechanism that is used for the "real" layout mechanisms. First, we need to agree on a general way of how to specify layouts... Do we really want combinators, or is that too abstract for our purposes? I was originally thinking of just using IO actions to add widgets to a container or to pass the container on widget creation; and to pass along some "layout constraint" (which depends on the container type). For a container that does grid-based layout, I'd pass a row and column number (and perhaps row & column span). For a container that does "explicit placement" layout, this "layout constraint" would just be the bounding rectangle in pixels, plus perhaps resizing flags. If we don't put the "explicit placement" container in the public interface, I'll still have it internally in the Mac version - as I said, It's useful for implementing the other kinds on top of it. The first reason why I thought we might want to have explicit placement everywhere is that it was my impression that it was easier to implement than any "serious" layout manager, even on platforms that already provide automatic layout (I might be wrong, though). I would just like to have some way to see if I implemented the Mac version of the XYZ widget correctly, and to compare it with other platforms, before I had all the layout stuff in place. But as I said, I won't insist on it. Cheers, Wolfgang

1 0