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 61019 - add a 'lock' flag per layer to protect it
add a 'lock' flag per layer to protect it
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
git master
Other All
: Normal enhancement
: 2.8
Assigned To: GIMP Bugs
GIMP Bugs
: 119238 119737 329282 559033 614066 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2001-09-23 20:32 UTC by Ed Halley
Modified: 2012-09-10 15:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Skeleton for implementation (13.71 KB, patch)
2006-10-19 23:19 UTC, Martin Nordholts
none Details | Review
Refined skeleton patch (13.50 KB, patch)
2006-10-22 18:36 UTC, Martin Nordholts
committed Details | Review

Description Ed Halley 2001-09-23 20:32:00 UTC
It would be very handy to have a toggle flag for 'lock' for each layer. 
The effect of a lock is to make that layer unmodifiable or read-only.

If a layer is locked, a lock icon would appear in the Layer list, much like
the eye and move icons appear.  The ordering of the locked layer in the
stack is still possible, and the visibility flag of the layer can be
flipped, but no other changes can be made to the layer's contents or other
attributes.

If a layer is locked, it would not considered for automatic layer selection
hit-testing, but would be painted/composited as usual in the display.

This is useful when building complex compositions; as each layer is
completed, it is made read-only to avoid accidental changes, such as moving
the layer or painting on the layer.
Comment 1 Alan Horkan 2003-07-23 18:41:21 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 2 Henrik Brix Andersen 2003-08-06 10:13:17 UTC
*** Bug 119238 has been marked as a duplicate of this bug. ***
Comment 3 Raphaël Quinet 2003-08-13 09:25:36 UTC
*** Bug 119737 has been marked as a duplicate of this bug. ***
Comment 4 Alan Horkan 2004-08-03 20:43:59 UTC
Some screenshots of how this is done in Adobe Photoshop  which might provide a
useufl reference
http://www.arraich.com/elements/ref/images/layers_linkedLocked.gif
http://www.dwphotoshop.com/photoshop/classroom/layers.gif

This page includes a useful description, you can lock 
opacity/transparency, painting/image editing, movement of the layer or lock all  
http://www.arraich.com/ref/aapalette_layers6.htm

I would assume that this feature request wants to be able to lock all (and that
more fine grained control would be a bonus, that could probably be left to
another bug).  
Comment 5 Aleksander Adamowski 2004-08-19 13:33:11 UTC
Yes, lack of this feature really stands out, especially in Gimp 2.0 which is so
feature-full, but lacks this simple usability enhancement that's present in all
major commercial programs like Photoshop or Photopaint...
Comment 6 Patrick 2005-06-27 20:11:27 UTC
Still not in the current version. I think it's a important function !
Hopefully someone is taking up this enhancement. 
Comment 8 Patrick 2005-07-01 09:49:06 UTC
Great there're working on it. I'm sure they are able to manage it....!
Comment 9 Sven Neumann 2005-07-26 14:34:09 UTC
Well, for the moment, it appears that noone is working on it. Pedro has vanished
after his proposal was discussed on the list. Mitch even already prepared the
user interface for the addition of more lock toggles. So basically what's left
to be done is to actually implement locking.
Comment 10 Casey Stanley 2006-01-31 01:08:47 UTC
Oops, suprised that i didn't notice this bug before reporting, makes Bug 329282 probably a duplicate. ^^;
This bug seems to suggest to fully lock a layer from being modified, while my bug was asking to move only the transparency lock flag.
Perhaps a a single flag instead that could be toggled from; lock transparency, read-only layer, unlock layer would be better, though i'm currently unsure about that useage. (does seem very strange)
Having two seperate lock flags beside the visibility actually might also take up more space and be confusing.
When i think about it now, the new unused space from the Gimp 2.3 actually might be usable and more better.
Could the space be used to have a dropdown menu the same as the layer blend mode, where the user could select the type of lock on a layer?
That would possibly allow addition of more lock types in the future.
Comment 11 Sven Neumann 2006-01-31 11:48:13 UTC
*** Bug 329282 has been marked as a duplicate of this bug. ***
Comment 12 Amar Takhar 2006-04-03 18:37:15 UTC
Is anyone activly working on this feature?

This is a feature I've been wanting in the gimp for years -- I'm sure I'm not the only one as well.  With all the features the gimp has been adding the lack of layer locking ability is really sticking out like a sore thumb.

