Conjoined WindowManager

Revision as of 11:10, 16 April 2008

A hybrid floating/tiled windowmanagement scheme.

The basic idea of Conjoined Window Manager is that multiple windows can be joined (tiled) together to act as one larger window in certain contexts.

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 or other tiling window managers.

My Terminology

• Window - an application window. ie, 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 since the advent of tabbing windowmanagers (pwm, ion, pekwm, etc) allows multiple windows within a single frame.
• Fleet - multiple frames conjoined together (sharing an edge or corner) in a tiling (or even overlapping?) manner.

Illustrations

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... ;)

A bit more technical

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...

Focus

Focus is always hanled at the window level (only one window can have focus), but the visual indication of focus is handled at the frame level. This should not change.

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)

Other Links

related notes:

• http://ml.42.org/wmx/msg00314.html

unrelated notes:

• http://ml.42.org/wmx/msg00590.html

See also:

• allSnap - This appears to be a windows app which implements this. (untested by me)
• allSnap homepage

• Compiz's 'groups and tabs' setting implements groups more or less as described here.

(It does not handle shared edges as described here however)

Final Thoughts

An implementation? Ever used winamp or xmms - the way the playlist and equalizerwindows will "dock" with the main window. This is an expansion on that basic idea.