[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-users] gtk's spontaneous size changes Was: [latest git] Assertions
From: |
Duncan |
Subject: |
[Pan-users] gtk's spontaneous size changes Was: [latest git] Assertions hit in header-pane.cc |
Date: |
Sun, 28 Oct 2012 21:51:19 +0000 (UTC) |
User-agent: |
Pan/0.140 (Chocolate Salty Balls; GIT f91bd24 /usr/src/portage/src/egit-src/pan2) |
walt posted on Sun, 28 Oct 2012 17:42:58 +0000 as excerpted:
> gtk3 is definitely doing things differently now, and I'm not loving it
> (yet). FWIW I compiled two versions of pan, one with gtk2 and one with
> gtk3.
>
> Both versions have issues with spontaneous changes in pan's window size,
> but the gtk3 version is outrageous that way.
>
> When I read your reply to me (gtk3) pan's window immediately widened to
> occupy the entire width of my 24" monitor, leaving the entire right half
> of the body pane blank. And, the window refuses to let me shrink it
> back to normal size until I navigate away to some other pane.
>
> I thought the spontaneous widening bug involved only displaying a
> pixbuf, and with gtk2 I still think so, but with gtk3 even pure text
> posts behave that way. Awful :(
At first the only place I saw the spontaneous size changes and huge blank
spaces was prefs, colors and shortcuts. Then it started hitting all over
the place, including the bug with expanding headers columns so only one
is shown. I see a commit where Heinrich tried to fix one of them, but
they're showing up all over, now.
I don't know what the problem is, but pan's code couldn't have changed
/that/ much and be /that/ buggy in /that/ many places, so it has to be a
gtk behavior change.
In at least the single engulfing headers-column case, apparently
triggered on the icon-only columns, the problem appeared to be a race
condition, such that the icon resources weren't loading soon enough,
presumably resulting in a null value when gtk tried to calculate the
required size, width in that case.
Extending from that suggests that the problem in all cases might be a
null-value, due to resource loading race conditions or whatever else, in
size calculations. It seems that there's both a missing lock thus making
gtk vulnerable to race conditions, and a missing critical sanity test,
such that these null values translate into huge blank spaces.
@ Heinrich, Petr, or anyone else with gtk programming experience or
familiarity with current gtk/gnome bugs outside the pan scope, are any
other apps getting bug reports on such behavior?
I don't seem to see it here in firefox or claws-mail, the other two gtk2
based apps I use heavily enough to have a reasonable familiarity with,
but that doesn't mean it's not happening elsewhere, or for that matter,
in them but I've just not triggered it.
I wonder how old a gtk2 I can find to install, to see if the problem goes
away. If it does, then we know for sure it's a change in gtk behavior
and can try bisecting from there.
But surely, if it /is/ a gtk problem as seems to be the case, other apps
should be coming across the bug as well, and finding other reports of the
problem shouldn't be too difficult.
Of course, since I have pan in git already, I can try checking out and
building some ridiculously (for me) old version of it too, and try to
bisect there if that doesn't show the issue.
--
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