RFC Evolving Mir support for writing shells

[Alan Griffiths]

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

At the moment USC is using it.  I have MP'd a change to fix that:

https://code.launchpad.net/~alan-griffiths/unity-system-compositor/use-WindowMangager-NOT-ShellWrapper/+merge/252933
<https://code.launchpad.net/%7Ealan-griffiths/unity-system-compositor/use-WindowMangager-NOT-ShellWrapper/+merge/252933>

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

I can understand that. It currently works this way to connect the window
manager to the existing focus notification mechanisms.

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

I hope it is orthogonal to the choice of render and input event management.

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

It is on my list.

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

https://code.launchpad.net/~alan-griffiths/mir/default-to-canonical-window-manager/+merge/253950
<https://code.launchpad.net/%7Ealan-griffiths/mir/default-to-canonical-window-manager/+merge/253950>

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

ditto

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

ditto

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

https://code.launchpad.net/~alan-griffiths/mir/unpublish-legacy-window-managment-customization/+merge/253967
<https://code.launchpad.net/%7Ealan-griffiths/mir/unpublish-legacy-window-managment-customization/+merge/253967>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20150324/8641d43f/attachment.html>