[Xquartz-dev] seems 2.7.2b4 helps a lot! (Re: Several nagging problems in recent Xquartz versions…)

[SciFi]

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.

--