Re: [Pan-users] squished headers pane columns

[Duncan]

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