April 2003 - GUI - Haskell.org

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

Resource files
by Vincenzo Ciancia 12 Apr '03

12 Apr '03

I have not understood some points about the resource files, wich seems already clear to others: 1. how is one supposed to write portable code if the interface is designed in platform specific resource files, wich are loaded with the appropriate system call? e.g. how does an application behave on gtk if the interface is specified in a .nib file? 2. maybe we will have an intermediate resource format? Vincenzo

1 0

Example for thought
by David Sankel 04 Apr '03

04 Apr '03

This is a real world example of a gui that I am having trouble conceptualizing in haskell. The problem is as follows: There is a list of object instances. Each object has a makeInstance function which displays an interface to an instance. Changes to the interface update the object and all interfaces. Changes to the object update all interfaces. An example of such an object would be an Int. The Int is interfaced by an spinbox. Another object could be an array. It would be represented by two spinboxes (index and value). Here is the c++ solution: class Object { public: virtual shared_ptr<Widget> make_interface()=0; private: signal onChange; public: void doOnChange( function<void> functionToDo ) //... }; class Int { private: int m_int; public: int getVal() { return m_int; } void setVal( int i) { m_int = i; onChange(); //Calls callbacks } virtual shared_ptr<Widget> make_interface() { shared_ptr< SpinBox > spinbox = new Spinbox(); spinbox.set_getter( getVal ); spinbox.set_setter( setVal ); doOnChange( bind( &Spinbox, SpinBox::refresh ) ); } }; What would a haskell solution look like? In my opinion this functionality would be very desirable if not required. David J. Sankel

3 4

Another stateful issue, and a proposal for the solution of all those
by Vincenzo Ciancia 02 Apr '03

02 Apr '03

Well, I promise this is the last feature request for state handling. I want... linked variables! For example a function link :: (a -> b) -> (b -> a) -> Var a -> Var b -> IO () when one writes to one variabile, the other gets written and vice-versa. This is not as easy as it seems (see the Ports library for issues), but can be done in various ways. It's useful when, for example, you want a scrollbar that control a numeric, user-writable textbox. You really want the two values to be synchronized! Also, this is useful for easy persistence of attributes. I am not sure the issue is generally solvable with filters only, like locking, but I guess so. Maybe it needs the ability to get any value that is *actually* written in the state, after all the filters have been processed. However, since it's clear that this state handling problem is longer to solve than I expected, but it's also clear that some of the problems that could arise needs to be handled now, or they will cause trouble forever (think about how would you implement filters if you had not them) I see three possible ways to keep on working: 1. Decide what of all the features that have been mentioned are really necessary, and identify primitive and derived features among those, then implement the thing. 2. Decide a minimal set of features (for example: create, get, set) that a "variable" needs to have, and just be prepared to extend that interface. This allows people that are not interested in subtle state handling techniques (wich are more high-level than mid-level) to start working on the widgets. 3. Decide the same minimal set of features, wich are the only one used in the construction of the base widgets, and allow the functions to be changed like other attributes. For example, we say that the features that are necessary to implement widgets are create, get and set. Then we allow the programmer to pass its own functions to a button, and the button will use these three functions to create, get and set its attributes. This allows to add e.g. filtering capabilities to the existing library in a second moment, and be sure that any other library that uses the get/set interface also gets "filtered". Note that combo of 1 and 2, and of 1 and 3 are possible, and if we choose 1, we are really getting "extended 2". If I haven't been clear, just ask; I would like to hear what you all think about this. Vincenzo

2 1

Re: [GUI] Setting properties of a widget
by Krasimir Angelov 01 Apr '03

01 Apr '03

On Sat, Mar 29, 2003 at 08:34:00AM -0800, David Sankel wrote: > > c) write-only arguments > > I can't think of any widgets that could utilize this > in an elegant way. Perhaps the callback list? I don't like write-only attributes. Usually I think about attributes as special kind of variables. For read/write attributes the get function will always returns the value which was set from the last set function call. The only exception is when the property value was changed from some kind of external action (example: the "text" attribute for "edit" control changes when the user types in the box). In such case there needs to have an event which to fire when the �ction occurs. The readonly attributes are also acceptable, but the writeonly is a litle bit strange for me. Setting of some writeonly attribute looks just like execution of some operation. In the Vincenzo example: On Sat, 29 Mar 2003 21:18:10 +0100, Vincenzo Ciancia wrote: > Consider a progress bar or a volume control, where > you can increment the > value by a relative amount. This is a write-only > property, but only if > you want to model the interface of a relative > increase by a property. > There might be better ways. I prefer to use the function: incrProgress progress d = set progress [pos ~: \x -> x*(1+d)] instead of writeonly attribute. On Mon, 31 Mar 2003 15:13:00 +0100, Axel Simon wrote: > You mean adding a callback? Yes. I guess the need of > write-only is > reflected in GIO by the special "on" function which > takes the name of > the callback. So if we have write-only parameters, > we might have simple attributes like onClicked > instead of "on clicked". The "on" function in the GIO doesn't mean write-only attribute. The "on" function converts Event to Attr on :: Event w a -> Attr w a The returned attribute is read/write. The following example explains this: oldhanlder <- get button (on click) set button [on click =: f >> oldhandler] or set button [on click ~: \oldhandler -> f >> oldhandler] This property allows to attach more than one handler to single event. The disadvantage is that the attached handlers cannot be removed independently. To remove the "f" handler in the above example we need: oldhanlder <- get button (on click) set button [on click =: f >> oldhandler] ... some code ... set button [on click =: oldhandler] The disadvantage here is that if the internal code attaches additional handlers to "click" they will be removed along with "f", but I think that the case doesn't exists very often. On Mon, 31 Mar 2003 16:43:49 +0200 Vincenzo Ciancia wrote: > Another thing that comes to my mind is that > sometimes one could need to > atomically give a sequence of values to an > attribute. This could be done > with a function to lock an attribute: > > lock :: Attribute a -> IO (Attribute a) > > release :: Attribute a -> IO () > > where the result of a lock operation is an attribute > wich is a > representation of the original one, and the only one > allowed to make > modifications until release, or perhaps in a simpler > way with > > putList :: Attribute a -> [a] -> IO () > > Someone wants to comment on this? In my opinions setting multiple values to single attribute is not reasonable. But there is one thing which I propose. The ~: operator should be thread safe for that reason the current implementation for Attr in the GIO should be changed: current: data Attr w a = Attr (w -> IO a) (w -> a -> IO ()) new: data Attr w a = Attr (w -> IO a) (w -> a -> IO ()) (w -> a -> IO a) Where the last function is "update" function. This will allow treadsafe ~: operator and also will increase performance in some cases. Maybe we need to have functions to synchronize on widgets instead of on attributes. In such case we have: lock :: Widget w => w -> IO () release :: Widget w => w -> IO () All the best Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com

2 2

Setting properties of a widget.
by Axel Simon 01 Apr '03

01 Apr '03

I assume everybody is on holiday, just a mail to keep the discussion on the core functionality going. So far it seems that we would like the following features: a) mandatory arguments b) read-only arguments c) write-only arguments d) setting a property and getting a result I guess the general outline will be that of Daan's posting. Regarding the unregister callback issue, I thought of the following: Maybe we can have the set function just taking one argument: set button $ on click =: messageBox "hi there" so that we need to use a special mapSet for several properties mapSet button [label =: "Open Dialogs", on click =: messageBox "hi there"] This enables each property we set to return something as well. In case of attaching a callback, we could return the unregister function: unReg <- set button $ on click =: messageBox "hi there" What do you guys think? Axel.

5 17