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