[xmonad] Fwd: How to use onScreen function on startup?

[kevind256]

Thanks for explaination. windows() therefore finally applies changes
specified by functions inside. Well at this moment, I think we
shouldn't have f_ (this means more verbosity in case of single
function call, but more uniformity and less possibility for incorrect
style which surely would arise otherwise).

On 12/13/10, Adam Vogt <vogt.adam at gmail.com> wrote:
> 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 <vogt.adam at gmail.com> wrote:
>>> * On Sunday, December 12 2010, kevind256 wrote:
>>>
>>>>---------- Forwarded message ----------
>>>>From: kevind256 <kevind256 at gmail.com>
>>>>Date: Sat, 11 Dec 2010 13:37:55 +0300
>>>>Subject: How to use onScreen function on startup?
>>>>To: xmonad at 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 at haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>