[Xquartz-dev] configuration

[Heiko Przybyl]

On Oct 26, 2009, at 5:34 PM, Jeremy Huddleston wrote:

>
> On Oct 26, 2009, at 05:59, Heiko Przybyl wrote:
>
>> Hello all,
>>
>> I can reproduce the problem on my MacBook3,1 running 10.6.1 with  
>> Xquartz  2.4.1_alpha3 (with and without X11.bin-1.7.0.901). Doesn't  
>> matter if I use the internal trackpad or the external USB mouse. As  
>> soon as I switch away from X11
>
> How are you switching away? Any way in particular?  clicking another  
> window, the dock, cmd-tab, ... ?

Cmd+tab seems to work, but i had the feeling of it being broken before  
as well.
Returning from a non-X11 window breaks things, but only if the X11- 
window is activated by a click into the X11-part (i.e. not the title  
bar). I was able to switch between Terminal.app and X11 several times  
without the problem happening, for as long as i reactivated the X11- 
window by a click onto the title bar. A reactivation by a click into  
the X11-part breaks the input immediately..

Ok, I could reduce it a bit more: There's no need to switch away from  
X11 to a native aqua application at all. It's enough to just switch  
X11-windows. I did it the following way: Open 2 xterms. Type to them  
whatever you want, switch between them by using cmd+, or clicks to the  
title bars. That'll work as expected. But if you click into one window  
(not the title bar) it'll show the broken input symptom. I further  
noticed that the keystrokes that were entered in the "broken" window,  
will be shown after unmapping/remapping (i.e. minimize/unminimize) the  
window. So it looks like a refresh/redraw problem

If you want a specific kind of trace (be it dtruss, gdb or w/e) just  
hint me how you want it to be done.
I can try to do a screen capture to show the problem, if you need it.

>
>> the input seems to be frozen and not being restored when switching  
>> back to X11 (that even holds for the quartz title bar of the X11  
>> windows -- there's no interacting with the title bar or the three  
>> shiny buttons). But I noticed that the input can be restored if one  
>> minimizes (cmd+m) the X11 window and restores it from the Dock.
>
> That is consistent.  Input isn't "frozen" in this bug ... what is  
> happening is a client is grabbing input focus and then it doesn't  
> get released.  I'm guessing the release event somehow gets lost or  
> ignored or something.  The minimization does an unmap which results  
> in the release.

Hmm lost events? Wasn't there a change to event timers to fix some  
sort of lost events for X11-screensavers? Maybe that had more side  
effects than expected? (Just a wild guess; http://cgit.freedesktop.org/xorg/xserver/commit/?id=db568f9eabf3450d8a023597ff007df355b13ea8 
  )

>
>> Could that at all be a problem related to the WindowServer-X11- 
>> brigde instead of X11 itself?
>
> Well, the issue is possibly both.  It's from something changing  
> outside of the XQuartz DDX between 1.5 and 1.6.  Either it's a bug  
> outside of XQuartz or XQuartz needs to be updated to behave in a new  
> fashion for these new changes.

And still I'm wondering why XQuartz.app is the only app that doesn't  
minimize windows into it's dock icon (all other apps, including third  
party things, do).

Another tiny thing for your /opt-installation i encountered on X11.bin  
invocation on the terminal:
   /opt/X11/bin/font_cache: line 197: /usr/X11/bin/fc-cache: No such  
file or directory
The path to fc-cache prolly should be /opt/...


   -- Heiko