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 677765 - Rotate/Scale/Shear tool: numeric input ignored
Rotate/Scale/Shear tool: numeric input ignored
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: User Interface
2.8.0
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
: 677766 691314 695538 697438 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-06-09 16:36 UTC by GrafxUser
Modified: 2018-05-24 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Results of comparison 'Calling via shortcut ./. Calling via toolbox' (28.40 KB, image/png)
2012-09-25 19:52 UTC, Max Mustermann
Details

Description GrafxUser 2012-06-09 16:36:24 UTC
Keyboard input in the numerical input fields is ignored.

How to reproduce:
1. start the Rotate tool
2. in the tool options select 'Layer'
3. enter some numerical values into the fields, go to the next field with TAB key, confirm the dialog

This should happen:
the angle or center coordinates are changed according to the user input.

This actually happens:
Nothing. 
The preview only changes when using the up/down spinbuttons, the slider or the canvas controls.

It happens always.
Comment 1 GrafxUser 2012-06-09 16:48:42 UTC
Addition: it's the same with the Scale tool and Shear tool.
Comment 2 Michael Natterer 2012-06-09 17:50:55 UTC
Works fine here. Can anyone reproduce this?
Comment 3 Michael Schumacher 2012-06-11 19:00:17 UTC
Confirming. It works fine the first time I use this, but then reacts like described in the bug.
Comment 4 Hartmut Kuhse 2012-06-21 17:18:24 UTC
Same reaction here. But when I click outside the rotate/scale/shear - tool, so the dialog looses focus and then click in the dialog again, so it gets the focus, the dialog and its widgets behave as they should.
So the workaround is: When dialog is opened, click outside it (loosing focus) and then click inside it (gaining focus).
It can be seen: when the dialog behaves like expected, there is a little dotted line around the focused widget inside the dialog.
Comment 5 GrafxUser 2012-06-21 17:24:50 UTC
Thanks, Hartmut, it works for me!
From a technical point of view this seems to be an issue of proper GUI initialization.
Comment 6 Michael Natterer 2012-07-28 10:01:35 UTC
*** Bug 677766 has been marked as a duplicate of this bug. ***
Comment 7 Michael Natterer 2012-07-28 10:04:42 UTC
I still don't see this. Is this a windows-specific focus problem?
If yes, don't we already have some more general bug about focus
handling on windows?
Comment 8 GrafxUser 2012-08-26 12:26:00 UTC
As this is a GTK+2 related bug for sure, postponing it for the merge of the GTK3 port.
Comment 9 Max Mustermann 2012-09-25 19:52:35 UTC
Created attachment 225171 [details]
Results of comparison 'Calling via shortcut ./. Calling via toolbox'

I just tried with GIMP 2.8.2 on Win7, 32 bit and compared with the similar bug #684672. In bug 684672 the reporters enters 90° and presses ENTER, the reporter of this bug presses TAB instead. Thus both bugs are not the same.

I observed a strange behaviour, which might also be the reason that it wasn't always reproducible (beside the reproduction attempts on different OS's): 
Calling the Rotate tool via the Shift+R key shortcut, the Angle field is properly selected. Entering an angle and pressing TAB rotates the layer immediately.
Calling the Rotate tool via the toolbox doesn't select the angle field properly. It stays grayish, entering an angle and pressing TAB shows the reported behaviour. 

The Scale and Shear tools show exactly the same misbehaviour. 

See the attachment for this.
Comment 10 Moltres_rider 2013-01-07 23:39:52 UTC
same problem at my end...
Comment 11 Michael Schumacher 2013-01-07 23:41:12 UTC
*** Bug 691314 has been marked as a duplicate of this bug. ***
Comment 12 Moltres_rider 2013-02-27 01:34:26 UTC
I'd like to report that this BUG STILL EXISTS IN 2.8.4!!!!!!!! NEW VERSION AND NOT EVEN FIXED!!!!!! HMMMMPHT
Comment 13 André Klapper 2013-02-27 01:53:28 UTC
Moltres_rider: In the upper right corner you can see the status of a bug report (in this case: no "RESOLVED FIXED" status). This one is "NEW". 
In general the limited manpower of volunteer developers does not allow fixing all known and unknown bugs for the next release. So if you want a specific bug to get fixed, your patch is highly welcome.
Comment 14 Michael Natterer 2013-02-27 08:07:28 UTC
Moltres_rider: Drop that crap attituce and either be constructive
or shut up and leave.
Comment 15 Michael Natterer 2013-04-10 01:52:17 UTC
*** Bug 697438 has been marked as a duplicate of this bug. ***
Comment 16 Michael Schumacher 2013-05-10 11:02:08 UTC
*** Bug 695538 has been marked as a duplicate of this bug. ***
Comment 17 Paul Barter 2016-07-19 12:30:48 UTC
Bug still exists in 2.8.18

To reproduce
1 open image
2 click rotate tool button
3 click in image to set centre
4 type in a rotation e.g 0.5
5 click the rotate button.
It processes, but does not actually rotate. This can be confirmed by the edit/undo menu which says 'undo rotate by 0 degrees about...'

Can be worked around by pressing enter after step 4, but is very annoying.
Comment 18 programmer_ceds 2017-09-07 20:49:40 UTC
This bug still exists in V2.8.22 BUT it doesn't seem to happen in V2.9.7 (commit 0ce289876a).

In V2.8.22 I can reliably reproduce the fault:

Select Transform Tools/Rotate - the dialog is displayed with a value of 0.0 highlighted for the Angle field. Type 5 TAB TAB 1000 TAB 1000 TAB then click the Rotate button - the image is rotated as expected. Also the changes caused by the entered values are applied to the preview when TAB is used to exit an altered field.

Left-click in the image (without using the menu to reselect the rotate tool) and the rotate dialog appears with the Angle field value not highlighted. Following the same sequence (5 TAB TAB 1000 TAB 1000 TAB Rotate) has no effect on the image - either when press TAB to leave an altered field or when clicking the Rotate button.

Using the menu to reselect the rotate tool between rotates causes it to function correctly.

Following exactly the same sequence with V2.9.7 the rotate works every time without a problem when the rotate dialog is reactivated by left-clicking in the image window. Given that there are work-arounds for V2.8 perhaps this bug could be ignored since it will not be present in V2.10
Comment 19 GNOME Infrastructure Team 2018-05-24 13:13:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/406.