I really like the new-pan "size-to-fit" feature, i.e. where it shrinks
big pictures to fit in the body pane. However it has an annoying bug:
With some pictures it goes into a never-ending "oscillation", i.e. it
keeps jumping between two different sizes (of course you can stop it by
clicking on the picture to turn off size-to-fit, but then you end up
with the un-shrunken picture that doesn't fit...).
Here I can't point to a sample post that exhibits the problem, since it
depends on the size of the body pane, i.e. individual setup - but it can
be reproduced with almost any picture posting, by resizing the body pane
such that the picture/posting more or less exactly fills the body pane,
*both* width-wise and height-wise. What happens is essentially:
1) The picture is resized to fit in the initially empty body pane.
2) Due to the complete posting display being slightly higher than the
actual picture (in some cases much higher, e.g. if the posting
includes a chunk of text or multiple pictures), it doesn't fit
height-wise, causing the creation of a vertical scrollbar.
3) With the vertical scrollbar in place, the available width in the body
pane is smaller than it initially was, causing a new resize-to-fit to
a smaller size still.
4) After the resize in 3), the *height* of the total posting is smaller
too, such that the vertical scrollbar is no longer needed - so it is
removed.
5) With the vertical scrollbar gone, the available width in the body
pane is bigger again, causing a new resize-to-fit to a bigger size.
6) Go to 2).
I can't really see a "proper" fix for this problem - the one I've come
up with (below) simply limits resizings to 1 per second, which is rather
"hackish", might conceivably not fix the problem on a really slow
system, and for the problematic pictures semi-randomly ends up with a
size that is either slightly "too small" or slightly "too big". However
it does seem to reliably prevent the "oscillation" on my test box, while
still allowing the picture size to follow manual resize of the body pane
reasonably well. And there is "prior art" in the same source file:-)
(dealing with double-click on links - though there a timing-based
solution is "proper", I think).
--Per Hedeland
--- pan-0.106/pan/gui/body-pane.cc.ORIG Wed Aug 2 22:30:30 2006
+++ pan-0.106/pan/gui/body-pane.cc Tue Aug 8 00:47:44 2006
@@ -1078,6 +1078,16 @@
gboolean text_size_allocated_idle (gpointer p)
{
+ /* this is a crude way of trying to prevent that changed allocation due
+ * to addition/removal of scrollbar(s) causes eternal "oscillation". */
+ static time_t last_alloc_time (0);
+ const time_t this_alloc_time (time (NULL));
+ if (this_alloc_time == last_alloc_time) {
+ text_size_allocated_idle_tag = 0;
+ return false;
+ }
+ last_alloc_time = this_alloc_time;
+
GtkWidget * text (GTK_WIDGET (p));
// get the resize flag...
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
