Conjoined WindowManager

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.

“	This is Nemo's brilliant idea for a Window Manager. 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?	”
—Screwtape

Or to summarise... I guess you could just say I propose arbitrary free-form (additive) tiling rather than strict divisive tiling as imposed by traditional "tiling" window managers

nemo

everything from here is arguably much too over-thought out, and should be considered as nothing more than brainstorming additions to the core idea.

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 frame 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 frame in a fleet are shared with the edges of other frames in the same fleet, then it's just a matter of keeping those shared point synchronised via multiple frame resizing or movement, as need be.

Topology

In fact, each fleet has a topology of internal connections. "this edge is shared with that edge", "this corner is attached to that edge", etc. All internal edge movements should maintain this topology. (so if you want to slide the corner-attached-to-edge along the edge, then just drag the corner. However, if you want to slide the corner down to attach it to the corner (and then maybe along to another edge?), you would have to activate the 'modify fleet topology' WM function. (presumably just a simple hotkey to hold when dragging)

How simple?

Note that this simple (?!) handling does not preclude frames within the fleet overlapping other frames within the same fleet. I think this is *correct* handling. Afterall, PWM could be partially emulated by this system by having multiple frames 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 frames in a fleet.

Now, most windowmanagement functions are designed to work with a single window/frame - not multiple windows - so let's look at some window/frame 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 - I think this is the genesis of the idea - august 1999!

• http://ml.42.org/wmx/1999/msg00304.html

unrelated notes:

• http://ml.42.org/wmx/2001/msg00056.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)

• [1] An ubuntu brainstorm where the idea was proposed. Written clearer than here I must say!

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.