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