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

X11 2.3.1 and pgplot not redrawing
by Jamie Kennea 19 Sep '08

19 Sep '08

Hi, I have found an issue with X11 2.3.1 and the pgplot graphing library, which is commonly used by Astronomers. The issue I have is the following, utilizing the "qdp" (Quick and Dirty Plotter) tool as an example. Launching qdp with a sample file works fine. qdp test.qdp To produce plot, please enter PGPLOT file/type: /xs PLT> I get a line plot as I would expected (test.qdp consists of 2 columns of numbers). Now when I try to modify the plot on the qdp command line by, for example the command "ma on" (switch from light to point plotting), nothing happens. In fact all changes to I attempt to make to the plot make no difference, the plot in the X11 window remains static. If I use the "hardcopy" command to create a postscript version of the plot however, the PS version has all the changes applied. I believe that something in X11 2.3.1 has stopped the X11 PGPLOT window from being refreshed/replotted. As far as I know this problem has been introduced somewhere between 2.3.1rc5 and 2.3.1. I've confirmed this behaviour on 2 machines running 2.3.1, including running pgplot from a linux box to a Mac via ssh forwarding, to the same effect. I'll submit a bug. Thanks, Jamie

2 3

rdesktop crashing with 2.3.1 release
by Brian Bender 17 Sep '08

17 Sep '08

Hi Jeremy, I'm seeing repeated crashes running rdesktop against X11 2.3.1 (on 10.5.5). It's usually triggered when the server tries to put up the selection box asking which session I want to resume (also a couple times in the middle of a session, and the crash report always has the same call at the top of the stack trace: > 0 libX11.6.dylib 0x00219f16 XPutImage + 54 I rebuilt rdesktop, just in case it might make a difference, but it still crashes frequently. Should I let it send the problem report to Apple, or post it here, or ... ? Thanks, - Brian

1 1

Re: [Xquartz-dev] Notes on OSX 10.5.5
by Jeremy Huddleston 17 Sep '08

17 Sep '08

Moved to xquartz-dev 'cause that's more appropriate for this discussion. On Sep 16, 2008, at 08:39, Mike Meyer wrote: > On Tue, 16 Sep 2008 00:51:11 -0700 > "Jordan K. Hubbard" <jkh(a)apple.com> wrote: >> fingers). If, even so, someone can still come up with a compelling >> argument for making "the user bits" and "the developer bits" one >> piece >> again, I'm certainly willing to listen to it. > > Two reasons: > > 1) If they're one package, they're never out of sync with each other. I believe the reason for the split initially was to decrease file size. X11 is actually split into 3 packages, X11User, X11SDK, and X11Doc. IIRC, X11SDK and X11DOC combined are less than 1M, but I don't recall exactly. That seems absurd to me, to me given the headache this is causing now, but it made more sense back with Tiger's X11 which was based off of XFree86 and had a much more stable SDK and didn't use autoconf/libtool (hence no .las). Furthermore, the goal is that we need to have a stable API that one can build off of and distribute an application to any 10.5.x system, so the API itself (which is what the SDK package is supposed to be) is not supposed to change. X11 in OSX has pushed the threshold of that position over the past few updates in order to jump forward as much as possible in the "official" updates to bring the progress you've seen here in the community to the users at large. The extent to which that threshold has been pushed coupled with the disjoint between the X11SDK and X11User updates has made that less than smooth for the power user and developer, but that is where xquartz.macosforge.org comes in for now. Hopefully with 10.6, these issues will be irrelevant. We've learned from these mistakes, and changes have been put in place to make sure they don't happen in the future. I wish I could turn back the clock and address this in Leopard, but I really don't see how that's possible with the disconnect between these two packages. The best thing we can do is just remove the .la files from future Xcode releases (which will make "fresh" systems work, but will leave reference issues in existing macports/fink installs... which are "broken" already). > 2) As part a larger ecosystem, having applications split into user and > developer packages makes things very painful for the developer. Yeah. > Details upon request. I don't know if that's where things are > going, but even if not, it would be nice if installing the user > bits included an option to install the developer bits, and even > better if there were a user-settable global default. (sorry if > that's already happened). This is an interesting idea, but it's far over my head. As a developer (putting on my open-source hat and taking off my Apple hat), I'd love to see SDK updates coupled with OS updates rather than downloading new XCode releases for that. I like the idea that Xcode is *just* an application and not some monolithic conglomeration of every SDK on the system on top of all that. Certainly, lay out what you think would be appropriate and try to anticipate retorts against it... at worst, it'll spark some discussion here and get people thinking more about this problem. --Jeremy

