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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
