March 2003 - GUI - Haskell.org

A case of use involving threads
by Nick Name 13 Mar '03

13 Mar '03

I fear that it's not unfrequent, for an IT company, to have to implement systems wich monitor some sort of hardware. It might happen that the hardware has a driver/library tightly coupled with it, written in C. Often, this library will have an event queue, but it could happen that the library has been designed to run in a sort of "mainloop", because it has to send impulses (sort of) to the hardware to let it do a continuous job, with hooks (callbacks) for an eventual UI. Well, in this case, suppose that a customer comes to you and ask an hardware monitor with a GUI. This case is easily rephrased as: make an opengl window and a CGA window run together, each one with its main loop, and manage both from haskell, without directly accessing the opengl event queue (if there is any directly accessible, I don't know). [this has no connection between opengl being a graphics library. An opengl window is just considered as a source of events] Now, if threadsafe exists, there are (if I have understood well what threadsafe is, someone please confirm it to me) zero issues. You run the opengl mainloop as a separate OS thread, and send the results back to haskell. If threadsafe does not exist, what are the alternatives? Would them easily be handled by a clever design of CGA? What sort of design? Can threads be spawned in C and then be used in haskell? Would this be a mess instead? Again, I can do anything more than asking question on this subject, and sorry for the confusion :) Vincenzo

3 2

Re: events & callbacks
by George Russell 13 Mar '03

13 Mar '03

Daan wrote (about whether callbacks are concurrent) > Just for the record: this is *not* true for most (all?) event > based implementations as they are *not* concurrent (at least not > pre-emptively concurrent). Somewhere down, there is an event loop -- > a loop that waits for an event, executes a callback, and loops again. > Even though more events can happen while executing the callback, it > will only propegate into Haskell once the callback returns and the > event loop pops it off the OS event queue. [note: You can achieve more > concurrency in Haskell by using Haskell threads but even than one > has to wait till the callbacks are done or otherwise the runtime system > sits idle while waiting for the next event (as this is a C call).] Well, if the callback model requires you to work in a gaol in which concurrency is banned, it is useless. I rest my case, m'lud. But really, are you serious? Imagine I click button A, which is supposed to start another dialog in which I click button B, and so on. Since it is apparently illegal in GIOs world for button A's callback to include a wait on button B's callback, the only way to do this kind of thing is turn my whole program inside out, rewrite it in continuation-passing-style, and then make button A put the whole continuation on button B's callback. I remember having to do this kind of thing once, back in the days when GHC only allowed continuations to be given to interrupt handlers, and believe me I don't want to do it again. As far as I'm concerned you can forget about any GUI which doesn't allow you to write a function confirm :: String -> IO Bool which puts up a window containing the String and "OK" and "Cancel" buttons, instead making the user put up with the CPS style. confirm :: String -> (Bool -> IO ()) -> IO ()

8 21

Re: [GUI] GUIs and events (was: Re: Concurrency)
by Wolfgang Thaller 13 Mar '03

13 Mar '03

(I accidentally posted this to ffi(a)haskell.org yesterday...) Glynn Clements wrote: > Wolfgang Thaller wrote: > >> 2) CGA implementations should automatically do all necessary >> synchronization so that the CGA fully supports concurrency even if the >> backend library does not. > > I suspect that this might be a bad idea, and I'm not totally sure that > it's even possible. I think that it would be better to defer this > decision until the feasibility can be assessed. While different implementations might in some cases be slightly more complex than just using locks, I don't see why it should be impossible. After all, thread-safe toolkits are not new. Do you have any specific problems in mind? Also, it should be noted that this feature is important: Unless we have this or an equivalent, it will _not_ be possible to use concurrent Haskell for writing GUI programs. Of course, we could still agree that it is a goal, add something like "unless it turns out to be infeasible" and then revisit the issue later. Cheers, Wolfgang

1 0

GUIs and events
by George Russell 13 Mar '03

