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.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
