request: mir::Server provide the_placement_strategy getter

I've no objection to exposing an accessor for this but, on the face of it, it doesn't seem particularly useful (as the strategy is a customisation point for Mir internals).

In case there is a better, more flexible, solution could you explain the scenario that motivates this request?

<alan_g> greyback_: I'm curious: how is the_placement_strategy() useful outside of Mir? Is it a workaround for a better API?
<greyback_> alan_g: I want to push the placement decision into qml. I do this by making the place() call emit a synchroneous signal, that qml can catch and make the decision
<greyback_> alan_g: https://code.launchpad.net/~gerboland/qtmir/initialSurfaceGeometry/+merge/231725 is how I'm using it
<alan_g> greyback_: OK but that just needs override (which is supported).
<alan_g> I'll take a look
<greyback_> alan_g: yeah, my workaround is just to save a copy of the shared pointer to the PlacementStrategy
<greyback_> ...in the override
<alan_g> I think it is similar to my saving the WindowManager in https://code.launchpad.net/~alan-griffiths/mir/tiling-window-mamagement/+merge/245228 (but I want the WindowManager, not the PlacementStrategy interface
<greyback_> alan_g: yes indeed. I've always let Mir create the objects and then relied on getters for them (not doing this was buggy with the old api). Perhaps I should relax that now
<alan_g> greyback_: it seems you actually want a MirPlacementStrategy* (not a ms::MirPlacementStrategy). So, rather than an accessor in Mir and a downcast (BTW wouldn't dynamic_cast be safer?), why not keep a weak_ptr<MirPlacementStrategy>? That would automatically give you your nullptr too.
<greyback_> alan_g: fair point, and yes fair point
<alan_g> Can I mark lp:1407687 invalid?
<greyback_> alan_g: just an FYI on why I'm implementing ms::MirPlacementStrategy - I received complaints from some clients where the surface size returned by the PlacementStrategy would be changed later when the surface is added to the scene. I.e. the surface would get a resize event shortly after creation. Some clients don't like that
<alan_g> that seems sensible
<alan_g> And what ms::PlacementStrategy is for
<greyback_> alan_g: you can. But it does open up a slight API inconsistency in mir::Server - as many overrides do have accessor methods, and only a few do not