Re: [Pan-users] Minimum application's window width

[Duncan]

Mateusz Viste posted on Sun, 01 Oct 2017 07:34:43 +0000 as excerpted:

> Well, my real problem is not truly about the general Pan window's width
> (although I guess it is related), but with the fact that sometimes Pan
> decides to make my list's group (that I keep as a column on the left
> side of the Pan window) very narrow, or even 0-pixel wide. This is very
> dynamic, because it is triggered when I click on some articles or
> threads. In such situation, it is impossible to manually bring back the
> list of groups, unless I also make the entire Pan window larger than my
> screen is.
> 
> I tried playing with the width of headers in the headers window, as well
> as enabling/disabling the wrapping feature inside the message window,
> but none of these actions cured the symptoms.
> 
> This is a laptop, and I am using a 1600x900 resolution which - I think -
> is not *that* small.

Please reply in standard newsgroup context-quote-then-reply-to-it 
fashion, not the out-of-context-top-reply that many use now days, at 
least on the pan group/list (many regulars including me read and reply to 
this list via gmane's list2news service, using pan).  There's a reason 
pan complains when you top-reply -- it's irritating as it makes further 
in-context replies that keep appropriate grandparent and above context as 
well, where necessary, impossible, without rearranging the text to proper 
quote/reply format.  Some people simply skip replies to top-posts as it's 
just too much work.  Here, I just clipped the entirety of grandparent and 
earlier posts, even if that leaves out otherwise useful context, instead.


In the case of 1600 width, you're certainly wide enough to not be 
triggering the toolbar width issue.

What you're seeing is very likely some variant of a bug I see 
occasionally, only in my case, it's with the headers pane, and it always 
happens the first time I open the pan window after having restarted pan, 
usually (I think always, but am not 100% sure) after an upgrade of pan or 
one of its libs.

In my case the problem seems to be a race between pan's calculation of 
header column widths and loading of resources such as the icons that 
populate certain columns (the state and action columns, which I have as 
the two left-most columns in the header pane).  At a guess those icons 
are loaded into some sort of cache, and upgrading invalidates that cache, 
sometimes causing the icons to load slow enough that they aren't 
available when the column width is calculated, so the column gets set to 
0-width because the resource that would populate it isn't available.

When this happens the rest of the columns (but one) end up zeroed out as 
well, resulting in the last column taking up the full header pane width, 
with all the column separators being stacked on top of each other at the 
left edge.

Unfortunately quitting pan then writes that configuration back to the 
config file, so a pan restart doesn't fix it.

This is with pan built against gtk2.  I've wondered if it'd happen when 
built against gtk3 (that is, whether it's a gtk2-only bug), but I've not 
tried it to see, because I have hacked up a workaround, crude hack tho it 
may be.

The first couple times this happened, I laboriously dragged each 
separator back to the right, setting each column width manually, but by 
about the third time that was getting old real fast!

So digging into a backup, I found the changed file (preferences.xml in 
the pan home dir, ~/.pan2 by default), and did a diff.  Then I separated 
that diff into a bunch of individual files, one for each line, and 
applied them as patches to the bad config (with pan shut down of course) 
to fix it.

I applied the patches manually the next few times it happened, and while 
that was sure better than laboriously dragging the column separators to 
reset them, it too got old.

But as it happens I already had a pan wrapper script setup to do a few 
things before it actually ran the normal pan executable, so with the 
patches already created and tested, it wasn't much trouble at all to add 
functionality applying them to the wrapper script. =:^)

So now, if I start pan and all the columns are invisible but the last 
one, because they're 0-width, I simply quite and restart pan, thus 
writing the 0-width config to the file, with the wrapper script then 
applying the patches because they now match the 0-width lines, rewriting 
them back to normal width.

Of course it's a hack, but it works, best if the main pan window and thus 
the header pane (which I have configured to full width at the top) remain 
the same consistent size.  Which they do because I have a kwin rule that 
enforces an initial and minimum size (tho I can make pan larger if 
necessary, and do on the rare occasion I do binary/image groups), the 
standard 1280x1080, 1/3 the width, 1/2 the height, so 1/6 of the space of 
my primary UHD (3840x2160) display, that I use for most normal windows, 
including pan, konsole (terminal), firefox (browser), claws-mail 
(separate instances for mail and feeds), etc.

I'm just glad I'm tech literate enough to figure out the patches and 
wrapper script to apply them.  While it doesn't happen at every update, 
being on pan git means I update it much more frequently than every 
release, and being on a rolling distro (gentoo) means even the normal 
release-versioned libs get updated more frequently than most people on 
fixed-release distros will be updating, so there's a LOT of possibilities 
for it to trigger, and I'd likely have abandoned pan if I had to manually 
adjust header column widths each time the bug triggered, as those who 
aren't particularly tech literate probably have to do!


Your case appears to be different because it's the groups pane that's 
going zero-sized, not the columns in the list pane, and it seems to be 
dynamically, not only at startup, as happens to me.  But it could well be 
due to the same root 0-width resizing bug.

You might try playing with the layout.  Try putting the group pane to the 
right instead of the left, and/or making the header and/or body pane full 
width, with the other of the two beside the groups pane.  That might at 
least give you a bit more hint what's triggering it, perhaps a long 
subject or author line is forcing the header pane wide, or perhaps a 
message body is forcing the body pane wide, for some reason.  If they're 
already full width, with the other two panes above or below, maybe it 
wouldn't happen.

If you can figure out what's causing it to the degree I did my case at 
least, perhaps you can use my patching-wrapper idea.

Or set preferences.xml read-only/immutable if necessary and see if 
quitting and restarting pan solves the problem at least temporarily.

Another alternative would be to hiding the groups pane except possibly 
when you need to switch groups.  You can either unhide it only to switch 
groups, or use the next-group menu actions and/or hotkeys (which are 
configurable) to avoid having to toggle the group pane on and off.  The 
idea being if the pane is hidden when whatever zero-width-trigger event 
happens, maybe it won't trigger, and you'll have a normal-width pane when 
you unhide it to switch groups.

Yet another workaround would be to switch to tabbed mode instead of 
panes.  You can do that for normal use, or only when switching groups, 
going paned but with the group pane hidden between group switches.

The good thing about tabbed mode is that it should let you use the group 
tab even when the group pane is zero-width, because in tabbed mode all 
three otherwise-panes are full-size window tabs.

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