On Mon, 2006-11-13 at 15:41 +0300, Bulat Ziganshin wrote:

Hello Duncan,

Monday, November 13, 2006, 3:36:32 AM, you wrote:

...

...

afaik, there are just two good enough libs - wxHaskell and GtkHs. can

in brief, i see the following main differences:

- wxHaskell is easier to understand and to use, Ght2Hs allows to use Glade to develop "look&feel"

Easier to understand is rather a matter of personal taste. Certainly Gtk is a big library, providing lots of features. I should also note that one of the main improvements in the upcoming Gtk2Hs release will be to try to simplify the api and improve the reference documentation by making greater use of atribute and signal abstractions rather than lots of getter/setter functions.

- Gtk2Hs had better support, but now wxHaskell has more maintainers and situation may change to opposite in a next few months

It'll be good to have more competition :-) hopefully both systems will improve more rapidly.

- wxHaskell provides more native look&feel, while Gtk2Hs simplifies porting of GUI application from Windows to Linux. Also Gtk2Hs needs Gtk DLL to be installed, but this can be made a part of application installation procedure, afaik?

Both Gtk2Hs and wxHaskell need DLLs to be installed and in both cases it can be made part of the install procedure. You just need to bung the right set of dlls in the same directory as the .exe that you distribute. It's exactly the same as with any other windows app that needs extra dlls.

- Gtk2Hs has better memory management

- differences between Gtk and wxWidgets that i will go to study

i also have more questions: first, how about tabbed pages control? such controls are widely used to represent plenty of information in limited screen space

Both have tab controls.

second: ability and easiness to develop my own controls, and to combine several customized controls together to make one "supercontrol" (although i guess that last feature is important only for RAD environments)

third: are there any "appetizers" demonstrating features of each library and with source code available for studying? except for memory.pdf which don't mention where full source can be downloaded

There are a bunch of demos included in the Gtk2Hs sources and there are various apps written by other people available on the web. For example: http://www.cs.kent.ac.uk/projects/pivotal/downloads.html http://haskell.galois.com/~paolo/nymphaea/ Apart from the memory pdf intro there a general intro presentation and a glade tutorial: http://haskell.org/gtk2hs/archives/2006/03/06/introductory-presentation/ http://eddy.writelinux.com/gtk2hs/GladeGtk2Hs.html

it will be interesting to see sources of more "business-like" applications developed with both libs. if there are no ones, may be i will develop basic file manager utility as such appetizer

That would be great. Duncan

On linux you should use your package manager (whenever possible), not binaries from the site (or compile it yourself). -- WBR, Max Vasin.

Hi

- Gtk2Hs had better support, but now wxHaskell has more maintainers and situation may change to opposite in a next few months

As long as Duncan is around, there will always be enough Gtk2Hs support! Currently Gtk2Hs _has_ better support, the situation may change or may not. Remember that Duncan is not the only Gtk2Hs person, merely the most active :)

- wxHaskell provides more native look&feel

