March 2003 - GUI - Haskell.org

Re: Gtk and Object I/O
by Axel Simon 22 Jan '06

22 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

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

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

13 Mar '03

Glynn Clements wrote: > But non-thread-safe toolkits still exist. X itself isn't necessarily > thread-safe (thread-safety is optional; AFAIK, XFree86 is thread-safe, > but some other implementations aren't), and toolkits built atop X tend > to be thread-safe only if the underlying X libraries are. ... but I know of no reason why a thread-safe toolkit couldn't be based on a non-threadsafe one. > 1. You need to run a specific sequence of toolkit operations without > any other operations being interleaved. Yes. > Even if the toolkit is > thread-safe, the application itself will still have critical sections > with regard to its use of the toolkit. Granted. I don't mean that the CGA should do the user's work - it should just do the synchronization that falls within it's scope. > And if the application has to do its own locking some of the time, it > may be better to just shift the general problem onto the application. The main reason why I don't like that is the fact that some toolkits are half-threadsafe and require some operations to be done from certain OS threads. Other toolkits already are threadsafe and require hardly any synchronization on the user's part. Writing a CGA backend with proper synchronization can be done IMO, but writing an application that caters to the different synchronization needs of different backends is hard (You'd need to read the docs for GTK, Win32, Carbon/Cocoa, etc. in order to do it properly). > That avoids substantially complicating the toolkit code for a case > which is seldom used (most GUI programs only call the toolkit from one > thread). There seems to be some interest in using Concurrent Haskell for writing GUIs. I fear it will be next to impossible to use Concurrent Haskell in the GUI part of an application if CGA does not automatically do the necessary locking. If people don't have a problem with saying that all CGA calls should come from one (Haskell) thread, then I have no problem with not making the first version of CGA threadsafe. For version 2, we'll know better a) wether we really need it and b) how much work it will be. Cheers, Wolfgang

1 0

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

13 Mar '03

[Originally sent to FFI.] 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. But non-thread-safe toolkits still exist. X itself isn't necessarily thread-safe (thread-safety is optional; AFAIK, XFree86 is thread-safe, but some other implementations aren't), and toolkits built atop X tend to be thread-safe only if the underlying X libraries are. > Do you have any specific problems in mind? 1. You need to run a specific sequence of toolkit operations without any other operations being interleaved. Even if the toolkit is thread-safe, the application itself will still have critical sections with regard to its use of the toolkit. And if the application has to do its own locking some of the time, it may be better to just shift the general problem onto the application. That avoids substantially complicating the toolkit code for a case which is seldom used (most GUI programs only call the toolkit from one thread). 2. Deadlock. You need to specify enough about the locking behaviour that the application at least has the possibility of avoiding deadlock. The most naive approach would be to simply hold a global lock across all toolkit functions. Of course, that would include e.g. XtDispatchEvent, which means that callbacks would be entered with the lock held, so any attempt to call toolkit functions from within a callback would either deadlock or fail. So, that approach won't work. What will work? Do the common toolkits even specify their behaviour in enough detail that it's possible to ensure that any given strategy will work? -- Glynn Clements <glynn.clements(a)virgin.net>

1 0

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

13 Mar '03

