I've just finished building and uploading 1.4.2-apple9. Install 2.3.1_beta2, then drop in this binary update. See http://xquartz.macosforge.org/trac/wiki/Releases#xorg-server for details. Here's the link: http://static.macosforge.org/xquartz/downloads/X11-1.4.2-apple9.bz2 This release addresses the following over 2.3.1_beta2: - Capslock "press ignored" bug is fixed. - modifier keys used to emulate button2/3 are not sent with the click/release - the list of modifiers allowed in the fake_button{2,3} defaults has been expanded: fn,{l,r,}{command,alt,shift,control} So if you want to be able to emulate command-button3 you can change fake_button3 to be fn and hold fn+command+button1. Or you can set it to lcommand and hold lcommand+rcommand+button1 ... hopefully this added flexibility will solve everyone's needs. Please try it out if you've been having modifier key or 3button emulation issues. Thanks, Jeremy
The 2.3.1_beta2 + X11-1.4.2-apple9 seems to work fine for me. Cut and paste with emulated buttons works fine for me between X11 windows and between X11 windows and aqua windows. The xterm menus are all accessible. And with a 3-button mouse plugged in, that also continues working as expected. I have not yet had a chance to play around with changing the fake_button{2,3} settings, but at least with the defaults, this looks to be a winner. Thank you Jeremy!!!!!! Merle On Aug 15, 2008, at 5:26 PM, Jeremy Huddleston wrote:
I've just finished building and uploading 1.4.2-apple9. Install 2.3.1_beta2, then drop in this binary update. See http://xquartz.macosforge.org/trac/wiki/Releases#xorg-server for details.
Here's the link: http://static.macosforge.org/xquartz/downloads/X11-1.4.2-apple9.bz2
This release addresses the following over 2.3.1_beta2: - Capslock "press ignored" bug is fixed. - modifier keys used to emulate button2/3 are not sent with the click/release - the list of modifiers allowed in the fake_button{2,3} defaults has been expanded: fn,{l,r,}{command,alt,shift,control}
So if you want to be able to emulate command-button3 you can change fake_button3 to be fn and hold fn+command+button1. Or you can set it to lcommand and hold lcommand+rcommand+button1 ... hopefully this added flexibility will solve everyone's needs.
Please try it out if you've been having modifier key or 3button emulation issues.
Thanks, Jeremy_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
Ok, then if I don't hear about any issues with 2.3.1_beta2 + this 1.4.2-apple9 drop-in, I'm going to put together a rc and announce it to the users list probably on Monday... so please test it out and let me know if there's anything serious with it (regressions over 2.2.3 or 2.3.0 being or primary concern). Thanks, Jeremy On Aug 16, 2008, at 07:09, Merle Reinhart wrote:
The 2.3.1_beta2 + X11-1.4.2-apple9 seems to work fine for me. Cut and paste with emulated buttons works fine for me between X11 windows and between X11 windows and aqua windows. The xterm menus are all accessible. And with a 3-button mouse plugged in, that also continues working as expected.
I have not yet had a chance to play around with changing the fake_button{2,3} settings, but at least with the defaults, this looks to be a winner.
Thank you Jeremy!!!!!!
Merle
On Aug 15, 2008, at 5:26 PM, Jeremy Huddleston wrote:
I've just finished building and uploading 1.4.2-apple9. Install 2.3.1_beta2, then drop in this binary update. See http://xquartz.macosforge.org/trac/wiki/Releases#xorg-server for details.
Here's the link: http://static.macosforge.org/xquartz/downloads/X11-1.4.2-apple9.bz2
This release addresses the following over 2.3.1_beta2: - Capslock "press ignored" bug is fixed. - modifier keys used to emulate button2/3 are not sent with the click/release - the list of modifiers allowed in the fake_button{2,3} defaults has been expanded: fn,{l,r,}{command,alt,shift,control}
So if you want to be able to emulate command-button3 you can change fake_button3 to be fn and hold fn+command+button1. Or you can set it to lcommand and hold lcommand+rcommand+button1 ... hopefully this added flexibility will solve everyone's needs.
Please try it out if you've been having modifier key or 3button emulation issues.
Thanks, Jeremy_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sat, Aug 16, 2008 at 11:40 AM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
so please test it out and let me know if there's anything serious with it (regressions over 2.2.3 or 2.3.0 being or primary concern).
One thing I've recently noticed with the 2.3.x series so far is that if you start an xterm from Terminal.app (without X11.app running), a white box appears in the top left hand corner and then a few seconds later the window border and title bar is displayed. All subsequent xterms, or if X11.app is already running, start up with the border and window title. So far I've only noticed this with small applications like xterm or xclock. Its a minor issue but this wasn't present in version prior to 2.3.0. Cheers Adam
Yeah, this is a well-known race condition between xinitrc (which starts the window manager) and the first client being started. It was present in earlier releases as well, but the startup code path was optimized in 2.3.0 (and further in 2.3.1), so now the launchd socket is actually "winning"... I'm a few steps away from having this solved for good, but for now, I'm still using a sleep() to delay opening the first X11 connection from the launchd socket. --Jeremy On Aug 16, 2008, at 10:28, Adam Mercer wrote:
On Sat, Aug 16, 2008 at 11:40 AM, Jeremy Huddleston <jeremyhu@apple.com
wrote: so please test it out and let me know if there's anything serious with it (regressions over 2.2.3 or 2.3.0 being or primary concern).
One thing I've recently noticed with the 2.3.x series so far is that if you start an xterm from Terminal.app (without X11.app running), a white box appears in the top left hand corner and then a few seconds later the window border and title bar is displayed. All subsequent xterms, or if X11.app is already running, start up with the border and window title. So far I've only noticed this with small applications like xterm or xclock. Its a minor issue but this wasn't present in version prior to 2.3.0.
Cheers
Adam _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Sun, Aug 17, 2008 at 1:13 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
Yeah, this is a well-known race condition between xinitrc (which starts the window manager) and the first client being started. It was present in earlier releases as well, but the startup code path was optimized in 2.3.0 (and further in 2.3.1), so now the launchd socket is actually "winning"... I'm a few steps away from having this solved for good, but for now, I'm still using a sleep() to delay opening the first X11 connection from the launchd socket.
Great, thanks for the update. Cheers Adam
participants (4)
-
Adam Mercer
-
Jeremy Huddleston
-
Martin Costabel
-
Merle Reinhart