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 787253 - Closing loop on free select tool doesn't commit
Closing loop on free select tool doesn't commit
Status: RESOLVED DUPLICATE of bug 785781
Product: GIMP
Classification: Other
Component: Tools
2.9.6
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2017-09-04 13:48 UTC by Tony Green
Modified: 2017-09-10 09:37 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tony Green 2017-09-04 13:48:52 UTC
A small annoyance on the free select tool on Gimp 2.9 (confirmed with latest GIT pull, commit 82dd06720d).

With Gimp 2.8, I could click around an area and then when I clicked again on the first point, the tool would commit that selection. I was confused when testing 2.9 to find that when I did the same, nothing happened. In fact, once I'd clicked on the first point, the tool became useless and I couldn't select anything else (so I couldn't add another area).

Purely by accident I found that by hitting <return> I could make the tool commit and then could select another area.

I'm happy to use this workaround for the time being, but I imagine it will cause a lot of confusion if this behaviour persists when the next version is released, hence  this bug report.
Comment 1 Michael Schumacher 2017-09-04 14:34:27 UTC
See bug 680715.
Comment 2 Michael Schumacher 2017-09-04 14:39:15 UTC
The change leading to the current behavior was deliberate - creating a selection when (accidentally) closing the selection frame and getting rid of it was not received well by many.

The current behavior doesn't have to be the final one, notably the differences to other selection tools in regard to interacting with an uncommitted selection frame can be examined.
Comment 3 Tony Green 2017-09-04 14:40:52 UTC
(In reply to Michael Schumacher from comment #2)
> The change leading to the current behavior was deliberate - creating a
> selection when (accidentally) closing the selection frame and getting rid of
> it was not received well by many.
> 
> The current behavior doesn't have to be the final one, notably the
> differences to other selection tools in regard to interacting with an
> uncommitted selection frame can be examined.

Fair comment. I can live with it if that's the case. Thanks.
Comment 4 Jehan 2017-09-10 09:37:16 UTC
Let's consider this as a duplicate of bug 785781 where we discuss alternative ideas for this interaction.

*** This bug has been marked as a duplicate of bug 785781 ***