Hi

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.

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.


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 :)


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.

Thanks

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

Reply via email to