Re: [Pan-users] Group settings keeping messed up

[Duncan]

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