Definately true. For GuiHaskell (http://www-users.cs.york.ac.uk/~ndm/projects/guihaskell.php) I was able to get it quite Windows looking with a bit of help from Duncan. As a result of the attempt to make it more Windows like a few Gtk bugs were filed, and it does appear that better Windows GUI styles are something that is already in a Gtk release.

third: are there any "appetizers" demonstrating features of each library and with source code available for studying? except for memory.pdf which don't mention where full source can be downloaded

The full source code of GuiHaskell is available. The one thing you should be aware of is that Windows + Threading + Gtk2Hs + Gtk + GHC = Pain. I suspect the same equation holds for wxHaskell as well. Ask Duncan for more information if this looks like being a problem. Thanks Neil

Hi Bulat, http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.10.exe That's the most recent Gtk2Hs for 6.4.2.

...

The one thing you should be aware of is that Windows + Threading + Gtk2Hs + Gtk + GHC = Pain.

why? are you tried to call Gtk2Hs from only one thread?

I think so, yes. Or there are bizare -threaded restrictions. Only Duncan (and perhaps Simon Marlow) understand this. I merely got bit by it... Thanks Neil

On 11/13/06, Bulat Ziganshin wrote:

Hello Neil,

Monday, November 13, 2006, 5:06:02 PM, you wrote:

...

http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.10.exe

...

That's the most recent Gtk2Hs for 6.4.2.

the http://haskell.org/gtk2hs/download/ page says that gtk2hs is available only for 6.4.1

...

...

...

The one thing you should be aware of is that Windows + Threading + Gtk2Hs + Gtk + GHC = Pain.

why? are you tried to call Gtk2Hs from only one thread?

...

I think so, yes. Or there are bizare -threaded restrictions. Only Duncan (and perhaps Simon Marlow) understand this. I merely got bit by it...

it will be great to see comments about this. it's impossible to write my program without using threaded RTS

I'm not an expert, but I think the only solutions available depend on some sort of polling. E.g. you could start the GUI in a single bound thread, and then pass in all GUI calls to a channel. Then you would attach an event handler to idle event (or a timer) which checks to see if there are any items in the channel, and if so runs them in the GUI thread. The problem is that you can't actually run GUI actions from other threads, you can only schedule them to be run by the GUI thread, and you can't actually "insert" your "block on the UI actions queue as well as message queue" in the GTK event loop. So you have to every now and then do this yourself. This could end up in a situation where you very often check this channel and it's empty, which uses unnecessary resources, or it could end up in a situation where you don't check it often enough and any UI actions caused by other threads get delayed. I suspect that a more sophistated scheduler could be written which helps with most of this (i.e. use a timer with some default value, if there are many items in the channel then decrease the timout value, if there are no items in the channel increase the timout value up to some maximum). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

Hello Duncan, Monday, November 13, 2006, 10:19:16 PM, you wrote:

...

...

...

why? are you tried to call Gtk2Hs from only one thread? it will be great to see comments about this. it's impossible to write my program without using threaded RTS

As for the threaded RTS, currently that's only ok if you never make GUI calls from more than one Haskell thread.

it is what i say about. threaded RTS + multipls threads that does computations + one thread that interfaces with Gtk2Hs. afaiu, the only problem is that i need to manage both Gtk events and periodically check queue of commands from other threads, but using timer + Chan should allow to implement this -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

I wonder whether it'd be possible to make the gtk2hs stuff emit warnings if you make calls from two different threads? Then an application would complain constructively rather than "becoming unstable". Simon | -----Original Message----- | From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Dmitry V'yal | Sent: 14 November 2006 10:27 | To: haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] what GUI library should i select? | | Bulat Ziganshin wrote: | | > it is what i say about. threaded RTS + multipls threads that does | > computations + one thread that interfaces with Gtk2Hs. afaiu, the only | > problem is that i need to manage both Gtk events and periodically | > check queue of commands from other threads, but using timer + Chan | > should allow to implement this | > | I wrote multi threaded gui application in Haskell last spring as a educational | project. That was a tool for analyzing and extracting contents of FAT volumes. | Then i started my project, i was completely unaware of these threading issues | and freely called gtk2hs routines from several threads. All worked fine at | first, but when i added some disk I/O to my threads, my program became unstable. | While on linux it just crashed from time to time, on windows i saw more curious | behavior. At random spots threads lost ability to call WinAPI functions. | Basically they got an error code meaning something weird like "insufficient | memory to complete call" in return. That was not easily reproducible and | depended on exact version of Windows. At some point my app was fully functional | on WinXP and didn't even start on Win2000. | I spent a lot of time trying to debug these issues and finally refactored my | program to make use of approach you describe. Worked fine after that. All you | have to do is to choose appropriate timer interval, otherwise your app becomes | too jerky or CPU hungry. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

On Tue, 2006-11-14 at 10:40 +0000, Simon Peyton-Jones wrote:

