Trying out the new email list - thinking about refactoring

[Alexandros Frantzis]

On Wed, Mar 13, 2013 at 09:40:49AM -0700, Robert Carr wrote:
> >>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.

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.

> 
> >>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?

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

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

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

> 
> >>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?

Looks good to me.