Hi, The new cairo-1.12.0 inside 2.7.2-beta4 seems to fix all the visual anomalies with Pan I reported last year. :) <https://lists.nongnu.org/archive/html/pan-users/2011-05/msg00019.html> <http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/12321> <news://news.gmane.org/453FC7B5-F410-497B-BC0A-7649B45ADF97@hush.ai> This is #3 in my xquartz report from July 12 2011 -- <https://lists.macosforge.org/pipermail/xquartz-dev/2011-July/003386.html> <http://permalink.gmane.org/gmane.os.apple.xquartz.devel/356> <news://news.gmane.org/pan.2011.07.12.17.55.33@scifi.homeip.net> I did not need to recompile anything here -- beta3 still showed the same whacky problems, yet beta4 with the new cairo suddenly showed those problems gone! Exact same Pan code & its other requisites etc. locally (but I did notice Pan takes a while to first start right-after the underlying XQuartz code has been updated, I believe this is due to the dynamic linking related jazz in OSX itself). Even the copy-&-paste highlighting artifacts are now looking as expected (which I could not show in the above posting). At least I presume it was the new cairo that fixed the problems. ;) (My Pan build should show in the User-Agent header line.) As for the other items in my report: 1. I've kept the work-around for the 2nd monitor, by moving the Display Prefs indicator for the Mits to the "other" side. 2. We still have the stuck-'h' key. In fact the bug-report #443 has a few more people who are experiencing this same problem. As for me, a recent Pan build from git.gnome.org can easily change its "hotkey" table, to let us steer-clear of using 'h' for any of its functions. 3. Apparently fixed as per the above. 4. Already fixed as noted further in the original thread. 5. I still cannot use the pkg-mgrs: the latest Pan code seems to need some projects/versions that are not (yet) available except for having to build 'em by hand the old-fashioned way. Sorry. ;) 6. I'm still here and in same condition. I am planning to move to a full open-source system sometime soonish. I find OSX not keeping-up with my favourite hobby for whatever internal reasoning besieging the company. Plus, my particular "iMac6,1" seems to be "officially retired" w/r/t 10.8. Again, sorry, and maybe this could be further discussed via email (BTW the gmane.org email system will de-obfuscate the strange addy for me, yes it will actually work, if you/anyone would like to correspond). Now I am a bit happyier, but still kinda afraid to move onwards. ;) FWIW I would like to pursue an old problem with the NNTP folks: The glitch with Giganews is still bothering us; I've asked the Pan team for some help if possible. Namely, I'd like to see the "hexdump -C" of the actual network packet(s) when we see this in the Pan error log:
Thu Mar 15 17:26:53 2012 - Error reading from news.giganews.com: Received corrupted data
Such glitches have been with GN ever since I first joined them many many years ago, and across several ISPs and news-reader apps etc., no matter if SSL is involved (even thru stunnel) or with just a plain straight connection. This occurs very randomly, a few times or so, day and night. It even occurs when I have Pan set off-line. No other Usenet server/company seems to do this (e.g. AW and Gmane do not do this, AFAICS). I'd like to get a handle on this glitch with GN and hopefully raise a proper support ticket with them. But we probably need to see the "guts" of the related network packet(s). It might be likely causing some other glitches with other F/OSS NNTP projects (such as the 'yencee' script I've mentioned in other earlier posts on the pan-* lists). Thanks for reading. --