ideas for new layouts and layout modifiers
Hi all, I'm partly just writing this to myself, to make note of the neat ideas I've had recently for new layout modifiers, and partly so you'll know what I might be up to soon, and partly in hope that someone else will implement them first, since I'm not sure when I'll have time to work on this. If any of these interest any of you, I'd be glad to explain my idea more fully, and let you take all the credit! :) (Or if you want to vote for what I work on when I've got time, you could do that, too... or suggest better module names.) 1. WindowNavigator A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left). 2. StrutLayout Automatically arrange screens so that windows won't overlap struts. This should involve changes to core, but may not *need* to involve changes to core. 3. Float A float layout (distinct from the current "float" layer) drawing title bars on the windows, so you can drag them around with one hand. Maybe even close boxes. 4. ToggleLayouts Allow for toggling between two layouts. Useful for allowing toggling of full screen mode, as in ion3. I'd much rather have this than include full in a rotating set of layouts. The easiest are (1) and (4), followed by (3). (2) would require learning more x-windows API than I currently do (to identify the struts/status bars). -- David Roundy Department of Physics Oregon State University
David Roundy wrote:
1. WindowNavigator
A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left).
Please display somehow (a *faint* red border?) the trail of windows that you'll go to with left or right. It annoys me in word processors that I can't see where up or down is going to take me to. Modal badness... (Although with xmonad, I don't put more than a few windows on a workspace and usually use full-screen, so it doesn't actually make much of a difference to me) more brainstorming would be appreciated Isaac
On Thu, Sep 27, 2007 at 04:09:38PM -0300, Isaac Dupree wrote:
David Roundy wrote:
1. WindowNavigator
A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left).
Please display somehow (a *faint* red border?) the trail of windows that you'll go to with left or right. It annoys me in word processors that I can't see where up or down is going to take me to. Modal badness... (Although with xmonad, I don't put more than a few windows on a workspace and usually use full-screen, so it doesn't actually make much of a difference to me)
I'm afraid that might be complicated, and my experience with ion3 navigation was that it was pretty intuitive. But what you describe shouldn't be hard, it's just that it'd mean that we'd have to keep track of which windows we outlined so as to be able to turn them back. My gut feeling is that the visual clutter will be more harm than gain, but it would be trivial to set the "navigation color" to black. -- David Roundy Department of Physics Oregon State University
On Thu, Sep 27, 2007 at 04:09:38PM -0300, Isaac Dupree wrote:
David Roundy wrote:
1. WindowNavigator
A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left).
Please display somehow (a *faint* red border?) the trail of windows that you'll go to with left or right. It annoys me in word processors that I can't see where up or down is going to take me to. Modal badness... (Although with xmonad, I don't put more than a few windows on a workspace and usually use full-screen, so it doesn't actually make much of a difference to me)
I've implemented this module, and even wrote the code for your special border (which I made bright blue so I'd be sure to know if it worked), but my border-setting code apparently didn't work as it ought, so I commented it out. Suggestions would be appreciated. I don't like X color stuff, it looks scary. -- David Roundy Department of Physics Oregon State University
On Friday 28 September 2007 12:33:26 David Roundy wrote:
On Thu, Sep 27, 2007 at 04:09:38PM -0300, Isaac Dupree wrote:
David Roundy wrote:
1. WindowNavigator
A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left).
Please display somehow (a *faint* red border?) the trail of windows that you'll go to with left or right. It annoys me in word processors that I can't see where up or down is going to take me to. Modal badness... (Although with xmonad, I don't put more than a few windows on a workspace and usually use full-screen, so it doesn't actually make much of a difference to me)
I've implemented this module, and even wrote the code for your special border (which I made bright blue so I'd be sure to know if it worked), but my border-setting code apparently didn't work as it ought, so I commented it out. Suggestions would be appreciated. I don't like X color stuff, it looks scary.
We set window border colors after executing the layouts, I bet this is the problem.
On Fri, Sep 28, 2007 at 01:53:57PM -0500, Spencer Janssen wrote:
On Friday 28 September 2007 12:33:26 David Roundy wrote:
On Thu, Sep 27, 2007 at 04:09:38PM -0300, Isaac Dupree wrote:
David Roundy wrote:
1. WindowNavigator
A layout modifier that keeps track of the rectangles of visible windows and a "cursor" point, to allow keybindings for "shift focus up/down/left/right" in a real geometric manner. It's independent of the tiling algorithm used. A key point is that moving left followed by right will always return focus to its original position (except sometimes if the layout of the screen changes when you move focus left).
Please display somehow (a *faint* red border?) the trail of windows that you'll go to with left or right. It annoys me in word processors that I can't see where up or down is going to take me to. Modal badness... (Although with xmonad, I don't put more than a few windows on a workspace and usually use full-screen, so it doesn't actually make much of a difference to me)
I've implemented this module, and even wrote the code for your special border (which I made bright blue so I'd be sure to know if it worked), but my border-setting code apparently didn't work as it ought, so I commented it out. Suggestions would be appreciated. I don't like X color stuff, it looks scary.
We set window border colors after executing the layouts, I bet this is the problem.
Sounds like it. Do you see an easy workaround? It seems like we only need to change borders when we change the focus, and in that case we should only need to change the border on two windows (the previously focussed window and the new focus window). Am I correct that making this (border-coloring) more efficient would also make the WindowNavigation coloring code work? -- David Roundy Department of Physics Oregon State University
participants (3)
-
David Roundy -
Isaac Dupree -
Spencer Janssen