GNOME Bugzilla – Bug 345541
Intelligent scissors inconsistent with other selection tools (usage of Shift, Ctrl)
Last modified: 2018-05-24 11:51:19 UTC
Please describe the problem: Contrary to all other selection tools, the intelligent scissors ignore the initial state of the Shift and Ctrl modifiers that are used to choose between the modes replace/add/subtract/intersect. The state of these modifiers is only considered once the path is closed and converted to a real selection. The current status bar messages used for iscissors are similar to all other selection tools and could lead the user to believe that the pressing Shift or Ctrl before the first mouse click is sufficient. However, this is not the case here. The user must either keep them pressed all the time, or remember to press them (again) just before converting the iscissors line to a selection. For consistency reasons, it would be better to modify iscissors so that it behaves like all other selection tools: consider the initial state of the modifiers, not their final state. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
For intelligent scissors, it really doesn't make any sense to look at the state of the modifier keys before the user has even started to draw the selection outline. Just like the SIOX tool, the modifier keys are relevant when the Enter key is pressed to convert the selected area to a selection. That's when the selection is actually created, so there's no inconsistency. We just need to make sure that the statusbar messages are shown at the right time.
I disagree because I think that most users would expect the initial state of the modifiers to be relevant (like for the rectangle/ellipse selection tools and others). Relying only on the final state could be confusing if modifiers can also be used for something else while the points are being defined. For example, a modifier (Ctrl?) could be used to delete a point instead of adding a new one. I will soon post a message to the gimp-developer list about the status bar messages and I think that they would be easier to understand if the initial state of the modifiers is taken into consideration for all selection tools. Other tools such as the zoom tool (magnify) and the transform tools also consider only the initial state of the modifiers and ignore subsequent changes while the user is clicking/dragging.
Indeed, this is exactly what I expected - to be able to create a negative selection to remove a portion of a previous selection I had made with the scissors, just like I can do with any other selection tool. I see both sides of this argument though. My suggestion is that the intelligent scissors tool be turned into a path tool instead, and then let the user turn that path into a selection. Because that is *almost* what it is not. Currently it fails to be either a selection or a path.
Sorry, typo. ... *almost* what is is now. ...
*** Bug 766397 has been marked as a duplicate of this bug. ***
Additionally, IScissors should use Backspace to remove the last placed node to be consistent with the Path tool.
The last request is done now: commit 7c29077acd459b091ff41846c564074d4b1d9408 Author: Michael Natterer <mitch@gimp.org> Date: Tue Nov 8 13:45:12 2016 +0100 app: allow to remove the last added IScissors segment with backspace app/tools/gimpiscissorstool.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
-- 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/197.