
There should be some more general discussion of the issue in this overview of the xmonad: http://www.haskell.org/haskellwiki/Xmonad/Guided_tour_of_the_xmonad_source But more specifically, it's an arbitrary split between functions that are allowed to directly modify xmonad's state, read and write arbitrary files and other IO, and those that only get to return new values. Suppose you have two functions with the type accepted by `windows', which focus another workspace, shift windows around etc.: f, g :: WindowSet -> WindowSet The xmonad library could also export: f_, g_ :: X () f_ = windows f g_ = windows g But let's say you want a single keybind that does f and then g. For example, shift a window to another workspace, and view the new workspace too. You could implement this as: x, y :: X () x = windows (\windowset -> g (f windowset)) y = do f_ g_ x is a better option than y, since it leads to less round trips to the X server: it produces a new version of xmonad's state, and then asks the X server to make the window arrangement fit the new state. y does the same as if you has two keybinds and hit them right after eachother. Another potential with the split up approach (`referential transparency') is easier testing. It's also better to have much of the code dealing with the X server all in one place (see the source for XMonad.Operations.windows). Or somebody might come along with another implementation of `windows' and be able to reuse some more code. In other words, the design reflects some common practices used to help simplify software. But those arguments don't really apply to whether contrib should export one, or both of f and f_, which is more of a bikeshedding topic. * On Sunday, December 12 2010, kevind256 wrote:
Thanks, it worked. I initially thought that viewOnScreen will also focus that screen (which I did not want), but it doesn't.
For the sake of my (mis)education, could you provide some info what is this windows(...) and why is it required? Maybe just a link to documentation, if possible.
On 12/12/10, Adam Vogt
wrote: * On Sunday, December 12 2010, kevind256 wrote:
---------- Forwarded message ---------- From: kevind256
Date: Sat, 11 Dec 2010 13:37:55 +0300 Subject: How to use onScreen function on startup? To: xmonad@haskell.org Hi,
Sorry to ask question out of total lack of knowledge of Haskell, but how do I use a function (in this case onScreen from XMonad.Actions.OnScreen) at xmonad startup? I's like to assign the last workspace to second screen by default, since it's really secondary in my setup (music player is there usually).
I tried putting this in main = do { ... } section: onScreen 1 "9";
First, onScreen manipulates xmonad state so it needs to be run after that has been created. So put it in the startupHook like:
main = do ... main = xmonad defaultConfig { ... -- other stuff modMask = modm, startupHook = windows (viewOnScreen 1 "9") }
I've corrected the expression as well, following the 'simpler' example given in the module documentation.
Adam
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad