David Chmelik posted on Thu, 21 Aug 2025 03:16:02 -0000 (UTC) as excerpted:
> Headers pane columns are wrong size and some not draggable: bytes > apparently no longer can be dragged from right to shorten (even after I > lengthened others) or is there another way? Takes maybe 2/3 columns' > space when that extra size would be significantly larger than Usenet or > entire Internet, while 'subject' should take that space but takes maybe > 1/4, and 'author', 'date' are also too small but 'lines' is too long. > It'd be easier if these were configurable numerically or a way (for all > panes) you don't have to find hidden handles to drag. There is another way, yes, but it's a bit more technical than some may be comfortable with... The size of each column, is stored in pan's preferences.xml file, to be found in (by default) ~/.pan2/preferences.xml . For instance, here's my bytes column setting, 63 (logical, scaled by display-scale settings) pixels: <int name='header-pane-bytes-column-width' value='63'/> With pan closed (so it doesn't overwrite your changes) you can edit that file, tho I'd suggest making a backup of it first just in case. Naturally your choice of font size will dictate how many letters a particular pixel width displays so you may have to experiment a bit to get it looking as you want, but there it is. I don't know why some of the column dividers aren't draggable for you, presumably a bug of some sort, but (you can stop reading if you're not interested in the history of how I'm all too familiar with the column- width settings in preferences.xml!)... FWIW, back in the gtk2 era there was a bug that could zero out the size of all but the last column, leaving the column dividers stacked on top of each other at the left, with the last column then taking the entire space. If you caught that as soon as pan started and did a killall -9 pan (on Linux, note that killall on the BSDs is probably NOT what you want! -9 being unblockable kill from the kernel without giving the app a chance to save its data), pan couldn't save the corrupted columm-width state as it would normally on close, and would thus load correctly the next time, as the corrupted state wasn't saved and the bug-trigger wouldn't normally trigger again. If you let it save-state however, you were stuck with either painstakingly dragging each column to an appropriate width, or text-editing preferences.xml to fix the issue. I believe the actual bug trigger had something to do with gtk2's regeneration of its icon-cache, normally after an upgrade. Because I run a non-gtk desktop (I prefer the qt-based kde plasma) but start pan with the session, the icon-cache-regen didn't happen when the desktop itself started after the upgrade as it would have with a gtk-based desktop, and would only happen when pan itself, as the first gtk-based app, started. Pan would start and the icon-cache would regenerate, but due to a race condition pan would query the size of the icons and get a non-initialized 0 before the regeneration was complete. Because my first two columns are state and action, both of which are icon columns, that would zero them out, and apparently as a side effect all the others were zeroed out as well, leaving the last one (score in my case) to take the entire space even tho it too was actually zero-sized. So the bug would only trigger occasionally, after upgrade of whatever package invalidated and re-cached the icon-cache, and further, would only happen to those on a non-gtk-based desktop and only when pan was the first gtk-based app to start. Which meant the bug was was relatively rare if they ever saw it at all for most folks, but that it occurred repeatedly for me over some time, since I had pan starting as part of the desktop session so it was always one of the first if not the first gtk-based app to start after an upgrade, and I didn't have a gtk-based desktop starting first to regenerate the cache before pan triggered it. The first time it happened I did the painstaking drag all the dividers to an appropriate position again thing. The second time I thought there had to be a better way and found the column settings saved in preferences.xml to edit. By the third time, months after the second but still, familiar problem by then, I was thoroughly tired of the whole process, and created patches that I could apply to preferences.xml to semi-automate the process. By the forth time, even that semi-automation wasn't enough, and I added to my pre-existing pan wrapper startup script a routine that applied the patches (which only actually apply if the pre-patch text matches, normally with a context of three lines on either side to be sure they apply in the correct place) before actually starting pan. Sometime later I redid the patches to no-context so they only had to match the individual line and would apply if its value was zeroed out, even if the lines around it didn't match. After that whenever I saw the bug I could quit pan and restart it, and the patches applied by my pan wrapper script would automatically fix the problem. Of course the patches set some arbitrary mostly-correct width for each column, and sometimes I'd have to tweak things a bit for one column or another, but at least things were mostly correct and when I /did/ have to tweak a column's width, I could grab the appropriate divider and drag it by itself -- the columns weren't zero-width stacked on each other at the left! Then after the width-tweak, if I felt like it I could go read the new setting in preferences.xml and edit the patch to apply that new size the next time it happened, instead. A /few/ other people triggered the bug and mentioned it on-list over the years, and I'd explain how to fix it, but not many. To my knowledge no one else ever had it happen repeatedly enough to go to the extent I did and setup auto-applied patches in a wrapper script, but I think several did the preferences.xml text-edit thing. After pan finally started defaulting to gtk3 the occasional posts to the pan list complaining about the bug died out, and while my wrapper script still attempts to apply those patches I've not had to quit and restart pan in ordered to apply the patched settings since gtk3 (which had other bugs at first making gtk3 pan nearly unusable, but DD made quick work of them after he took over pan maintainership), so I think that bug is history along with gtk2 pan. But now you're seeing another column-with related bug... At least I can point you to the lines to edit in preferences.xml... while I hope I never see it, or worst-case, that text-editing either that file or my patches that worked around the zeroed-out bug for me work around it, and that whatever the problem is, it's a bug that goes away with an upgrade of either pan or some library or other so I only see it once, unlike that repeatedly triggered gtk2 bug that only went away permanently for me with the upgrade to gtk3. -- 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 [email protected] https://lists.nongnu.org/mailman/listinfo/pan-users
