[Xquartz-dev] XQuartz 2.6.0_rc1 (for Leopard and Snow Leopard)
doh123
doh123 at doh123.com
Sun Jan 23 16:37:44 PST 2011
yeah, the captured display is always like a 2 billion level on the shielding window... I'm just not sure how to actually code the changes to tell it to change the windowing levels so it will use the max one. Can I just call the xpr function and reset the levels? I'm just a bit clueless on the structure of the program and what part does what functions... so feel a little lost when hacking away at the code.
I don't think any other app is really grabbing focus. Doesn't an app that grabs focus actually change the top menu bar?
What happens is, every window (rootless or fullscreen) including the shielding window, lose focus... nothing else really grabs focus, and Xquartz is still the active application... its just all windows lose focus for a second or two, then the last window that was in focus comes back into focus if you haven't click on anything. Its not actually changing to another app... I've reproduced this on many many machines now, even with bare minimum software running to get OSX to run, including getting rid of Dashboard or anything else that could be problematic, and it never changes... just once an hour or two, sometimes only takes 10 minutes... its totally random... just "poof" and all X11 windows lose focus... then come back. Its highly annoying in fullscreen since it hides the shielding window and you lose the whole fullscreen and see the desktop... it happens more often when I'm not running quartz-wm than when I am. (I never run it in fullscreen)
I think Display capturing would fix this only because no other app could take focus if it wanted to... now of course if its just Xquartz losing focus on windows, it will still happen and instead of the desktop I'd probably just see the shield.
On Jan 23, 2011, at 5:49 PM, Jeremy Huddleston wrote:
>
> On Jan 23, 2011, at 15:16, doh123 wrote:
>
>> ok... first, I've been playing with Display Capturing some, though I haven;t really gotten anywhere. Every time I have it capture the display its always solid black and everything drawing behind it... I still haven't gotten around that.... it looks like capturing the display automatically makes a shielding window at the highest level over everything else that was already up, so Xquartz is still using lower levels, and I don't see any way to change the captured display shielding window... is there a way I can actually change the captured display's shielding window level?
>
> Yeah, that's pretty much where I ended up. I've tried moving that window to another level and deleting it (both with private APIs). X11 thinks it is moved, but the Window Server still reports it at the highest level… so I dunno how to move past that. The only thing I can think of is moving *everything* to the same window level (the shield is actually max - 1, so we'd be able to use max).
>
>> Maybe theres a way that every time a new window is made that it can set it to a window level of default+shieldingwindowlevel ?
>
> Yeah, that would work if the shield window was low enough. It's max - 1.
>
>> Another thing.... the main reason I want to get this working is because of the fullscreen focus loss bug where it flashes back to the desktop every once in awhile... and while display capturing could fix that I guess, I'm not sure that its needed really.
>
> Right… I'm not sure that display capturing would actually fix that. Some other application is stealing focus. This happens in rootless as well as fullscreen.
>
>> I know its been said the focus loss bug is something to do with OSX and not Xquartz, but I had played with Crossover, and their fullscreen never has this focus problem, even running at the same time, seeing it happen in Xquartz, their X server still never does it.
>
> Yeah, I dunno. We're using the same libXplugin as them, and I really don't know what about X11.app makes it susceptible to focus-theft.
>
>> I assumed earlier on that it was because they were capturing the display... but multitasking and switching still works, unlike when the display is actually captured, so I doubt they are actually capturing the display. This leads me to believe there is some other bug in Xquartz that is allowing this focus issue to happen that doesn't need to happen since I can see a different X server not having the same problem. The root cause may be somewhere in OSX, but it see
>> ms as though its something that could be fixed in Xquartz if the Crossover X server can do it.
>
> Yeah, if you figure out what knob it is, I'll certainly turn it, but the sources have diverged so much that it's too difficult to bisect.
>
>
>>
>> -doh123
>>
>>
>> On Dec 10, 2010, at 11:22 AM, Jeremy Huddleston wrote:
>>
>>>
>>> On Dec 10, 2010, at 07:13, doh123 wrote:
>>>
>>>> I know the display capturing issues are complicated... I'm going to spend some time on my Christmas vacation trying to dig into Xquartz to learn how it works some more, and see if I can get it working... but no promises, I'm far from an expert, or experienced programmer. If I find a way to get it working that isn't a hack that just lets it work right for my usage (which would probably be a miracle) I'll definitely share it. This is just like the number 1 thing holding me back from a Wineskin 2.0 release, which I know isn't your issue... I don't envy you really, as xquartz seemed very complicated in general to me :-) Had no idea it needed 5 window levels, I assumed it was all done on one, and the guard could be put up, then dropped back a single level and the rest done on the highest.
>>>>
>>>> Thanks though, you do a great job
>>>
>>> Thanks. Hopefully I can provide some help if you get stuck. I probably won't be on IRC much, but you can email. Below you'll find a patch which was my starting point when looking at this last. It just determines if we should be captured or released and does the capture/release.
>>>
>>> hw/xquartz/xpr/xpr.h has our window levels:
>>>
>>> #define AppleWMWindowLevelNormal 0
>>> #define AppleWMWindowLevelFloating 1
>>> #define AppleWMWindowLevelTornOff 2
>>> #define AppleWMWindowLevelDock 3
>>> #define AppleWMWindowLevelDesktop 4
>>> #define AppleWMNumWindowLevels 5
>>>
>>> static const int normal_window_levels[AppleWMNumWindowLevels+1] = {
>>> 0, 3, 4, 5, INT_MIN + 30, INT_MIN + 29,
>>> };
>>> static const int rooted_window_levels[AppleWMNumWindowLevels+1] = {
>>> 20, 21, 22, 23, 19, 18,
>>> };
>>>
>>> Our levels are different depending on rootless vs fullscreen mode and are chosen based on the menu bar's level (24), and the levels for normal (0) and floating (3) windows.
>>>
>>> Note that we actually use *6* levels rather than 5. The 6th one is for the root window. see the comment in xpr/xprAppleWM.c:
>>> // AppleWMNumWindowLevels is allowed, but is only set by the server
>>> // for the root window.
>>>
>>> <capture.patch>
>>>
>>>> On Dec 10, 2010, at 2:30 AM, Jeremy Huddleston wrote:
>>>>
>>>>>
>>>>> On Dec 9, 2010, at 23:22, doh123 wrote:
>>>>>
>>>>>> Multi Monitor fix is nice...
>>>>>
>>>>> It just fixes the mode-change regression... it doesn't add support for the extended resolution changes.
>>>>>
>>>>>> does it actually use display capturing?
>>>>>
>>>>> No. Display capturing doesn't quite work right for us. The guard window is at the highest level - 1, but we need 5 window levels ... I tried updating the window level, hiding the guard window, and other tricks with no success. I haven't given up, but it is not as simple as "just capture the display"
>>>>>
>>>>>
>>>>>> I'll try it out in the next couple of days hopefully
>>>>>>
>>>>>> On Dec 10, 2010, at 12:28 AM, Jeremy Huddleston wrote:
>>>>>>
>>>>>>> I just released the first release candidate of XQuartz 2.6.0. This is the first pre-release built for Leopard as well as SL, so please give it a whirl on Leopard to see if there are any Leopard specific issues we may have missed.
>>>>>>>
>>>>>>> There are still a couple bugs left that I'd like to address before 2.6.0 is released, but they're not worth holding up release if I don't get to them, so consider this mostly complete.
>>>>>>>
>>>>>>> The changes worth noting from 2.6.0_beta2 are:
>>>>>>>
>>>>>>> Updated freetype which should address font rendering issues introduced in 2.5.2.
>>>>>>> The mac OSX screensaver is now disabled while in fullscreen mode.
>>>>>>> Mode changing works again for multi-monitor configurations.
>>>>>>> XBell() is now exclusively NSBeep() (ie: the "use system alert" preference option is now gone)
>>>>>>> Misc stability fixes in the server
>>>>>>> libX11-1.4.0 and misc other modules
>>>>>>>
>>>>>>> For the full list of changes, see the draft release notes:
>>>>>>> http://xquartz.macosforge.org/trac/wiki/X112.6.0
>>>>>>>
>>>>>>> You can install it using automatic updates from a previous beta (or full version if you enable the beta feed) or directly:
>>>>>>> Leopard: http://static.macosforge.org/xquartz/downloads/Leopard/X11-2.6.0_rc1.dmg
>>>>>>> Snow Leopard: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.6.0_rc1.dmg
>>>>>>>
>>>>>>> At this point, I'm just waiting on the final X11R7.6 release at which point I'll pull in the rest of the updated modules and call it 2.6.0.
>>>>>>>
>>>>>>> Please test and let me know if there are any regressions.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Jeremy
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Xquartz-dev mailing list
>>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Xquartz-dev mailing list
>>>>>> Xquartz-dev at lists.macosforge.org
>>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xquartz-dev mailing list
>>>>> Xquartz-dev at lists.macosforge.org
>>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xquartz-dev mailing list
>>>> Xquartz-dev at lists.macosforge.org
>>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>>
>>>
>>> _______________________________________________
>>> Xquartz-dev mailing list
>>> Xquartz-dev at lists.macosforge.org
>>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>>
>>
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>
>
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20110123/ed9a86ac/attachment-0001.html>
More information about the Xquartz-dev
mailing list