GNOME Bugzilla – Bug 512233
Resizing and moving windows sometimes causes window to reset to the default window size
Last modified: 2012-04-10 19:55:11 UTC
One of the users of a program of mine just reported a problem in GTK-Quartz regarding the resizing and moving of a window. The problem is that when a window which is in a normal state (not maximized) is resized to a certain size (larger than the default size) and then moved, the window itself gets automatically resized and the window position is changed. This may sound very cryptic, but this user has created a small movie showing this behaviour. This movie is available at http://appelkaas.nl/openftd/openftd_resize_bug.mov I have tried to reproduce this behaviour with a small testprogram, but with no success yet. The window of the program shown in the movie is initialized with: gtk_widget_set_size_request 850, 600 gtk_window_set_position GTK_WIN_POS_CENTER The signal 'window_state_event' is caught, but under OSX the callback function only does a 'return FALSE'. Normally this callback is used to minimize the window to the tray, but this isn't desired under OSX.
Do you know if the app sets any restraints on the window like aspect ratio or resize steps?
This isn't the case. Just the set_size_request and the set_position are used during initialisation of the window. Any signals about a possible window resize aren't caught by the app. The app itself contains a GtkHTML widget and a lot of VBox'es, HBox'es and a GtkNotebook.
OK, thanks. I will try to reproduce this so it's easier to debug.
I have a hunch what this might be. Does the window have a resize-grip? If so, try disabling that (since OS X always draws one anyway if the window is resizable). The manual resizing clashes with the normal resizing. We should just conditionally disable the grip on OS X from gtkstatusbar I think. If you want to try it, just set has-resize-grip to false on the statusbsar.
Created attachment 103990 [details] [review] Disable event handling on the resize-grip Just attaching a quick patch to disable the event handling so I don't lose it.
Yep, your hunch was right. After calling gtk_statusbar_set_has_resize_grip(FALSE) the strange resize behaviour doesn't occur anymore.
Is there any reason that the patch shouldn't be committed as is?
Or perhaps just disabling the grip by default on osx since it isnt going to handle the event, no need to even show it.
I think that disabling the gtk+ resize grip on OS X makes sense. I am not sure what our current policy is for putting backend specific hacks in GTK+ widgets (we tend to avoid that as far as I know), so I need to check up on that.
The following two patches make the GTK+ resize grip play nice together with Quartz's native resizing. This was tested on Lion, but should work on Snow Leopard as well. After some more testing, we will push these patches into gtk+ 2-24 and as well the latest 3-x branch.
Created attachment 207982 [details] [review] Patch 1 out of 2: export break all grabs within GDK Quartz backend
Created attachment 207983 [details] [review] Patch 2 out of 2: fix manual resizing
Merged in gtk-2-24 and master.