On 23/03/15 02:11, Daniel van Vugt wrote:
> For the benefit of all future shell developers;
> <hand waiving>I'd like to inherit from "SomethingShell" and get
> something that works in a few lines without writing additional code.
> Then I would like to be able to override functions to customise the
> shell behaviour.</hand waiving>
>
> I feel that's the driving requirement because that would rapidly
> accelerate Mir shell development globally, if it's really easy for
> people to get started. With hundreds of header files and classes, I
> can see libmirserver is probably overwhelming if someone was just
> starting out trying to build a shell.
>
> Syntax and implementation details are secondary.
At the moment we support rather too many options:
1. The shell writer can implement PlacementStrategy &
SurfaceConfigurator and "get something working". But it doesn't
really provide the flexibility needed for anything ambitions and is
only relevant to a few tests and "playground" code.
2. The shell writer can inherit from ShellWrapper override a few
functions and "get something working".
3. The shell writer can inherit from AbstractShell override a few
functions and "get something working".
4. The shell writer can implement the WindowManager interface and
supply their window manager to AbstractShell and "get something
working".
USC currently uses approach 2, but I've also tried approach 4 and found
it better.
qtmir combines approaches 3 & 4 - it could migrate to 4 alone, but I
don't yet have a POC.
In the examples I've implemented a couple of window management
strategies and combined option 4 with a BasicWindowManager template that
allows the window manager to track the information it needs while
deferring the window management logic to a WindowManagerPolicy. While
neither CanonicalWindowManager not TilingWindowManager are fully
functional I think they are enough to prove this is a viable approach.
As implied by Q3 in the OP I think we should be losing the legacy option 1.
Once we can migrate USC and qtmir to option 4 we ought to deprecate
options 2 & 3 for later removal.
The questions raised by my OP:
0. should we replace the legacy
DefaultShell/PlacementStrategy/SurfaceConfigurator with
CanonicalWindowManager?
1. Should a shell::BasicWindowManager template be public, supported
and used by examples? Or should it be private and copy exist in
examples?
2. Should shell::CanonicalWindowManagerPolicy just be a "snapshot"
of example::CanonicalWindowManagerPolicy which could remain for
experimentation or should the code move?
3. We have some tests and playground that are coupled to the
PlacementStrategy & SurfaceConfigurator used with
DefaultWindowManager but I don't think these configuration points
are needed downstream. Are we happy to "unpublish" them (for now)
but keep them to support the legacy code in tests and playground?
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
