pan-users
[Top][All Lists]
Advanced

[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




reply via email to

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