Sorry for my extremely late reply to this, I've been in crunch time on a project this month.
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 think we've been trying to solve multiple problems here, under the expectation that we'll get one shot at it and have to live with the consequences. I'm a little uncomfortable with how large the spec is becoming, if we're being honest, so refocusing isn't a bad idea.
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.
This is a pretty good idea. The whole idea started as a parallel to _NET_WM_STATE_FULLSCREEN, but perhaps that was the wrong place to start. An added benefit to this approach: talk of "fullscreen" windows in other places in the spec would no longer be ambiguous.
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
If there aren't objections, I think I'll rework the spec like this, probably lifting a lot of this language directly.
The x,y was to specify the monitor. It wasn't enough to say "I want it on the third monitor because it has a resolution I like," when a game (in Raster's example) might want to say "I need the monitor that's directly to the left of the other one I'm using."
_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 know Mac OS X has a control panel that lets you specify monitor position in relation to each other (including to the left and right, but also above and below), and I imagine X11 DEs could offer the same thing, if they don't already.
There seemed to be a real (some would say "passionate") desire to at least allow for this, in hopes that some other extension would make input-redirection possible at a later point. We don't have to talk about it directly, so long as the spec doesn't make it hard to implement later.
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.
That being said, there are two other big uses for _NET_RESOLUTIONS:
- The DE can allow a user to specify resolutions a game is allowed to use (even if the X server offers 800x600 on an LCD, maybe the user only wants the native LCD's 1920x1200, or whatever).
- This allows applications to never touch XRandR at all. Without this, even if the Window Manager handles the actual resolution switch, the app still needs to use XRandR to query for available resolutions.
I'd say, even without rescaling, this is useful and important functionality which should remain.This was something Martin wanted, so I threw it in there. I don't feel strongly about removing it, or replacing it with a better solution. Martin, any thoughts?
_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.
It would be useful to know what listens for XRandR events and what would behave badly. If it's just a system control panel, I don't think it matters. If it's everything using Qt, that could be a problem.
Then again, these apps already are responding to an XRandR event, as games change the resolution themselves, and the world hasn't ended. I'm inclined to say we drop this section, but it's possible I just didn't draft a decent approach.
--ryan.
_______________________________________________
wm-spec-list mailing list
wm-spec-list gnome org
https://mail.gnome.org/mailman/listinfo/wm-spec-list