Subject: scene::Session => scene::Application

From: Alan Griffiths <[email-masked]>
Date: Mon, 02 Jun 2014 10:08:35 +0100

With the current review of "trust session" it is clear that "Session" is
a bad name for what the scene::Session class represents.

I suggest that we rename it to "Application" as that seems to better
reflect its role.

Clearly that has the potential to break some downstream projects - but
that could be mitigated by the temporary introduction of some typedefs
and forwarding functions to give us API compatibility while we update
those projects.

Any opinions on the desirability of doing this rename?

---

From: Gerry Boland <[email-masked]>
Date: Tue, 03 Jun 2014 15:39:23 +0100

> Any opinions on the desirability of doing this rename?

Your reasons for why Session is a bad name would help the discussion.

I've always thought that since Mir is a server, why not refer to clients
as "Client" - I interpret Application as a client that creates a window
for a user to interact with - but configuration tools & snapshotting
tools may not create a window (i.e. for scripting)
-G

---

From: Alan Griffiths <[email-masked]>
Date: Tue, 03 Jun 2014 15:59:56 +0100

> Your reasons for why Session is a bad name would help the discussion.

Because it is the collection of surfaces owned by a MirConnection - and
"session" doesn't convey *any* of that.

> as "Client" - 

Currently there is no representation of a "client" in Mir - nor is there
a simple way to identify one: We do try to identify the PID of the
process talking over a socket but there are limits to that.

> I interpret Application as a client that creates a window

OK, so "Application" might not be a good name either.

And, if you move onto the desktop, an application can have more than one
windows for a user to interact with.

---

From: Cemil Azizoglu <[email-masked]>
Date: Tue, 3 Jun 2014 14:24:06 -0500

collection of surfaces owned by a MirConnection <<==== SurfaceSet?

On Tue, Jun 3, 2014 at 9:59 AM, Alan Griffiths <[email-masked]
> wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/mir-devel
>

-- 
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA

---

From: Alberto Aguirre <[email-masked]>
Date: Thu, 12 Jun 2014 13:13:50 -0500

So we have mir::scene::Session with the following interface:

    virtual void force_requests_to_complete() = 0;
    virtual pid_t process_id() const = 0;

    virtual void take_snapshot(SnapshotCallback const& snapshot_taken) = 0;
    virtual std::shared_ptr<Surface> default_surface() const = 0;
    virtual void set_lifecycle_state(MirLifecycleState state) = 0;
    virtual void send_display_config(graphics::DisplayConfiguration const&)
= 0;

And mir::frontend::Session with:

    virtual SurfaceId create_surface(scene::SurfaceCreationParameters
const& params) = 0;
    virtual void destroy_surface(SurfaceId surface) = 0;
    virtual std::shared_ptr<Surface> get_surface(SurfaceId surface) const =
0;

    virtual std::string name() const = 0;

    virtual void hide() = 0;
    virtual void show() = 0;

This looks like it belongs to a SurfaceBundle class:

    virtual std::string name() const = 0;  <== This could be a different
name than the one for mir::frontend::Session
    virtual void hide() = 0;
    virtual void show() = 0;
    virtual void take_snapshot(SnapshotCallback const& snapshot_taken) = 0;
    virtual std::shared_ptr<Surface> default_surface() const = 0;
    virtual void force_requests_to_complete() = 0;

These methods looks like they belong to a Surface factory but I can see
this being folded into the SurfaceBundle above:

    virtual SurfaceId create_surface(scene::SurfaceCreationParameters
const& params) = 0;
    virtual void destroy_surface(SurfaceId surface) = 0;
    virtual std::shared_ptr<Surface> get_surface(SurfaceId surface) const =
0;

Not sure exactly how to categorize this - for me it would make more sense
if they belonged to frontend::Session
    virtual void set_lifecycle_state(MirLifecycleState state) = 0;
    virtual void send_display_config(graphics::DisplayConfiguration const&)
= 0;
    virtual pid_t process_id() const = 0;

On Tue, Jun 3, 2014 at 2:24 PM, Cemil Azizoglu <[email-masked]

> On Tue, Jun 3, 2014 at 9:59 AM, Alan Griffiths <
> [email-masked]> wrote:
>