GNOME Bugzilla – Bug 309373
Keyboard shortcut for scaling an image in "Scale image"-dialog not working correctly
Last modified: 2008-01-15 14:04:04 UTC
Please describe the problem: When only one new dimension (width or height) is set, the Scale image dialog just closes without scaling the image after using an keyboard shortcut for the Scale-button (ALT+S). Clicking the button with mouse works well, ie. it computes the other dimension if appropriate, and scales the immage properly. Steps to reproduce: 1. Open an image 2. Open the "Scale image"-dialog 3. Enter new width or height (not both) and press the keyboard shortcut for the Scale-button imadiatelly Actual results: The scale image dialog disapears without scaling the image Expected results: 1. the dialog computes the other dimension when needed ("closed chain"-button) 2. the image gets scaled 3. the dialog disapears Does this happen every time? yes, I even tried EN and CZ language versions to find if there's possibly any difference - there is no difference. Other information: Following the same steps as above with the only difference in clicking the Scale-button except of using the keyboard shortcut works well. Also just pressing TAB or ENTER key before pressing the shortcut for the Scale-button resolves this problem.
We probably need to add an API to GimpSizeBox that updates all values from the associated entries. At the moment GimpSizeBox is only updated when an entry is actually changed. As long as the focus is still in the entry and the user hasn't pressed Enter, the entry is still being edited and no changes are notified. I take it that this problem also exists in GIMP 2.2 ?
This problem also is on the cvs version, the problem is that the event of update don't "fire" when you press the shortcut, the problem lies in this part: case GTK_RESPONSE_OK: g_object_get (private->box, "width", &width, "height", &height, "unit", &unit, "xresolution", &xres, "yresolution", &yres, "resolution-unit", &resolution_unit, NULL); (about line 233) in gimp/app/dialogs/scale_dialog.c I've noted that when you enter in the callback, the changed callback is called, but of course, the values aren't changed; I've solved in a dummy way, with: gtk_widget_set_sensitive the following code is the replacement case GTK_RESPONSE_OK: gtk_widget_set_sensitive(dialog, FALSE); g_object_get (private->box, "width", &width, "height", &height, "unit", &unit, "xresolution", &xres, "yresolution", &yres, "resolution-unit", &resolution_unit, NULL); Of course, maybe other calls to the widget could fire the past events, but what could be the best?. Regards,
Looks like a dirty workaround and I don't see why calling gtk_widget_set_sensitive() should actually cause an update. If it does, that would be a side-effect of GTK+ that we would better not rely on. On the other hand, this could be a reasonably workaround for the stable branch and I would like to see this fixed for 2.2.9.
What I think it's happening, it's the following: the event "changed" of the entry it's not "fired" because the first event is the event of response, but in fact when the focus leaves the entry, the event should be fired (and that happens if don't press the shortcut), but the first event is "response", that's why when it's called the gtk_widget_set_sensitive, the queue of past event's is fired, but none of these events change the data because it was saved previously. Yes, we need to know if this is a side-effect of GTK.
Well, it is pretty obvious what is going wrong here, that is not the problem. The problem is to identify where this is best being fixed. I think this is actually a GTK+ bug and I think that GTK+ used to behave differently here. When the OK button is activated using the mnemonic, this should be equivalent to pressing the OK button with the mouse. There is even feedback that indicates this equivalence to the user. It seems that GTK+ doesn't move the focus to the OK button though. If it would be doing that, the focus would move out of the entry and any changes done to that entry would become effective. We should verify this and if it is indeed a GTK+ problem, have it fixed there.
Created attachment 50904 [details] [review] possible fix in GtkButton, untested
Fixed in HEAD. I don't really think that's fixable in 2.2 without changing all affected dialogs manually. Leaving open anyway. Opinions? 2006-01-03 Michael Natterer <mitch@gimp.org> * libgimpwidgets/gimpdialog.c (gimp_dialog_init): connect to our own "response" signal so our callback is the first one called. (gimp_dialog_response): let the activated widget grab the focus, so input fields which update their model and/or constraints on focus_out are properly recalculated. Fixes bug #309373.
Since 2.4 is coming up shortly, it does not make sense to do so much work to fix a relatively small problem in 2.2. Resolving as FIXED accordingly, and setting target to 2.4.