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 421434 - warn when painting will have no effect, explaining reason
warn when painting will have no effect, explaining reason
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
unspecified
Other All
: Low enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2007-03-22 11:12 UTC by david gowers
Modified: 2018-05-24 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description david gowers 2007-03-22 11:12:06 UTC
Several times, after using the drawing tool opacity adjustment (via keyboard shortcuts), I have set the opacity to 0% accidentally, and then became completely baffled because drawing had absolutely no effect, and occasionally went to file a bug before realizing the source of the problem.

I think that either:
 a. Opacity should be limited to 1.0...100.0% (or possibly (1/2.55)%..100.0%)
 or
 b. A message should be shown in the status bar when attempting to paint with opacity == 0% -- perhaps drawing should be disabled, also.

I believe (a) or something similar is the better solution, though (b) will be less troublesome.

Most often, this has caused me problems by:
  * I finish a GIMP session, accidentally setting opacity -> 0% just before finishing
  * The opacity setting is saved
  * It is reused next time I start gimp, so I start out with 0% opacity.

So it might also be useful to force opacity settings to be >= (1/2.55).
Comment 1 Sven Neumann 2007-03-22 16:23:47 UTC
These settings aren't any longer stored between sessions, at least not by default.

Anyway, I doubt that (a) solves the problem because even if you set opacity to 1 (on a range of 0 to 255), you are likely not going to see any effect.

I wonder if it makes sense to try to deal with this at all. You could run into the same problem when trying to draw with the same color as the background. Or by using a paint mode that doesn't have any effect. Should we really try to cover all this? I vote for closing as WONTFIX because we simply can't keep the user from shooting himself in the foot.
Comment 2 Joao S. O. Bueno 2007-03-23 04:37:01 UTC
Yes, I  say there is no much point in fixing this - there at least 10, and possibly many more, other settings under which the program will not paint.

I am also, personally, agains restrictive settings. Opacity "0" may look like nonsense now, but I really want to put some effort, after 2.4 is out, in trying to implement things described in bug #119240 - and a setting of 0 makes sense as part of a opacity x (speed, angle, pressure, tilt) curve.

Back here, when I am lecturing on GIMP I usually say "several times it will happen that you try to draw, and nothing happens - you will have to understand what you are doing".

However - making the program aware of all possible "not drawing" situations, and warn this in a non-intrusive way would be extremely nifty - and IMHO, unfortunattely, extremely boring to implement. :-/

What do you both say of changing this to a more general bug saying - "warn when painting will have no effect, explaining reason", and mark that as low priority, so maybe some good soul could work on it someday?
Comment 3 david gowers 2007-03-23 07:36:11 UTC
Okay. 
I'll review some of the relevant points here:

* It's unreliable to warn, if one of the color modulating options is enabled (Use color from gradient, or Adrian Likins' patch for HSL color jitter)
* Otherwise, paint modes are fairly simple; Warn when using:
  * Add/Subtract/Screen/Dodge/Difference/Lighten Only when color == #000000
  * Soft Light when color == #7f7f7f (I think this is an off-by-one bug. It would be nice to fix it if possible, so it matches all the other drawing modes that have a full negative..neutral..positive range available (just below))
  * Grain merge/extract/Overlay/Hard Light when color == #808080
  * Multiply/Divide/Burn/Darken Only when color == #FFFFFF
Comment 4 Sven Neumann 2007-03-23 08:00:06 UTC
Painting on a layer mask is also a frequent point of confusion. It will be very difficult to catch all possibilities and it is probably not worth the effort. I suggest that no more time is wasted to discuss this any further. If someone thinks that this is doable, please show us that it is by writing a patch.
Comment 5 weskaggs 2007-11-09 03:15:14 UTC
There need not be a universal solution in order to make it worth dealing with individual cases, such as trying to erase a layer with alpha locked (see bug #446085).  How about in such a case changing the cursor to a circle with a diagonal line through it (the universal "No" symbol)?  Ideally it would be red, but it should still work even if that can't be done.
Comment 6 Sven Neumann 2007-11-09 08:41:17 UTC
Such a cursor doesn't help at all to explain the user why he/she can't paint.
Comment 7 david gowers 2009-02-07 01:53:35 UTC
Revisiting this, I wonder whether we could/should add an icon to the cursor to indicate 'editing a layer mask' or 'editing a channel'. I think this would be an improvement on the current setup where you may have difficulty finding out whether you are editing a normal layer or something else. It could also help with the selection tools' UI.
Comment 8 GNOME Infrastructure Team 2018-05-24 12:09:47 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/237.