March 2015 - Xquartz-dev - lists.macosforge.org

Re: [Xquartz-dev] Xquartz-dev Digest, Vol 78, Issue 10
by René J.V. Bertin 23 Mar '15

23 Mar '15

On Monday March 23 2015 12:00:02 xquartz-dev-request(a)lists.macosforge.org wrote: > With an xterm window open and focused, simply open the Help menu in > XQuartz's menu bar. Since the Search item in that menu has a text field > that receives focus, it steals it from the xterm window. When you dismiss > the menu, the xterm window does not get focus back. I suspect that the > problem with external apps stealing focus is similar. > > Something similar happens if you bring up the About XQuartz window and then > close it. Or the Preferences window. Etc. Is that really a valid, representative example? In that case you're generating mouse events yourself that take away focus. I do have my focus set to "follow mouse", btw. That may alleviate any issues for me. R.

1 0

Intermittent loss of input focus?
by Ben Hyde 23 Mar '15

23 Mar '15

A forced upgrade means I have a new 2015 MacBook Pro, Yosemite, and XQuartz 2.7.8_beta3 (xorg-server 1.16.4) freshly installed over/under a restore from via Time Machine. Previously I was running 10.6.8 :). So. If I pop up an new Xterm and start typing in many cases a few characters in the typing cursor will transition from solid block to rectangle. Naturally this means my input is lost. A few seconds later it will transition back again. At that point I can continue typing. Sometimes when the keyboard focus departs I get a beach ball. Sometimes when it departs it never returns, but if I click in the terminal I can restore it. I can occationally get this to happen without typing. I just open the xterm and start and the black keyboard cursor and after it bit it disappears, optionally I see the beachball, and optionally it comes back after a bit. This behavior occurs dependably and repeatedly if I have work to do. I occurs less reliably if I’m trying to reproduce the behavior or record it in a screen capture. But even if I do record it it’s boring because all you see is the cursor changing. Is anybody else suffering this affliction? Or would anybody like to suggest a treatment of big stick I might hit it with? - ben ps. Emacs is hell when you have this issue!

3 3

Re: [Xquartz-dev] Intermittent loss of input focus?
by Kyle J. McKay 22 Mar '15

22 Mar '15

On March 22, 2015 01:28:33 PDT, Jeremy Huddleston Sequoia wrote: > > This has come up before. > > The issue is http://xquartz.macosforge.org/trac/ticket/58, and > there's a radar filed for the issue that is pretty much just as old. > > Note that XQuartz has no say in giving up focus. Something else is > stealing focus from us. I presume since it is just XQuartz that is > seeing this issue that there must be *something* I could do put > XQuartz in a mode that would prevent this focus loss, but I'm at a > loss to know what that is because I have no idea why the focus is > being allowed to be stolen in the first place. > > In any event, you can run the attached script (which Ken Thomases > provided to the list a couple years ago) to find out what is > stealing the focus and possibly stop it from periodically doing so > (by disabling it, deleting it, etc): > > <watch_activations.py> > > Hope that helps. > > --Jeremy Just to satisfy my curiosity, I took a look at this. I was able to duplicate it after building and running the "Mail Status Control.app" [1]. I think I understand what's happening. Let me include some logging output: 004 17:35:56.744: 'appl'/7 (kEventClassApplication/ kEventAppFrontSwitched) -psn_0_2757281 (X11.bin) pid 30108 "/Applications/Utilities/X11.app/Contents/MacOS/ X11.bin" processMode=0x000012e0 004 17:36:55.880: 'appl'/7 (kEventClassApplication/ kEventAppFrontSwitched) -psn_0_2937549 (System Events) pid 32342 "/System/Library/CoreServices/System Events.app/ Contents/MacOS/System Events" processMode=0x000016e0 (modeOnlyBackground) What's happening in this case is that 'Mail Status Control.app' is a LSUIElement=1 app and it periodically runs an AppleScript using this snippet: appleScript = [[NSAppleScript alloc] initWithContentsOfURL: scriptURL error: &errorDict]; *ae = [appleScript executeAndReturnError:&errorDict]; Now the script in question includes a bunch of stuff in a 'tell application "Mail"' block (but it only runs that if Mail.app is already running, so if you try to duplicate this using "Mail Status Control.app" you will need to make sure Mail.app is already running). For whatever reason, that causes the front switch to "System Events.app". Here's the thing though. Other applications that are frontmost when the mail check triggers do not get a switch to System Events. And, just like the bug report says, if I click on X11.app in the Dock to bring it back to the front it doesn't get them either. However, if after clicking on X11.app in the Dock to bring it forward, I then click on a different X11.app window (other than the one that became active after clicking on X11.app in the Dock), X11.app will start getting the switch to System Events at the next mail check again. So clearly, the code that activates a different X11.app window even when X11.app is already frontmost is enough to trigger the bug. As a hack, X11.app could always examine the processMode modeOnlyBackground bit of the application that's becoming frontmost and attempt to compensate (looks like it's set for both LSUIElement=1 and LSBackgroundOnly=1 apps). -Kyle [1] Downloaded source from archive.org and built it. See <https://web.archive.org/web/20070818064601/http://xoomer.alice.it/czk/mac/ >.

1 0

Re: [Xquartz-dev] Xquartz-dev Digest, Vol 78, Issue 9
by René J.V. Bertin 22 Mar '15

22 Mar '15

