GNOME Bugzilla – Bug 148389
Rotate tool does not work with numeric input
Last modified: 2004-12-22 21:47:04 UTC
Open an image Select Tools/Transform Tools/Rotate from menu In Rotation Information dialog enter 90 Click Rotate button Progress bar is shown Image does not rotate The image should rotate. Workaround: After entering 90, click the up arrow (to get 91). This will cause the grid lines to appear rotated. Click down (to get 90 again). Then click on Rotate.
This works fine here. Could you try again with the latest stable version, 2.0.3?
The spin box doesn't emit the appropriate signal (activated, I think) until either you press enter, or you press Tab to move onto the next field in the dialog. Perhaps it should do so on a keypress too... So hit Enter after changing the angle in the entry box, and you will see the grid lines update. And please note that to rotate an image by 90 degrees, it is much faster to use Layer->Transform->Rotate 90 degrees Cheers, Dave.
We should probably update the spinbox on emission of the GtkWidget::button-press-event signal. Could this be done automatically at the GTK+ level? Shouldn't value-changed be emitted on a button press? Dave.
Sorry - key-press-event looks more like what we should use.
Hmm. I still have 2.0.2 on my system (Linux, FC2), and I don't see the problem occurring as described. When I hit rotate, the image rotates. The fact that clicking the arrows works, rules out most of the obvious mistakes the reporter could be making, so it's a puzzle. Dave: a properly designed GUI should not depend on numeric entry widgets emitting signals in order for their displayed values to be used. When the user commits to an action (i.e., hits Rotate in this case), the GUI should read the values that are present in the entries at that time, regardless of any signals that have previously been sent.
Hmmm.. works fine for me too. I was expecting the grid to update as I was typing the number in the enrty. Perhaps I shouldn't have. However, when I press "Rotate", the rotation is performed according to the actual state of the dialog.
Like any other spin-button the typed-in value is only set after either the Enter key is pressed or the focus is moved out of the spin-button using the Tab key. This is fully intentional and not a bug.
I installed 2.0.3 and the same problem exists (under Windows at least), so I updated the version in the bug. This is a bug since the rotation is not performed according to state of the dialog. (It's also a bug because GIMP is doing a NULL rotation.) The typed-in value should be used when "Rotate" is clicked. If this is the intended behaviour, then there is a problem, because other dialogs do not work this way. E.g. If I open the Layers/Colors/Hue-Saturation dialog, check Preview and type in a Hue of 120, the image is not updated (unless I hit enter, tab, or change focus) however when I click OK, the image is updated with the new Hue.
I can confirm that this bug exists in windows, but it looks to me like it may be a GTK bug. The focus is supposed to switch from the spinbutton to the "Rotate" button when it is clicked, which would set the value that was typed in, but this doesn't happen. It works properly in linux, but in windows the spinbutton keeps the focus - this can be confirmed visually because the dashed outline doesn't appear around the rotate button like it should. Apparently the cause is that the rotate dialog itself isn't really getting focus after the canvas is clicked, even though the titlebar color indicates that it has; clicking the titlebar of another window and then refocusing the rotate dialog makes everything work correctly.
If that is indeed how it behaves on Win32 then that's most likely a bug in the GDK backend.
This is obviously a GDK backend issue, reassigning accordingly. Bug was originally reported against GIMP 2.0.3.
Hmm, there definitely is something odd with the Rotate dialog (and presumably others) on Windows, but to describe exactly what is hard... For me, if I choose Transform tools/Rotate from the menu, type in an amount which replaces the already-selected 0.0, don't type any Tab or Return, and then click on Rotate, it does rotate. But if I select the rotate tool from the toolbox, click in the image, again just type some digits, and click on Rotate, the image does not rotate. (And if I click again in the image, the dialog does have the amount I just entered preset in the spinbuttton, but if I then just click Rotate, it still doesn't.)
The oddity is probably (definitely?) due to the fact, that if you pop up the dialog by clicking in the image, the dialog is shown while the canvas owns both a GTK and GDK grab.
I'd say this is related to bug 137551 ("grab can block first focus-in-event on new windows"). If you click the image to bring up the dialog, type some digits, switch focus to another window and then back (so there is a focus in event and you get a blinking caret in the spin edit), and finally click Rotate, it works, at least for me.
(Sorry, Philip had already described the workaround, I should have read his comment better)
Since nobody seems to object I think it is safe to mark this as a duplicate of bug #137551. *** This bug has been marked as a duplicate of 137551 ***