I wonder whether it'd be possible to make the gtk2hs stuff emit warnings if you make calls from two different threads? Then an application would complain constructively rather than "becoming unstable".

I have three plans: Plan 1: prevent gtk2hs initialising when using the threaded RTS. This is what the dev version does at the moment to prevent people shooting themselves in the foot. Obviously this is not satisfactory as long term the threaded rts is going to be the only option available. The funny thing is that we can actually use Haskell threads with Gtk2Hs perfectly well with the single threaded rts (we currently use a polling scheme to to cooperative scheduling between gtk+ and ghc rts but there are some non-polling possibilities that could be implemented.) Indeed, we used to be able to have GUI stuff work fine in GHCi, but now that GHCi uses the threaded rts we're in trouble. Plan 2: Make the threaded rts do what we want. This is hard and involves begging Simon M to do lots of work. The constraints we have are that only the OS thread that initialised the GUI can make calls to the GUI lib. So any Haskell threads doing GUI stuff have to be running on that OS thread. Note that this really means one OS thread, not one capability which can run on a pool of threads (with X11, the pool might be ok as only one would be doing GUI stuff at once but on Win32 the restrictions are even tighter). I really don't want to make the Haskell coders have to deal with passing actions between threads to get it right, because people will get it wrong too easily. So any thread cunning needs to be hidden in the library so that people cn just use threads willy nilly without there being dangerous unchecked conditions. So one idea is to start the UI in a bound OS thread, but then we also want to make sure that any Haskell thread that makes a GUI call only do it in that same OS thread. Currently we cannot bind several Haskell threads to a single OS thread. From discussions with Simon M it is clear that making this possible is non-trivial. Then even once we have that, to make it transparent we'd need to be able to migrate a Haskell thread to the right OS thread if it makes a GUI call. The GUI wrapper lib would need to arrange this and arrange for cooperative scheduling on the one OS thread. Lots of work. The reason we can't just post actions to the right thread all the time is that GUI calls are typically very short lived. Many are just reading fields out of C struts. If every one of those needed an OS thread switch then it'd be pretty bad. So thats why we'd need to migrate the thread since that's a one off and after that GUI calls would be quick. Plan 3: perhaps the IO monad isn't the right monad It's really quite convenient to have complete access to the IO monad when doing GUI stuff and that seems to be the design that most recent libs have chosen. So suppose we had a GUI monad and the boundaries between the IO and GUI monad would take care of making sure we were using the right OS thread. So we would initialise the GUI and then work inside the GUI monad. It'd fork a bound thread to run the GUI lib's event loop. It'd also have to arrange for cooperative scheduling in that OS thread. Then the GUI monad could have a forkGUI that uses Haskell level scheduling to schedule several GUI 'threads' in the single bound Haskell thread. Then to do IO, we could provide an escape hatch to do IO, for blocking stuff we could forkIO and let it run in an unbound thread. Similarly for long running pure computations we could provide something (or just par?) to let those run outside the GUI thread so that it doesn't block the UI. So you'd be able to lift IO stuff into the GUI monad. As for the other way around, I guess that could arrange for the GUI action to be added to the GUI scheduler run queue. Tricky bits: callbacks get run in their own unbound Haskell thread which would therefore not run in the bound OS GUI thread. That'd be annoying as it'd involve 2 pointless context switches per callback event. Is there any way we could be a bit less strict. All we need is that the GUI Haskell thread runs in the GUI OS thread, we don't mind if other Haskell threads run in that OS thread too. So a could a callback that comes in on that OS thread spark a Haskell thread in that same OS thread? Then we could add the callback action to the Haskell GUI thread's runqueue and yield to that thread. So we might still need some RTS changes to make it work nicely. Sigh. I'd welcome other suggestions. If we can make it work nicely it should be great. Using light weight threads is a nice approach to GUIs compared to the contortions that people have to do in other languages to do everything in an event driven style to share a single thread while avoiding ever blocking. Duncan

On Wed, 2006-11-15 at 01:29 +0000, Neil Mitchell wrote:

