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 785781 - Additional Free Selection step (hitting Enter) is a regression in common cases
Additional Free Selection step (hitting Enter) is a regression in common cases
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
: 784772 787253 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-08-03 15:37 UTC by Jehan
Modified: 2018-01-03 08:12 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jehan 2017-08-03 15:37:54 UTC
1/ Having to hit Enter is annoying when you don't work with the keyboard/mouse as your main input devices. In particular with a tablet, having to go up to the keyboard to hit Enter at each selection is time/movement consuming.

2/ Being able to edit complicated selection is cool, and is a killer feature. Yet this is useless most of the time. For the 1 time where it saves you time (from not having to redo a complicated selection with many points), there are 99 times where you were just doing a quick and dirty selection and don't want to bother with the additional commit step.

Just an idea, couldn't we have the selection committed by default, yet with a way to enter an edit mode (Esc?) which goes back to editing selection points for further moves and modifications?
Comment 1 Michael Natterer 2017-08-03 17:05:25 UTC
I found the old behavior pretty much unusable, and many people on IRC
agreed that they all the time lost a free select outline because they
accidentially closed the shape.
Comment 2 Jehan 2017-08-03 17:12:17 UTC
I'm not saying to revert to previous status. I think we can have the best of both world. Hence my finale proposition: by default create the selection directly, yet keep track of the last outline and allow to get back into edit mode (allowing to modify the outline, add or remove nodes, whatever…).
Comment 3 Jehan 2017-08-03 17:22:55 UTC
> many people on IRC agreed that they all the time lost a free select outline

P.S.: and what you say definitely happens a lot, no dispute there. But as I said in my description, for the 1 time it happens, you will do 99 easy selections with no problems. You know better than anyone that people don't complain about things that work, only about when they don't, therefore "many people on IRC agree" is certainly *not* a valid argument. ;-)

So since most of the time it works, I believe the default should be the one with 1-less step, *BUT* your feature should stay there and it should be possible to get into "edit mode" (so that they day you lose your outline by accidentally closing the shape, you can just update it).

Alternative even better: the edit mode should be the same as the selection mode. For instance, when you create a rectangle selection, you can still edit its size and you don't have to "commit". Why should it be different with free select?
Comment 4 Michael Natterer 2017-08-03 18:10:04 UTC
I would rather not duplicate the horrible rectangle select undo code
that makes this possible at all, we don't need new bugs :)

Maybe simply a double click to commit the shape to a selection,
additionally to enter?
Comment 5 Jehan 2017-08-03 20:05:30 UTC
> I would rather not duplicate the horrible rectangle select undo code

Well… what about writing such a code in a non-horrible (if not beautiful!) way? ;P

> Maybe simply a double click to commit the shape to a selection

Yeah that was my first proposition on IRC, though I didn't write it in the bug report because — after more thinking — I decided that it would be even better if we didn't have to commit.

If you really don't think a direct commit (while still allowing edit, like for rectangle/ellipse select) is feasible right now, then I guess double click to commit is an acceptable trade-off. At least for now, until we manage to improve this interface while still keeping clean code.
Comment 6 SenlinOS 2017-08-04 01:37:22 UTC
I mentioned it before: 784772 :)
The way I use it now is to press the Enter key without connection, direct completion operation.
Comment 7 SenlinOS 2017-08-04 02:27:04 UTC
(In reply to Michael Natterer from comment #1)
> accidentially closed the shape.

I want the cause of the accident: Is Double-Click
PenTablet is very easy to cause double-click operation.

In the "options" way, maybe better.
The options, Such as:
--Auto-Close
--After the connection, the adjustable nodes  (Now this new feature)
Comment 8 Jehan 2017-08-06 10:49:26 UTC
> Is Double-Click PenTablet is very easy to cause double-click operation.

I guess that will be true. Therefore double-click may indeed not be the best idea for tablets as well.

As for the main issue, I had the issue today again. I was doing a free selection around a small piece of an image, hit ctrl-c, then ctrl-v to do a quick copy-paste, and… it actually copied the whole layer! Since the free selection was actually not active, it was as if everything was selected.

Of course one could claim that's just about being used of how the free select tool now works, but that is the only selection tool which works this way. All the other selections, even the ones which still allow edits (rectangle, ellipse) are instant. I really think we need to find a way to make the free select instant as well while still allowing edits.

Just watch any video of photography editing, the free select tool is one of the most common selection tool used, and in most cases, you are just doing a quick and dirty approximate selection around an object. So this is the main case to take into account IMO, not the case where you want accurate handle position (which we should also take into account, but it should be the particular case, not the other way around).
Comment 9 Jehan 2017-09-10 09:37:16 UTC
*** Bug 787253 has been marked as a duplicate of this bug. ***
Comment 10 Jehan 2017-09-10 09:40:26 UTC
For info, last I heard for Aryeom, she said she was getting used to the new behavior. So we'll hold the rants for finale opinion. ;-)

This said, having the possibility to always come back to an "editing mode" even after having committed the free selection would be a very valuable interaction nonetheless.
Comment 11 Thomas Manni 2017-11-16 21:06:52 UTC
A simple solution would be to add an option checkbox : "select on shape closing" (or something like this).
Comment 12 Jehan 2017-11-19 15:15:48 UTC
I'll just push this to 2.12 for now. It's not unusable and we can take more time to think on a proper solution.
Comment 13 Jehan 2017-11-24 13:06:36 UTC
Uh. While using a Wacom Mobilestudio (basically a tablet-computer with no keyboard), we just realized a use case where this is very annoying! No keyboard = no Enter key! So when we do a free selection, we can't confirm it.

Actually it's not entirely true. The Wacom Mobilestudio has 10 configurable buttons on the side. So we could map one of the button to Enter, but that means unmapping another shortcut. In the end, 10 buttons only is very small.

So a way to confirm the selection without a keyboard would be very good. Actually as a general rule, we should not have any action which can be done only with the keyboard.
Comment 14 Michael Natterer 2017-12-01 21:22:58 UTC
Let's call this FIXED by implementing double click to commit:

commit d60c237805ac2d4018a20cf7acbad6bf4e33b622
Author: Michael Natterer <mitch@gimp.org>
Date:   Fri Dec 1 22:19:42 2017 +0100

    Bug 785781 - Additional Free Selection step (hitting Enter)...
    
    ...is a regression in common cases
    
    Commit the free select tool on double click inside the polygon.
    
    Done by implementing GimpCanvasItem::hit() in GimpCanvasPolygon, using
    ugly code.

 app/display/gimpcanvaspolygon.c | 46 ++++++++++++++++++++++++++++++++++++++++++
 app/display/gimptoolpolygon.c   |  6 ++++++
 app/tools/gimpfreeselecttool.c  | 22 +++++++++++---------
 3 files changed, 64 insertions(+), 10 deletions(-)
Comment 15 Michael Schumacher 2018-01-03 08:12:51 UTC
*** Bug 784772 has been marked as a duplicate of this bug. ***