#1) Yes, the spin from beta2 is fixed. http://static.macosforge.org/xquartz/downloads/X11-2.3.2_beta3.pkg The main changes from beta 2 are: Many GLX updates... support for multisampling is now present, better listing of supported visuals pbproxy updates... PICT support, workaround nedit/eterm bugs The menu bar is no longer mapped to the X11 screen (so other WMs won't "hide under" the menu bar) Fixed some threading related issues in mieq (possible crash with a full event queue fixed) quartz-wm now supports window gravity libXplugin is now more thread safe (the "spin" bug from beta2) X11.app should now exit if you are using a WM other than quartz-wm and you exit the WM Added an option to show the menu bar when your mouse approaches it in fullscreen mode. Please let me know if there are any major show-stopping issues. I expect that this will be fairly close to what becomes rc1 (the main difference being that I intend to make xpbproxy be a server thread for the release-candidate rather than a separate process). --Jeremy
This is somewhat speculative because I don't have any real evidence. I live in a world of xterms - where they are invoked like xterm -name ${sys} -vb -sb -sl 5000 -e ssh -Y ${port} ${remote}& I've noticed recently (and perhaps before) that if a connection to one remote machine hangs - often because the network down the line is snipped in some way and is reconfiguring.. then all the X processes hang. I don't think the X11 server is hanging - because I don't get the Not responding message in the Force Quit dialog. It's probably hard to simulate this - I suspect that the TCP connection is perhaps maintained by the Linux code in my local broadband router. Just wondered if my diagnosis makes sense and is likely. If so, I'll try and get some dumps next time it happens. Thanks for beta3!!!
On Nov 11, 2008, at 11:13, Peter Collinson wrote:
This is somewhat speculative because I don't have any real evidence.
I live in a world of xterms - where they are invoked like
xterm -name ${sys} -vb -sb -sl 5000 -e ssh -Y ${port} ${remote}&
I've noticed recently (and perhaps before) that if a connection to one remote machine hangs - often because the network down the line is snipped in some way and is reconfiguring.. then all the X processes hang. I don't think the X11 server is hanging - because I don't get the Not responding message in the Force Quit dialog.
That is not really possible... they're likely independent events... or even more likely, maybe you're assuming that your connection to the remote machine is hanging when in reality it's X11.app hanging... If you saw this in beta2, it's probably the spin bug that is fixed in beta3 ... In the future, when something like that does happen, you should report the bug and include the crash report / stack trace.
On Nov 11, 2008, at 11:13 AM, Peter Collinson wrote:
I've noticed recently (and perhaps before) that if a connection to one remote machine hangs - often because the network down the line is snipped in some way and is reconfiguring.. then all the X processes hang. I don't think the X11 server is hanging - because I don't get the Not responding message in the Force Quit dialog.
Erm. Really? That sounds very odd. What happens when you sample one of the hanging X clients? Where is it hanging? - Jordan
Hi Jeremy! What about the localisation of at least the new pasteboard screen of the X11 preferences (see http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080922/6859a... Any help needed? I would offer my help for german language translation. Sierk -- Sierk Bornemann email: sierkb@gmx.de WWW: http://sierkbornemann.de/
On Nov 11, 2008, at 11:17, Sierk Bornemann wrote:
Hi Jeremy!
What about the localisation of at least the new pasteboard screen of the X11 preferences (see http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20080922/6859a... Any help needed?
Yeah, I just do English.lproj. The Apple localization team takes care of Apple's localizations, and we got permission to open source that localization data. The down side is that we need to wait for them to update the localizations before I can put them in xorg-server's git, so English.lproj is really the only one with all the latest and greatest... so you can either sit tight and wait for them to get around to it or send me some patches =)
I would offer my help for german language translation.
Sure... patches are welcome =) --Jeremy
Am 11.11.2008 um 20:29 schrieb Jeremy Huddleston:
I would offer my help for german language translation.
Sure... patches are welcome =)
What file(s) and/or strings do have to be localized and at what particular area of the files has this to be done? I think, you mean http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/bundle/Resources/En... and http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/bundle/Resources/Ge... ? Is it possible to contribute s.th. without installing the whole git stuff? I will try to look at it and play a little bit around. If Ifeel well, I will give it a try, otherwise we have to wait for Apple's official translation. OK? Sierk
On Nov 11, 2008, at 1:51 PM, Jeremy Huddleston wrote:
Please let me know if there are any major show-stopping issues.
In fullscreen mode, switching is extremely buggy. I'm seeing artifacts (e.g. a white box where the KDE kicker menu is) when switching back and forth using cmd-option-a for example. Clicking on these artifacts from the non-X11 side switches back to X11. I get this with both the Apple menu option on and off. Here is the steps I need to recreate this problem. Start X11 with fullscreen enabled. Start "kicker" (using KDE v3.5.8 from fink). Press cmd-option-a a few times to switch back and forth. White boxes appear on the non-X11 side. Cheers, Jamie
Yeah, that's because of some override-redirect window, and I'm not sure the exact cause/fix... but it's a known issue. On Nov 11, 2008, at 13:36, Jamie Kennea wrote:
On Nov 11, 2008, at 1:51 PM, Jeremy Huddleston wrote:
Please let me know if there are any major show-stopping issues.
In fullscreen mode, switching is extremely buggy. I'm seeing artifacts (e.g. a white box where the KDE kicker menu is) when switching back and forth using cmd-option-a for example. Clicking on these artifacts from the non-X11 side switches back to X11. I get this with both the Apple menu option on and off.
Here is the steps I need to recreate this problem. Start X11 with fullscreen enabled. Start "kicker" (using KDE v3.5.8 from fink). Press cmd-option-a a few times to switch back and forth. White boxes appear on the non-X11 side.
Cheers,
Jamie _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
participants (5)
-
Jamie Kennea
-
Jeremy Huddleston
-
Jordan K. Hubbard
-
Peter Collinson
-
Sierk Bornemann