Re: [Pan-users] Pan stops showing more than one message header column

[Duncan]

Dave posted on Thu, 08 Nov 2018 23:07:47 +0000 as excerpted:

> On Thu, 08 Nov 2018 05:16:44 +0000, Duncan wrote:
> 
>> The issue I see here is that for some unknown reason, pan will
>> sometimes reset all the message header columns to 1-px-width, resulting
>> in just the /last/ (right-most) one being displayed across the entire
>> width of the header-pane, as all the others are collapsed to a single
>> pixel each. As best I have figured out, this seems to only happen when
>> I update pan or one of its deps (maybe gtk, not sure), tho not always,
>> making it hard to track down, but often enough that over the years I've
>> seen it happen a few times now and have devised a semi-automated fix
>> for my own use.
> 
> That's interesting.  I've also been using Pan for many years on KDE,
> currently on KDE5/Plasma, BUT I use FreeBSD, currently on
> 11.2-RELEASE-p4.  I've had a few issues in the past, all traced back to
> other libraries such as gmime and glib.  I've never seen the issue you
> describe, which kinda implies it's something outside of Pan.
> 
> Maybe during close-down, something sets or corrupts the columns widths
> during the save of the preferences.xml?

AFAIK, preferences.xml is saved every time pan closes, and possibly every 
time you change the size of the window, I'm not sure.  Because there's 
settings in there about the sizes of the sub-windows that change every 
time the size of the main window changes.

But I did say that I believe it's not pan itself, but rather, something 
else, because it seems to trigger only after I've updated something.  But 
I'm not sure if it's gtk+-2.x updates, or some other library, because it 
has happened repeatedly, but doesn't happen often enough to have actually 
tracked it down to updating a specific package, partly because I /
suspect/ it doesn't happen on /every/ update of the package, only some of 
them.

But it'd be far less likely to trigger on a non-rolling distribution, and 
more likely to trigger on a rolling one like the gentoo I run, or arch-
linux.  Because non-rolling distros rarely do in-place core library 
updates except for security patching of release-shipped versions; they 
wait for releases and update pretty much everything at once, and even 
then, releases, and thus lib updates, tend to be far less often than on 
rolling releases.  Only rolling-release distros where someone may have 
originally installed a decade or more ago, but will be regularly updating 
libs, some of them several times a year, are likely to see this sort of 
problem.

And for rolling releases, people on the testing/development branch/
profile/whatever are likely to see more updates than those on stable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman