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

From: Alan Griffiths <[email-masked]>
Date: Tue, 01 Apr 2014 17:30:42 +0100

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.)

---

From: Robert Carr <[email-masked]>
Date: Tue, 1 Apr 2014 09:42:27 -0700

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 <[email-masked]
> 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.
>
>     auto shell_session = std::dynamic_pointer_cast<msh::Session>(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
> // 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
> visible? (That surface hasn't yet posted a frame so it is not available to
> be rendered.)
>
> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>
>