Yeah; I probably did (relatively new to xmonad myself).. My understanding of the OP's question is they want a set of layouts they can cycle through normally in the layoutHook (eg resizabletall, mosaic, spiral); then have a hot key that overrides this behaviour and jumps to another layout (eg full). If this is the case one can define all of their layouts in the hook, then using onWorkspace (or onWorkspaces) from XMonad.Layout.PerWorkspace, indicate which layouts to use in the normal rotation whilst still having the hot key layouts defined [I also use avoidStruts here; hence my original confusion]. Otherwise I've missed the point entirely; hopefully your suggestions will solve the problem Brandon. On 03/05/13 09:49, Brandon Allbery wrote:

Did you mean something else? avoidStruts has nothing whatsoever to do with what layouts are selectable.

On Thu, May 2, 2013 at 6:24 PM, Tim DuBois <tim@neophilus.net <mailto:tim@neophilus.net>> wrote: Would it not be better to list all your layouts in the layoutHook; then use avoidStruts to only allow a subset of those layouts to function on your workspaces? That way your shortcuts (i.e. the layouts not listed in avoidStruts) will still be accessible, just not 'visible' in general.

On Thu, May 2, 2013 at 8:04 PM, Brandon Allbery <allbery.b@gmail.com> wrote:

Note the shortcomings, though:

- if you want layout modifiers, they must be included here; there is no way to apply the layoutHook's layout modifiers to something not in the layoutHook. - layouts store state in their constructors in the layoutHook. This state will probably be inaccessible. - the layout and its state will be lost across mod-q because only the layoutHook is saved across invocations. No, it is not possible to save the keybindings on the off chance that someone hid a layout inside them. - layout modifiers with runtime behavior, as a result of the above, will either not have that behavior or will malfunction in various ways. (Example: mod-b to toggle struts would only toggle them in the layoutHook. - some runtime behavior is accomplished via sending messages to layouts. This, again, expects those layouts to be reachable via the manageHook, and often requires some state. At the very least, I expect broadcast messages will not reach your layout. - other things that know that the layout is reachable from layoutHook will break. I'm not thinking of any off the top of my head, but it's not unlikely that something in the xmonad core cares.

One more that just occurred to me: persistent ExtensibleState is stored within the layout so it can be passed on via mod-q, and I'm not sure what would happen to this state if you replace the layout with something not reachable via layoutHook. (This may not only affect persistence across restarts, but conceivably could result in anything using ExtensibleState using an unrelated copy of that state post-setLayout. I would have to trace through the ExtensibleState code to see if this is a problem, or if we hid it in the Layout wrapper or something so it might get copied over correctly.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net