[sugar] Supporting desktop applications, extending the EWMH spec

[Marco Pesenti Gritti]

On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> Let's keep thinking about this.  For example, I wonder what Metacity does
> to a window that is both  _NET_WM_STATE_FULLSCREEN and
> _NET_WM_STATE_BELOW?  Does it stack it below the Frame, if the Frame is
> _NET_WM_TYPE_DOCK and _NET_WM_STATE_ABOVE?  If not, could we convince the
> Metacity developers that this is a good idea?

I just thought of a worst problem with the FULLSCREEN approach.
FULLSCREEN windows are always on the top of NORMAL windows.

I think the general issue is that the meaning of FULLSCREEN type on
the desktop is very different from our needs, sincethe typical use
case is a video player. The type is used to mark windows which must
be:

1 Always on the top of everything else.
2 Maximized/undecorated.

We would need to drop 1.

> What about making Activities run as _NET_WM_TYPE_DESKTOP? How does
> Metacity handle multiple DESKTOP windows? (It probably isn't happy about
> them...)

I'm pretty sure it won't handle them as we would like. Also DESKTOP is
used for the home/group/mesh view already.

> It may be that we can find a way to make this work under stock Metacity if
> we're creative.  If not, Metacity is under very active development.
> Perhaps we can find a small change that resolves our problem and is
> satisfying to upstream Metacity.

It could be done by extending metacity (upstream) to provide an option
to enable a different handling of FULLSCREEN windows. But what is the
advantage over defining a new type which is more closely tied to our
use case? The one I can think of is that existing toolkits has already
a way to create fullscreen windows without using low level API.

Marco