I'm thinking that the most flexible way of doing this would be to write a layout modifier that declares different parts of the screen to be dedicated to certain types of clients, while the remainder of the screen uses any regular layout. Doing this using a modifier has the advantage that the client doesn't have to cooperate and one could have multiple reserved screen areas (e.g., bottom, very narrow for the minibuffer, left for emacs speedbar, etc.) If you want to do it using struts, I can only see three ways of doing it, and neither seems too appealing: 1. Set the strut statically, but what if you want to use the same workspace for other stuff later on. The strut is still there. 2. The suggestion by Bruce: make the minibuffer window set _NET_WM_STRUT_PARTIAL. 3. Same as (1) but create and tear down the strut as part of window management whenever the minibuffer window appears/disappears. I'm not sure how to do (3), and it may in fact be easy, but I suspect that it would end up being more kludgy than writing the above layout modifier, which shouldn't be hard at all. Cheers, Norbert On Sat, May 02, 2009 at 07:43:49PM -0400, John Yates wrote:
Bruce,
Thanks for the quick reply.
I don't know whether this is the best approach, but it occurs to me that having the mini-buffer frame declare itself as a strut (by setting _NET_WM_STRUT_PARTIAL) might be a good way to do it?
A fully-tiled mini-buffer is amazingly frustrating. It moves around and invariably has a disconcerting aspect ratio.
Having an Emacs mini-buffer-only frame declared as some form of strut would seem appropriate. The xmonad FAQ suggests that being able to set override redirect is also important. And for good measure the _NET_WM_WINDOW_TYPE should probably be changed from _NET_WM_WINDOW_TYPE_NORMAL to _NET_WM_WINDOW_TYPE_DOCK.
There's an xmonad extension to handle struts, and presumably other window managers could make use of it, too.
Absolutely. Down the road I would love to have the freedom to experiment easily with various window managers without each time having to contend with a screwy mini-buffer.
(I don't know whether this could be done in elisp. Hmm, I guess it's not, but that feels like a logical thing for Emacs to be able to do, so maybe add a frame parameter to do that?)
Emacs already has a number of frame parameters that seem to exist only to be passed through as window attributes. Similarly window type and override redirect could be exposed as simple pass-throughs. By contrast a strut or strut_partial property probably would have to examine at least the top, left, height, and fullscreen frame parameters.
History suggests that getting such changes into an Emacs release could take a while. Near term I will continue to pursue the xmonad manage hook approach of modifying the window's properties. Such a capability might prove useful in making other applications run comfortably under xmonad while remaining tiled.
/john _______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- "And it happened all the time that the compromise between two perfectly rational alternatives was something that made no sense at all." -- Neal Stephenson, Anathem