On Mon, 2012-11-19 at 15:56 -0500, Ryan C. Gordon wrote: > Just pinging about this; anyone have any problems with this draft > (besides the one concern about specifying a monitor for the window)? > Everyone happy? Everyone already overwhelmed by the upcoming holidays? :)
I've had a chance now to go over the current draft in detail. I think it needs more work- it isn't ready to go in as is. I'm still not happy about the relationship between _NET_WM_FULLSCREEN and _NET_WM_FULLSCREEN_RESOLUTION. The draft is written as if these are two independent concepts with the only connection that they can't be used as once. What if we have a PDF viewer, a movie player, and a game, all with fullscreen modes. Maybe the PDF viewer and the game should behave slightly differently - but what about the movie player? I don't think anybody would argue that that it should behave more like the PDF viewer or more like the game depending on whether it wants to change the output resolution or not. Or what about a game that is happy running at the default desktop resolution - does it need to use _NET_WM_FULLSCREEN_RESOLUTION to get "gamelike" behaviors. I'd like to propose a basic rule here - that we treat three things independently. * An app that wants the resolution changed when its fullscreen window is displayed. * Any fixes that are needed to the definition of a fullscreen window, like specification of what happens when there are multiple fullscreen windows or when a fullscreen window loses input focus. * Any behavioral differences what we need for a fullscreen game and for a fullscreen PDF viewer or web-browser. and for now, we try only to figure out the right fix for the first one. So, does it make sense to use a separate state for "fullscreen with a resolution change" compared to "fullscreen"? I don't think it's unworkable - so if that's the general consensus, I'm willing to go along with it - but what would make more sense to me in the context of the specification is to parallel _NET_WM_FULLSCREEN_MONITORS: _NET_WM_FULLSCREEN_DIMENSIONS, width, height, CARDINAL[2]/32 A size that the application prefers when displayed fullscreen. If set by the application, when the window is in the fullscreen state, the window manager SHOULD change the effective display resolution so that the pixel size of the window is as close as possible to the specified size while being equal to or larger than the specified size in both width and height. If no display resolution would permit the given size, the window manager SHOULD use the largest display resolution possible. The determination of what monitor or monitors the fullscreen window will occupy MUST be done as if _NET_WM_FULLSCREEN_DIMENSIONS was not set. If the application wants to ensure that a particular monitor is used because the available resolutions for that monitor better match an intended size, it it MUST set _NET_WM_FULLSCREEN_MONITORS. Rationale: a game or similar application might want to take advantage of scaling capabilities of the display subsystem. Making the window manager responsible for changing the resolution provides more information to the desktop environment about what is going on and robustness if the application quits unexpectedly. I still think that letter-boxing should be left to the application - it will be more efficient, more flexible, and just a few lines of code. The reason that I wrote the above to disallow picking the monitor based on the dimensions is to avoid games inadvertently jumping between monitors if the user changes the screen resolution preference. If an application wants that, they can use _NET_WM_FULLSCREEN_MONITORS. _NET_RESOLUTIONS - as written, this has a couple of problems - First, resolutions are just width/height not x/y/width/height. Second, it doesn't take multi-monitor into account. I think probably we should just drop this for now - as was pointed out, software scaling by the compositor under current X has an input-redirection problem. _NET_FULLSCREEN_TEMPORARY - I don't think this works - you've described it as being useful for some app to ignore *changes* - but what if an application started up when _NET_FULLSCREEN_TEMPORARY was already set - the geometry would be indeterminate. I think any solution would require knowing what the use cases are for listening to RANDR changes, figuring out what the apps actually need to calculate, and exporting that (_NET_WM_VISIBLE_DESKTOP_AREA or something.) But I think the currently known examples - file managers drawing the desktop, panels - are components of the desktop environment, so it's probably better to just leave it up to the desktop environment rather than making a stab toward a solution. - Owen _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list