- GUI - Haskell.org

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

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

13 Apr '03

> Neither do I. Which is why I'm so keen to see an API which separates > the initialisation from the core application logic. Yes, that's definitely a good idea. We'd have... a) programmatic creation & layout of widgets you execute some monadic IO actions, and in the end you've got a set of values of types like Widget, Button, whatever... b) platform-specific loading UIL/nib/etc. ... for people who want to design their UI once for each platform (i.e. more work), but get perfect results in terms of L&F. Let's start out with platform-specific extensions, and keep thinking about how to reconcile the differences. In an ideal world, we could use the same code and just different (i.e. platform-specific) interface definitions. Then you'd somehow extract references to the elements that you find interesting, and again, you end up with values of types like Widgets, Button, etc. c) People have been tossing around the idea of having our own interface definition file format. I think there is nothing that prevents us from implementing a library that loads some self-made cross-platform interface definition, based on a), just like libGlade is built on top of GTK. I don't think we need that for CGA 1.0, though. After doing one of a, b or c, you'd attach some callbacks to the widgets and go... > To me, the most important part to get right initially is the stuff > which interfaces with the application logic, because that tends to be > scattered throughout the code. Primarily state management; not just > the generic set/get interface, but the semantics of common widget > types (e.g. how do you specify a scrollbar position?). Yes, somebody should already be writing down the minimum set of widgets and their attributes that we need for the first version. >> For 3), I'm thinking of a high-level approach. >> Of course, there'd be the usual grid-based mechanisms (cf Java's >> GridBagLayout), but I'm also thinking of specialized layouts for >> special situations - like a "button bar" in a dialog box, where you >> just tell the layout manager which button is the OK button and which >> is >> the Cancel button and so on. > > That's one case you probably don't need to handle. OK/Cancel dialogs > should be available as complete components; if they are available, > they should be used. I was not referring to OK/Cancel message boxes, I was thinking about more complex dialogs with lots of different widgets, and a group of buttons that affect the entire dialog. Those buttons might be OK & Cancel, they might also be "Apply" and "Revert". There might also be some additional buttons, like "Revert to Factory Defaults" or "Save Settings as...". So I'm talking about something that needs to be a bit more flexible than all the readymade components that I've already seen. Of course, I don't really care if it's really a "layout mechanism" or something else that does the same job... Cheers, Wolfgang

1 0