...

The funny thing is that we can actually use Haskell threads with Gtk2Hs perfectly well with the single threaded rts (we currently use a polling scheme to to cooperative scheduling between gtk+ and ghc rts but there are some non-polling possibilities that could be implemented.)

Do these work for my particular application? (running a process in the background, and sending its stdout to a Gtk Window). The polling I implemented didn't work very well at all.

Yeah, we did have that weird problem on windows with the single threaded rts that we never tracked down. However I get the feeling that we shouldn't be putting too much effort into fixing the single threaded rts on windows as it will not be around for ever.

...

Plan 2: Make the threaded rts do what we want.

This is hard and involves begging Simon M to do lots of work.

How many people are required to beg? I volunteer :)

Heh :-) Well it's got to be clear that it's worth the effort. We don't want to steal too much of his paper-writing time.

...

Plan 3: perhaps the IO monad isn't the right monad

It's really quite convenient to have complete access to the IO monad when doing GUI stuff and that seems to be the design that most recent libs have chosen.

Can I read a file in a GUI thread? Can I spawn a process and read an external handle? I suspect that more and more things would be added to the GUI monad until GUI == IO.

Aye, there would be methods to get between them. So you could do IO in the GUI monad using liftIO, and perhaps another liftIO variant for IO actions that would block. So we wouldn't need to keep adding things to the GUI monad. The crucial ones would be for liftIO, forkGUI and MVar-style synchronisation. Duncan

On 11/14/06, Dmitry V'yal wrote:

Bulat Ziganshin wrote:

...

it is what i say about. threaded RTS + multipls threads that does computations + one thread that interfaces with Gtk2Hs. afaiu, the only problem is that i need to manage both Gtk events and periodically check queue of commands from other threads, but using timer + Chan should allow to implement this

I wrote multi threaded gui application in Haskell last spring as a educational project. That was a tool for analyzing and extracting contents of FAT volumes. Then i started my project, i was completely unaware of these threading issues and freely called gtk2hs routines from several threads. All worked fine at first, but when i added some disk I/O to my threads, my program became unstable. While on linux it just crashed from time to time, on windows i saw more curious behavior. At random spots threads lost ability to call WinAPI functions. Basically they got an error code meaning something weird like "insufficient memory to complete call" in return. That was not easily reproducible and depended on exact version of Windows. At some point my app was fully functional on WinXP and didn't even start on Win2000. I spent a lot of time trying to debug these issues and finally refactored my program to make use of approach you describe. Worked fine after that. All you have to do is to choose appropriate timer interval, otherwise your app becomes too jerky or CPU hungry.

