RFC Evolving Mir support for writing shells

[Daniel van Vugt]

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.


On 20/03/15 20:21, Alan Griffiths wrote:
> 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.
>
>