After our discussions on IRC I thought the intent was to provide a "hook" so that shells implemented using Mir could "hook" into these events and process them. As such I think that HostLifecycleEventListener should be in shell and not in scene.
This new "scene/nested" library is not justified. All it contains is a default (null) implementation of an interface: scene::HostLifecycleEventListener. I see no reason not to put this in scene directly (or, in view of the above remarks: shell). (That's where you've put mir::DefaultServerConfiguration::the_host_lifecycle_event_listener() anyway).
After our discussions on IRC I thought the intent was to provide a "hook" so that shells implemented using Mir could "hook" into these events and process them. As such I think that HostLifecycleEv entListener should be in shell and not in scene.
~~~~
86 + mirnestedscene ry(nested/ ) default_ host_lifecycle_ event_listener. h"
...
193 +add_subdirecto
...
203 +#include "nested/
etc.
This new "scene/nested" library is not justified. All it contains is a default (null) implementation of an interface: scene:: HostLifecycleEv entListener. I see no reason not to put this in scene directly (or, in view of the above remarks: shell). (That's where you've put mir::DefaultSer verConfiguratio n::the_ host_lifecycle_ event_listener( ) anyway).
~~~~
144 + std::static_ pointer_ cast<void> (host_lifecycle _event_ listener) .get()) ;
No obvious need for the cast.
~~~~~
+void DefaultHostLife cycleEventListe ner::lifecycle_ event_occured( MirLifecycleSta te state) >for_each( (std::shared_ ptr<Session> const& session) >set_lifecycle_ state(state) ;
283 +{
284 + app_container-
285 + [&state]
286 + {
287 + session-
288 + });
289 +}
I think the default behavior should be to do nothing and let the implementing shell use this as a hook.