I'm aware the life of a developer is a busy one just curious if anyone out there is activly looking into this still :)
Comment 13 Patrick 2006-04-04 08:29:52 UTC
Still waiting for this feature....
Hopefully someone could take up this point....
Comment 14 stz web 2006-08-15 20:12:59 UTC
It would be such a usefull feature, it's sometimes very uneasy to handle numerous layers without locking some you still need to see.
Comment 15 Martin Nordholts 2006-10-19 23:19:31 UTC
Created attachment 75045 [details] [review]
Skeleton for implementation

I am going to make an attempt at implementing this. I am uploading this patch to signal that there is a person who works on implementingthis, and to provide a skeleton for a solution in case I fail (which I hope I don't, and don't think I will)

NOTE: The patch adds a temporary checkbox below the transperacy lock checkbox in the layer list widget, but this is only temporary! As Simon Budig and others stated in the mailing list discussion which was refered to above, I also think it would be far better to enable one to see the locked state of each layer independently of which is selected, i.e. this button should probably be put next to the visible and chained icons. That will be another issue though, once the logic behind the content lock is in place.
Comment 16 Michael Natterer 2006-10-20 08:48:02 UTC
It should not go below "lock alpha", it should go right of it. Having
an additional column in the tree will take up too much space IMHO.
Also, it should push an undo exactly as lock alpha, and I think
"lock pixels" would be better, but i'm not entirely sure here :)
Comment 17 Martin Nordholts 2006-10-20 12:06:36 UTC
The placement of the Lock checkbox/icon is quite a tough decision I guess, IMO it should be on each layer, to enable one to easily and quickly toggle locked layers. But let us postpone this discussion of the placement until a descision must be made.

I was a bit unsure if pushing a lock onto the undo stack would make sense since once you have locked a layer, the only way to unlock it should be by explicitly unlock it. If it would be undoable, you might accidentally unlock it if, say, you undo a bunch of paintstrokes "too far", and the reason we want locks in the first place is to prevent you from accidentally change the layer. I failed to find a mailing list discussion on this issue, but since this is easily modifyable, we can postpone this dicussion and decision as well.

Yeah, lock pixels is a better name than lock content, I will change that.
Comment 18 Sven Neumann 2006-10-20 18:56:39 UTC
We explicitely moved the Lock Alpha check-box there to make room for other Lock types. I don't think we need to have this discussion again.
Comment 19 Martin Nordholts 2006-10-22 18:36:49 UTC
Created attachment 75211 [details] [review]
Refined skeleton patch

Unfortunately the changes involved to implement this is too numerous for me to do currently.

Here is the skeleton patch which will probably be useful for anyone who makes an attempt att implementing this.

Changes compared to the other version:

 * Uses 'pixels' instead of 'content'

 * Moved the pixels lock checkbox up a row
Comment 20 Nick Smith 2007-06-04 15:26:57 UTC
I'd find this enhancement very handy.  I tend to get dozens of layers.  Take my character for my games as an example.  He has nearly 100 different arrangements and each has 3 layers, one temporary.  For standing, there's one for facing left and right, the lighting layer in grayscale (temporary), then another with the grayscale values as the alpha as all-black for the actual lighting.  That's 6 layers for the stand state alone, two temporary ones.  If I, for example, spot a mistake in the facing-left one, I'd switch to that layer and make the change, but it's likely I'd forget to change back to the layer I intended to be working on and thus I'm editing the wrong layer unexpectedly.  That's just an example.  In another case, I use a temporary layer as a palette for choosing colors off of and I've made unwanted edits to that layer a few times.  I find it annoying when I'm editing in a layer I'm not expecting to to find out I need to undo what I did (or copy/paste into the correct layer if possible).  I would appreciate the inclusion of the layer lock feature.

Anything that doesn't modify the pixel color data (such as the layer visibility, layer opacity (using the slider on the layers window only), making selections in the layer, or the colocube analysis filter) should be allowed since they don't modify the actual pixel content information.

The only method for layer locks that I can think of would be to compare the pixel color values after a change.  If unlocked, the new values can be used, but if locked, then the old edits are reverted as if nothing happened.  It's as if drawing outside the image's boundaries - nothing happens.  I have insufficient C programming skills to be able to do this, but I can come up with algorithms and methods quite well.

I also see a potential problem with not adding a layer lock change to the undo history.  Let's say you made some changes to a layer, then lock it going to another layer.  You edit a bit, but spot a mistake in the recently-locked layer.  You hit control+Z a few times, but when it comes to undoing something that would be present in the locked layer, a change would occur and if locked, the change wouldn't occur.
Comment 21 tomr 2008-10-28 19:35:22 UTC
If you'd like to sponsor this feature, please take a look at:

