- GUI - Haskell.org

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

The register/unregister callbacks issue
by Peter Achten 20 Mar '03

20 Mar '03

Dear all, A lot has been said about the register/unregister of callbacks. In my opinion a programmer should not have to register/unregister callbacks explicitly. The reason for this is that a decent GUI program already is supposed to do proper subsetting of the available callbacks by a number of means. For instance by opening/closing menu (elements), or enabling/disabling mouse, keyboard, window (element)s, menu(elements)... . It is up to the implementation of the platform what the appropriate action is in order to achieve an efficient implementation. On the X Windows platform this seems to be registering/unregistering of callbacks. The MS Windows platform also does not like to keep track of unnecessary mouse movements. A program must explicitly set a flag in order to receive these events. For Object I/O this flag is always set. In addition, a 'filter' function is associated with the keyboard and mouse callback. Suppose mouse events have type MouseState, then the corresponding filter function is of type (MouseState -> Bool). Before the OS sends a mouse event to the callback, it first checks if it passes the filter, and only if so, sends the event. This call is cheap and does not invoke IO actions (unless you use unsafePerformIO). Regards, Peter

4 4

Update of the opinion poll document.
by Axel Simon 20 Mar '03

20 Mar '03

I tried to summarize the recent discussions on this list in the technical section. The easiest way to read it is to use the following link: http://www.cs.ukc.ac.uk/people/staff/as49/poll.pdf The document is now available under /home/cvs/root/haskell-report/gui/poll.tex in the (GHC) CVS repository on haskell.org. The only way to receive emails about commits seems to be to subscribe to cvs-all which probably fills you inbox quite quickly. Thus I recommend: if you make bigger changes (and any change is welcome), just write a message to this list. Lacking is a statement about procedure (naming versions "Proposal", "Stable", etc). I'll add that some time in the future. Axel.

2 2

CGA standard
by Krasimir Angelov 20 Mar '03

20 Mar '03

Dear Haskellers, After a long absence I again have the chance to follow the discussions in the forums. And now I would like to express my personal opinion. A lot of attention is paid to the way of realizing the multithreading in CGA. I totally agree that the choice of concrete abstraction for multithreading is a little bit out of the CGA standard. The callback functions are simple and effective way of realizing the event handling. This mechanism doesn�t require but also doesn�t exclude the usage of threads. The stream-based library can be developed later on top of callback functions. In order to realize multithreading all library primitives should be thread safe. Primitives whose execution require a long period of time (i.e. the primitives that start event-loop or directly/indirectly execute the callback functions in Haskell) should not block the execution of the concurrent threads. The way of realizing it depends on the used compiler. For the future versions of GHC probably the best way will be by using �threadsafe� foreign calls, but for Hugs maybe the �yield� primitive. That�s why I propose not to specify the exact way of multithreading. AS for the realization, it can be done in a different way for the different combinations compiler/toolkit. Another point that I noticed is the way of registering/unregistering of the event handlers. Under Windows all events are passed to the function handler even if it ignores them. Under GTK the event is passed only if there is a registered event handler. All libraries based on X have similar design because this allows minimizing of the traffic between the application and the X server. It is a disadvantage of the GTK based Port library where all event handlers are automatically registered even if they are ignored by the Haskell program. It is not difficult to correct this, but we have to bear it in mind when making the standard. Summary: - CGA should use callback functions for event handling - All primitives should be thread safe - Calling whoever of the primitives should not block the concurrent threads. An exception can be done only for the primitives who are executed in a very short constant time - For each event there should be two functions: register and unregister I am under the impression that there is a consensus of all points mentioned above but they have to be specified in the standard. In this context I would like to ask whether there are any additions to the document that Axel wrote. Best wishes, Krasimir __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com

9 30

RE: [GUI] Towards a low level specification?
by Simon Peyton-Jones 20 Mar '03

20 Mar '03

| So, I ask to everybody: would it be right to provide a working low-level | interface, in the IO monad, even if it sucks completely, call it "the | CGA core", and ONLY THEN think about issues as initialization syntax and | a nice way to handle local state? I think it makes sense to have a clear picture of what the *programmer's* interface will look like, and then design the underlying core to support it. Or, perhaps to do both at once. If you do the low-level stuff first, you may find it just doesn't support any decent mid-level interface nicely. (The reverse is also true: one might design a programming interface that is so convenient it's just unimplementable.) After all, the mid-level interface is the goal; the low-level stuff is just a means to that end. However, its true that the fine details of the mid-level interface are not so important (what functions, with what names); it's just the architectural features that matter. | A related issue is that, ideally, the common API should start at as | low a level as possible, so that as much code as possible only needs | to be implemented once rather than separately for each back-end. Indeed so; there is another reason to keep clear sight of the mid-level goal. Simon

1 0

Menu Command Events
by Wolfgang Thaller 18 Mar '03

18 Mar '03

Another discussion topic for everyone... I'm bringing this up now because it has to do with event handling - there'll (hopefully) be another menu-related discussion later, but we should think a little about the event handling related things now. How should menu commands be handled in the CGA? I don't think that simply attaching a callback to the menu item is a good solution - consider the following: The "About", "Quit", "Open", etc. menu commands are handled by the application - they are the same regardless of which window or widget has the input focus. The "Close", "Save", etc. menu commands are handled by the front window[MacOS] / the window to which the menu bar is attached[other platforms]. The "Cut", "Copy", "Paste" etc. menu commands are handled by the widget that currently has the input focus. In many (OO) toolkits that I know, a "menu command" event is first passed to the widget that has the focus. If that widget doesn't handle it, the event is passed on to the widget that contains it, and so on, then to the window, and finally to the application object. I've also seen toolkits where this "responder chain" (as it's called in Cocoa) can be freely configured. Also, should enabling/disabling menu items be handled in a similar way, using a callback, or should menu items be explicitly enabled/disabled by IO actions like enableMenuItem and disableMenuItem? The first is probably much more practical... Cheers, Wolfgang

5 6