Hi all!<br><br>This may end up being a long e-mail. Executive summary:<br><br> 1. PerWorkspace is an inelegant hack with several icky problems:<br> - 'description' is not in the X monad so can't figure out the<br>
current workspace<br> - the currently focused workspace might not even be the correct<br> one anyway, in the case of xinerama or message handling.<br><br> 2. Andrea's LayoutCombinator class and core patch to move the result<br>
of the description function into the X monad will help with some<br> but not all of the problems. In particular it still won't work<br> with xinerama.<br><br> 3. It would be nice to have the PerWorkspace functionality supported<br>
in the core, and I have a nice, elegant way to do it. This would<br> fix all the problems. ...The only catch is that it would also<br> require going back to requiring existential Layout wrappers<br> everywhere. =(<br>
<br> 4. Well, crap.<br><br><br><br>I had recently been thinking about PerWorkspace and ways to improve<br>it, but hadn't yet gotten around to really doing anything about it.<br>Andrea's new emptyLayout function, and then in particular his<br>
reimplementation of PerWorkspace using the new LayoutCombinator<br>framework obviously motivated me to get around to it! So I'd like to<br>explain some of the problems with PerWorkspace and possible future<br>directions. <br>
<br>First, the basics: although the xmonad core tracks layouts separately<br>for each workspace, it is not possible to *specify* a different<br>starting layout on a per-workspace basis. Only a single layout may be<br>specified in the XConfig record, and this layout is duplicated across<br>
all workspaces on xmonad startup. PerWorkspace attempts to get around this<br>limitation by providing a layout which dynamically decides on which of two sub-layouts<br>to use, based on the current workspace tag. All workspaces still have the<br>
same layout, but that one layout acts differently depending on the current workspace. <br>You can see from the beginning that this is something of a hack.<br><br>This approach has two major limitations, each of which leads to one or<br>
more problems.<br><br> * To find out the current workspace obviously requires access to the<br> X monad. For doLayout and handleMessage this is obviously not a<br> problem. The description method, however, is a pure function. I<br>
solved this in a very hackish way before by having a call to<br> doLayout return a modified PerWorkspace layout structure with a<br> cached value remembering which of the two layouts should be used.<br> description could then use this cached value to decide on the<br>
description to return. Andrea's current reimplementation of<br> PerWorkspace does not do this caching, which is why the<br> description method is currently broken. I can reimplement this,<br> and the new emptyLayout method will help, but it still feels very<br>
inelegant.<br><br> * A more insidious problem is that it is not possible, in general,<br> for doLayout or doMessage to figure out which workspace they<br> belong to, and hence which layout to use. PerWorkspace currently<br>
works by retrieving the tag of the currently focused workspace<br> from the xmonad state, but there are several situations in which<br> doLayout or handleMessage are called on a workspace which is<br> not the currently focused workspace:<br>
<br> - If xinerama is in use, doLayout will be called for all the<br> visible workspaces as well as the focused workspace.<br> - Messages can be broadcast to all workspaces, in which case<br> handleMessage will be called for all workspaces, including<br>
non-focused or even hidden workspaces.<br><br> In either of these situations, PerWorkspace may choose the wrong<br> layout. The message problem can be solved by simply passing along<br> any messages to all layouts, without trying to decide on the<br>
correct one: it cannot hurt to pass messages to unintended<br> recipients, especially if the unintended recipient layouts will<br> never be used anyway! The xinerama problem seems insoluble,<br> however. PerWorkspace simply cannot work on xinerama because it<br>
cannot get the information it needs to decide which layout to<br> use.<br><br>So, what is the way forward? It looks like I can get PerWorkspace<br>back to its original level of workingness --- thanks to the<br>LayoutCombinator class it will be a lot shorter, but it still won't<br>
work with xinerama, and it will still be an ugly, fragile hack.<br><br>I had been intending to suggest adding support for per-workspace<br>layouts to the xmonad core. After all, xmonad does track and<br>save/restore layouts on a per-workspace basis, so why shouldn't it<br>
allow configuring them on a per-workspace basis too? I intended to keep<br>the current layoutHook (specifying the default layout to be used on<br>all workspaces not otherwise specified) as well as adding a new field<br>to the config which would store a list of (workspace tag, layout)<br>
pairs. The core modifications necessary to support this are not too<br>hard and end up being fairly elegant -- in fact, I have made these<br>modifications in a local branch.<br><br>The catch? Having a bunch of layouts in a list like this requires<br>
going back to wrapping everything with Layout existentials in user<br>configs! =( This doesn't sound like much fun either.<br><br>So, I am at something of a loss. Any thoughts or suggestions for moving forward<br>are appreciated!<br>
<br>-Brent