On Wed, Dec 31, 2008 at 7:02 AM, Danny Baumann <<a href="mailto:dannybaumann@web.de">dannybaumann@web.de</a>> wrote: <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> - 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.</blockquote><div> I'll look at this next, but I wanted to get back to you on your revision below first...   </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> - 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) </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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</blockquote><div> 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... </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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.</blockquote><div> 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.  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Also, I'm not quite familiar with the Compiz release schedule yet... <div class="Ih2E3d"> > 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? </div>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.</blockquote><div> 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! </div></div> -- -[ Jason 'vanRijn' Kasper    //  <a href="http://movingparts.net">http://movingparts.net</a> ]- -[ KDE PIM Developer         //  <a href="http://www.kde.org">http://www.kde.org</a>  ]- -[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-