Re: Proposing _NET_WM_STATE_FULLSCREEN_EXCLUSIVE

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Wed, 07 Nov 2012 10:57:07 -0500 "Ryan C. Gordon" <icculus icculus org> said:

ok - i'm cycling around to this after some e17 stuff. i have an issue:

"This array contains a list of all window ids that have temporarily changed a
monitor's resolution with the _NET_WM_STATE_FULLSCREEN_RESOLUTION hint. This
array MAY be updated to include or remove the window before any resolution
change goes into effect. The intention is that applications that are listening
for XRandR events can view this list and decide if they should ignore this
resolution change."

trying to syncrhonize the randr event changes with events indicating changes in
this property is bound to be hell. what rationale would apps have to listen to
BOTH randr events AND property changes here? i see the logic of this list - it
indicates which windows have been treated specially by the wm to have screens
change resolution.

another issue:

"In relation to _NET_WM_STATE_FULLSCREEN_RESOLUTION, the Window Manager MAY
simulate a physical resolution change by instead scaling the window's
rendering, such as with a compositor, so long as the window is rendering
into its expected dimensions and the given monitor is dedicated to that window."

this is not possible in x11 without event redirection/transformation too
(xevie being dead.. i put this in the "can't be done" list). even then that is
tricky to get right. perhaps you wish to word this more like:

"In relation to _NET_WM_STATE_FULLSCREEN_RESOLUTION, the Window Manager MAY
simulate a physical resolution change by instead letterboxing' a window ans
blanking out unused regions, making the window occupy the fullscreen visually as
the rest has been blanked out".

that covers the intent in that an app gets the fullscreen state it asked for,
but letterboxing et.c has been taken care of for it. it does this letterboxing
in the next paragraph anyway - so i am not even sure the above is needed.

so i have a q...:

"If there is no resolution that can completely contain the window's undecorated
size hints, the Window Manager MUST refuse to allow this hint."

in this case.. how does the app KNOW it has been refused? it knows when it
succeeded, but not when it failed. as i read it... ? did i miss something?

for now the _NET_RESOLUTIONS hint should do for advertising all available
resolutions (and even monitor locations) to clients to pick from.  we're find
for a single window fullscreening to a single monitor here. maybe we should
worry about "spanning/filling  multiple screens" at some future date. i'd like
to know how games view the world of "span multiple monitors". eg for wide field
of view - or extra game control panels etc. etc. and how they tend to want to
solve this - or if they would PREFER a different way. i personally lean to
pushing them to open 1 window per screen they wish to occupy with hints as to
how to arrange the windows relative to each-other, but this is another topic for
another day i believe. what we have here is sufficient for now and i don't smell
that there would be an issue extending going forward.

> 
> >> What is wrong with _NET_WM_FULLSCREEN_MONITORS?
> >
> > That's a good question. Raster, can we repurpose this, or do you need more?
> 
> Just following up, since this is (I think) the only outstanding concern 
> before I submit a new draft.
> 
> I imagine you're still recovering from the E17 alpha announcement at 
> LinuxCon...congrats on that.  :)   But when you get a moment, let me 
> know if we can make _NET_WM_FULLSCREEN_MONITORS fit your needs, or if I 
> should build something new into the spec.
> 
> Thanks,
> --ryan.
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> https://mail.gnome.org/mailman/listinfo/wm-spec-list
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com