On Fri, Sep 19, 2008 at 12:13 AM, Benjamin M. Schwartz <[EMAIL PROTECTED]> 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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar