December 2008 - Xquartz-dev - lists.macosforge.org

Re: [Xquartz-dev] 2.3.2_rc5 quitting and restarting
by John Koren 31 Dec '08

31 Dec '08

Since 2.3.2_rc4 I am facing a problem with quitting X11.app and restarting it again. Two things happen depending on how long I wait before the restart of X11.app: 1) When I restart shortly after quitting, rxvt launched from xinitrc starts up but the quartz-wm does not seem to complete drawing the entire frame, just the white background. After that X11 stall permanently. 2) If I wait longer after to restart, rxvt only flashes on the desktop and disappears immediately, and again X11 stalls. After the stall, if I try to kill the X11 related processes, the X11 keeps restarting on its own and the only way I can get rid of it is to reboot the system. I wonder if other are facing this issue. One more thing. I use tcsh, nevertheless before 2.3.2_rc4 I had no problem inheriting the correct environment. Now, after 2.3.2_rc4, I had to put "cd ~" into my .xinitrc otherwise rxvt launched by xinitrc would start at the root level "/" and not my home directory. -John My system: X11: 2.3.2_rc5 Mac OS 10.5.6 Powerbook G4 Aluminum I normally start my X11.app by clicking its icon in the Dock.

5 20

Re: [Xquartz-dev] 2.3.2_rc5 quitting and restarting
by Zulli, Louis P 31 Dec '08

31 Dec '08

This new binary seems to have corrected the problem. As a test, I put an xeyes in my .xinitrc xsetroot -mod 2 2 -bg Red -fg Orange xeyes & . /usr/X11/lib/X11/xinit/xinitrc >& ${HOME}/xinitrc-debug.txt Before installing your new X11.bin, I was having the same problem (I believe) that John reported. I installed the new binary and invoked xterm in Terminal.app. No hang. The only issue is that the xeyes window appears briefly in front of my Desktop before the root window appears. But I ended up with xeyes and xterm on my root screen, and no more hang/non-responsive X11. Louis ----- Original Message ----- From: "Jeremy Huddleston" <jeremyhu(a)apple.com> To: "Developer talk about Xquartz" <xquartz-dev(a)lists.macosforge.org> Sent: Wednesday, December 31, 2008 5:16:43 PM GMT -05:00 US/Canada Eastern Subject: Re: [Xquartz-dev] 2.3.2_rc5 quitting and restarting Hi John, Sorry for the confusion. I think I have a fix for you. Please try this binary: http://people.freedesktop.org/~jeremyhu/X11.bin-20081231.bz2

1 0

Re: [Xquartz-dev] 2.3.2_rc5 quitting and restarting
by Peter Dyballa 31 Dec '08

31 Dec '08

Am 31.12.2008 um 16:00 schrieb Martin Costabel: > "Don't Run Any X Clients From ~/.xinitrc, or you are in deep trouble". What is the difference between launching X clients from ~/.xinitrc and launching them from /usr/X11/lib/X11/xinit/xinitrc? And why is there a difference? Is it something good for? -- Greetings Pete Computers are good at following instructions, but not at reading your mind. - D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

3 3

2.3.2_rc5 no crazy cpu
by Christof Wolf 31 Dec '08

31 Dec '08

Hi Jeremy, I can't believe it, I just installed rc5 and everything works - no cpu goes crazy - I can even use klipper and all pasteboard options - no problem :-) thanks :-) ciao christof -- public key www.hfph.mwn.de/~chwolf/chwolf.asc Please respect my privacy and do not make my contact information available to third parties.

1 0

pixman for 2.3.2_rc5
by Zulli, Louis P 30 Dec '08

30 Dec '08

rc5 provides the latest cairo, but its version of pixman is 0.12.0 (while the latest is 0.13.2). ----- Original Message ----- From: "Jeremy Huddleston" <jeremyhu(a)apple.com> To: "Developer talk about Xquartz" <xquartz-dev(a)lists.macosforge.org>, "X11 Mailing List" <x11-users(a)lists.apple.com> Sent: Tuesday, December 30, 2008 12:17:46 AM GMT -05:00 US/Canada Eastern Subject: [Xquartz-dev] 2.3.2_rc5 Ok, you know the deal. Just like the last two rcs, I'm *SURE* this will be the last one before the release... There were just too many changes since rc4 to justify releasing without another rc, so here we go. http://static.macosforge.org/xquartz/downloads/X11-2.3.2_rc5.dmg Changes since 2.3.1: http://xquartz.macosforge.org/trac/wiki/X112.3.2 Changes since 2.3.2_rc4: mkfontscale 1.0.6 -- support for bzip2 compressed fonts libXfont 1.3.4 -- support for bzip2 compressed fonts cairo 1.8.6 -- misc bugfixes (mainly a matrix inversion crash fix)

