[xmonad] broadcastMessage should not call modify
andrea.rossato at unibz.it
Thu Feb 21 07:03:05 EST 2008
I now have perfectly clear in my mind what happens when issue #111
shows up. I don't know if the solution I'm proposing is the right one,
this is a different matter. Moreover I might even be wrong. But at
least I can try to share my understanding of the problem.
When boradcastMessage is called it will 'get' the windowset, call
handleMessage with the (against would be a correct expression?) layout
of each workspace, and then update the state with a list of workspaces
made up of the stack retrieved by the previous 'get' call, and a
(maybe modified) layout returned by the *successive* handleMessage.
The problem is that handleMessage may change the windows' stack in a
workspace, if a call of 'focus' is made within handleMessage.
This is what happens when you click on a decoration: the stack is
changed *after* 'gets windowset', but broadcastMessage updates the
state with an *outdated* stack, the one retrieved by 'gets'. The
decorations, instead, reflect the updated stack that has been
This doesn't happen with 'sendMessage' because sendMessage calls
handleMessage with (against?) the layout of the current workspace. If
handleMessage returns a new layout, then 'sendMessage' will call
Operations.windows to update the state. And 'windows' will operate on
a state retrieved *after* handleMessage returned, that is to say, with
an updated windowset (and so with an updated stack).
This is why my patch fixes #111 (as long as I can try with my
simulated Xinerama setup - but I'm able to reproduce the issue with
that very setup): it uses 'windows' to update the (Maybe) modified
layouts (when it is Just) of every visible workspace.
Now, as far as I understand, the use of 'modify' in 'broadcastMessage'
is done in order not to call the resource intensive Operations.windows
(there is no other reason *I* am aware of). But I think this wrong,
because it is the only reason why a layout cannot safely call 'focus'
This is my understanding.
More information about the xmonad