Subject: RFC Evolving Mir support for writing shells

From: Alan Griffiths <[email-masked]>
Date: Fri, 20 Mar 2015 12:21:13 +0000

Hi,

I've been spiking replacing DefaultWindowManager with the "Canonical"
one from examples (and discovered a number of tests make implicit
assumptions about the default window management policy). But I'm
wondering what the right end-state is:

    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?

Opinions?

Thanks in advance,
Alan

PS If you want to look at the spike it is here:

https://code.launchpad.net/~alan-griffiths/mir/spike-using-camonical-window-manager/+merge/253653

NB I won't be MPing it in this form. The main point of interest is the
test changes  - the rest is dependent upon the above discussion.

---

From: Daniel van Vugt <[email-masked]>
Date: Mon, 23 Mar 2015 10:11:08 +0800

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.

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 23 Mar 2015 13:12:22 +0000

On 23/03/15 02:11, Daniel van Vugt wrote:
> 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.
>

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?

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 24 Mar 2015 11:22:27 +0000

I've now proposed
https://code.launchpad.net/~alan-griffiths/mir/default-to-canonical-window-manager/+merge/253950

>     DefaultShell/PlacementStrategy/SurfaceConfigurator with

Yes

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

private and a copy

>     experimentation or should the code move?

private and a copy

>     but keep them to support the legacy code in tests and playground?

Kept and left public

---

From: Gerry Boland <[email-masked]>
Date: Tue, 24 Mar 2015 12:50:00 +0000

>     only relevant to a few tests and "playground" code.

Good to remove

>     functions and "get something working".

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

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

>     supply their window manager to AbstractShell and "get something

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.

> qtmir combines approaches 3 & 4 - it could migrate to 4 alone, but I

I'm open to your ideas on the matter!

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

>     DefaultShell/PlacementStrategy/SurfaceConfigurator with

Y

>     and used by examples? Or should it be private and copy exist in

Private + copy

>     experimentation or should the code move?

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

>     but keep them to support the legacy code in tests and playground?

I'd be happy to unpublish.

Thanks!
-G

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 24 Mar 2015 16:03:51 +0000

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

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

> AbstractShell, as it needs the additional power.

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

> I'm open to your ideas on the matter!

It is on my list.

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>

>>     and used by examples? Or should it be private and copy exist in

ditto

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

ditto

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

---

From: Daniel van Vugt <[email-masked]>
Date: Wed, 25 Mar 2015 09:50:13 +0800

Changing focus is a WM concept. But strictly speaking "focus" is an 
input concept [1]. It exists lower level in the display server to ensure 
key events land on the correct surface. You might also have "active" 
window for visual focus (greater highlighting, shadow), which is usually 
and hopefully the same window, except when using input methods. But 
"focus" is all about keyboards.

I'm not sure we've correctly separated these two concepts in Mir yet. 
But last I saw, the design docs for Unity8 did.

[1] http://en.wikipedia.org/wiki/Focus_(computing)

---

From: Alan Griffiths <[email-masked]>
Date: Thu, 26 Mar 2015 15:42:31 +0000

>> I'm open to your ideas on the matter!

Now available as a proof-of-concept:

https://code.launchpad.net/~alan-griffiths/qtmir/spike-using-WindowManager/+merge/254235
<https://code.launchpad.net/%7Ealan-griffiths/qtmir/spike-using-WindowManager/+merge/254235>