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 313634 - scissor tool does not allow to create holes into selection.
scissor tool does not allow to create holes into selection.
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
2.2.x
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-08-16 13:58 UTC by heno
Modified: 2008-01-15 12:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description heno 2005-08-16 13:58:40 UTC
1. select region with scissors (large enough)
2. switch scissors mode to "substract"
3. select smaller region inside the first selection.

what happens: selection does not change.
(gimp:4716): Gimp-Core-WARNING **: gimp_channel_combine_mask: unknown operation type

expected: hole inside the first selection
Comment 1 Sven Neumann 2005-08-17 17:18:47 UTC
Actually it works if you use the modifier keys instead of the buttons but that
is of course not quite right.
Comment 2 Sven Neumann 2005-08-22 13:33:42 UTC
The problem is actually in GimpSelectionTool. The state of the buttons should be
kept separate from the state of the tool. That would fix the problem for other
selection tools as well.
Comment 3 Jeremy White 2005-08-23 16:00:29 UTC
More info: I got it to work, but it isn't intuitive. The scissors area has to
have some portion outside of the current selection. Oddly enough, it seems like
if you take ANY button state of the intelligent scissors and make an area, but
click on a portion where that area overlaps with the selection, it cancels the
intelligent scissors.

Now that I observe more carefully, I think it's because the intelligent scissors
tries to do what any other selection tool does when you hover it over a selected
area: move the selection. And when you do click on it, it cancels intelligent
scissors.

I'll assume the best fix is to have gimp stop canceling scissors and instead
move the area if the user clicks and drags, otherwise if it's a single click
then the intel scissors area is committed to the main selection.

Sound good?
Comment 4 Sven Neumann 2005-08-23 16:07:26 UTC
No, I don't think you understood the problem. The problem is actually a simple
design bug in the GimpSelectionTool class that also affects other selection tools.
Comment 5 Michael Natterer 2006-10-18 08:09:12 UTC
Fixed in HEAD. Setting milestone to 2.4.

2006-10-18  Michael Natterer  <mitch@gimp.org>

	Separate selection tool function (select, move, cut, ...) from
	selection mode (replace, add, ...). Fixes bug #313634 (that bug
	wasn't triggered any more in HEAD, but was still there).

	* app/tools/tools-enums.h: renamed enum SelectOp to SelectFunction
	and replaced the values REPLACE, ADD, SUBTRACT and INTERSECT by a
	single value SELECT.

	* app/tools/gimpselectiontool.h (struct GimpSelectionTool):
	renamed member "op" to "function". Changed "SelectOps saved_op" to
	"GimpChannelOps saved_operation".

	* app/tools/gimpselectiontool.c: we always have the right
	GimpChannelOps in the tool options, so simply use it instead of
	mixing up unrelated stuff in one enum. Results is some medium-ugly
	nested switches, but is generally much cleaner than before.

	* app/tools/gimpforegroundselecttool.c
	* app/tools/gimpfreeselecttool.c
	* app/tools/gimpiscissorstool.c
	* app/tools/gimpregionselecttool.c: changed accordingly. Use the
	operation from the tool options instead of selection_tool->op when
	making the actual selection.