Fleet WindowManager
|
A hybrid floating/tiled windowmanagement scheme.
The basic idea of the Fleet Window Manager is that multiple windows can be joined (tiled) together to act as a fleet - this allows one to attach multiple disparate windows into a single fleet to represent a task or project.
| “ | 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
|
Terminology
- Window
- a window as an application sees it. ie, exactly what you'd expect from a traditional non-tabbing window manager
- Fleet
- multiple windows connected with linked edges.
Windows
Normal windows should move/resize/raise/lower/maximise/iconise/windowshade as per normal.
For values of 'normal' that should be familiar to any user of WindowMaker, GNOME, etc.
Fleets
Creating a fleet
A hotkey when moving windows alongside other windows would add them into a fleet. Similarly a hotkey (same one) to remove a window from a fleet. (eg: alt+mouse = move window. If window is part of a fleet, then it moves the fleet. alt+control+leftmouse = move window, and if end position is against another window, they merge to become a fleet. Similarly alt+ctrl+leftmouse = move window out of a fleet)
Managing fleets
Moving
Moving a fleet is simply a matter of moving any window within the fleet. Linked borders ensures that all linked windows in the fleet move together.
Raising / Lowering
All windows in a fleet should raise and lower together.
Resizing
From a solo edge
Resizes the window it is connected to only - as expected
When resizing from an edge, the resize should attempt to alter the proportions of both windows. ie, the fleet boundary does not change, but the relative proportions of each windows will change.
However, when resizing a window via alt+middlemouse (or other non-edge method?), we should resize the window itself, and drag linked borders along as much as possible.
What about corners?
Just like shared edges, but can resize both horiz and vert, as well as attaching up to four windows.
Maximising
When maximising a window that is part of a fleet, it should maximise itself not to fill the available screen space (as per normal maximise), but so that the fleet will fill the available screen space. ie, the window will fill screen space less other-windows-in-the-fleet space. See the somewhat related compiz plugin 'maximumize'
Any windows that are partially off-screen already should remain partially offscreen (though may be slid vertically or horizontally along the screen edge?)
Windowshade / Iconisation
Iconising any window in the fleet should iconise the whole fleet. Similarly restoration. The fleet should iconise to a single icon (or taskbar entry), but I don't think that's required.
Windowshade is a little messy - I think the concept should be the same - windowshade one window and all windows in the fleet also shade, but this leaves a series of visually unconnected (but will still raise/lower/move/iconise together) titlebars. It's very unoptimal, but I think better than not allowing it at all!
Visualisation
Do we need visual indicators that a window is part of a fleet? for eg, a n-pixel wide border around the whole fleet? Uniquely coloured title/borders? A transparent rectangle under the whole fleet to show where 'holes' in the fleet are?
A visual cue that windows are linked would certainly be useful!
Other issues
Overlapping within a fleet?
...say that a window A exists. to it's right is linked window B, which extends lower than A. Below A is linked window C... can it extend to the right of A? (creating an overlap between B and C). I think this should not be allowed - but what happens if window C wants to resize itself into that space?)
Other links
- Enlightenment (e16) has the concept of 'window groups'. This is similar to this idea, though there is no requirement that the windows be touching/sharing an edge, and the default UI for creating a group is very clunky.
- Haiku implements this as "stack and tile" within r1alpha3, based of a 2008(?) university of Auckland research project.
Please see Conjoined WindowManager for a much earlier draft of this idea, which also has links to external sites where this idea or similar has been noted or proposed.
