Kevin, can you reproduce this with 1.2*? I'm currently trying
with plain 1.2 and can't following exactly your steps.

I have reproduced this on 1.3.0. Just to let you know it's not dead :)

Dave Neary

I confirm that the bug exists in 1.2.1, and I confirm the steps to
reproduce the problem:
1 - Create a new image, size 1x63
2 - Scale to 10x630.  For a fraction of a second, the window is
    apparently resized to 10x630 (hard to tell because it happens
    so fast), but then it is immediately resized back to the same
    size as before.  This is already suspicious.
3 - Undo.  The window is apparently resized and moved twice, and
    the following error is displayed:

    Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate
widget with width 198 and height 65095

I could reproduce this (with exactly the same errors) on two
platforms, both running gimp 1.2.1:
- Solaris 2.6, OpenWindows 3.6, fvwm 2.0.43
- Linux (SuSE 6.4 + Helix Gnome), XFree86 3.3.6, sawfish 0.36

I don't know what you gave Wilber to smoke but it works
fine here for me with GIMP 1.2. I'm using it remotely but
cannot see any of the mentioned effects or errors. Maybe it's
a windowmanager issue? I'm using enlightenment BTW.

This is not a window manager issue.  I just tried the following
window managers with the Gimp 1.2.1 (Helix RPM under Linux or
compiled from sources under Solaris) and the Gimp displays
exactly the same error message with all of them:
- twm
- sawfish 0.36
- fvwm 2.0.43
- enlightenment 0.16.3

When you follow the steps described above, what happens in step 2?
Do you get a large window containing the 10x630 image or does it
have the same size as before?

Another update: I tried the same operations with an old version of
the Gimp 1.0.0 under Solaris.  No problem.  The window is correctly
resized in all cases, and no error is generated during the undo step.

So this looks like a bug that was introduced at some point in time
during the 1.1.x development and it is still there in 1.3.0, but it
apparently depends on some external conditions because some people
are not affected.

Under 1.2 and under HEAD the result is always the same:
a proper scaled 10x630 image displayed with a zoom factor < 50%.

Yet another comment...  This may (or may not) be related to the
version of GTK+ used.  Dave Neary and I are using 1.2.8.  Daniel,
which version of GTK+ are you using?

This bug may also be related to bug #50867, which also happens
with a 1x63 image.  But in contrast with #50867, this one also
happens with other sizes than 1x63 or 2x63.  I got the same error
with image sizes like 3x63, 10x63, 10x10, 63x63, 64x64, 65x65,
70x70, 100x100, ...  but not with 100x200, 256x256 or anything
larger.  So maybe this is something completely different.

I'm using gimp-1.2.1, gtk-1.2.8, fvwm-1.24r
and I can't reproduce this.

I see the ephemeral resize at stage 2 (and agree, it looks
about right for 10x630), but I never get any GTK warnings.

Its still a bug, since there shouldn't be the extra resize.

Austin

Created attachment 302 [details] [review]
This forces window resizing by calling gtk_widget_set_usize() on the contained widget.

This is almost certainly a window-manager specific error. There is a
call to gdk_window_resize() where the success or failure of the call
is not checked, and the Gimp plods on assuming the new window was
allocated. The fix is a hack which forces resizing of the window. 

The best solution would be to handle the possibility of the new window
not being allocated and living with it. This bug is directly related
to both bug #50867 (which was discovered while trying to fix this bug)
and bug #13926.

Re-writing gdisplay_shrink_wrap() and crop_buffer() to handle failed
window resizes is the best way to handle this, and the related, bugs.

Pardon my slip of the hand - the related bug is 13296. 

Dave Neary.

I have applied your patch to my copy of gimp-1.2.1 (offset by 3 lines)
and the problem is indeed gone.  In step 2, the image window is
correctly resized to 10x630, and the following undo works as well.
So it looks like your patch solves the problem, and someone should
consider adding it to CVS (both HEAD and 1.2 branch) so that we can
close this bug.  However, the comments in bug #13296 (which is
directly related to this one) make me think that other problems could
occur with the crop tool.