13 Mar '03

Oh gosh I'm glad we've got a decent debate going on this ... Wolfgang Thaller wrote (snipped) > 1) Callbacks will be executed synchronously. No other events will be > handled until a callback returns. > Rationale: > *) This maps directly to the execution model of all backend toolkits > that I know > *) You can easily get concurrency by calling forkIO, but going the > other way is difficult. I am strongly opposed to this proposal. As a matter of fact this does *not* map directly to the execution model of HTk, in the sense that if I wanted to add such callbacks to HTk I would have to add an extra lock to prevent callbacks running synchronously. However there is a more fundamental objection. I think in general this does not scale. For example initialisation code (1) might occasionally need to put up a window (eg one that says "Can't find configuration file, please enter new path") (2) might, thanks to the common paradigm of doing initialisation using unsafePerformIO, need to be run almost anywhere in the program, including during a callback. The only way of avoiding that is to force the user to adopt a paradigm where no callback may make use of a service which might require an initialisation (or anything else) which itself requires a GUI event. This is highly unpleasant. Also this way of programming is highly unpleasant. For example, if I have a button "Send an insult to Simon.Peyton-Jones(a)microsoft.com" and it wants to put up a window saying "Do you really want to insult Simon Peyton-Jones?" then you need a chain of callbacks. The callback attached to the first button is not allowed to insult Simon PJ itself, instead it has to attach a continuation (containing the insult) to the confirmation button. In general this means continuation-passing-style is going to infect this part of the program. For programs where almost everything is initiated by user action, an awful lot of them is going to have to be written in CPS.

6 7

Re: Events and finalizers
by George Russell 12 Mar '03

12 Mar '03

Nick wrote (snipped) > The true problem here is that once you got an Event, you never uninstall > the callback, even if you just take the first n events and then stop > using the stream. This can be really expensive; do you use finalizers to > uninstall the callback? Well there are two approaches: (1) you provide a more complicated function which in addition to the new event, returns an IO () action which unbinds it. This is what HTk does, in general, though for many simple examples it is of course not required. (2) in many but not all cases it is possible to work out that the stream can be automatically deregistered. For example, as well as finalizers you can also forget the stream when the object is destroyed. Of course this isn't anything particular to do with events; a callback model also has to have a way of deinstalling the callback.

5 13

Events/Finalizers/Streams
by George Russell 11 Mar '03

11 Mar '03

