What problem does mf::Shell::handle_surface_created() actually solve?

[Robert Carr]

The point is just to ensure focus notification is sent after the surface ID
is, you may remember the CloggableEventSink...this was the solution after
that got rejected.


On Tue, Apr 1, 2014 at 9:30 AM, Alan Griffiths <alan.griffiths at canonical.com
> wrote:

>  In my trawl through the data model I came across handle_surface_created()
> and wondered exactly what problem it solves.
>
> I suspect the "scene" rework will offer a better solution, but I'd like to
> understand what's going on before proposing anything.
>
> Firstly, note that *this function is not the subject of any tests*. So
> changes that break the required behaviour will not cause test failures.
>
> Now, from mf::SessionMediator::create_surface()
>
>             // TODO: NOTE: We use the ordering here to ensure the shell
> acts on the surface after the surface ID is sent over the wire.
>             // This guarantees that notifications such as, gained focus,
> etc, can be correctly interpreted by the client.
>             // To achieve this order we rely on done->Run() sending
> messages synchronously. As documented in mfd::SocketMessenger::send.
>             // this will require additional synchronization if
> mfd::SocketMessenger::send changes.
>
> And the active code is:
>
> void
> ms::SessionManager::handle_surface_created(std::shared_ptr<mf::Session>
> const& session)
> {
>     auto shell_session = std::dynamic_pointer_cast<msh::Session>(session);
>
>     set_focus_to(shell_session);
> }
>
> So, it appears to be a mechanism for setting the focus to the session that
> owns a surface *after* the surface data has been sent to the client.
> Except that we also call it from mf::SurfaceId
> ms::SessionManager::create_surface_for()
>
> // TODO: We use this to work around the lack of a SessionMediator-like
> object for internal clients.
> // we could have an internal client mediator which acts as a factory for
> internal clients, taking responsibility
> // for invoking handle_surface_created.
>
> In any case, the requirement appears to be that to focus on a session
> immediately a new surface in the session is known to the client.
>
> I assume this is so that input can be routed to the surface before it is
> visible? (That surface hasn't yet posted a frame so it is not available to
> be rendered.)
>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20140401/e3b3b963/attachment.html>