http://www.fossfactory.org/project.php?p=p131

FOSS Factory would like to get $ behind important-but-neglected bugs like this!
Comment 22 Martin Nordholts 2008-11-03 07:09:46 UTC
*** Bug 559033 has been marked as a duplicate of this bug. ***
Comment 23 Michael Natterer 2009-08-20 11:15:12 UTC
Added a "lock_content" property and API to GimpItem and a toggle to control
it to the layers, channels and paths dialogs. Not closing as FIXED until
the new flag is actually honored.

Stuff was based an Martin's patch attached here.
Comment 24 Michael Natterer 2009-08-20 11:16:09 UTC
This will definitely be in 2.8
Comment 25 Michael Natterer 2009-08-20 11:17:13 UTC
Comment on attachment 75211 [details] [review]
Refined skeleton patch

Marking as committed because I copied most parts of it while hacking the stuff.
Comment 26 Michael Natterer 2009-08-20 20:53:53 UTC
After a couple of more commits I call this enhancement request FIXED.

There are remaining issues but these will be fixed soon or shall
be filed as new bugs.
Comment 27 Gregory Perry 2010-03-27 00:17:48 UTC
*** Bug 614066 has been marked as a duplicate of this bug. ***
Comment 28 Sergei Stolyarov 2010-07-30 04:56:44 UTC
What about locking layer movements?
Comment 29 Eric Toombs 2012-09-08 01:21:35 UTC
> What about locking layer movements?

Да, точно, Сергей! Yes, exactly, Sergei! If you're going to lock a layer, LOCK it. In every other sane piece of image editing software, that means locking the layer's movement! It's been 11 YEARS since this has been brought up as an issue and we're still making due with half-measures. It's an embarrassment to FOSS. This is not a resolved issue yet. Not until movement locking is implemented. Only then will GIMP have caught up with the turn of the millennium! (In reply to comment #28)
Comment 30 Michael Natterer 2012-09-08 06:51:11 UTC
So, Eric, have you done fucking anything to help resolve the situation?
Have you contributed a patch, or done ANYTHING, except insulting us?
This is so lame I can't believe it. Be constructive or leave.
Regards from the last millennium.
Comment 31 Eric Toombs 2012-09-10 00:05:29 UTC
I'm not criticising you, personally. I am criticising software. You are the one who is taking it personally. And yes, I have done something constructive to help resolve the situation, by pointing out that the situation has not yet been resolved, as the bug's status erroneously indicates.
Comment 32 Alexia Death 2012-09-10 07:13:13 UTC
GIMP is not a company or a thing in itself. GIMP is people who make it and if you look at the label behind his name, you can probably see why he takes your insults personally. And while we like constructive criticisim, yours is not it... Look at comment #26 for how to proceed if you are unhappy with current solution. Politely please.
Comment 33 Michael Natterer 2012-09-10 07:51:20 UTC
Yes, it's indeed very constructive to call our lack of time and
resources an embarrassment, thank you I must have missed that.
Politely please. WTF.
Comment 34 Michael Schumacher 2012-09-10 14:25:36 UTC
A constructive approach to the remaining problem is detailed in bug 674160. 

Instead of writing comment #29 (and subsequent reply to the expected replies), the time could have been spent on evaluation of the code mentioned and attached there.
Comment 35 Eric Toombs 2012-09-10 15:45:40 UTC
As for comment #26, I saw a "new bug" regarding this problem that was marked as a duplicate of this one, keeping the issue "RESOLVED". Thus comment #26 is less than credible. It seemed increasingly that the issue was being wilfully unacknowledged. I was never demanding you fix it immediately, or even at all. Only that you acknowledge an issue, which believe it or not is apparently very difficult elsewhere in the community. I have seen this happen before—legitimate issues with open source software that would normally be bugs, or at least enhancements, being called invalid, or worse, "fixed". I thought I was looking at another case of this acquiescence with mediocrity, so I did what I could to draw what seemed like an appropriate amount of attention to the issue, since previous, more polite attempts like Sergei's had apparently failed.

After looking at bug 674160, though, it seems I was mistaken. The issue has indeed been acknowledged. I hadn't found it before because the word "layer" was not mentioned in the title, meaning it didn't appear in any of my searches. So, I'm sorry for having made these conclusions about you based on incomplete evidence. It is clear to me now that you are being completely honest about the software's capabilities and shortcomings.