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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
