After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 60623 - resizing problems
resizing problems
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
1.3.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 59721 60266 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-09-17 08:47 UTC by Matthias Clasen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
the screenshot (11.97 KB, image/png)
2001-09-17 08:49 UTC, Matthias Clasen
Details

Description Matthias Clasen 2001-09-17 08:47:44 UTC
The new resizing logic seems to have some problems. 
I observed them in the stock item browser in gtk-demo.
Start it up, select a few items (starting with short macros
and move to longer ones, to force repeated growth of the
selected frame.

What sometimes happens is that the toplevel is grown large enough,
but the frame stays at its previous size, so that the macro is not
displayed completely. 

Probably just somebody waiting on a (synthesized) configure event,
since moving the toplevel around using the wm makes the frame resize
properly.

I've attached a screenshot.
Comment 1 Matthias Clasen 2001-09-17 08:49:22 UTC
Created attachment 5613 [details]
the screenshot
Comment 2 Havoc Pennington 2001-09-17 14:22:44 UTC
I saw a similar bug yesterday. Basically queuing resize on a label
doesn't seem to resize its parent widgets or something. I don't know
if it's a label-specific issue or not but the test case I have is also
using a label.
Comment 3 Owen Taylor 2001-09-20 19:46:43 UTC
*** Bug 60266 has been marked as a duplicate of this bug. ***
Comment 4 Mikael Hermansson 2001-09-24 13:26:21 UTC
There seems to be lots of problems with resizing in gtk 1.3.

If you remove/hide/paned_set_position a widget it doesn't
resize automatically.

Some new examples:

1. If you hide I child widget the other widgets doesn't resize
 to the new free area. 
 
2. gtk_widget_reparent() to remove/insert the widget fails to
calculating resize.

3. gtk_paned_set_position doesn't resize if widget is realized. 
Comment 5 Havoc Pennington 2001-09-24 15:24:43 UTC
Owen investigated, it turns out that the resize code assumes all
configure requests result in a configure notify, but this is not true 
if the configure request doesn't actually modify the window size,
apparently. (Though the ICCCM seems to require it, with many WMs
including Sawfish and Metacity it isn't happening.)
Comment 6 Owen Taylor 2001-09-24 20:45:56 UTC
Fixed in CVS, I hope.

Mon Sep 24 15:09:08 2001  Owen Taylor  <otaylor@redhat.com>

	* gtk/gtkwindow.c (gtk_window_move_resize): Don't wait for a
	response back from the window manager if our size hasn't changed 
	since we won't get a response back from the window manager;
	there was code in there to do this, but it was in the wrong
	place so if the hints change and the size didn't we'd expect
	a response.

	Also, optimize the position-only-changed case by running
	the resize queue immediately, and clean up some comments
	for the changes.
Comment 7 Owen Taylor 2001-09-26 19:41:15 UTC
*** Bug 59721 has been marked as a duplicate of this bug. ***