Ping? I'd really like to see this spec be successful. On Sun, Dec 23, 2012 at 9:43 PM, Ryan C. Gordon <iccu...@icculus.org> wrote:
> > 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. +1 > > > _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. Does _NET_WM_FULLSCREEN_MONITORS not cover this use case 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 don't see the big advantage of adding additional complexity and synchronization between the WM and the application just to avoid a library call to XRandR which would generally be supported by the toolkit anyway. > > 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. Agree with Owen's concerns. If applications want to know what the non-XRandR bounds of the desktop are and such, they should use other existing hints from the WM (or add something along those lines), rather than forcing apps to maintain some kind of state machine making guesses at what the "real desktop bounds" are inside the WM. > > > --ryan. > > > > ______________________________**_________________ > wm-spec-list mailing list > wm-spec-list@gnome.org > https://mail.gnome.org/**mailman/listinfo/wm-spec-list<https://mail.gnome.org/mailman/listinfo/wm-spec-list> >
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
