RFC Evolving Mir support for writing shells

[Gerry Boland]

On 23/03/15 13:12, Alan Griffiths wrote:
> 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.

Good to remove

> 
>     2. The shell writer can inherit from ShellWrapper override a few
>     functions and "get something working".

AbstractShell/WindowManager more powerful than this, happy to let it go.
I wasn't using it anyway.

> 
>     3. The shell writer can inherit from AbstractShell override a few
>     functions and "get something working".

This class satisfies QtMir's needs, allowing the use of a custom
renderer and input targetting. It does demand a lot of work in QtMir
side to re-implement Mir classes however, so is quite clumsy to operate.

Minor point is I'd rather it didn't contain concept of "focus", as IMO
that's a window management concept.

> 
>     4. The shell writer can implement the WindowManager interface and
>     supply their window manager to AbstractShell and "get something
>     working".

I anticipate this class could evolve to satisfy QtMir's needs. It has a
much nicer API than AbstractShell, but does appear to demand using Mir's
default renderer and input event management - things QtMir has
overridden. If that's the intention, then QtMir will remain with
AbstractShell, as it needs the additional power.

> 
> 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.

I'm open to your ideas on the matter!

> 
> 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.

Happy to deprecate 1 & 2 anyway. I think dropping 3 would limit third
party shell writers greatly however. 4 is a great option for a simpler
shell.

> 
> The questions raised by my OP:
> 
>     0. should we replace the legacy
>     DefaultShell/PlacementStrategy/SurfaceConfigurator with
>     CanonicalWindowManager?

Y

> 
>     1. Should a shell::BasicWindowManager template be public, supported
>     and used by examples? Or should it be private and copy exist in
>     examples?

Private + copy

> 
>     2. Should shell::CanonicalWindowManagerPolicy just be a "snapshot"
>     of example::CanonicalWindowManagerPolicy which could remain for
>     experimentation or should the code move?

Private + copy for now, can revisit later when it matures and wanted by
shell.

> 
>     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?

I'd be happy to unpublish.

Thanks!
-G


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150324/1f3bba3c/attachment.pgp>