Another problem with the desktop metaphor: In every window manager I’ve ever used, if you move a window out of the way, there’s a tendency to move part of it off the screen. This is fine sometimes, but if you are moving it out of the way so you can still look at it, while also looking at another window (and wouldn’t you just minimize it otherwise?), this has all the same problems as overlapping windows.

For instance, if you take a window in any normal window manager:

.--------Desktop----------.
|                         |
| .==============.        |
| |             ^|        |
| |             ||        |
| |             ||        |
| |             v|        |
| '--------------'        |
|                         |
'-------------------------'

and drag it off the screen, a lot is now hidden from view, including the scroll bars:

.--------Desktop----------.
|                         |
|                         |
|                         |
|                         |
|                .========|:::::.
|                |        |    ^:
|                |        |    ::
|                |        |    ::
'-------------------------'    v:
                 '..............'

Everything off-screen is now unreadable, and you can’t even scroll to access it.

It would be great if, when you move a window off the screen, the window would “smoosh” up against the edges of the screen, dynamically shrinking or increasing in size as you move towards or away from the edge, to keep everything visible.

In this case the bottom and right borders stop at the edge of the screen and the window resizes dynamically:

.--------Desktop----------.
|                         |
|                         |
|                         |
|                         |
|                .=======.|
|                |      ^||
|                |      v||
|                '-------'|
'-------------------------'

Then all the content in the moved window is still accessible by text wrapping and/or scrolling.

Normally, when you maximize a window to fill the whole screen, it “remembers” the previous size and position, allowing you to restore it to its original size.

Similarly, when a window is “smooshed” like this against the edges of the screen, it will remember how big the window originally was. When you drag the window back towards the center of the screen with the title bar, it will “re-inflate” to its original size.

.--------Desktop----------.
|                         |
|      .==============.   |
|      |             ^|   |
|      |             ||   |
|      |             ||   |
|      |             v|   |
|      '--------------'   |
|                         |
'-------------------------'

But this means that when the window is smooshed, the borders at the edges of the screen aren’t the same as normal borders. They should then be shown in a different style from normal borders, to differentiate them and remind the user that the window still remembers its previous state. If you resize the window inwards using these borders, it will forget the previous state and remain at the current size forever. The borders of the window will then revert to normal functionality. You could also force the window to forget its previous size just by clicking them, perhaps.

I’d say that all windows should do this by default — when would you ever want part of the window to be non-visible? — but there might be important reasons not to for some types of windows, like a program that really loads down the processor during window resize, or a window that can’t be shrunk below a certain size. Maybe the window manager could just add scroll bars in situations like this, when the window has been squished to its smallest size, which would still enable you to scroll around the window (including menu bars or whatever), though without the benefits of word wrapping, etc.

• KDE Bug 133932 – Should be able to move windows without any part of them going off the screen (dynamically resizing as you move)

When windows are tiled, each window continues to have the usual resizable borders; if you shrink one, the other stays untouched. But if edges and corners of windows can be snapped to each other, why can’t two such snapped edges be moved at once? The border that is shared between two windows should behave more like the “split” view you get in applications that let you view two parts of a single document at once.

Say you select two windows and you move them so they tile the screen horizontally; one is on the left half of the screen and one is on the right half:

.--------------.--------------.
|              |              |
|              |              |
|              |              |
|              |              |
|              |              |
'--------------'--------------'

Normally, the border in the middle, where the two windows meet (and have snapped to each other), consists of two independent resize handles that happen to be touching each other. If you want to make one window smaller and the other larger, it takes two operations. What should happen is that the borders should “fuse”, forming a split handle between them.

The individual window resize borders would still be present, with differentiation by the cursor changing when you hover over each, as is normally done to find the resize handles. So as you move the cursor from left to right, it starts as a regular arrow, changes to a resize cursor for the left window, then a split cursor for both windows, then a resize cursor for the right window, and then back to a regular arrow inside the right window.

Closeup of joint border between two windows (a few pixels wide):

Inside | Resize     | Resize  | Resize    | Inside
left   | right-hand | both    | left-hand | right
window | border of  | windows | border of | window
       | L window   | at once | R window  |

If you move the split line to the left, the left window shrinks while the right window grows, so they are always using up the entire screen.

.---------.-------------------.
|         |                   |
|         |                   |
|         |                   |
|         |                   |
|         |                   |
'---------'-------------------'

This could also work for corners, letting you drag both windows’ corners at once:

        --+--
          |
---------._,--------
         | |
         | |
         | |

In fact, such a split line could form any time two windows have adjacent (snapped) edges, even if they’re not filling up the entire screen. This:

          .-------------------.
.---------.                   |
|         |                   |
|         |                   |
|         |                   |
|         '-------------------'
'---------'

could be changed to this:

               .--------------.
.--------------.              |
|              |              |
|              |              |
|              |              |
|              '--------------'
'--------------'

with one click and drag.

• KDE Bug 133927 – Tileable windows with split bar between them
• KDE Bug 120595 – Enable grouping of windows by welding the edges together

If you double-click on a window resizer handle (either on the sides or the corners), it should do something helpful like “maximizing” in only one direction; expanding the edge or corner all the way to the edge of the screen, in the same way that double-clicking the title bar maximizes all four borders to the edge of the screen. (Maybe it or a similar function could also be used to maximize to the nearest window border without overlapping?) KDE has some intermediate options:

• Left-click the Maximize button
  • The window maximizes to the entire screen
• Middle-click the Maximize button
  • The window maximizes in the vertical direction, but stays the same width
• Right-click the Maximize button
  • The window maximizes in the horizontal direction, but stays the same width

Although this functionality is useful, I think this is pretty unintuitive. Which button does which? Do people use this often enough that it should use up the default functions of all three mouse buttons?

Also, why not have windows snap to a coarse grid instead of just to the screen edges and each other? Is there any reason that windows have to be resizable down to the single pixel? This is very rarely necessary.

I’ve been using allSnap in Windows, which allows snapping to other window borders and coarse things like grids and half-way marks. It makes resizing and moving windows much quicker. You can always press Alt or Shift while dragging to override the snapping for the few instances you need it, just like you currently do in GNOME.

• KDE Bug 20969 – Window resizing by clicks on window borders