GNOME Bugzilla – Bug 61019
add a 'lock' flag per layer to protect it
Last modified: 2012-09-10 15:45:40 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.
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.
*** Bug 119238 has been marked as a duplicate of this bug. ***
*** Bug 119737 has been marked as a duplicate of this bug. ***
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).
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...
Still not in the current version. I think it's a important function ! Hopefully someone is taking up this enhancement.
See http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg09875.html
Great there're working on it. I'm sure they are able to manage it....!
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.
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.
*** Bug 329282 has been marked as a duplicate of this bug. ***
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 :)
Still waiting for this feature.... Hopefully someone could take up this point....
It would be such a usefull feature, it's sometimes very uneasy to handle numerous layers without locking some you still need to see.
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.
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 :)
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.
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.
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
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.
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!
*** Bug 559033 has been marked as a duplicate of this bug. ***
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.
This will definitely be in 2.8
Comment on attachment 75211 [details] [review] Refined skeleton patch Marking as committed because I copied most parts of it while hacking the stuff.
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.
*** Bug 614066 has been marked as a duplicate of this bug. ***
What about locking layer movements?
> 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)
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.
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.
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.
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.
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.
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.