On Sunday March 22 2015 12:00:02 xquartz-dev-request(a)lists.macosforge.org wrote: > I presume since it is just XQuartz that is seeing this issue that there must > be *something* I could do put XQuartz in a mode that would prevent this > focus loss, but I'm at a loss to know what that is because I have no idea > why the focus is being allowed to be stolen in the first place. Let's see how wide open the door is I'm about to kick in :) I think that what happens is that some application starts in a way that it becomes the front application (is it (still) possible to launch an app through LaunchServices without that happening?). It, or the OS returns focus to the application that had it (which is something that could be done so quickly that there's very little chance anything gets lost). Normally, someone would know what window was the key window in that application, but X11 must be different. Either no window gets focus, or the wrong window. Myself I've never seen this happening, and I spend a lot of time in XTerms. I wonder if the reason is that I never use QuartzWM but something more traditional (recently migrated from ctwm 3.5 to xfmw4 4.11.2). If that's the case though, my explanation above cannot hold, or at least I don't see how. I can't imagine that a legacy WM like ctwm is prepared to restore focus after the X11 server lost and regained focus, it's author likely never dreamt such a thing would even be possible :) I *am* seeing another undesirable behaviour since updating from OS X 10.6.8 to 10.9 . I'm running rooted, and up to 10.6 I could bring 1 xterm to the front and have the others hidden behind native windows. Very practical if you're keeping a native browser window open for reference, for instance. This is still possible, but periodically all X windows will pop to the foreground. The reverse also happens. It's as if certain events cause the application belonging to the key window to be brought to the foreground - and that could actually be the same event in which others lose their X11 input focus. Hope this helps in some way... R.

2 1

Booting straight to xquartz
by Jonny Bowes 16 Mar '15

16 Mar '15

HI Guys. I would like my Mac to boot straight to xquartz instead of having to boot the osx desktop first. Is this at all possible :? I'm currently running mavericks but have the choice between mavericks, snow leopard and leopard. Jonnybowes...

2 1

Problems with xorg-server-devel @1.17.0_0 and xorg-server-devel @1.17.1_0 on PPC Mac OS X 10.5.8, Leopard
by Peter Dyballa 15 Mar '15

15 Mar '15

Hello Jeremy and others! When I today booted into Leopard and launched X11, it was the MacPorts package xorg-server-devel @1.17.1_0 that provided the X server. The clients looked different, instead of brown the window decoration was green. And gkrellm and GNU Emacs 23.4 died. The mouse cursor was invisible although X11 had the focus and therefore was easy to quit. I then activated xorg-server-devel @1.17.0_0. With the same results. With xorg-server-devel @1.16.99.1_2 everything is OK. I have crash logs: -rw------- 1 pete admin 21182 14. Feb 19:02 emacs-23.4_2015-02-14-190207_Leopard.crash -rw------- 1 pete admin 23320 14. Feb 19:01 gkrellm_2015-02-14-190103_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:56 emacs-23.4_2015-02-14-185620_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:55 gkrellm_2015-02-14-185514_Leopard.crash -rw------- 1 pete admin 21180 14. Feb 18:51 emacs-23.4_2015-02-14-185108_Leopard.crash -rw------- 1 pete admin 23318 14. Feb 18:51 gkrellm_2015-02-14-185022_Leopard.crash -- Greetings Pete The best way to accelerate a PC is 9.8 m/s²

5 19

XQuartz 2.7.8_beta3 problems
by Jack Howarth 14 Mar '15

14 Mar '15

The XQuartz 2.7.8_beta3 has been very cantankerous with regard to autolaunching when executing X windows binaries in the Terminal application. Is an improved beta4 seed expected soon? I have found that the autolaunching doesn't occur after logging out or even rebooting. Manually launching the X11 app doesn't help as well. Most frustrating is that the beta3 release will start to autolaunch without any obvious reason but will also stop autolaunching again after system software updates to the public 10.0.3 seed. Jack ps I am also very confused by the comments at... Default X11 Server If this is your first time installing XQuartz, you may wish to logout and log back in. This will update your DISPLAY environment variable to point to XQuartz.app rather than X11.app. If you would prefer to keep using X11.app as your default server (you can still launch XQuartz.app manually), you'll want to disable /Library/LaunchAgents/org.macosforge.xquartz.startx.plist using launchctl(1). at http://xquartz.macosforge.org/trac/wiki/X112.7.8. In particular, on Yosemite, I find that the Finder shows X11 in /Applications/Utilities but the terminal window shows Xquartz.app and no X11.app. I have never heard of that behavior where there is a complete rupture between the Application name displayed by the Finder window and that shown in the terminal window with 'ls'.

3 2

XQuartz 2.7.8_beta2
by Jeremy Huddleston Sequoia 05 Mar '15

05 Mar '15

XQuartz 2.7.8_beta2 is available for download. You can see http://xquartz.macosforge.org/trac/wiki/X112.7.8 for a full set of changes, but most noteworth ones are: 1) xauth now correctly parses the Yosemite launchd $DISPLAY socket path 2) libGL has been updated to Mesa 10.4.4 3) Various exploits were fixed in xorg-server, freetype, and libpng 4) A bug preventing automatic updates in some cases has been fixed For #4, note that the automatic update bug is fixed when updating *from* 2.7.8_beta2 and later. If you are on an effected version (I think 2.7.7_rc1 throuch 2.7.8_beta1), you may need to manually download the installer from the URL above to update. If you have any GLX intensive applications, please report back on how libGL is now. Thanks, Jeremy

4 3