Maybe we should also test the Gimp with a window manager that is
specially configured to constrain the image windows to a fixed size
(or a maximum size that is smaller than the screen size).  That would
probably reveal other bugs, although I do not know which window
manager would allow such options.  Any ideas?  If we do not find a
way to test this, we could at least apply your patch and close this
bug, but leave #13296 open until we can test it.

By the way, this bug is certainly related to bug #13296, but probably
not related to bug #50867, because the latter can be triggered even
if you do not rescale the image (so it is probably related to the
tile management in the plug-in previews and has nothing to do with
this resize bug).

Re-assigning all Gimp bugs to default component owner (Gimp bugs list)

Apparently, this patch was not applied to the stable branch so the bug
is still present in 1.2.3-pre2.  I just got the following GTK warning:

Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget
with width 65442 and height 593

I haven't applied the patch because I don't think it is a valid fix.
We shouldn't use GDK functions at all to achieve our goal here since
the overlying GTK+ layer makes certain assumptions about the size of
the GDK windows it controls. Changing the size of the GDK window
directly will break those assumptions and lead to strange errors (like
the one we observe here).

Overall the code that does resizing of the image window is very
fragile and definitely wrong. Changing it in order to fix the szenario
described here will however most certainly break it for other usage
patterns. It'd only risk to do change this code in the stable branch
if there was a reasonably complete suite of test cases and if we'd
have enough time to test the change. This is something we might
consider doing for 1.2.4.

For GIMP HEAD, I'd suggest a complete rewrite of these functions
especially since most of the GTK+ and GDK functions involved here are
deprecated in the GTK+-2.0 API.

About testing Gimp with a window manager that constrains sizes: Use
Ion (see my comment to bug 13296). Gimp breaks horribly, which is a
pity as Ion would be the perfect window manager to run Gimp under.

Breaks horribly how, exactly? In that it assumes resizes always succeed?

Is there any reliable way to obtain the real window size & placement
from the window manager after a resizing request? I was assured that
there wasn't when I asked way back when...

In any case, this is a symptom of bug 13296, so I'm marking it as a
duplicate.

Dave.

*** This bug has been marked as a duplicate of 13296 ***

I would like to be able to track this problem separately from bug
#13296 because the visible errors are different here (even if both of
them might have the same origin).  So I am re-opening this bug report.

I am not sure about what haferfrost@web.de means by "breaks horribly"
but I just tested gimp-1.2.4-pre2 (with gtk-1.2.10) and I still see
the following error message:
Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget
with width 212 and height 65279
This happened after I created a 10x200 image, scaled it to 100x2000
and then hit Ctrl-Z.  In some cases, the display is confused and some
parts of the image are not drawn in the correct position (I saw that
ugly effect a couple of times, but I do not know how to reproduce it).

Regarding how to get the size and placement of an image after resizing
it, the only way AFAIK is to use gdk_window_get_geometry(), as I wrote
in bug #13296.

This seems to be fixed in the HEAD branch. What we did there is that
we don't use any GDK functions at all to resize the window but simply
call gtk_window_resize().

The lack of gtk_window_resize in GTK+ 1.2 makes me think that it's not
feasible to reliably resize a window with said version, so if this
hack gives a better solution than leaving the code as is then it
should be reconsidered for 1.2. The patch solves bug #57952 as well.
If it's not going to be applied then I think this bug and #57952
should be resolved as WONTFIX for the reasons given by Michael
Natterer in bug #13296.

I'm tempted to say WONTFIX here since any change is likely to break
the behaviour with other window managers. We can not possibly test all
combinations, so it's probably best to not touch this code at all.

Agree with Sven. WONTFIX.

Dave.

*** Bug 57952 has been marked as a duplicate of this bug. ***