Sorry in advance for the long post... Daan Leijen wrote: > Please think a little bit longer before voting a "big NO". If we want > to make > progress we shouldn't rule out a solid and simple solution based on > shaky arguments. My vote remains a big NO for now because I don't consider my arguments shaky. Of course, I'll keep thinking about it, and as soon as I discover the error of my ways, I'll change my vote. If I remain too stubborn, a single "NO" vote isn't a majority for no, so don't worry... ;-) > 2e) All haskell call backs are run in a single OS thread (the "GUI > thread"). Calls to the CGA > can be made at any time from any Haskell thread that run within the > GUI thread. My reservation remains that there is no way for a standard Concurrent Haskell program to control which Haskell threads run in which OS thread. The current proposal for "bound threads" (see ffi(a)haskell.org) will allow some control, but for the sake of simplicity it doesn't support explicitly binding multiple Haskell threads to one OS thread. > 1) What if Haskell automatically decides to run Haskell threads in > some other OS thread? > First, I believe that an automatic system would be a mistake, ... which, if you think that it is a mistake, this mistake has already been made. Threadsafe already exists. > but secondly, such system > will surely provide a forkIO variant that runs the Haskell thread in > the same OS thread. ... which would defeat the purpose of "threadsafe", which was to prevent the FFI from blocking other Haskell threads unpredictably. > However, I don't really want to discuss OS threads/Haskell threads > here, it is > enough to know that this formulation does *not* rule out future GHC's > or future > OS multi threaded systems. ) Do we know this? GHC does not guarantee that multiple Haskell threads are run in a certain OS thread. It most definitely rules out the current version of GHC (with a special configure switch) and everything that was planned for the next version. As I said, there is no defined mapping between Haskell threads and OS threads. So we can't say "... from the same OS thread", because a Haskell programmer currently has no way to say "fork a new Haskell thread in the same OS thread as the current Haskell thread". That leaves us with two options that I can think of: a) Restrict everything to one *Haskell* thread b) Don't restrict anything - require implementations to do proper synchronization or, if the backend requires it, even to channel everything to the right thread. b) is of course more work, and people have had doubts that it is implementable. I'm convinced that it can be implemented, and that it's not too difficult, but of course we can't go ahead with this until all backend implementors are convinced that it's possible. a) probably won't be popular with people who want to experiment with concurrency for GUIs. > You are right that different Haskell threads can interact with each > other in devious > ways by modifying global state... this is called the IO monad :-) > There is no way you can solve this problem in general, and for the GUI > it may involve a lot of overhead. > > *This is the responsibility of the user when using concurrency*. In > your example, > it is a classic multiple writers, single resource pattern. I was thinking of situations where the state is not visible to the user of the CGA. Suppose there was a function like messageBox :: String -> IO () in the CGA. On Win32, this could be implemented by a call to the Win32 MessageBox function. On MacOS, there is no predefined function for that, so the implementation would consist of the following steps: 1) Create a dialog window with the message 2) Show the window & bring it to the front 3) Run the modal event loop 4) Close the window If two Haskell threads (possibly even running in the same OS thread) attempt to call messageBox, then there'll be a race condition here in the Mac version, but not on the Windows version. If we say that that is the application's responsibility, then the application developer would need to know the implementation of the Mac OS backend in order to write a correct program. An average programmer would not forget about locking, test it on Windows, and it would work. On Mac OS, we'd get hard-to-reproduce bugs. > Well, you introduced heavy weight synchronisation that has to be > wrapped around > *every* foreign call to the GUI. No. I'm talking about normal Haskell synchronization primitives. As there's still only one Haskell thread running at one time, they are as lightweight as ever. > Furthermore, you imply that a worker thread should > be run in a different OS thread to keep everything reactive. That will happen automatically in future versions of GHC. If you want a foreign call and a Haskell thread to run in parallel, you need at least two OS threads. Idle callbacks are more inefficient. > However, OS threads are > rather heavy weight and it may take longer to start one than the > processing takes. > In contrast, Haskell threads are extremely light-weight and fast. The RTS pools OS threads. In GHC, I don't expect a complex concurrent GUI program to spawn more than about three OS threads. > I appreciate the work you are doing on supporting OS threads in GHC -- > it is interesting > to see how it will work out. However, for the CGA it is enough to run > in a single OS > thread. The specification should just allow room for use of the CGA in > the context > of multiple OS threads -- but it doesn't have to support all this > automatically as > I think that the issues are more subtle than initially appreciated. > Evolution, not revolution! Of course. I don't insist on requiring CGA implementations to do proper synchronizing, but I think that a) it's not any more difficult than any other problem involving concurrency b) Prohibiting Concurrency and limiting everything to one Haskell thread would be very restrictive c) The middle ground that you proposed, that is to allow multiple Haskell threads to call the CGA as long as they all run in one OS thread, doesn't exist, as a Haskell thread is never guaranteed to run in a certain OS thread. d) Achieving the amount of synchronization & serialization that is automatically provided by a single-threaded RTS is _really simple_, so the number of OS threads should be a non-issue. The question is, do we want to support concurrency or not? Cheers, Wolfgang

1 0