Subject: Re: Trying out the new email list - thinking about refactoring

From: Robert Carr <[email-masked]>
Date: Wed, 13 Mar 2013 09:40:49 -0700

>> Working through some recent MPs it has become apparent to me that some
>> refactoring would clarify the code.

>> shell::SessionStore = > frontend::Shell

>> This is an interface defining a dependency of
>> frontend::ApplicationMediator (so it should be in frontend) and has
>> operations on it that don't fit the current name. What it does fit is
>> the functionality that frontend needs from a shell.

I think this is right, there may also still be shell:Shell though, or (shell::SessionStore) for example "request_focus" is not interesting to the frontend.

>> shell::Session = > frontend::Session
>> shell::Surface = > frontend::Surface

>> Similarly, these define what frontend::ApplicationMediator needs and the
>> dependencies belongs in frontend.

The way these interfaces are used now I think this is correct. Though the frontend::Surface interface should certainly be smaller. Again though I think we also need a shell::Surface, i.e. shell::Surface::maximize() or shell::Surface::last_restored_size()
various windowing semantics that have no implications on the frontend. I guess this is ProxySurface?

  ~~~~

>> Now that the session compositing use case is becoming clear it is
>> apparent that ApplicationMediator isn't specific to applications. It
>> mediates both system and user sessions.

Yes

>> surfaces::ProxySurface => shell::Window (or shell::Surface? cf above)

>> The base class (shell::Surface = > frontend::Surface) is being populated
>> with additional functionality that belongs to shell and not to surfaces.
>> There's some rework about constructing these objects - that should move
>> into shell too.

Yes

>> What to folks think? Anything to add to the list?

---

From: Alexandros Frantzis <[email-masked]>
Date: Wed, 13 Mar 2013 19:22:32 +0200

> I think this is right, there may also still be shell:Shell though, or (shell::SessionStore) for example "request_focus" is not interesting to the frontend.

Which entity is in need of the request_focus functionality? The
interface should be "owned" by that entity (i.e., we should use the same
reasoning behind this refactoring), assuming of course there is only one
such entity.

> various windowing semantics that have no implications on the frontend. I guess this is ProxySurface?

Likewise, we should figure out which entity needs this functionality.

> >>surfaces::ProxySurface => shell::Window (or shell::Surface? cf above)

I am in favor of shell::Surface since this the natural language of the
shell. That is, the shell deals in surfaces not windows.

> >>What to folks think? Anything to add to the list?

Looks good to me.

---

From: Alan Griffiths <[email-masked]>
Date: Wed, 13 Mar 2013 17:28:26 +0000

> reasoning behind this refactoring), assuming of course there is only one

I agree that request_focus() as in the MP isn't relevant to frontend, but my suggested rework (in the review) means it won't be needed there - it is an implementation detail of create_surface_for().