What's the point? To improve on the classic desktop metaphor instead of watering it down and malimproving it beyond repair.
Balance copyleft and permissive licensing in a reasonable
way.
Use a reasonable free-software license with a share-alike clause (“copyleft”).
Offer a virtually unlimited number of workspaces.
Let the user arrange them on an adequately sized grid.
Especially allow for “cross” and “cross with empty center” (North–East–South–West (NESW)) arrangements, which Xorg doesn't.
Make four workspaces, arranged in NESW order, the default.
Allow for different configuration setups per workspace to a reasonable extent (desktop background, possibly panel configuration, possibly styling).
The window manager shall offer ways to select, arrange, and group windows easily and make all of these work together dynamically. The improvement to be had here really is in unleashing the versatility entailed in these things working together, and in providing a low-overhead interface for it.
There should be a way to save window arrangements and groupings.
This whole problem space requires careful decomposition so that those features can be implemented with a minimal amount of ideally non-overlapping concepts and context layers.
The user shall be able to select windows one of two ways: explicitly or implicitly. Explicit selection shall mean adding each window to a selection individually. The opposite, i.e., implicit selection shall be done by drawing a frame or using another pre-defined method. Useful methods to have would include selecting all windows or all windows currently visible on the current workspace. These methods should be easily accessible.
“Explicit” and “implicit” might not be the best terms, though. It's more of a one-by-one versus several-at-once scheme.
Practically, form a user's point of view, “selecting” a window is two things: Putting focus on it and bringing it to the top of the stack (i.e., layering, i.e., arranging). (Side note: The stack also exists in purely tiled layouts, necessarily.)
Arranging windows includes three actions: positioning, sizing, and layering. The latter is essentially positioning on the z-axis, but it is better treated as a separate concept because there's no scale on the z-axis in the desktop model.
Stacking shall be the default. If possible, new windows shall be put onto unoccupied screen space. If there is not enough unoccupied screen space left, the least intrusive place to draw the window shall be guessed based on a set of well-defined criteria. For example, an unselected window twice the size of the new window could be seen as a reasonable thing to partly cover up.
It should also be possible to have new windows confine themselves to the most adequate available space (i.e., be tiled) in stacking mode on opening.
Maybe, try to make windows appear in the same place they occupied when they were closed.
Tabbing shall be defined as stacking windows on top of each other, only showing the selected (top-most) window, and keeping each window on the stack accessible via a tab bar shown somewhere on the selected window's frame.
Tabbing usually implies all windows on the stack being of the same size. While this is a reasonable configuration, it is not a strict necessity in this context. What is necessary for tabbing to make sense is merely that windows be aligned along at least two orthogonal edges (e.g., left and upper), depending on where the tab bar resides.
If the tab bar in the current window runs out of space, room shall be made by increasing that window's dimensions along the edge the tab bar resides on. Or, better yet, just make the tab bar scrollable.
Having a vertical tab bar with horizontal entry text is probably the best solution because it uses the least amount of space. A horizontal bar with vertical text would also achieve this, but would obscure readability.
Tabbing implies grouping.
Tiling shall be defined as:
The space available for tiling is ultimately defined by the size of the full usable screen space but may be confined by other windows on the same workspace that are not part of the tiling arrangement. It should also be configurable ad-hoc somehow.
Snapping shall be defined as arranging windows edge-to-edge (i.e., without overlapping, i.e., unlike stacking and tabbing) while keeping their original dimensions (i.e., unlike tiling).
Provide grow-to-edge functionality, including the ability to do it left and right, top and bottom, or in all four directions, at the same time.
Provide center-window action.
Grouping shall be defined as interlocking a set of windows so that they form a single unit from the user's perspective.
TODO: Single unit in what respect?
The user shall be able to select any set of windows within a single workspace, define them as a group, and then perform actions on that group, e.g., hiding the whole group or tiling (or tabbing) its member windows (and undo that again).
Tabbing is a special form of grouping.
Grouping windows and dissolving window groups shall be virtually zero-overhead operations because they're going to be performed very often.
Maybe even more importantly, the user should be able to enter a group's scope, rearrange windows within that group, and then exit its scope, without much hassle.
When the objects selected to form a new group include a set of tabbed windows, these shall, by default, form a sub-group. But an easy way to dissolve the tabbed group into independent windows (or a sub-group) of the newly created group shall be provided. Further, the default may be changed to “dissolve by default” (if that makes any sense).
While, except for tabbing, arranging windows shall not automatically create a window group for the user, it might be necessary to treat arrangements as groups implementation-wise. So, arrangements should probably be handled as “soft” or “loose” groups.
When the user is actively working inside a window, neither open other windows on top of said window nor select newly opened windows. E.g., when the user waits for the Web browser to start up while typing in a text editor, open the browser window beneath the text editor window and keep the current window selected. (This might be a sane default, but it should be configurable nonetheless.)
Window focus is not really a useful term. It conflates two things: layering and selection. Well, from a user's point of view, that makes sense.
Window management operations shall be easily “undoable”.
See also:
Provide sane scrollbars:
All text areas (i.e., multi-line input fields) within a window are zoomable independently of the window’s size. This also goes for other input areas, i.e., the canvas in a painting program. (Single-line input fields are zoomable as part of the GUI dialog itself.)
See Plan 9 for some more ideas.
Two panels
Use two distinct kinds of panels, but don't strictly enforce their positioning. Any panel may be placed at any of the four screen edges.
Provide hiding them via keyboard shortcuts or buttons, and auto-hide.
Default location: bottom.
The monitoring panel is “passive”.
Default location: top.
...
By default, the mouse pointer should be a hand.
More specifically, it should be a hand with an extended index finger (and thumb), rotated to the left by something between, say, 20 and 45 degrees.
When you select stuff to pull it around, it should become a fist.
But then, how do you know exactly when to start making that fist? After the first tiniest dragging movement? Well, if you click on any "non-interactive" area of a window? But that would also make it a fist when you just click on the window to bring it to the foreground…
The mouse pointer shall disappear when the mouse is not moved for a certain amount of time, or when the user types stuff, and possibly in other cases.
The mouse pointer should be easily customizable. Provide a convenient way to adjust color. Provide some ready-made alternatives to the default pointer (e.g., the standard arrow) and a small utility to create custom pointers.
Provide a quick and easy way to switch style schemes/profiles completely.
Provide a way to automate theme selection and/or switching, based on the time of day.
Terminal emulator should offer easy color configuration, like, e.g., Konsole does.
Some things should always appear in the same place. But despite that, the user should not be required to be in that place to make them appear or use them. E.g., an application menu, quick launch bar, run dialog, etc. should be immediately accessible through key bindings (or even mouse bindings), i.e., without having to move the mouse pointer onto them to use them.
In fact, activating/selecting, e.g., the application menu or the quick launch bar should move the mouse pointer into their area automatically. This makes sense because the mouse is often a better tool to select things than the keyboard.
A run dialog might be built right into the action panel, but only visible after being activated (launched). Configuration options other than "Run in the terminal" could be placed within the action panel's configuration dialog.
Note on Openbox' menu: It would be pretty cool if you could mark up certain sections of this menu semantically, e.g., as a "quick start list". And that quick start menu section could then have the capability of automatically numbering its entries and making the respective entry number the shortcut for the program referenced in that entry. This should switch off the normal shortcut policy, though, to avoid collisions with things called “1coolprogramivewritten”, “2hottobewritteninc” and such.
Last changed: 2024-05-04
Copyright © 2021, 2022, 2024 Michael Siegel
This work is made available under the terms of the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0).