Overhaul view transations

[chrisduerr]

Currently transitions between the different views are handled by transactions. This causes an issue with the transition to the overview since the on_gesture and on_gesture_done methods check for the current view, rather than the pending view. As a result, it's possible that the overview is entered, but it's stuck in the transitory state where the primary percentage is stuck at 100%.

The simplest solution would be to use the pending view instead, ensuring that the transactional state is taken into account. However this could cause the transition to the overview to be delayed for up to one second which is not acceptable now that the overview transition is animated.

The best solution that comes to my mind is to remove all transactionality from the view transitions and ensure they only rely on moving windows around, rather than resizing them.

One important part of this is to remove the available_overview method that removes the exclusive zones from top/overlay layer shell windows. These windows should likely also be rendered in the overview again. To ensure applications like Epitaph don't interfere with the overview it should be ensured they still receive touch input.

TBD:

• If Epitaph is open it's impossible to give feedback to the user when he's transitioning to the overview, should overview transition be blocked?
• What should be done about layer shell windows like Squeekboard, should they stay visible at the bottom of the screen? Keyboard interaction in the overview would be extremely strange

[chrisduerr]

Okay, so I think I have a plan:

- [ ] Focus is cleared when switching to the overview (effectively killing IME windows)

• Focus is NOT cleared when switching to the overview
• Switching to the overview will not resize all windows
  => Prevents flickering for background applications
  => No longer any transaction necessary to enter the overview (fixing this issue)

- [ ] (Exclusive) Layer shell windows on top/overlay are never reaped in the overview
=> Prevents flickering from exclusive zone updates

• Exclusive layer shell windows on top/overlay are hidden or scaled in the overview
  => available_overview sticks around, but shouldn't be used to resize windows in the overview
  => If scaled, they're only shown for the current window
• On confirmation, layout is switched with a transaction and focus is set
• On cancel, transaction is used too. Same as confirmation.
  => Should this use transaction? Technically not necessary if we don't change focus.

[chrisduerr]

One alternative I'd like to bring up in case this comes back to haunt me in the future: A simpler alternative is to just scrap the animation when opening the overview and using a transactional transition triggered by a double-tap on the gesture handle instead.

[chrisduerr]

Slight change of plans: We are not going to remove focus when entering the overview.

This allows us to avoid all the special-cased logic of not reaping certain layer shell windows while in the overview and will ensure that going back to the current layout will be flicker-free.

One drawback of this is that opening any other application will now require a resize since the virtual keyboard is initially still open. The best solution to that seems to be killing the virtual keyboard, potentially through some IME special-case handling, to ensure that its removal is included in the transaction to switch to the new layout.

In theory the virtual keyboard does not need to be killed, since a focus loss will automatically cause it to be unmapped. So it would be possible to just mark it as "dead" and wait for reaping. However this is likely to prove unreliable and ideally it should be manually closed, potentially through zwlr_layer_surface_v1::closed. Unfortunately squeekboard will not be able to bring the keyboard back up when closed once with zwlr_layer_surface_v1::closed, however this might be something that can be patched upstream.

[chrisduerr]

This new approach also allows splitting up the implementation a bit better. The synchronization of the virtual keyboard being killed when leaving the overview can be handled separately, while this issue should focus on getting the transition into the overview ironed out.

Follow-up for virtual keyboard: #118