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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
