studying xmonad code as a guideline for gui-code?

Hi all, I'm wondering if studying xmonad code will help me write better gui code. I've got some ui-code for wxHaskell, with several drop downs where the selection of one drop-down effects the contents of every other drop-down. I wrote this with IORefs all over the place and I think this problem begs for a zipperish solution. I have only glimpsed at the xmonad code but I don't remember seeing even a single IORef, so I am asking for your opinion: Can studying xmonad code provide me with a better solution for my problem? Günther

On Sun, Dec 20, 2009 at 05:58:29PM +0100, Günther Schmidt wrote:
Hi all,
I'm wondering if studying xmonad code will help me write better gui code. I've got some ui-code for wxHaskell, with several drop downs where the selection of one drop-down effects the contents of every other drop-down. I wrote this with IORefs all over the place and I think this problem begs for a zipperish solution.
I have only glimpsed at the xmonad code but I don't remember seeing even a single IORef, so I am asking for your opinion: Can studying xmonad code provide me with a better solution for my problem?
Günther
I'm not sure how representative xmonad is of GUI applications. Raw X11 is likely very different from wxHaskell, and xmonad isn't really interactive in the same way that GUIs are. Regardless, XMonad.StackSet is a good study in how to separate an application's model into a separately testable, purely functional module. Cheers, Spencer Janssen PS: It's true, there isn't a single IORef in xmonad's core

Quoting Günther Schmidt
I have only glimpsed at the xmonad code but I don't remember seeing even a single IORef, so I am asking for your opinion: Can studying xmonad code provide me with a better solution for my problem?
xmonad uses a State monad transformer to maintain information. The upside of this is that no mutable variables are necessary -- it just passes along different copies of its state as the state needs to "change". The downside is that it is utterly impossible for two threads to share the internal state as it changes. Since most GUI code is multithreaded eventually (to keep the GUI responsive during expensive operations), I wouldn't recommend this approach... ~d
participants (3)
-
Günther Schmidt
-
Spencer Janssen
-
wagnerdm@seas.upenn.edu