pan-users
[Top][All Lists]
Advanced

[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 02:36:00 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT 0becc9f /usr/src/portage/src/egit-src/pan2)

Duncan posted on Tue, 09 Oct 2012 00:16:13 +0000 as excerpted:

> 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 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[.  I]t
> MIGHT be some sort of race condition

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

I still have no idea if that gdk-critical is related, but it seems to
appear ONCE consistently the first time I open the main pan window (from
the tray) after a pan restart, NOT when I start pan and it goes to the
tray, and NOT when I close the window (to the tray) and reopen it.  It
ONLY appears the first time I open the window.

Perhaps critically, however, it (or a message very similar) appeared at
least THREE times the once, immediately before I noticed the single-
header-column problem.

So it normally appears ONCE, that time it appeared THREE times, and the
header-column issue appeared immediately thereafter.  Related?  I don't
know for sure, but seems likely, and if so, it WOULD appear to be race
condition triggered.

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

OK, I figured /that/ bit out... sort of.  Action and state are icon-only
columns, apparently fixed width.  So dragging their dividers trying to
change their width doesn't work.  (More below...)

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

My present working theory builds on the fact that action and state are
fixed-width icon-only columns.

When whatever race condition triggered, I'm guessing the action and state
icons/subwidgets/whatever weren't loaded.  That sent gtk into a tizzy,
causing their columns to be zero-width, but gtk probably isn't prepared
for zero-width fixed-width columns. (Variable-width columns, yes, the user
can make them zero width and gtk's prepared for that, but it probably
isn't prepared for fixed-width columns to be zero-width, since in that
case why would a dev insert them in the first place?)

With the first two columns being zero-width fixed-width, that meant I
couldn't drag them wider to expose the other columns or their dividers.

That's also why changing the order of the columns, placing action and
state elsewhere, didn't seem to work.  Being zero-width I still couldn't
see them and could only see where they were by the order in prefs, and
because they were fixed-width, attempting to drag them wider to expose the
other divider underneath wouldn't work either.

The one time I mentioned that I DID get the one to show, it was the right-
most column, and by shrinking the variable-width column to the left...

Which with a bit more experimentation and a couple pan restarts after that
first posting, I discovered seemed to work reasonably consistently.

Actually, now that I think about it, trying to toggle one of the columns
on and off when it was to the left DID result in a horizontal scrollbar.
Apparently, it wasn't zero-width, but one-width.  After a restart with the
action and state columns disabled, however, I could add them to the right,
and I got a scrollbar with a bit more scroll -- AND ICONS.  The resources
were now loading!

After getting the columns to appear to the right, I restarted pan, and 
the columns were still there, at normal width.  I was then able to open 
pan prefs and reorder the columns so action and state appeared to the 
left again, and again restarted pan.  Again they stayed where I had put 
them, normal width.

Then I tried resizing columns and it was at that point that I found the 
icon columns weren't resizable.

So at this point I'm back to working reasonably normally, all columns 
displayed once again, order and widths retained over pan restarts.

But, I still haven't the foggiest what triggered the problem in the first 
place, except that it seems to be some sort of race condition, such that 
the resources for those columns weren't loaded, causing gtk to screw all 
the others up as well.

One final bit of evidence supporting the race condition idea.  I double-
checked and the update I was doing at the time was rather small, with no 
gtk or other pan dependencies, so it couldn't be a version issue there.  
BUT, I *WAS* doing a system update, with all six cores loaded rather 
heavily (gentoo, updates build from sources) and likely some disk I/O 
going on as well.

That's exactly the sort of system load conditions under which race 
conditions like to trigger!

So at this point I think it's quite likely that there's some sort of gtk2 
(at least) resource race condition, which under the right conditions, 
causes it to fail to load either the icons or some other resource related 
to pans action and state columns.  Without that resource, those columns 
end up as either zero-width or one-width, triggering other problems in 
pan as described, apparently because gtk isn't prepared for fixed-width 
columns to be 0/1 width!

For the people unlucky enough to trigger that race and end up with a 
single-column header pane, a temporary fix (until triggered again) 
appears to be:

1) Disable the action and state columns in pan prefs, headers tab.

2) Restart pan.

3) Use the drag-divider trick to readjust the width of the remaining 
columns to something sane, exposing additional columns in the process.

4) Once all remaining columns are visible, restart pan again and ensure 
that all columns remain visible at their configured width.

** Optionally (Do you value the display of those columns enough to risk 
triggering the problem again?):

5) Reenable the state and action columns again, at the RIGHT.  Verify 
that they show up at a sane width by observing the horizontal scrollbar 
if they aren't initially visible (as they weren't here).  Again adjust 
other column widths as desired, still keeping these two columns to the 
RIGHT.

6) Restart pan again, again verifying retention of column order and width.

7) Optionally, ONLY AFTER THEIR POSITION TO THE RIGHT IS RETAINED, 
reorder the state and action columns to your desired order.

8) Restart pan again, hoping/verifying column order and width retention 
once again.

9) Operate normally until the next time the race condition triggers, 
repeating this sequence if necessary.

The question now is, what's triggering that race condition, and presuming 
it's a gtk issue as opposed to a pan issue as seems likely, which 
versions are affected?

FWIW, I don't even have gtk3 installed here, so pan is built against gtk2.

Current version of gtk2: 2.24.13, built/installed Sept 26.

Previous version: 2.24.12, built/installed Sept 9.

Questions for thufir:

You mention that you're running Ubuntu 12.10, so pretty new.

Is your pan the ubuntu-shipped version, built yourself, or installed from 
a third party repo, and what version of pan is it?

(Gentoo here, pan from upstream gnome git, freshly updated today.)

Do you know if your pan is built against gtk2 or gtk3?

(Here, built against gtk2, but I suspect the ubuntu version may build 
against gtk3, which would mean it's NOT a gtk2 specific bug.)

What gtk version(s)?

(Here, gtk 2.24.13 as listed above.  It's new but I only ran 2.24.12 for 
less than a month, so the issue could have been in it and just never 
triggered, too.  But 2.24.10 was April and 2.24.11 was July, so they had 
a bit longer to trigger the problem and didn't, so I'd guess the problem 
was probably introduced after 2.24.10, unless of course that's what 
you're running and your pan is built against.)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]