Move alt tabbing logic to the scene instead of the `ApplicationSelector`

[mattkae]

Currently downlaoding everything into my :brain: :

• So before ApplicationSelector existed, we would navigate apps using the BasicWindowManager::focus_next_application()
  • This method called out to FocusController::focus_next_session() who - after a long, windy road - got the next session via SessionContainer::successor_of. This latter function is funny, because it grabs the next app in a list of apps that have come online without regard to the specific focus order.
• Additionally, we can eventually raise a surface using AbstractShell::raise. This method asks SurfaceStack::raise which has somewhat of a focus order (at least the most-recently focused elements are all at the end)

[mattkae]

Solution

• The SurfaceStack should be the definitive ordering for surfaces with regard to focus
  • This means that SessionContainer::successor/predecesor_of is useless, as it doesn't provide a meaningful order. I want to mark these methods as deprecated.
  • To mark them as deprecated, we must handle the fact that SystemCompositorWindowManager also uses these to focus a session when a session is removed. This will have to be resolved via the SurfaceStack, as explained below
• The FocusController will introduce one method:
  • FocusController::get_focus_iterator(): this can be used to return a new FocusIterator
• The AbstractShell will implement this interface
  • When FocusIterator::focus_next/prev_session is called, we will defer to the SurfaceStack to enact the temporary ordering.
• The BasicWindowManager will remain largely untouched, except that it must begin application cycling on the first alt-tab and end it when alt is released for the final time
• ApplicationSelector may be marked as deprecated or deleted altogether

[mattkae]

And yet another complication! The SurfaceStack holds a std::vector<std::vector<Surface>>. It has a different focus order for each layer essentially. But we would want an overall focus order of all focusable surfaces. This is a bit different. I wonder if we actually need a different focus order for each layer (probably).

[mattkae]

Things that care about the layers:

• SurfaceStack::surface_at ...

And that's it. Looks like we can pretty safely implement that method with a flat layer list representing the current focus order. But now I am having second thoughts if that's actually the best thing to do.

[mattkae]

It's the right place IMO. It implements msh::SurfaceStack, which only cares about focus

[mattkae]

AH! And the list generated by scene_elements_for needs to be in stacking order. That's a big reason not to make that switch. But it does mean that we should have a separate list for the focus order. Or perhaps we can do something very clever to avoid the hit of iterating the list too many times.

[mattkae]

Keeping two lists in parallel is a mess though. There must be a better way !

[RAOF]

So, I think you've got there, but rather than augmenting SurfaceStack with additional focus responsibilities, I think we should be paring back SurfaceStack. It is almost (but not quite) our pseudo-scenegraph - its interfaces are “what is the topmost surface under this point”, “get me a list of {buffer, position} pairs in rendering order”, and various manipulations of the stack (add, remove, raise, lower), and then a couple of miscellaneous bits (which maybe we should remove when we get a better abstraction??).

Focus is not the same as stacking order - things like floating regular windows are above, but don't (necessarily) have focus. For a focus-follows-mouse mode focusing a window doesn't even imply raising it.

On the other end, ApplicationSwitcher should be able to cycle through the applications without changing the stacking order until the alt-tab sequence is complete (it's a persistent low-grade annoyance to me that switching between windows with alt-tab messes up the stacking order).

I think we need to keep two separate lists because there are two distinct lists, and also because they're lists of different things. One's a list of surfaces¹, the other's a list of applications. Changing one does not necessarily require a change to the other.

¹: Actually, It's not a list of surfaces; it's a list of windows, which it probably shouldn't be.

[mattkae]

@RAOF: Why shouldn't it be a list of windows? In fact, it also has to be a list of surfaces to handle alt+tick functionality as well (although that would be a list of surfaces within the list of sessions)