Hi, I would like to bind a keyboard shortcut to change to a specific layout (e.g. Full, Grid, etc.). I've been using sendMessage $ JumpToLayout "Full", however, it will only switch to a layout that is already configured in layoutHook. I'd like to switch to a layout that is _not_ in the layoutHook. Is this possible? Thank you, -- There are 10 types of people, those who know binary and those who don't.
On Thu, May 2, 2013 at 1:46 PM, Eyal Erez
I would like to bind a keyboard shortcut to change to a specific layout (e.g. Full, Grid, etc.). I've been using sendMessage $ JumpToLayout "Full", however, it will only switch to a layout that is already configured in layoutHook.
I'd like to switch to a layout that is _not_ in the layoutHook. Is this possible?
In theory you could set a layout that is not in the layoutHook, using setLayout and an existential wrapper; in practice, I suspect it would be forgotten fairly quickly and you would be reset back to what is in the layoutHook. The layoutHook is how the rest of xmonad knows about the layout. What are you expecting things that need to run the layout (for example, when a new window opens) to do? Guess and hope? -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
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 03/05/13 03:46, Eyal Erez wrote:
Hi,
I would like to bind a keyboard shortcut to change to a specific layout (e.g. Full, Grid, etc.). I've been using sendMessage $ JumpToLayout "Full", however, it will only switch to a layout that is already configured in layoutHook.
I'd like to switch to a layout that is _not_ in the layoutHook. Is this possible?
Thank you,
-- There are 10 types of people, those who know binary and those who don't.
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
On Thu, May 2, 2013 at 6:24 PM, Tim DuBois
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.
Did you mean something else? avoidStruts has nothing whatsoever to do with what layouts are selectable. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
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
Oh, I gave you half the answer but not the other half. It would be something along the lines of (setLayout $ Layout $ layout goes here). 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.
On Thu, May 2, 2013 at 8:04 PM, Brandon Allbery
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
On Fri, May 3, 2013 at 7:05 AM, Brandon Allbery
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.)
Hi Brandon & Eyal, ExtensibleState is a separate from the layout http://xmonad.org/xmonad-docs/xmonad/XMonad-Core.html#t:XState so whatever you do with setLayout shouldn't have an impact there. It's pretty likely that you won't maintain the results of a (setLayout $ Layout x) after a restart. An exception to that trend is if `x' has the same type as what you have in the layoutHook. In that case you'll have the new layout restored, instead of just getting the one specified in the layoutHook. Cheers, Adam
participants (4)
-
adam vogt -
Brandon Allbery -
Eyal Erez -
Tim DuBois