darcs patch: An alternative mosaic layout implementation
This is a new layout which is very similar to David's Mosaic, but produces different tilings. The algorithm is simpler, but I think it gives more useful results. It divides the space in a more balanced way, in particular trying to avoid very narrow windows. Cheers /J Tue Oct 2 02:17:16 BST 2007 Jamie Webb * An alternative mosaic layout implementation
On Tue, Oct 02, 2007 at 02:45:12AM +0100, Jamie Webb wrote:
This is a new layout which is very similar to David's Mosaic, but produces different tilings. The algorithm is simpler, but I think it gives more useful results. It divides the space in a more balanced way, in particular trying to avoid very narrow windows.
This looks pretty nice, although it is less flexible. The algorithms that Mosaic uses need to be totally rewritten, but I like the ideas behind them (which is to write down a "goodness" function and then minimize it). The trouble is that discrete minimization is hard... but the real reason that Mosaic has languished is that Combo works better for me. Dynamical tiling just has trouble competing with static tiling intelligently laid out. Particularly when the dynamical tiling is constrained to display all windows--very often there *is* no useful way to display all windows. So if I get around to working on Mosaic again, I'll probably work on finding a way of mingling it with something like Tabbed, so that it can ensure that every visible window is usefully visible (e.g. no xterms less than 80 chars wide or two chars tall, and no emacsen less than 80 chars wide or two dozen chars tall). This will also have the benefit of both making the algorithm faster (fewer windows displayed means exponentially fewer possible tilings) and as a result simpler (e.g. we may be able to try exhaustive search of tilings, provided window areas are kept fixed). The trouble is figuring out which window to hide when the user clicks on one of the tabs. Plus, I don't have much time for xmonad hacking. -- David Roundy Department of Physics Oregon State University
On 2007-10-02 07:28:06 David Roundy wrote:
On Tue, Oct 02, 2007 at 02:45:12AM +0100, Jamie Webb wrote:
This is a new layout which is very similar to David's Mosaic, but produces different tilings. The algorithm is simpler, but I think it gives more useful results. It divides the space in a more balanced way, in particular trying to avoid very narrow windows.
This looks pretty nice, although it is less flexible. The algorithms that Mosaic uses need to be totally rewritten, but I like the ideas behind them (which is to write down a "goodness" function and then minimize it). The trouble is that discrete minimization is hard...
Mmm... makes sense, though I wonder if it's not an unnecessarily general problem. I've had a bit more of a play and I think I have a reasonable compromise: I break the windows into an arbitrary area-balanced tree as before, but then I use the minimisation approach to select the screen divisions. The tree constraint means that I can do it exhaustively in quadratic time, which should be easily fast enough for reasonable numbers of windows. The results are presumably not always optimal, but they seem to be pretty good. The main disadvantage is that windows jump about a lot as the layout changes. I've also made the target aspect ratio modifiable for each window. The trouble is that this is fine for xterms and the like, and it seems like it /can/ give good results for other sorts of windows, but too much fiddling with areas/aspects is often required: it would be easier to drag borders about. It needs to select more sensible defaults based on the window type. Maybe it can use the geometry that the application initially asks for? I'm not sure how to do that.
but the real reason that Mosaic has languished is that Combo works better for me. Dynamical tiling just has trouble competing with static tiling intelligently laid out. Particularly when the dynamical tiling is constrained to display all windows--very often there *is* no useful way to display all windows.
Yes, I was pretty happy with Ion for something like five years until I found Xmonad a few days ago, and I still think Ion's model probably works better overall, at least for now. A WM that's so easy to hack on was just too tempting though... I think MosaicAlt works very well for a suitable number of xterms, and passably for some other cases. Aside from that I'm mostly using a fullscreen Tabbed at the moment. I'm also using a Combo of ResizableTile and Tabbed sometimes, but I'm not entirely happy with it: as you say, there's difficulty in getting the right set of windows visible. Perhaps you have a better setup than mine? Do you mind posting your layout config? At the moment, my feeling is that it would be better if the user were able to move windows manually between Combo sub-layouts, rather than just assigning a fixed number to each one.
So if I get around to working on Mosaic again, I'll probably work on finding a way of mingling it with something like Tabbed, so that it can ensure that every visible window is usefully visible (e.g. no xterms less than 80 chars wide or two chars tall, and no emacsen less than 80 chars wide or two dozen chars tall). This will also have the benefit of both making the algorithm faster (fewer windows displayed means exponentially fewer possible tilings) and as a result simpler (e.g. we may be able to try exhaustive search of tilings, provided window areas are kept fixed). The trouble is figuring out which window to hide when the user clicks on one of the tabs. Plus, I don't have much time for xmonad hacking.
That sounds nice, but I imagine that it might be an impossible task to usefully guess which windows the user is looking at. Let me know if you have any ideas, and I may have a go. Cheers /J
On Wed, Oct 03, 2007 at 05:40:28PM +0100, Jamie Webb wrote:
On 2007-10-02 07:28:06 David Roundy wrote:
On Tue, Oct 02, 2007 at 02:45:12AM +0100, Jamie Webb wrote:
This is a new layout which is very similar to David's Mosaic, but produces different tilings. The algorithm is simpler, but I think it gives more useful results. It divides the space in a more balanced way, in particular trying to avoid very narrow windows.
This looks pretty nice, although it is less flexible. The algorithms that Mosaic uses need to be totally rewritten, but I like the ideas behind them (which is to write down a "goodness" function and then minimize it). The trouble is that discrete minimization is hard...
Mmm... makes sense, though I wonder if it's not an unnecessarily general problem. I've had a bit more of a play and I think I have a reasonable compromise: I break the windows into an arbitrary area-balanced tree as before, but then I use the minimisation approach to select the screen divisions. The tree constraint means that I can do it exhaustively in quadratic time, which should be easily fast enough for reasonable numbers of windows.
The results are presumably not always optimal, but they seem to be pretty good. The main disadvantage is that windows jump about a lot as the layout changes.
Sounds like a neat approach. Jumping windows is an almost-unavoidable side-effect of the mosaic-style layout. It's lessened if you always put larger windows to the left/top when possible (if the user defines a continuum of window areas).
I've also made the target aspect ratio modifiable for each window.
Yay!
The trouble is that this is fine for xterms and the like, and it seems like it /can/ give good results for other sorts of windows, but too much fiddling with areas/aspects is often required: it would be easier to drag borders about. It needs to select more sensible defaults based on the window type. Maybe it can use the geometry that the application initially asks for? I'm not sure how to do that.
Yeah, using window hints was definitely in my plans for mosaic. I know there are places where you can find examples of window hints code, and that's what I'd do for some of these properties. Also I'd like a property (per window) of "min/max width" "min/max height" etc, which would mesh well with hints. I think you could adjust this (in principle) by key combinations + dragging borders, but probably you'd mostly want it set by manageHook, so all xterms start out with appropriate minimum dimensions.
but the real reason that Mosaic has languished is that Combo works better for me. Dynamical tiling just has trouble competing with static tiling intelligently laid out. Particularly when the dynamical tiling is constrained to display all windows--very often there *is* no useful way to display all windows.
Yes, I was pretty happy with Ion for something like five years until I found Xmonad a few days ago, and I still think Ion's model probably works better overall, at least for now. A WM that's so easy to hack on was just too tempting though...
I think MosaicAlt works very well for a suitable number of xterms, and passably for some other cases. Aside from that I'm mostly using a fullscreen Tabbed at the moment.
I'm also using a Combo of ResizableTile and Tabbed sometimes, but I'm not entirely happy with it: as you say, there's difficulty in getting the right set of windows visible. Perhaps you have a better setup than mine? Do you mind posting your layout config?
I just have two layouts at the moment, fullscreen tabbed and ,Layout $ combo (combo (Mirror $ TwoPane 0.03 0.8) [(Layout $ TwoPane 0.03 0.8,1) ,(Layout Square,1)]) [(mytab,8),(mytab,30),(mytab,1)] The square is because I prefer to keep an xclock visible at all times. Basically, this gives me a big window (I've got a 1024x768 laptop screen) for editing and a little one for a shell (for compiling, usually), and tabs all round so I can view lots of windows. I'd use a different setup with a bigger screen, where I could put two useful windows (other than an xclock) side-by-side.
At the moment, my feeling is that it would be better if the user were able to move windows manually between Combo sub-layouts, rather than just assigning a fixed number to each one.
Yeah, Combo could be extended in this direction, which would be good. Basically we could keep the current data structure, but add messages that would have the effect of changing the number of windows shown in each sublayout. One trickiness would be figuring out how to handle nested combos (i.e. to send the messages to the "right" layout). And we'd want to have Combo probably synchronize changing the number in each sublayout with a reordering of windows. This might be done something like the new Swap message in WindowNavigation. But ultimately, I think we'll be heading towards insanity if we're forced to emulate all nested-stack transformations in Combo. Proper handling of the float layer requires nested stacks (in my opinion), and I'm hoping that by adding this support we can sneak nested stacks into the core.
So if I get around to working on Mosaic again, I'll probably work on finding a way of mingling it with something like Tabbed, so that it can ensure that every visible window is usefully visible (e.g. no xterms less than 80 chars wide or two chars tall, and no emacsen less than 80 chars wide or two dozen chars tall). This will also have the benefit of both making the algorithm faster (fewer windows displayed means exponentially fewer possible tilings) and as a result simpler (e.g. we may be able to try exhaustive search of tilings, provided window areas are kept fixed). The trouble is figuring out which window to hide when the user clicks on one of the tabs. Plus, I don't have much time for xmonad hacking.
That sounds nice, but I imagine that it might be an impossible task to usefully guess which windows the user is looking at. Let me know if you have any ideas, and I may have a go.
Right, you can't figure out what windows they're looking at, but you could display, for example, the N windows that most recently had focus. And you could add a message that will ensure that the currently focussed window always remains visible (for something like an xclock that you want to see, but don't want to focus, or a kpdf set on autorefresh displaying the paper you're working on). -- David Roundy Department of Physics Oregon State University
On Monday 01 October 2007 20:45:12 Jamie Webb wrote:
This is a new layout which is very similar to David's Mosaic, but produces different tilings. The algorithm is simpler, but I think it gives more useful results. It divides the space in a more balanced way, in particular trying to avoid very narrow windows.
Cheers
/J
Tue Oct 2 02:17:16 BST 2007 Jamie Webb * An alternative mosaic layout implementation
Applied.
participants (3)
-
David Roundy -
Jamie Webb -
Spencer Janssen