[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] Minimum application's window width
From: |
Duncan |
Subject: |
Re: [Pan-users] Minimum application's window width |
Date: |
Sun, 1 Oct 2017 11:16:47 +0000 (UTC) |
User-agent: |
Pan/0.143 (Quaint little villages here and there; 001222cab) |
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