3 2

2.3.2_rc4
by Jeremy Huddleston 30 Dec '08

30 Dec '08

I know I said this with 2.3.2_rc3, but this time I really mean it. I expect 2.3.2_rc4 to be our last rc before the final release, so please give it a good pounding. http://static.macosforge.org/xquartz/downloads/X11-2.3.2_rc4.dmg Changes since 2.3.2_rc4 include: * X.org updates: * xextproto-7.0.4 * xcbproto-1.3.0 * util-macros-1.2.1 * inputproto-1.5.0 * xcb-util-0.3.2 * libXi-1.2.0 * quartz-wm updates: * Fixed zoom button misbehavior * Xquartz * Hopefully fixed the white rectangle issue * added a 'dpi' option for that you can set to choose what resolution the X server uses * Changed how X11 applications inherit the shell environment. X11.app now starts from a login shell and passes this off to its children rather than starting each child from a login shell * If you are using tcsh, you may want to customize /Applications/ Utilities/X11.app/Contents/MacOS/X11 (it's a shell script) * libGL * Added a workaround for PyMol running in mono mode while stereo is available --Jeremy

12 113

2.3.2_rc5
by Jeremy Huddleston 30 Dec '08

30 Dec '08

Ok, you know the deal. Just like the last two rcs, I'm *SURE* this will be the last one before the release... There were just too many changes since rc4 to justify releasing without another rc, so here we go. http://static.macosforge.org/xquartz/downloads/X11-2.3.2_rc5.dmg Changes since 2.3.1: http://xquartz.macosforge.org/trac/wiki/X112.3.2 Changes since 2.3.2_rc4: mkfontscale 1.0.6 -- support for bzip2 compressed fonts libXfont 1.3.4 -- support for bzip2 compressed fonts cairo 1.8.6 -- misc bugfixes (mainly a matrix inversion crash fix) server fixes: fixed the crash and hang that were reported after rc4 updated Xquartz man page with fullscreen defaults options re-enabled rlAccel for faster 2D until we get an EXA driver Don't pass cmd-opt-a to the X11 client when using it to toggle fullscreen Fixed various fullscreen related rendering & state issues Workaround the VNC modifier key bug Better fix for stuck keys (release all keys when we leave X11.app) Updated X11 shell startup script to work better with tcsh and others

1 0

Re: [Xquartz-dev] xorg-server on Macports (works with Tiger)
by Peter Dyballa 30 Dec '08

30 Dec '08

Am 29.12.2008 um 11:42 schrieb Jeremy Huddleston: >> The ``??? stands for an apple. Is there no improvement for neither >> the list software nor Mail to handle UTF-8 or similiar encodings? > > I'm using Mail.app on Leopard, and I saw the ? in your previous > mail. Additionally, it was retained when I hit reply to that mail. > Is it maybe some mail filtering on your mail server? Unlikely! I can send these characters to other lists (TeX, Emacs related). And I can also send them to other accounts via the same eMail services provider without loss of information. > >> The white rectangles did not reappear, and either the apple menu >> bar. When the X11 clients are visible, achieved by clicking at the >> X11 icon in dock, the apple menu bar is invisible. When I pick a >> Quartz application the X clients become invisible and the apple menu >> bar appears. > > Right, that's how it's supposed to be for fullscreen What I described is when I toggled full-screen mode off in the menu. BTW, the apple menu bar returned ... Meanwhile X11 and Quartz clients can coexist on the same desktop as with original Apple X11. Although the blackbox WM's dock is still missing ... > >> In this state only Desktop Manager "feels" the mouse cursor and >> appears. > > I don't know what you mean by this... Information about the position of the cursor is leaking off the full- screen X11. This information does not trigger Dock to appear but Desktop Manager receives it and appears. > >> When I switch off full-screen mode in the preference pane, blackbox >> WM's "dock" never appears, > > That's probably because it is being rendered offscreen because the new > X11screen is a few pixels shorter now (because of the lack of the menu > bar). Blackbox WM's dock is at the bottom on its left side. It was visible before I toggled full-screen. It is visible when I don't have full- screen set in X11 preferences. -- Greetings Pete Schön zu können, wenn man muss. – Always Ultra