[I sent a message earlier to this effect but accidentally hit "reply" rather than "reply all" so only duncan got it] I'm looking through the GTK docs and it appears to me that you don't actually have to choose an interval at all. All that's needed is that you somehow "trigger" the GTK event loop to call an event handler in its thread which empties the channel and executes any GUI actions therein. It seems that GTK supports adding custom sources to the event loop (if I understand the docs correctly, this is thread safe, and signalling one of these sources should be too). So either we add a new custom source, or find some other way of "signalling" a particular event. I would guess one way of doing this would be to add a timeout event handler with delay 0, this event handler would be a function called, say, dispatchPendingGUIActions, which empties the channel of GUI actions, and also returns False so that it will only get called once (per "signal" - the next "signal" it will get added again). In other words, there is no need for polling. Just add the function to the channel and signal the main loop (first checking if we are already in the main GUI thread in which case we just call the action directly without going through the channel, and also checking if a "signal" has already been raised but not yet "handled" in which case we don't do it again) . Something like (untested): -- contains the action, and the response mvar data GUIWorkItem = forall a . GUIWorkItem !(IO a) !(MVar a) newGUIChan :: IO (Chan GUIWorkItem) newGUIChan = newChan -- this adds an action to the main channel, unless we're already -- in the main GUI thread, in which case we just run the action directly dispatchGUIAction act do isMain <- isMainGUIThread if isMain then act else do res <- newEmptyMVar writeChan theGlobalGUIChan (GUIWorkItem act res) triggerMainGUIThread unsafeInterleaveIO (takeMVar res) -- this is the action we want to call from the main GUI thread -- every time a new action has been added to the queue, e.g. -- by adding it as an event handler to a timer event dispatchPendingGUIActions do empty <- isEmptyChan if empty then setGTKThreadNoLongerTriggered >> return False else do GUIWorkItem act resVar <- readChan theGlobalGUIChan res <- act putMVar resVar res dispatchPendingGUIActions -- an example GUI action, this is how we "wrap" all our actions gtkAction' x y z = dispatchGUIAction (gtkAction x y z) -- this is how we signal GTK so that it will call the code which -- handles all the actions in theGlobalGUIChan triggerMainGUIThread = do isTriggered <- isGTKThreadTriggered -- not necessarily needed... if isTriggered then return () else timeoutAddFull dispatchPendingGUIActions priorityHigh 0 (note: The unsafeInterleaveIO is there so that dispatchPendingGUIActions won't have to block until the main GUI thread gets around to handling the event, after all for quite a few GTK actions you don't really care about the result so you should return immediately). There are some minor gaps here, but that's the general idea. We avoid the polling by explicitly signalling GTK whenever we add a GUI event to the channel. I've done it here by adding the "dispatch" function as an event handler to a timeout event (this event handler returns False so the timeout event is removed after being called). This depends on wether or not adding event handlers is thread safe. If it isn't, it may be enough to wrap the triggerMainGUIThead action in a global lock (someone who knows more obout this?). If that still isn't safe, then we could add our own custom source to the GTK event loop and signal the event loop using that (though that might be a bit more messy?). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862

Bulat Ziganshin wrote:

third: are there any "appetizers" demonstrating features of each library and with source code available for studying? except for memory.pdf which don't mention where full source can be downloaded

it will be interesting to see sources of more "business-like" applications developed with both libs. if there are no ones, may be i will develop basic file manager utility as such appetizer

There are plenty of nice gtk2hs examples out there. You can take a look at [1]himerge, one of the applications i've been developing with gtk2hs as an example, which uses several features and common functionalities for most GUI. Regards, [1] http://www.arjox.org/himerge.html

[reposted with improved subject] I notice that the Socket returned by ghc Network.Socket (socket) has been set non-blocking. (Noticed empirically, not from documentation.) The Network.Socket functions that use it, e.g., recv, are ready for that, of course, but as a general rule, external functions that expect a socket are very likely not. So I hacked up a crude fcntl call to undo the damage and restore my socket to normal default mode, but it makes me wonder what moved the ghc library authors to depart from common usage in this respect, and provide no obvious means for the programmer to restore the normal mode? Threads, maybe? Is blocking I/O seriously incompatible with the GHC threading model (or one of the models)? If I have external library functions that use socket I/O internally, e.g., an OpenLDAP interface, that's effectively the same as a blocking socket created in Haskell, so whatever problem with one is the same with the other, right? thanks, Donn Cave, donn@drizzle.com

On Mon, 2006-11-13 at 04:18 +0100, Iván Pérez Domínguez wrote:

I'm using Gentoo Linux. We obviously don't use prebuilt packaged versions, but installing it is just doing "emerge wxhaskell" and 'playing the... waiting game'. Gtk2hs support under Gentoo is mostly missing (the package is included, but doesn't work at all).

Heh, that's odd. For me it's usually the other way around and I maintain both of those Gentoo packages! :-) Are you thinking of this bug or is it something else? http://bugs.gentoo.org/show_bug.cgi?id=144028 If it's something else then please report it. Duncan

Iván Pérez Domínguez wrote:

