[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pan-users] squished headers pane columns
From: |
Duncan |
Subject: |
Re: [Pan-users] squished headers pane columns |
Date: |
Tue, 9 Oct 2012 00:16:13 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT 0becc9f /usr/src/portage/src/egit-src/pan2) |
Duncan posted on Wed, 03 Oct 2012 09:52:44 +0000 as excerpted:
> thufir posted on Wed, 03 Oct 2012 06:36:37 +0000 as excerpted:
>
>> At first the additional columns were squished to, I guess, a zero
>> width,
>> but by stretching or shrinking the first column other columns then
>> became visible. Weird.
>
> I've seen that a few times too (but not that I recall with pan), in
> three different types of instances.
@ Heinrich and thufir:
I just had this happen here, too, and have a bit more information to
report:
1) In my case, I was quitting and restarting pan rather rapidly, testing
the new tray functionality (much better now). I didn't notice the
problem with the first couple starts on the new build tho I wasn't really
looking for that, but on about the third one I noticed #2b below and
later saw the problem, so it MIGHT be some sort of race condition
trigger, assuming #2b is indeed related at all.
2) I don't know if it's STDERR or STDOUT, but I happened to be launching
pan in the background from a terminal window, which then disowns childrend
and closes, so I got a bit of output. Investigating further:
2a) I routinely get a "diff NNN" line, where NNN is a number (normally 0
at launch, but I see a 18446744073707670705 from further in the program
in my current session).
I've no clue where this is coming from. Presumably Heinrich knows
something about it?
2b) (pan:1726): Gdk-CRITICAL **: IA__gdk_window_get_state: assertion
`GDK_IS_WINDOW (window)' failed
This is the one that got my attention, as I hadn't seen in in earlier
launches. But about the third launch I got several printings very
similar to this in a row... and either that launch or the next, noticed
the single-column-only header-pane problem!
Naturally, as soon as I saw the problem, I recalled this thread and knew
I must be seeing the same thing. Why now, I haven't a clue, unless it IS
related to some sort of race condition, and my quick restarts trying to
test the new trayicon code triggered it. And/or...
3) Playing with the columns, both width and which columns are set active
in preferences, in ordered to try to get back a normal display, I noticed
another peculiarity:
By dragging the dividers, I can get MOST of the columns to show up (I run
pan horizontally maximized on a 1920 px wide display, with the header
pane full-width across the top so there's lots of room and I have all
columns active by default), *BUT* action and state don't seem to
cooperate at all.
Action and state don't want to appear, no matter where I have them in the
order, altho I WAS able to get one of them to appear momentarily, but
then I tried to get the other one, and the first disappeared again.
Now here's the thing. I've long since forgotten what the defaults are,
but here, I had action and state configured as the first two columns to
the left.
What I suspect MIGHT have happened based on the evidence available, is:
For some reason, the state and action columns weren't created by the time
the header list widget tried to display, triggering the GDK-critical
window get-state assertions in #2b.
When they failed, that meant the existing column width configuration was
invalid, since the first couple columns weren't there. That caused the
widget to only display one column. For whatever reason, it happened to
be the bytes column in my case, tho subject and author were first. Maybe
bytes was ordered last? I don't remember and I've been playing with the
order now so there's really no way to check.
FWIW, it appears that if I disable the action and state columns and set
widths appropriately for the others, I can close pan and reopen it, and
my new setup is retained.
But I've had it revert to just bytes at least once. I haven't yet
figured out why, or exactly what bearing the action and state columns
seem to have on the problem, tho they DO seem to be related in SOME way.
The BIG questions: Why are the action and state columns so problematic,
and what triggers the problem in the first place, since it seems to be
fine until SOMETHING triggers it. At this point, it does NOT seem to be
triggered by a specific rebuild or version of this or that dependency,
tho I haven't /entirely/ ruled that out just yet as I /was/ doing
upgrades at the time. But it /seemed/ to be fine for several starts,
then the problem triggered, and here I am.
Meanwhile, Heinrich, does any of this ring a bell in terms of changes you
might have made? I know you've changed some of the icons in the not
/too/ distant past, did you change the icons that appear for action and
state? But at least the changes I noticed there were probably a couple
months ago now, and it had been working fine... What about the code for
action and state? I've not noticed any changes in that area in the git
log recently, but then again, I've not been specifically looking for it
either. And of course there's the possibility of it being related to a
specific gtk (2.x only?) version, tho again, it doesn't seem /directly/
related to that, maybe a newer version is simply a bit more racy in some
way.
Now to post this and experiment a bit more... If I find anything else
interesting, I'll post.
--
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