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

[Duncan]

David Chmelik posted on Tue, 06 Nov 2018 01:51:26 +0000 as excerpted:

> I'm temporarily trying Pan (with same profile from a working
> installation of Pan on other OS) on Kubuntu.  I must say it's a poor
> implementation of KDE.

Pan is gtk-based, not qt/kde-based.

FWIW, I run a kde-plasma desktop myself, but use pan, as I have used both 
for over a decade and a half now, because kde simply has no pan 
alternative, and knode, the one they did have but which is now abandoned 
and remains unported to kde-frameworks-5, never worked as well as pan for 
binaries.

> In this, Pan only shows one message header
> column (either author, subject, date, etc.)  What can I do about that? 
> It's not a resize issue;
> the cursor never goes over a place I can resize it to get the other
> columns.  They are just not displayed at all.

Dominique Dumont mentioned that on debian/ubuntu, pan is built on gtk3, 
while gentoo (which I use) and AFAIK on fedora as well, it's still built 
on gtk2.

So I'm not entirely sure whether you're seeing the issue I discuss below, 
which I know happens on gtk2-based-pan as I see it sometimes myself but 
I'm not sure whether it happens on gtk3-based-pan, or if you're seeing a 
gtk3-specific issue, or if it's something different that I've simply not 
seen, but the issue is similar enough to what I've seen here that it 
could indeed be the same...

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.

My guess is that there's some sort of icon cache or something that has to 
be regenerated after whatever update triggers the problem, and further, 
that pan has a race condition between its attempt to load and set the 
column widths and whatever cache generation is going on at the same 
time.  When the cache generation doesn't occur before pan tries to set 
the column widths, pan gets 0 values for the sizes, and resets everything 
to 1 pixel wide, which it then saves back to the preferences.xml file.

The thing is, I use a rolling distro, gentoo, and am actually running the 
~arch (aka unstable) variant, so get updates rather frequently compared 
to most people, and I actually build pan from git sources, thus updating 
it more or less every time a new patch or translation tweak is added.  
That frequency of updates means I run into the problem a lot more than 
most people will, so I needed a more automated workaround.

Meanwhile, to the actual workarounds...

The surest and least technical workaround is (with pan shut down) to 
delete the preferences.xml file (found in the pan home dir, ~/.pan2/ by 
default), so when pan starts again it uses internal defaults for the 
header columns and they display properly again.

Unfortunately, there's a bunch of other settings in preferences.xml that 
get reset that way as well, and I quickly got tired of reconfiguring them 
all to my liking every time this issue triggered.

So instead of deleting the entire file, I started opening it in a text 
editor (again, with pan shut down) and simply deleting the...

<int name='header-pane-*-column-width' value='1'/>

... lines.  Only the 0-value ones should need deleted, but it'll probably 
be all of them.

That works, but even manually editing the file got old after I did it a 
few times, so...

Since for unrelated reasons I was already using a (bash) script to start 
pan instead of starting the elf-binary pan itself, it was relatively easy 
to simply add a function to that script that ONLY if necessary, reset the 
column sizes to something sane.

That's the solution I've been using for some time, with the script 
applying single-line no-context patches that patch the values from the 
collapsed single-pixel, back to whatever pixel value I've chosen.  The 
patches will only apply if the size is a single pixel, so I can 
dynamically modify widths as necessary and they'll stay put... until the 
next time whatever update triggers a cache rebuild and pan resets the 
values to 1 pixel again.

So when pan opens to display only a single header-pane column, these days 
all I have to do is shut it down again and restart, and the restart will 
run the script that does the patching of all those values from 1 pixel to 
whatever I've decided is reasonable for that particular column and put in 
the patch for that column's value.

These days I'd probably script sed commands instead of doing the single-
line no-context patching, but what I have works well enough that I've not 
found the need to go messing with it, other than occasionally tweaking 
the target size of various columns in the patches, as I did when I 
upgraded to a new 4K monitor and changed the size I was using for the pan 
window, so the old target sizes weren't appropriate any longer.


For you, for now, try either of the first workarounds, either removing 
the preferences.xml file entirely, or editing it and deleting (or editing 
if you're comfortable with it) the lines as described above, whichever 
you're most comfortable with.  If that works, you will have confirmed 
that as the bug, and will know what to try first if it happens to you 
again.

If it starts happening frequently, which I doubt it will given your 
likely update frequency, and you need help with an automated workaround 
like I use, we can deal with it then, as by then you will have confirmed 
the problem, its manual workaround, and presumably that it still happens 
on a gtk3-based pan, which I was really hoping it didn't, thus letting 
the problem eventually cure itself due to eventual gtk2 obsolescence.


Of course the proper fix would be tracking down whatever cache generation 
race condition is causing the problem and developing an appropriate pan 
code fix to eliminate it, but I don't claim to be a developer, that's 
beyond my skill level, and I was /hoping/ to be rid of the problem 
whenever I started building a gtk3-based pan in any case.  Meanwhile, 
while I have seen the occasional mention of the problem or something 
similar to it here, as with your post, it apparently doesn't happen 
enough to any pan-using real developers for them to get annoyed enough 
about the problem to find and fix it, so it still happens from time to 
time, more often for people like me who update more often, to people 
unlikely enough to have an update trigger it.

-- 
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