3 3

X11-2.3.1
by Jeremy Huddleston 16 Sep '08

16 Sep '08

I am very pleased to announce version 2.3.1 of our X11 package for Leopard. You can find full release notes (MANY bug fixes) and details here: http://xquartz.macosforge.org/trac/wiki/X112.3.1 And here's a direct link to the package: http://xquartz.macosforge.org/downloads/X11-2.3.1.pkg This version requires OSX 10.5.5 to be installed first, so we no longer require you to logout after installation. This final version is 100% identical to 2.3.1_rc7 which was the same as rc6 but without libGLw and the the OS version dependency updated to 10.5.5. Thanks to everyone for your help testing and reporting issues. --Jeremy

6 16

2.3.1_rc7
by Jeremy Huddleston 13 Sep '08

13 Sep '08

This isn't much of a big release. It's the same as rc6 but with GLw stuff punted and now depending on 10.5.5 (so we don't need to logout after install). If you don't have access to a 10.5.5 seed, wait. If you do have access, please test, so I can release this sooner rather than later. http://static.macosforge.org/xquartz/downloads/X11-2.3.1_rc7.pkg --Jeremy

2 1

Proposal for PRIMARY and CLIPBOARD Copy/Paste
by George Peter Staplin 12 Sep '08

12 Sep '08

Hi, I've been working on pbproxy, and examining other X11 selection code. It seems to me that we need the following menus and corresponding messages that the AppleWM could provide to a pbproxy-like app: Copy Primary Copy Clipboard Paste Primary Paste Clipboard The reasons are as follows for the Copy menu items: The existing Copy isn't precise enough. The user may have text selected in an xterm that uses the PRIMARY selection, and an image or text copied in the Gimp or another Gtk+ app that uses CLIPBOARD. This means that it's unclear which selection to Copy to the NSPasteboard/pbs. If we copy PRIMARY then it may not be what the user wants. If we copy CLIPBOARD that may not be what the user wants either. The reasons for the Paste menu items are as follows: When calling XSetSelectionOwner to set the X11 selection, it's also imprecise to set ownership of the PRIMARY and CLIPBOARD. The user may wonder why the previously selected PRIMARY xterm text selection is no longer usable. I wish the situation could be handled in a simpler manner, but X11 complicates this for us. The existing way is ambiguous. I'm hoping to be able to have the pbproxy code working with these new messages from the AppleWM soon. I wrote an Xlib-based prototype that I showed to Jeremy that supports the INCR protocol, so users will be able to paste large amounts of text properly from toolkits that use the INCR protocol (such as Tk and Xt/Xaw/Motif). The prototype also supports images, so it should eventually be possible to copy and paste images from/to X11. Any thoughts or opinions on this? George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/

5 22

Making it less ambiguous - Copy/Paste Problem
by George Peter Staplin 12 Sep '08

12 Sep '08

Hi, This code I just wrote demonstrates part of the idea: http://www.xmission.com/~georgeps/xfixes_clipboard.c We can use something like that to determine which window most recently set ownership of the selection, and what selection was involved. However there is still an unfortunate ambiguity still. The X11 Tk text widget doesn't set the PRIMARY or CLIPBOARD again if it already has acquired it. Gtk+ apps always request ownership again, even if they already own it. The ambiguity is this: 1. select some text to own PRIMARY in an X11 Tk text widget. 2. do an Edit->Copy to get a Gimp image into the CLIPBOARD. 3. select some text in a Tk text widget that already owned PRIMARY. Nothing happens, so the code will think the last selection was from the Gimp. Unfortunately we can't copy images from most Gtk+ apps unless we support CLIPBOARD, and if this ambiguous situation continues to persist, there is little hope for the default Copy/Paste menus to work properly in all cases. I hope this is clear. George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/

3 9

Re: [Xquartz-dev] Proposal for PRIMARY and CLIPBOARD Copy/Paste
by Jeremy Huddleston 11 Sep '08

11 Sep '08

> The problem with that is that some apps never set PRIMARY. The > experience will be just as confusing without more menu items. Well then their application won't work in X11 on UNIX, so let's not worry about getting it to work on OSX. If selecting text doesn't change PRIMARY, then there's really no way for us to GET that selection. > For instance the Gtk+/Gimp image copy only sets CLIPBOARD. So the > user may come to expect image copies to not work, but in reality > they will work (if I get this code finished) but only be aware of > that after switching to CLIPBOARD. Right, and this will be handled "automatically" (ie, not with the Edit- >copy menu) when the user does 'Edit->Copy' in gimp, xemacs, openoffice, etc. (assuming that is what the user wants... hence the 4 options I mentioned in my pseudocode). >> We should have an option that changing CLIPBOARD causes that to be >> proxies to pb. The reason being that users don't want to copy twice >> (once to CLIPBOARD then to pb). Additionally, most users don't >> understand what that would even mean. > > I agree that most will not immediately understand what it will > mean. But it's the kind of thing that trial and error could > indicate. I wish there was a better way. I think there is (what I outlined in my pseudocode) >> The user almost never expects the copy action in our menu to copy >> CLIPBOARD. > > Well, if they copy images, or have just done Copy in an X11 editor > menu, they might expect that. I think they'd expect that if they copy imaged or hit copy in an editor, the PB will automatically be updated. You should never need to do edit->copy (menu 1) then edit->copy (menu 2) to copy to the PB. Additionally, some users disable key equivalents, so actually forcing them to goto the menu is not desirable (hence the proxy on select and proxy clipboard options). > X11 Tk apps for instance use PRIMARY for the highlighted text, and > an Edit->Copy usually copies that to the CLIPBOARD via > [tk_textCopy]. Tk apps aren't alone in that regard either. Yes. That's actually the expected behavior, and we want to support that (and not care about apps that break that convention). > XGetSelectionOwner can return 2 different windows if you have > different PRIMARY and CLIPBOARD owners. yep.

1 0

New Idea for Copy and Paste...
by George Peter Staplin 11 Sep '08

11 Sep '08

Hi, After discussing the copy/paste issue with Jordan Hubbard a new idea was formed. We can use the most recently set selection atom, instead of having 4 menu items. I think this sounds reasonable. We can use XFixes to see which client most recently owned the selection, and thereby trigger an XConvertSelection request in pbproxy for the TARGETS list, and then respond accordingly... http://www.freedesktop.org/wiki/Software/FixesExt How does that sound? George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/

2 1

2.3.1_rc6
by Jeremy Huddleston 11 Sep '08

11 Sep '08

Yes, I know I *JUST* released rc5, and I know I said that was pretty much it... but I ended up fixing a bug yesterday that some users have been patiently waiting for for some time now, so I decided to not make them wait much longer for it. http://static.macosforge.org/xquartz/downloads/X11-2.3.1_rc6.pkg 2.3.1_rc6 adds the following over rc5: 256 Color support* Stability improvements in the file-descriptor handoff from /usr/X11/ bin/Xquartz to X11.app If these two issues don't really impact you, then there's not really a need for you to try out rc6 if you have rc5 already. Thanks, Jeremy *: kinda... there's a bug in the colormap processing if you are in TrueColor mode, but it works fine if you select '256 Color' from the X11->Preferences->Output->Colors, but that never wasn't working on Tiger, so this gets us to atleast where Tiger was.

3 5