Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE
- From: "Ryan C. Gordon" <icculus icculus org>
- To: "wm-spec-list gnome org" <wm-spec-list gnome org>
- Subject: Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE
- Date: Sun, 23 Dec 2012 21:43:10 -0500
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.
Sorry for my extremely late reply to this, I've been in crunch time on a
project this month.
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.
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.
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
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.
If there aren't objections, I think I'll rework the spec like this,
probably lifting a lot of this language directly.
_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.
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."
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.
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.
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.
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.
_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.
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?
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.
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]