2 1

Re: [Xquartz-dev] xorg-server on Macports (works with Tiger)
by Peter Dyballa 29 Dec '08

29 Dec '08

Jeremy, there is a problem now. It came up when I expanded font path to use font directories in Fink. Actually these fonts are just sym-links to fonts in the usual Fonts directories in Mac OS X. The Fink packages check whether the font files are flat or keep the font in a ressource fork. In the latter case fondu fetches it from there. The usual fonts.dir and fonts.scale files exist, but not encodings.dir or fonts.list. The error messages are: FreeType: couldn't find encoding 'ksc5601.1987-0' for '/sw/lib/X11/ fonts/applettf/Gulim.ttf' FreeType: couldn't find encoding 'jisx0208.1983-0' for '/sw/lib/X11/ fonts/applettf/Osaka.ttf' BScreen::setCurrentStyle(): couldn't load default font. The encodings exist, for example in /usr/X11/lib/X11/fonts/encodings/large/ksc5601.1987-0.enc.gz /usr/X11/lib/X11/fonts/encodings/large/ksc5601.1992-3.enc.gz /usr/X11R6/lib/X11/fonts/encodings/large/ksc5601.1987-0.enc.gz /usr/X11R6/lib/X11/fonts/encodings/large/ksc5601.1992-3.enc.gz /usr/X11/lib/X11/fonts/encodings/large/jisx0208.1990-0.enc.gz /usr/X11R6/lib/X11/fonts/encodings/large/jisx0208.1990-0.enc.gz -- Greetings Pete War springs from unseen and generally insignificant causes. – Anonymous

1 0

Full-screen vs. Spaces
by Zulli, Louis P 29 Dec '08

29 Dec '08

