Ctrl-drag window tiling

[felix-andreas]

Fixes: #591

I think it would be a useful addition if CtrlDrag could be used to tile windows. I did a implementation which is based on #579.

Behavior:
The screen gets divided into 9 different areas which all correspond to a different tile-action (see second picture). Dragging a window with Ctrl pressed to one of these areas will activate the tile preview (blue rectangle). Releasing the Left-Mouse-Button will tile the window corresponding to area where the mouse pointer is currently in.

Use-cases:

• This PR will enable quarter and vertical-half tiling (which is super useful on vertical monitors).
• The ctrl-tile-left/right action is also useful for horizontal multi-monitor setups where the edge-tiling can get a bit inconvenient.

A problem is that Mutter does not expose an API for tiling, so the windows are not "really" tiled (compared to the edge tiling).

Ctrl is pressed while dragging the window

[Serkan80]

It would also be cool if:

1. you could easily navigate with your keyboard between the tiled apps
2. when you tile an app, a second suggestion should appear to let you choose another app to tile your app against.
   In W10, when you tile an app to the left, then automatically on the right side of the screen a suggestion appears with miniature apps to choose from (when you press esc then the suggestion disappears). This is especially handy for only half tiling. For quarter and other tilings this suggestion should not appear.

[felix-andreas]

@Serkan80 this PR only targets mouse tiling. Maybe you should open separate issues for keyboard navigation and tile suggestions.

[cassidyjames]

So I think the main issue is that this is not "real" tiling, i.e. the window manager and thus stylesheet has no way of knowing a window is considered tiled in this way. If we're fine with that (which it seems we'll have to be until there are some big tiling improvements to Mutter), then I would be open to pursuing tiling that uses the existing Super+Drag mouse shortcut as well as some keyboard shortcuts.

Some things to keep in mind with this sort of tiling:

• What happens when a window is moved across to another display of a different size (or the resolution is changed)? Is it tiled relative to the new display, or does it retain its pixel-size? I believe the former is what Mutter attempts to do.
• How does this interact with Mutter's actual side-by-side tiling? Especially since Mutter has a concept of resizable tiling; I think you'd want this tiling to be aware of that and thus not always be split 50/50.
• Is this written in a way that will be maintainable, support both mouse and keyboard (and probably window-menu) tiling?

[felix-andreas]

@cassidyjames

What happens when a window is moved across to another display of a different size (or the resolution is changed)? Is it tiled relative to the new display, or does it retain its pixel-size? I believe the former is what Mutter attempts to do.

Yes, windows which are tiled via edge tiling will be tiled relative to the new display when moved via SuperShiftRight:

Windows which are (fake-)tiled via the new Ctrl-Drag feature will retain their pixel size when moved via SuperShiftRight. But this is also an issue for normal untiled windows (see same video below):

How does this interact with Mutter's actual side-by-side tiling? Especially since Mutter has a concept of resizable tiling; I think you'd want this tiling to be aware of that and thus not always be split 50/50.

This is currently not possible. Mutter does not expose an API for tiling, it only exposes the tiled match. The windows will always be tiled with 50%. I could implement, that the maximizing action would use the mutter API, so that a least maximized windows are "really" maximized.

Is this written in a way that will be maintainable?

I think so. This branch is based on @donadigo's work of #579 . He implemented a WindowMovementTracker class which makes it possible to hook into the window movement. I just implemented the tiling logic into this class. As soon as mutter exposes an API for tiling it should be pretty straight forward to replace the my custom implemented tiling logic (it is only 21 lines of code).

In the future the WindowMovementTracker could also be used for other fancy features like drag-down for workspace-overview (#579) or Alt-drag to move windows between different workspaces ...

Is this written in a way that will be support both mouse and keyboard (and probably window-menu) tiling?

I do not think that WindowMovementTracker class should implement the keyboard/window-menu tiling. At some point the tiling logic should be implemented in mutter. And then this class should be just a user of the tiling API.

Besides the technical issues what do you think about the Ctrl tiling from a UX point of view?

I definitely like this approach because it does not break the existing left/right-edge-tile workflow for users, which do not want to use quarter/vertical-half-tiling. For example, at my university my supervisor has a gnome extension, which enables vertical-half-tiling by dragging the window to top/bottom of the screen. And it always annoys me when I accidentally vertical-half-tile windows at his computer.

[ToxicDragon]

Would be nice if this code were to code merged for the new release :)

[fabiozaramella]

@danrabbit Is it time for a user survey? This PR seems to have gathered lot of attention.

[danirabbit]

I'll defer to @cassidyjames here since he's done a lot of UX work on tiling already

[felix-andreas]

Within the last commits I tried PR to address some points of criticism:

• Introduce keyboard shortcuts

  I also really want to think about keyboard tiling with this, as I think people will expect to be able to do all the same tiling from a keyboard as soon as we would release this.

• Make behavior more consistent with existing tiling window manager - See 1.

  a somewhat hidden, non-default behavior.

• Introduce minimum tile size (currently 600x400)

  Something to maybe consider is that for a lot of apps there will be a minimum size where that app is usable

• Don't require a modifier - See 5.

  I would much rather arrive at a solution that we could just enable by default on normal window dragging instead of requiring a modifier.

New Behavior

1. Similar to other tiling window managers a Tiling-Mode can be activated by pressing SuperReturn: This will show a tile preview for the current window, which can then be moved using ↑←↓→, wasd, hjkl or the mouse. Pressing Return or space will confirm the current preview and will tile the window accordingly. (Windows can also be moved between multiple monitors)
2. In the future this mode could be complement with a Window-Selection-Mode: Here windows can be selected using the arrow keys (similar to the Multitasking view).
3. The grid can be changed by pressing the number keys when in Tiling-Mode. For example pressing 32 will set a 3 by 2 grid.
4. Inspired by the latest blog post I also added optional gaps, which can be toggled by pressing g when in tiling mode.
5. The DragCtrl tile action is still available. Additionally it is also possible to activate the Tiling-Mode by DragSecondary-Click which does not require any modifier key. I admit this also a bit hidden/non-default. Has someone a better idea how to activate the tiling-mode without using a modifier? Maybe be shaking the window? But this seems also weird ...

[felix-andreas]

@cassidyjames What would you think about merging this as experimental feature, which could be used for the user survey. (After the last couple of changes this PR isn't even production-ready enough for an experimental mode. So there is still some cleanup needed.)

I already added an "experimental-tiling-mode" flag which toggles the features introduced in this PR. It could be set to false by default, so that adventurous users would be able to test the behavior. If it turns out that the introduced workflow isn't beneficial or there are better alternatives, it should be easy to revert this PR as changes made are relatively self-contained.

[felix-andreas]

As this PR is in its current state much different from its initial implementation, I will close this PR. I also revert this branch to a previous commit (84aa12b) in case someone wants to test the initial behavior. See #963 for the new implementation.