I'm using Gentoo Linux. We obviously don't use prebuilt packaged versions, but installing it is just doing "emerge wxhaskell" and 'playing the... waiting game'. Gtk2hs support under Gentoo is mostly missing (the package is included, but doesn't work at all).

Hmm, that strange. I emerged both gtk2hs-0.9.10 and ghc-6.4.2 just fine. Probably you should update your portage tree. I don't remember exactly, but I used portage snapshot from late spring of 2006. Now I'm waiting for ghc-6.6 being added to official portage tree.

Has anyone succeeded in getting it running on OSX/intel at all? ...I had a brief go a few weeks back, managed to get the Cairo Clock running, but anything that used GTK seemed to blow up instantly. (OSX/ ppc was fine). --Ben On 13 Nov 2006, at 19:03, Duncan Coutts wrote:

On Mon, 2006-11-13 at 18:00 +0000, Tim Docker wrote:

...

...

afaik, there are just two good enough libs - wxHaskell and GtkHs. can anyone point (or write) detailed comparison of their features?

One point in wxHaskell's favour is that it supports Mac OS X directly. At present, to the best of my knowledge, you can only run GtkHs applications on OS X using the X Windows server. Whilst this works, it's a _long_ way from native look and feel.

This is quite true. Fortunately the Gtk+ folk are well underway with a project to make it all more native looking. The latest released version of Gtk+ 2.10.x has 'experimental' support for running on OSX without using X11. The next step (apart from general bug fixing) is to use the right native theme.

So yes, at the moment it doesn't look native on OSX but hopefully in the future it will. You can read more about that here:

http://developer.imendio.com/projects/gtk-macosx

Duncan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

gtk-demo seemed to run fine. --Ben On 13 Nov 2006, at 21:01, Duncan Coutts wrote:

On Mon, 2006-11-13 at 20:49 +0000, Ben Moseley wrote:

...

Has anyone succeeded in getting it running on OSX/intel at all?

I'm not sure actually. I seem to recall someone trying it but I can't remember who now.

cc-ing to gtk2hs-users in case anyone knows: has anyone on OSX tried the new Gtk+ 2.10.x that doesn't use X11?

...

...I had a brief go a few weeks back, managed to get the Cairo Clock running, but anything that used GTK seemed to blow up instantly. (OSX/ ppc was fine).

Did you try any of the C examples, like gtk-demo? I'm afraid I don't have access to OSX.

We're actually looking for someone to help with maintaining Gtk2Hs on OSX (and someone for windows too). So if you're interested or know anyone who is interested then do get in touch.

Duncan

...

On 13 Nov 2006, at 19:03, Duncan Coutts wrote:

...

...

...

One point in wxHaskell's favour is that it supports Mac OS X directly. At present, to the best of my knowledge, you can only run GtkHs applications on OS X using the X Windows server. Whilst this works, it's a _long_ way from native look and feel.

This is quite true. Fortunately the Gtk+ folk are well underway with a project to make it all more native looking. The latest released version of Gtk+ 2.10.x has 'experimental' support for running on OSX without using X11. The next step (apart from general bug fixing) is to use the right native theme.

So yes, at the moment it doesn't look native on OSX but hopefully in the future it will. You can read more about that here:

http://developer.imendio.com/projects/gtk-macosx

On 11/16/06, Eric Willigers wrote:

Bulat Ziganshin writes:

...

Hello haskell-cafe,

afaik, there are just two good enough libs - wxHaskell and GtkHs. can anyone point (or write) detailed comparison of their features? i plan to write large GUI program in Haskell and want to select best one.

Putting aside issues of completeness and the availability of particular components **, how have people found the Functional Reactive approach used by Fruit or FranTk? The example code for each looks very appealing.

** Suppose FranTk had been written or generated with Gtk2Hs or wxHaskell as the underlying library instead of Tk.

Personally I find all of that stuff really cool in a geeky sort of way, but for unclear reasons it just doesn't "feel" all that useful for real-world stuff. It just seems a bit too "heavy" to use, to the point where I prefer a much more low level but straightforward approach (using a thin wrapper on top of imperative libraries). I'm sorry I can't explain better, but I do think it's a promising area for research. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862