[compiz] _NET_WM_FULLSCREEN_MONITORS hint (YAY!!)

Wed Dec 31 14:09:38 PST 2008

On Wed, Dec 31, 2008 at 7:02 AM, Danny Baumann <dannybaumann at web.de> wrote:

> - There's one reported regression: URL I will try to see what's
> happening there (and if I can reproduce it at all), but if you have any
> pointers, let me know.

I'll look at this next, but I wanted to get back to you on your revision
below first...

> - What the current compiz code does (which is similar to what kwin and
> metacity do) is that the fullscreen rectangle is calculated as the
> boundary box of all the specified monitors, no matter at which point
> they were specified. Re-reading the spec I think this is not exactly
> correct. The spec clearly states that the specified monitors specify
> edges, not an arbitrary set. Attached is my take on fixing that and
> bringing compiz' behaviour in accordance to the spec.
> For an example, imagine a scenario with 2 monitors: a 1280x800 laptop
> panel and a 1280x1024 external monitor. The resulting window sizes for
> some specified monitor sets are as follows:
> (monitor set: left/right/top/bottom - old code - new code)

0000 - 1280x800+0+0     - 1280x800+0+0
> 1111 - 1280x1024+1280+0 - 1280x1024+1280+0
> 0001 - 2560x1024+0+0    - 1280x1024+0+0
> 0100 - 2560x1024+0+0    - 2560x800+0+0
> 0101 - 2560x1024+0+0    - 2560x1024+0+0

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.

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? 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?).

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. 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...

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.

> > 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?

Thanks Danny!

-- 
-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
-[ KDE PIM Developer         //  http://www.kde.org  ]-
-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/compiz/attachments/20081231/41ec6678/attachment.htm 