Nick wrote, quoting me, snipped >> For example, will this stream library also subsume CML style events >> (as implemented by me as part of HTk), which allow you to wait on >> multiple events and return when any one of them occurs? > > Well, this is an example wich requires concurrency. "Merge" of events > will be available only on preemptive multithreaded implementation, > unless I am wrong and there is an alternative way (like a "select" > operator). OK, with higher-order events, as invented by John Reppy (CML) and implemented by me in Haskell, you do have a select operator, and you do not need pre-emptive multithreading. (Obviously such things are a good thing anyway, but they are not essential.) So if an Event a is an event carrying a value of type "a", there is a function (+>) :: Event a -> Event a -> Event a which selects either of the two events. There is also another operator (>>>=) :: Event a -> (a -> IO b) -> Event b allowing you to postprocess the result of an event in some way. For example if you have two buttons, a "Yes" button with a click event (yes :: Event ()), and a "No" button with a click event (no :: Event ()) then you can define construct yesOrNo :: Event Bool yesOrNo = (yes >>>= (\ _ -> return True) +> (no >>>= (\ _ -> return False) Then sync yesOrNo will wait for the next button click, and tell you if it was of "Yes" or "No".

1 0

GUIs and events/callbacks.
by George Russell 11 Mar '03

11 Mar '03

I think I've pointed out that the main difference between GIO and HTk is that HTk uses composable events, while GIO, like most other Haskell GUI's (including GTk+hs) use callbacks. Now of course I'm biased, and I prefer events to callbacks, but I appreciate the arguments that have been made that including composable events in a GUI would simply involve adding too much heavy machinery which doesn't have anything to do with graphics. But I think I have a solution to this, which I would like to propose. This is that a GUI standard specify events, but *doesn't* specify that they be composable. Then they would be trivial to implement, and still (in my opinion) be better than callbacks. Also systems like HTk could of course add an extra module which did provide the composition operators. So, in detail, the GUI standard should have a new type Event a which means "Event carrying a value a". To generate for example something like a button click event we could have a function clicked :: Clickable widget => widget -> IO (Event ()) Thus, after this function is called, the returned "event" would happen each time the user clicks the button. A mouse click event might, for example, have type (Event (Int,Int)) giving the co-ordinates of the mouse pointer at the time of the click. To "listen" for events, two functions would be provided: sync :: Event a -> IO a which blocks until the event happens (or returns immediately if a queued occurence of this event has already happened), and setCallBack :: Event a -> (a -> IO ()) -> IO () which added an action to be performed each time the event happens. There are questions to be asked about what happens when you have multiple consumers of the same event. I think it should be guaranteed that when an event happens, only one consumer gets to hear about it, but which does not perhaps need to be specified. (I don't think this is very likely anyway.) Summary ------- Advantages over Composable Events. easier to implement. Advantages over callbacks: can easily be extended to composable events the "sync" operator is more powerful than callbacks (without being particularly hard to implement). For example, I think all or at least most of the call-back-based solutions to the "simple GUI Example" at John Meacham's page http://repetae.net/john/computer/haskell/gui/ contain the following bug: if the user clicks twice very rapidly on the button, the second click will be ignored. In general the click-handling routines can run concurrently, perhaps modifying common shared data, and leading to all sorts of trouble, unless the user uses locks. It seems clear that what is wanted here is sync, not callbacks.

7 17

Re: GUIs and events/callbacks
by George Russell 10 Mar '03

10 Mar '03

Glynn wrote (snipped) > Does this mechanism allow the toolkit to determine whether an event is > being listened for? Or would it force the toolkit to always generate > all events just in case it's being listened for? The latter is > unacceptable on X. Yes. You'll see I provided an IO *action* clicked :: Clickable widget => widget -> IO (Event ()) This tells the toolkit to *generate* an event whenever a button (or whatever "widget" is) is clicked. I agree that the alternative, for general GUI events, would be unacceptable.

2 1

wxwindows and native look and feel
by Nick Name 07 Mar '03

07 Mar '03

I don't know if this is true, but my professor of "Graphical interfaces" told me some month ago that wxwindows is not really "native look and feel" on windows, since for example the "file open" dialog is not native. At the same time, wxwindows has its own format for resources, and the "file open" dialog is not native under gnome (even if it's better than the gnome one). Anyone wishing to clarify? Vincenzo PS: Maybe the wxwindows experience should tell us that what we are looking for is impossible to reach?

2 2

How to create objects and how to get/set their attributes
by David Sankel 07 Mar '03

07 Mar '03

Thanks to Wolfgang for sorting out the current discussion topics. I hope this to be the thread for 1 on the issue list. There have been three, that I have seen, competing ideas. The first is the GIO/Object IO style of objects: button <- Button [ title =: "Hello", position =: (0,0), size =: (300,50) ] set button [ onPress =: (buttonPressed button) ] set parentWindow [children ~= (/a -> button:a)] The second is a motif style (please correct me if I have this wrong): button <- create "Button" parentWindow [ title =: "Hello", position =: (0,0), size =: (300,50) ] set button [ onPress =: (buttonPressed button) ] The third is the OO approach button <- new Button button # setOnPress (buttonPressed button) button # setPosition (0,0) button # setSize (300,50) parentWindow # addChild button I propose we use the GIO/Object IO style. Does anyone have any other preferred styles that I'm missing? Which style do you prefer? David J. Sankel

4 4