[compiz] _NET_WM_FULLSCREEN_MONITORS hint (YAY!!)

[Danny Baumann]

Hi,

> You confused me... The spec goes top/bottom/left/right... Let me redo
> this that way...
> 
> (monitor set: top/bottom/left/right - old code - new code) 
> monitor #0 being 1280x800
> monitor #1 being 1280x1024
> 
> A) 0000 - 1280x800+0+0     - 1280x800+0+0
> B) 1111 - 1280x1024+1280+0 - 1280x1024+1280+0
> C) 0100 - 2560x1024+0+0    - 1280x1024+0+0
> D) 0001 - 2560x1024+0+0    - 2560x800+0+0
> E) 0101 - 2560x1024+0+0    - 2560x1024+0+0
> 
> So, A, B, and E are not changed. 

Correct.

> You're right that C would be a change, but I would think it would be a
> weird thing for an app to ask for, since it would be saying "make me
> exist on only the first head, but make me as tall as the second head."
> I would hope a sane app wouldn't ask for that? 

I hope so as well.

> If an app did ask for it, my guess would be that it was really asking
> for the "old" behavior shown above (why list 2 different monitors in
> your top/bottom/left/right indices if you don't want to span 2
> monitors?).

I used an extreme (as opposed to real world) example on purpose. I
wanted to point out what can happen if the property is used
incorrectly ;-)
I thought a bit about sanity checking this kind of thing, but couldn't
come up with a sane algorithm for that. What looks like a really weird
scenario for horizontally arranged monitors can be valid for vertically
arranged monitors.

> E is different too, you're right, but I think that it's another weird
> request. The app (at least with your proposed change) would be saying
> "make me span 2 heads, fullscreen, but don't cover the full screen of
> the second head--just take up 800 pixels of the 1024". That doesn't
> seem quite right to me. 

Why? If I were to write a video player using this hint, I would request
_exactly_ that size. I don't want parts of my video offscreen.

> I'm not sure how WM's deal with apps that ask to be fullscreen, but
> don't actually cover the full screen? That sounds kinda buggy to me...

Well, single head fullscreening is the same as this scenario: A
fullscreen window not covering the whole visible (X) screen area. The
only difference is the arrangement of fullscreen window vs. remainder
area.

>         You can also see the difference when trying the test tool with
>         two
>         differently sized monitors. I think the new version makes much
>         more
>         sense because it allows greater flexibility (e.g. a video
>         player doesn't
>         want parts of its window offscreen) and it matches the spec
>         much better.
>         I wanted to know about your opinion, though.
> 
> I definitely agree that your proposed change would fit the letter of
> the spec more, but given the 2 cases I mentioned above, I'm not sure
> you'd actually want the behaviour that your change would produce.

Well, D is a valid scenario IMO, C is a broken one. I'm wondering if we
can't just say "make sure your app gets fixed" in that case.

Actually, I think the metacity and kwin implementations were done
_before_ the property was fully spec'ed. At least it looks like that
because the first specification proposal (e.g.
http://mail.gnome.org/archives/wm-spec-list/2008-February/msg00004.html)
was not defining the listed monitors as edges. The metacity and kwin
implementations perfectly match what was spec'ed in the first proposal.
Is that a possible explanation?
 
>         > Also, I'm not quite familiar with the Compiz release
>         schedule yet...
>         > does anyone know what released Compiz version will have
>         > _NET_WM_FULLSCREEN_MONITORS in it and when that will happen?
>         Is there
>         > any chance it can make it into the next released stable
>         version?
>         
>         
>         If we can solve the regression above, I see no reason not to
>         pick this
>         change into the 0.8 branch. I even think we _should_ pick it,
>         because
>         some distros are likely to stay with 0.8 (once it's released)
>         for a
>         while.
> 
> Yeah, I definitely agree, and that's what I'm hoping for too. Right
> now, we have a bunch of folks internally who just can't use Compiz
> with Workstation/Player and this would bring Compiz back to being a
> first class WM for VMware users. =:) Do you know when 0.8 is being
> tentatively planned for release?

Heh, see parallel thread "The future of compiz" :-/
I definitely want to see it out of the door before the next round of
distro updates.

Regards,

Danny