[Xquartz-dev] Cmd-tab switch behavior and Spaces [was: 2.3.2_beta2]

[Brian Bender]

Hi Jeremy,

I couldn't find a ticket specifically for this issue; do you know of
one that includes it, or would you like me to create a new one? I
verified that it's still broken in 2.3.3_rc2 if you uncheck that
Spaces setting.

Thanks,

 - Brian

2008/11/11 Jeremy Huddleston jeremyhu-at-apple.com
|Xquartz-dev/personal| <...>
>
> Yeah, that won't be fixed until maybe 2.3.3...
>
>
> On Nov 11, 2008, at 11:12, Brian Bender wrote:
>
>> Hi Jeremy,
>>
>> I assume this one was too ugly (or just too low priority) for 2.3.2_beta3?
>> (either way, FYI, it's still wonky <g>)
>>
>> Glad the spin/hang is fixed, though. Thanks!
>>
>> - Brian
>>
>> 2008/10/27 Jeremy Huddleston jeremyhu-at-berkeley.edu
>> |Xquartz-dev/personal| <...>:
>>>
>>> Yes.  In spaces preference pane, there's a checkbox for "When switching to
>>> an application, switch to a space with open windows for that application"
>>> ... we now support that option... and it looks like a side effect is that
>>> it's not raising the windows in the current space if there are any... so...
>>> yick... this is gonna get ugly I think...
>>>
>>> --Jeremy
>>>
>>> On Oct 27, 2008, at 12:37, Brian Bender wrote:
>>>
>>>> Hi Jeremy,
>>>>
>>>> I think there's a regression in this release with cmd-tab not bringing
>>>> X11 windows to the top any more. I reverted back to  2.3.2_beta1 +
>>>> X11-1.4.2-apple20 + xpbproxy-20081015 to verify, and it works OK. If I
>>>> reinstall 2.3.2_beta2, cmd-tab switching to X11 doesn't bring windows
>>>> to the top of the z-order. They gain focus, but they stay behind other
>>>> windows.
>>>>
>>>> Were there any updates after X11-1.4.2-apple20 (but before
>>>> 2.3.2_beta2) that I'm missing that would affect this?
>>>>
>>>> - Brian