darcs patch: add new combo layout combiner.

This module subsumes the TwoTabbed layout, which should not be applied.
David
Mon Jun 11 15:49:22 PDT 2007 David Roundy

On Mon, Jun 11, 2007 at 03:50:16PM -0700, David Roundy wrote:
This module subsumes the TwoTabbed layout, which should not be applied.
David
Mon Jun 11 15:49:22 PDT 2007 David Roundy
* add new combo layout combiner.
For the curious, I'm attaching a screenshot that demonstrates the use of combo with twoPane and tabbed. The manipulations of window order are ugly (for some reason mod-shift-j/k don't work for me, and it's very confusing swapping with "master" window), but the layout is approximately as flexible as that of ion3, although we really ought to pass messages into lower-level layouts, one way or another. Still, it looks pretty nice to me, and it's relatively easy to get things formatted as I'd like. What we need now is a twoPane that provides a handle to drag its divider back and forth. Then we'd be as flexible as the subset of ion3 that I use. And even better would be a serialization of Layout state... of course, then mosaic would be at least competitive with combo+tabbed+twoPane. Oh, and in case you wonder about the source for this configuration: it's visible on the screenshot itself, if you look closely. -- David Roundy Department of Physics Oregon State University

droundy:
On Mon, Jun 11, 2007 at 03:50:16PM -0700, David Roundy wrote:
This module subsumes the TwoTabbed layout, which should not be applied.
David
Mon Jun 11 15:49:22 PDT 2007 David Roundy
* add new combo layout combiner. For the curious, I'm attaching a screenshot that demonstrates the use of combo with twoPane and tabbed. The manipulations of window order are ugly (for some reason mod-shift-j/k don't work for me, and it's very confusing swapping with "master" window), but the layout is approximately as flexible as that of ion3, although we really ought to pass messages into lower-level layouts, one way or another. Still, it looks pretty nice to me, and it's relatively easy to get things formatted as I'd like. What we need now is a twoPane that provides a handle to drag its divider back and forth. Then we'd be as flexible as the subset of ion3 that I use.
And even better would be a serialization of Layout state... of course, then mosaic would be at least competitive with combo+tabbed+twoPane.
Oh, and in case you wonder about the source for this configuration: it's visible on the screenshot itself, if you look closely.
very nice. i've applied that. -- Don

On Mon, Jun 11, 2007 at 03:50:16PM -0700, David Roundy wrote:
Mon Jun 11 15:49:22 PDT 2007 David Roundy
* add new combo layout combiner.
Hi David,
unfortunately this layout is broken due to an api change:
Mon Jun 11 20:26:29 CEST 2007 Spencer Janssen

On Tue, Jun 12, 2007 at 01:47:54PM +0200, Andrea Rossato wrote:
On Mon, Jun 11, 2007 at 03:50:16PM -0700, David Roundy wrote:
Mon Jun 11 15:49:22 PDT 2007 David Roundy
* add new combo layout combiner. Hi David, unfortunately this layout is broken due to an api change: Mon Jun 11 20:26:29 CEST 2007 Spencer Janssen
* API CHANGE: Give doLayout a Stack rather than a flattened list I'll be trying to fix it as soon as I understand what is actually doing...;-)
I've fixed it to compile (soon to be sent in) but it'll be more work to make it actually work again. :( Rather disappointing that as soon as I get a layout with which I can consider actually switching to use xmonad full-time it no longer works. It relied on subtleties of the raising and lowering of windows which apparently no longer work. In particular, the change in doLayout seems to have affected the stacking order of windows, with the result that tabbed sublayouts in combos no longer function properly. In fact, even the focussed window is no longer on top (often not even visible). :( I keep hoping we can actually have stacks of stacks, then this would be much easier. As it is, Combo emulates stacks of stacks by only implementing nested layouts. But nested layouts isn't enough, because each layout really needs to know which window is focussed in that layout--which is to say, a stack. -- David Roundy http://www.darcs.net

droundy:
On Tue, Jun 12, 2007 at 01:47:54PM +0200, Andrea Rossato wrote:
On Mon, Jun 11, 2007 at 03:50:16PM -0700, David Roundy wrote:
Mon Jun 11 15:49:22 PDT 2007 David Roundy
* add new combo layout combiner. Hi David, unfortunately this layout is broken due to an api change: Mon Jun 11 20:26:29 CEST 2007 Spencer Janssen
* API CHANGE: Give doLayout a Stack rather than a flattened list I'll be trying to fix it as soon as I understand what is actually doing...;-)
I've fixed it to compile (soon to be sent in) but it'll be more work to make it actually work again. :( Rather disappointing that as soon as I get a layout with which I can consider actually switching to use xmonad full-time it no longer works. It relied on subtleties of the raising and lowering of windows which apparently no longer work. In particular, the
Right. Undocumented semantics not to be relied upon. We've not fixed the API, though it probably won't change that much.
change in doLayout seems to have affected the stacking order of windows, with the result that tabbed sublayouts in combos no longer function properly. In fact, even the focussed window is no longer on top (often not even visible). :(
I'll be rechecking the stacking code, since the change was to solve a problem in the core anyway.
I keep hoping we can actually have stacks of stacks, then this would be much easier. As it is, Combo emulates stacks of stacks by only implementing nested layouts. But nested layouts isn't enough, because each layout really needs to know which window is focussed in that layout--which is to say, a stack.
-- Don

On Tue, Jun 12, 2007 at 11:46:51PM +1000, Donald Bruce Stewart wrote:
droundy:
I've fixed it to compile (soon to be sent in) but it'll be more work to make it actually work again. :( Rather disappointing that as soon as I get a layout with which I can consider actually switching to use xmonad full-time it no longer works. It relied on subtleties of the raising and lowering of windows which apparently no longer work. In particular, the
Right. Undocumented semantics not to be relied upon. We've not fixed the API, though it probably won't change that much.
Stacking order, unfortunately, is something that seems to be both undocumented and untested... I wonder if there could be a way to introduce the concept into Stack? -- David Roundy http://www.darcs.net

droundy:
On Tue, Jun 12, 2007 at 11:46:51PM +1000, Donald Bruce Stewart wrote:
droundy:
I've fixed it to compile (soon to be sent in) but it'll be more work to make it actually work again. :( Rather disappointing that as soon as I get a layout with which I can consider actually switching to use xmonad full-time it no longer works. It relied on subtleties of the raising and lowering of windows which apparently no longer work. In particular, the
Right. Undocumented semantics not to be relied upon. We've not fixed the API, though it probably won't change that much.
Stacking order, unfortunately, is something that seems to be both undocumented and untested... I wonder if there could be a way to introduce the concept into Stack?
There is, as its supposed to be the integral of the focus , concated with the integral of the tiled layer. That defines the stacking order as defined by the stackset itself. To do this requires separate tiled and stack layers, which are in the works. They're not as concise as I'd like, unfortunately, so I'm delaying the merge. -- Don
participants (3)
-
Andrea Rossato
-
David Roundy
-
dons@cse.unsw.edu.au