Duncan posted on Mon, 04 Aug 2014 16:46:05 +0000 as excerpted:
>> - the one where the window gets wider than the screen, and can't be
>> made smaller. It seems to be because of the right-most column in the
>> header pane, which is far too wide but refuses to be resized smaller.
>
> That's a known issue. There's a workaround but I don't have time to
> explain it ATM. Punting until later on that..
"Later" it is...
I run into this bug somewhat regularly, usually after a pan rebuild, and
others have mentioned it on occasion as well, so I know I'm not the only
one.
As best I've been able to figure out, the bug is a result of some sort of
gtk2 resource race, whereby some icon resource (candidates include the
state and action column icon resources) or the like that pan uses isn't
loaded by the time the window gets drawn and the column with must be
calculated. Without the resource, pan calculates a zero-width column,
likely resulting in a divide-by-zero or similar exception. Pan doesn't
crash, but it does throw the entire header pane column layout off,
effectively zeroing the width of all columns, resulting in whatever you
have as the last column (here it's score) taking up the entire width.
The first time I saw it happen was a number of gtk2 versions and quite
some pan commits ago now.
At first, I fiddled with the GUI to get everything lined up properly
again each time it happened. Go to pan preferences, header tab, and
uncheck all columns but two (and leave state and action unchecked), hit
OK, and adjust the width of the left column to something reasonable, the
right taking up the remaining area. I'm not sure whether it's necessary
but I seem to recall quitting and restarting pan each time to ensure that
the preferences stuck, as well. Obviously the below process got old
rather fast, however, so I adapted...
Again open prefs, header tab, and add another column, repeating the
process of setting the width of each column but the right one each time.
Do this until you have all columns you want enabled EXCEPT state and
action. When you add them (assuming you consider the info they provide
worth the hassle), add them one at a time at the RIGHT (or second from
right, I think it might have been), and set their (minimum) width. If
you weren't doing it for the other columns, be sure to quit and restart
pan before and after setting the width of each of these, one at a time,
still keeping them to the right.
After adding all the columns you want, still with state and action to the
right (if enabled at all), quit and restart pan again, just to be sure.
You may also want to make a backup of pan's preferences.xml file at this
point, since that's where column order and widths are stored.
Then, as the last bit of reconfiguring, move them one at a time to the
desired column position, again quitting and restarting pan after
positioning each one.
Quit and restart pan once more, to ensure it's all still appropriately
ordered and assuming so, make another backup of the preferences.xml file.
If you change anything important stored in preferences.xml, remember to
back it up again.
Now if pan eats the column order, quit pan and restore preferences.xml
from backup. =:^)
Or as a likely simpler alternative to the above described GUI reset
method, consider manually editing preferences.xml for each column as
suggested by the sample patch below. Obviously with pan not running.
Hopefully with a reasonable non-zero (non-one) width value, even if it's
not perfect, you can start pan and finish recalibrating widths from
within the GUI.
Actually, that preferences.xml backup file was my middle level of
adaptation. Eventually I got tired of doing the replacement manually as
well, and ended up automating the process even further.
What I did was this: When pan ate the columns again, I quit pan and did
a diff between the now bad preferences.xml and my backup. Then I created
a set of patches out of the relevant lines from that diff. I've long had
a pan-wrapper startup script that does some setup before starting the
normal pan binary, and now I apply these patches from that wrapper script
before starting the usual pan binary. Of course, a simpler solution
would simply copy the preferences.xml file from backup, overwriting the
old version each time, but that would have been a hassle if I decided to
actually change a preference. So I went the patches route.
Now normally, patch files come with several lines of context on each side
of the patch, but in this case, that's not what I wanted since I know
there's only one possible line-match in the file anyway So these patches
don't have any context. Additionally, I split out the patches one per
line, so each column has its own patch file. I have a particular subdir
which contains all these patch files, each of which patches exactly one
line of the preferences.xml file, corresponding to one column width
setting.
So now there's this patches subdir with a bunch of patches in it. The
pan wrapper script goes thru each of these patchfiles, doing a dry-run
patch on each one. If the dry-run succeeds, the patch is applied for
real.
Meanwhile, each of the patches replaces a line with a zero-width column
setting with a line with the corresponding desired-width column setting.
If the patch applies then the column obviously had a zero-width setting,
which got patched to the desired-width setting instead. Since each patch
is apply-tested independently, any time any of the columns get set to
zero-width, on the next restart, the script will patch the patch and set
it back to the desired width.
So now, if I see that pan has eaten all my columns again, I simply quit
and restart it. On quit, pan rewrites the preferences.xml file with the
zero-width column settings, and on restart, my wrapper-script patches
those zero-width column settings back to the desired width, before
actually starting the pan binary. So now if it happens, all I do is a
simple quit and restart, and I have my columns set back the way I like
'em. =:^)
Obviously, if I deliberately change the widths for some reason (maybe
somebody comes up with a new column I want to add), I'll need to edit the
corresponding patches accordingly, but that's simple enough.
OK, here's the relevant bits from my pan wrapper script (bash):
--------snip-----
# Bug-workaround: if pan reset column sizes to 1...
patch_header_columns() {
local line patch
cd "$PAN_HOME"
for line in action author bytes date lines score state subject; do
patch="-fi ../patches/column-$line.patch preferences.xml"
patch --dry-run $patch >&- && patch $patch >&-
done
}
patch_header_columns
--------snip------
Looking at the patches, it looks like pan must actually set the bad
columns to a width of 1, as that's what the patches match on. Here's one
of them (for the lines column, column-lines.patch) as a sample. (Note
that 60 px is my desired lines column width. You'd obviously need to set
a different replacement width value if your desired widths are different
as they likely are. Snip the blank lines too...)
-----snip------
*** preferences.xml.bad 2013-01-06 01:08:44.000000000 -0700
--- preferences.xml 2013-01-06 23:05:45.000000000 -0700
***************
*** 91 ****
! <int name='header-pane-lines-column-width' value='1'/>
--- 91 ----
! <int name='header-pane-lines-column-width' value='60'/>
-----snip-----
--
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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
