Hi folks,
First of all, thanks for gtk2hs. It's already awesome. There are a number
of improvements I would suggest and I may even be willing to work on if I
can find the time.
#1: This one is a 10-second programming effort and is really necessary, I
think.
The current definition of EventM is
type EventM t a = ReaderT (Ptr t) IO a
This is unfortunate because it prevents users from wrapping this in a monad
transformer, for example to carry application state around. For example,
if I were to try to define an action
doSomething :: StateT MyState (EventM any) Bool
the compiler complains because EventM expects two type arguments and was
given only one. The fix is simple: Change the definition of EventM to
type EventM t = ReaderT (Ptr t) IO.
(Arguably, the plumbing should be hidden and EventM should be a newtype,
but that would be more effort because it probably requires changes
elsewhere in the gtk2hs code base.)
#2: MonadIO and type classes for EventM and Render
Let me start by saying that I am not sure how hard this is to do, but it
would help users a lot. Again, the motivation is that applications often
use monad transformers to carry state around, so the main monad may not be
IO but something like StateT MyState IO. Now using pretty much all the
standard gtk functions requires cluttering the code with lots of calls to
liftIO. Changing the type signature of all gtk2hs functions as illustrated
here for buttonNew would solve this: Currently, the type of buttonNew is
buttonNew :: IO Button
Can't we make it
buttonNew :: MonadIO m => m Button ?
This would eliminate the need for lifting in the user code. The same
reasoning applies to Render and EventM, except that it requires more effort
because one would have to define type classes such as MonadEventM and
MonadRender. The lack of this approach for EventM is quite a bit more
annoying than the need to sprinkle liftIO's throughout the code because
passing an event handler wrapped in a StateT transformer or similar to "on"
explicitly requires packing and unpacking the state.
Let me close by saying once more that I am happy gtk2hs exists because,
even though I say "annoying" above, it would be more annoying not to have
gtk2hs for GUI development in Haskell. Thanks for your efforts, guys.
Cheers,
Norbert
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
