darcs patch: switch to nested stacks
Hi all,
Here's a patch that switches to nested stacks in xmonad core. I haven't
converted the test suite, because I've got quickcheck 2 installed, and
therefore can't compile the test suite, and I don't intend to uninstall
QC2. If this code works as intended (I haven't tried running it either),
then it shouldn't change xmonad behavior. I haven't adjusted the
LayoutClass to handle nested layouts, so there is considerable work to be
done (and not by me, I really should be focussing on darcs, but compiling
takes a while, particularly when I have to do actual work on my laptop due
to a sketchy internet connection).
But I think my ideas are down there. It's a reasonably simple data
structure. And it ought to be a clean solution for handling the float
layer, besides allowing nested layouts to be implemented cleanly. I
haven't implemented full navigation within nested layouts, but that's not
hard to implement, and can also be implemented in contrib (or later), if
this is accepted.
The other reason I've put so little work on this, is that it's not at all
clear whether the core xmonad developers would accept a patch implementing
this feature, regardless of how well-tested, well-documented, etc it is.
So that's what we really need to hear (we being those of us who want this
feature, especially those who would be willing to take over its
development).
David
Sun Dec 23 09:03:40 EST 2007 David Roundy
droundy:
Hi all,
Here's a patch that switches to nested stacks in xmonad core. I haven't converted the test suite, because I've got quickcheck 2 installed, and therefore can't compile the test suite, and I don't intend to uninstall QC2. If this code works as intended (I haven't tried running it either), then it shouldn't change xmonad behavior. I haven't adjusted the LayoutClass to handle nested layouts, so there is considerable work to be done (and not by me, I really should be focussing on darcs, but compiling takes a while, particularly when I have to do actual work on my laptop due to a sketchy internet connection).
But I think my ideas are down there. It's a reasonably simple data structure. And it ought to be a clean solution for handling the float layer, besides allowing nested layouts to be implemented cleanly. I haven't implemented full navigation within nested layouts, but that's not hard to implement, and can also be implemented in contrib (or later), if this is accepted.
The other reason I've put so little work on this, is that it's not at all clear whether the core xmonad developers would accept a patch implementing this feature, regardless of how well-tested, well-documented, etc it is. So that's what we really need to hear (we being those of us who want this feature, especially those who would be willing to take over its development).
Thanks David. We can't look a this for 0.6 (coming out after new year's). However, I'm heading off on vacation for two weeks, and will play with this. We've a long open ticket for fixing the floating layer, so this looks like a good start. Thanks! -- Don
On Sun, Dec 23, 2007 at 01:37:10PM -0800, Don Stewart wrote:
droundy:
Hi all,
Here's a patch that switches to nested stacks in xmonad core. I haven't converted the test suite, because I've got quickcheck 2 installed, and therefore can't compile the test suite, and I don't intend to uninstall QC2. If this code works as intended (I haven't tried running it either), then it shouldn't change xmonad behavior. I haven't adjusted the LayoutClass to handle nested layouts, so there is considerable work to be done (and not by me, I really should be focussing on darcs, but compiling takes a while, particularly when I have to do actual work on my laptop due to a sketchy internet connection).
But I think my ideas are down there. It's a reasonably simple data structure. And it ought to be a clean solution for handling the float layer, besides allowing nested layouts to be implemented cleanly. I haven't implemented full navigation within nested layouts, but that's not hard to implement, and can also be implemented in contrib (or later), if this is accepted.
The other reason I've put so little work on this, is that it's not at all clear whether the core xmonad developers would accept a patch implementing this feature, regardless of how well-tested, well-documented, etc it is. So that's what we really need to hear (we being those of us who want this feature, especially those who would be willing to take over its development).
Thanks David. We can't look a this for 0.6 (coming out after new year's).
However, I'm heading off on vacation for two weeks, and will play with this. We've a long open ticket for fixing the floating layer, so this looks like a good start.
Alas, I've since realized that it's not obvious how this'd work out for the floating layer. As long as both layers are populated, it's simple: you've got two nested nests, and by convention the first one is tiled, the second floating. The trouble comes when one of them is unpopulated: there's no way to distinguish whether it's the floating or tiled layer that's empty, since by construction each Nest is non-empty. One option would be to allow empty Nests, which would make them much more different from Stacks than the implementation I sent in. I suspect that's the "correct" implementation. Then instead of a Maybe (Nest a) a Workspace would just hold a (Nest a). And nest2stack would have type Nest a -> Maybe (Stack a). -- David Roundy Department of Physics Oregon State University
participants (2)
-
David Roundy -
Don Stewart