Conjoined WindowManager
This is Nemo's brilliant idea for a WindowManager. Basically, he wants to be able to dock any window up against any other window, and have the group behave like a single window (for some functions, whilst other functions would still behave on the window individually). You should (in theory) be able to join (glomm?) more windows onto the group, repeating until you have a vast fleet of oddly-shaped windows floating around your desktop in unison, looking (like a VogonConstructorFleet) more like it was congealed than designed.
Oops. Did I say that last bit out loud?
Terminology used in this page
- Window - an application, or traditional idea of a window within a windowmanager
- Frame - a single box of windowdecoration. In a traditional windowmanager, "window" and "frame" are essentially interchangeable terms. I make the distinction since pwm allows multiple windows within a frame (with tabs along the top).
- Fleet - multiple frames conjoined together (sharing and edge or corner) in a tiling or even overlapping manner.
Note that "focus" is handled at the window level, but the visual indication of focus is handled at the frame level. This should not change.
Crappy ascii art time:
+---+ | | Window A | A | +---+ | | Window B | B | +---+ +---+
move window B to the left and have B's left edge be shared with A's right edge...
+---+ | | | A +---+ | | B | +---+---+
Any "move this window" action applied to either window would move the shared edge, and hence move any attached window - ie, the whole fleet would move. Resizing a shared edge would resize both windows independantly (and not alter the size of the fleet unless nescessary (say, due to window minimum size limits)). Note that B's left edge is entirely shared, but only half of A's right-edge is shared - if you resized A's window from the top half of it's right edge, that should *move* window B, not resize it... at least, that's kind of how I imagine it. ;)
You'd probably want to allow corner sharing as well as edge, so things like the bottom edge (as seen in the example above) could be moved together... maybe share that complete bottom edge newly with window C...
+---+ | | | A +---+ | | B | +--++---+-+ | | | C | +------+
...and so on. If each window was pwm-style - and could have it's own tabs... and you organised the layout to fit nicely into your display... then you end up with a tiled windowmanager... sounds familiar doesn't it... ;)
I guess you could just say I propose arbitrary free-form tiling rather than a "tiled area must equal size and shape of display" as imposed by ION.
So, let's get a bit more technical and detailed...
For each window we need to keep track of the 8 points that can be shared - 4 edges and 4 corners. If we keep track of which edges on each window in a fleet are shared with the edges of other windows in the same fleet, then it's just a matter of keeping those shared point synchronised via multiple window resizing or movement, as need be.
Note that this simple (?!) handling does not preclude windows within the fleet overlapping other windows within the same fleet. I think this is *correct* handling. Afterall, PWM could be partially emulated by this system by having multiple windows which share all four corners (ie, they're stacked perfectly on each other, and any resize/movement will affect all windows in the fleet). Note that just as most windowmanagers provide a hotkey to move between windows, and pwm provides another hotkey to move between tabs on a frame, this system should provide a *third* hotkey to cycle between windows in a fleet.
Now, most windowmanagement functions are designed to work with a single window - not multiple windows - so let's look at some window functions specifically in the context of a fleet...
- Moving frames
- Attempting to move any part of a fleet (ie, a frame within the fleet) would move the whole fleet. Some method needs to be given to allow a frame to attach/detach from a fleet, and for a shared-edge joining, to "slide" along the share.
- Resizing frames
- The edge/corner being resized should act normally - which is to say, if it is shared, it should resize all the windows relevant so as to maintain the same basic layout of the fleet (even though the proportions will change). Note that there is an exception to this - if you resize a shared edge, you're basically increasing the size of one window at the cost of another - if the window being reduced has a minimum size, then it should start to be moved accordingly once that size limit is reached.
- Iconising
- The whole fleet should iconise into a single fleet-icon. Perhaps the icon should be based around the icon of the focused window when iconising, but with an indication that it is part of a fleet. I envisage fleets as part of a pwm-like windowmanager, whcih does not do iconisation anyways, preferring windowshade
- Windowshading
- Each frame in the fleet may still windowshade independantly. This means that a "hole" in the fleet may exist, but the edges/corners of a shaded frame, while invisible, are still in place. (note that pwm appears to treat shaded windows this way - try a keyboard-hotkey resize of a shaded window in pwm sometime...)
- Maximising
- The windowmanager should try to keep the fleet from overstepping the visual display - so when a frame is told to maximise, it should not maximise to the size of the display, but only as much as possible without pushing other windows off the viewable area. (note that this is a case where window edges are resized, but adjoining windows are moved, rather than similarly resized)
related notes:
unrelated notes:
An implementation? Ever used winamp or xmms - the way the playlist and equalizerwindows will "dock" with the main window. That's more or less it exactly!