I've noticed the following behavior; not sure what "standard" behavior should be. I use three Spaces, 1--2--3. With X11 set for full-screen mode but not open, I start xeyes from Terminal.app. (For me, Terminal.app windows open in Space 3 by default.) This starts X11, and I see an xeyes window on my root window. This xeyes window inherits a "binding" to Space 3 from Terminal.app. (It's "bound" to the Space of the Terminal.app that invoked it.) By "bound to" I mean the following: I drag the xeyes window off the left edge of my root screen and Spaces switches to Space 2. I see my Desktop but no Apple menu-bar; xeyes is still active. If I click on that Desktop, the xeyes window vanishes and I'm in Space 2. If I activate X11 by clicking on its dock icon, I get the xeyes window on the root window again. This xeyes window is still bound to Space 2, and can now be dragged off either the left edge or the right edge of the root screen. Anyway, I guess I was surprised that I could do this. Perhaps it's only me, but I like to think of that X11 root screen as being "isolated" from the OS X environment, so that it should require a "cmd-opt-a" to escape from it. Maybe we need a preference for X11 that "disables" Spaces from acting from the root window? I guess the larger issue is: How should X11 fullscreen and Spaces interact? ----- Original Message ----- From: "Jeremy Huddleston" <jeremyhu(a)apple.com> To: "Developer talk about Xquartz" <xquartz-dev(a)lists.macosforge.org> Sent: Sunday, December 28, 2008 11:13:25 PM GMT -05:00 US/Canada Eastern Subject: Re: [Xquartz-dev] 2.3.2-rc4 full screen oddities On Dec 28, 2008, at 16:27, Viv Kendon wrote: >>>> Well, you'd have to switch to space 6... >>> Exactly...only once I'm in full screen I can't find a way to do >>> that: is there something I'm missing? >> >> I think the only way is the menubar control. In System Preferences- >> >Spaces, click the option to add a control to the menu bar... > > I already have that. In X11 preferences I checked the auto-show > menu-bar in full screen mode box (I didn't do that in my previous > testing). And now I can get to different screens while in full > screen mode, with a brief flash back into Aqua on the way. Have you tried: defaults write org.x.X11 fullscreen_hotkeys -boolean YES >>> If I go to screen 6 first then cmd-opt-a into full screen, well, >>> things just get worse, with the effects mentioned below. In the >>> Spaces preferences I have unchecked the option to have Spaces >>> switch to a screen with active windows when selecting an app, but >>> this sort of switching still happens, >> >> Are you using 2.3.1 or 2.3.2_rc4? 2.3.2_rc4 should support that >> spaces checkbox. > > I meant in the Expose+Spaces preferences, at the bottom, the option > to have Spaces switch to a Space with open windows for an > application if you select that application. I have that unchecked, > I don't want Spaces to do that. But it still does quite of lot of > that sort of switching between Spaces when I didn't ask it to. > Especially around X11 windows. For example... Yeah, that's actually hard to do right with Fullscreen X11 since with fullscreen, we need to "unhide" the windows... and "unhiding" the windows actually causes us to switch to that Desktop since it's different than just activating the Application. I'm not really sure that we can support that in a trivial manner (and I'm not sure a complicated solution is really worth the cost of implementation) <snip/> > I even managed at one point to get both the Finder menu bar and the > X11 menu bar superimposed, but I don't have a reliable way to > reproduce that (yet). And I just lost focus from X11 entirely while > typing This has been reported before... and actually, I've seen it happen with applications other than X11, (I've lost focus from Mail.app and Terminal.app as well while typing) <snip/> > Another reliable way to get out of full-screen using the menu bar > only is to click on the menu bar to drop focus from the X11 window, > run the mouse along to the Spaces control so the drop-down appears, > then, without selecting anything, run the mouse back to the left so > the drop-down goes away. That lands you back in Aqua-land but with > X11 still having focus. Can you get back to "X11-land" with a cmd-opt-a there? > I think I'm going to stop testing with quartz-wm and set up full > screen with a different window manager. I don't think how X11 full > screen works with Spaces is a high priority. But I do care a lot > about the focus stealing and would really like that fixed so it > doesn't happen except for drastic events like system shutdown. It > is much more intrusive when working in full-screen, especially when > it flips you back to Aqua without warning. Yeah, I agree with you on that, and I'll buy a case of beer for anyone who figures out that bug or comes up with the reproducible test case that leads to that bug being squashed once and for all. >>>>> (How did I get into this state in the first place? well, I was >>>>> trying to test the cmd-opt-a thing in another app, and >>>>> RetroOffice (X11 build of NeoOffice) was open on Space 6...it's >>>>> an app bundle so it is natural to start it in a different space. >>>>> and yes, it does react to cmd-opt-a, by doing "select all".) >>>> Well if it's an X11 application with an app bundle... then it's >>>> either got its own X11 server or its using ours... which is the >>>> case? >>> It uses xquartz, it doesn't bundle its own: >>> http://neowiki.neooffice.org/index.php/RetroOffice >> >> Ans meta-alt-a is a key-sequence in RetroOffice for select-all? > > Both ctl-a and cmd-a appear to do select all. I think RetroOffice > has some Aqua key bindings as well as traditional X11 key bindings. Right, but in X11-land, OSX's cmd is mapped to X11's meta... but as you said, it's not getting this key sequence any more, so this issue is really moot now. >>>>> Finally, something also appears to have changed with the cut and >>>>> paste in relation to RetroOffice, I can't find a combination of >>>>> pasteboard options that allows the ctr-c and ctl-v that should >>>>> work within the app to function properly. >>>> How so? >>> ctl-c on a selection followed by ctl-v pastes something previously >>> copied from elsewhere in X11 land, or whatever cmd-c last copied. >>> I have the X11 preferences window open and the only pasteboard >>> option I have checked is "enable syncing. So RetroOffice is not >>> copying (or cutting) into the buffer it then pastes from. But >>> I'll have to get back to you after I've had a chance to revert to >>> the previous RetroOffice version and test in a more vanilla >>> account, log out, reboot, etc., etc.. >> >> Well, file this bug with Retrooffice then. If all you have >> selected is the 'enable syncing' option and no sub option, that's >> the same as it being completely disabled =/ > > RetroOffice doesn't do bugs, it only exists for debugging > NeoOffice. I'm testing with it because I can't test at work using > the Ooo on linux I first had cut+paste problems with, until we are > back in the New Year on 5th Jan. I'll come back on this one once > I've reverted to the previous RetroOffice version...it may be it has > picked up some NeoOffice code that interacts with the Aqua > Pasteboard independently of X11, because cmd-v works to paste in > it...hmmm. Oh, yeah... interesting point. It's probably using NSPasteboard directly since it's NeoOffice under the hood. _______________________________________________ Xquartz-dev mailing list Xquartz-dev(a)lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

1 0