GNOME Bugzilla – Bug 86337
add support for layer trees or layer groups
Last modified: 2009-09-03 07:05:06 UTC
This has been discussed several times on the gimp-developers mailing list and I thought that it was the same feature as the one discussed in bug #51112, but apparently this is something different... It would be nice to have a way to group several layers together, optionally as a tree (if a group can be included in another group). Some operations could be applied to the whole group as if it was a single layer. A first version of this feature could allow the following operations on the group: - toggling the visibility of the group - changing the stacking order of the group (relative to the other layers) - changing the opacity and blending mode of the group - changing the mask of the group This first subset is probably identical to what is proposed in bug #51112 and could be achieved with a clipping mask that does not clip anything. A more advanced version of this feature (which is not mentioned in the other bug report) would also allow some transformations to be applied to the group. Maybe even some plug-ins. I don't know if it would be better to apply the operation separately to all layers in the group or to apply it to a single "virtual layer" that contains a merged version of all layers in the group, but hopefully someone can think about the best way to implement this.
*** Bug 85577 has been marked as a duplicate of this bug. ***
*** Bug 91283 has been marked as a duplicate of this bug. ***
As mentioned in duplicate #91283, color coding of layers need to be implemented too...
Since several bugs reports describe different but similar features related to "groups of layers", here is a list for quick reference: - "linked" layers: bug #51112, bug #86277, bug #86337. - "active" layers: bug #79025, bug #98262 (dup).
*** Bug 101973 has been marked as a duplicate of this bug. ***
*** Bug 117687 has been marked as a duplicate of this bug. ***
nobody thinks that a great dea or wath? several duplicate bugs, but no comments.
We surely think that it is a great idea and we working towards it.
Everyone thinks this is a good idea. It's just slated to be done in the next development cycle, not this one.
*** Bug 123399 has been marked as a duplicate of this bug. ***
Debian bug tracking this: http://bugs.debian.org/220757
*** Bug 138702 has been marked as a duplicate of this bug. ***
*** Bug 156804 has been marked as a duplicate of this bug. ***
*** Bug 164717 has been marked as a duplicate of this bug. ***
Is any suggestion when this feature will be added? Is it "in works" or" suspended" ?
Unless someone says otherwise it is best not to assume a feature is being worked on. If someone was working on this they might assign themselves the bug report or increase the priority level. I dont think there has been much discussion on this because Adobe Photoshop and Jasc Paint Shop Pro amongst others provide examples of how layer functionality could be improved, but if you wanted you could probably copy relevant comments from other duplicate reports to here.
*** Bug 157164 has been marked as a duplicate of this bug. ***
*** Bug 300382 has been marked as a duplicate of this bug. ***
*** Bug 306000 has been marked as a duplicate of this bug. ***
*** Bug 307964 has been marked as a duplicate of this bug. ***
*** Bug 314260 has been marked as a duplicate of this bug. ***
There is some usability discussion applicable to this enhancement request available at: http://openusability.org/forum/forum.php?thread_id=585&forum_id=462
Created attachment 51673 [details] jpeg mock-up I attached a mock-up of what a group feature implementation might look like according to the usability post I made. Feel free to flame, bicker, and moan about how GIMP should be a photoshop clone.
*** Bug 323902 has been marked as a duplicate of this bug. ***
Created attachment 60809 [details] Mockup of layer groups proposal Here is my proposal for an implementation of layer groups in the GIMP. IMO, the groups should be hierarchical and the GUI should reflect this. * Reordering of child layers is limited to within the group. * A context menu options would permit making a layer the child of the layer above or below. * Another context menu option would "detach" a child layer from its group. If the child is above its parent in the stack, its new stack location is above the "family"; else below. For the mockup, if P2-2 were detached then it would be placed between P1-1 and P2-1; it would be at the same hierarchical level as the other Parents. * If a Parent is made hidden then its children are also (I think folding the tree to just the Parent is desirable). It does have the limitation that grouped layers have to be grouped together (to me, this also seems intuitive but it does limit flexibility). This approach could be coded in a manner such that this limitation only pertains to the GUI, plugins could place children in whatever stack order required (perhaps it is best to not allow the user to execute convoluted editing methodologies). I think that this approach lends itself well to GTK, it places the Child layers on the same level as Layer Masks (this would seem to be intuitive as they are also "attachments" to the Parent), and it does not waste real estate (a single level of nesting requires no more than the current "chain link" approach). The interface from present versions is little changed and the developers could focus on implementing the required support with less concern for GUI.
*** Bug 335257 has been marked as a duplicate of this bug. ***
*** Bug 339251 has been marked as a duplicate of this bug. ***
This is a feature that can improve productivity. I'll like the suggested mockup proposals. Please consider this feature.
*** Bug 344556 has been marked as a duplicate of this bug. ***
*** Bug 348961 has been marked as a duplicate of this bug. ***
I would be happy to see this feature someday in gimp :)
I must say i haven't liked the mockup. it doesn't enable you to select multiple groups, since the groups are in a drop down. it will be a pain when the layer effects 'bug' gets implemented. I personaly loves the fireworks interface. it's plain simple. Just like the nautilus folder tree on the side bar. nothing fancy, but widely used in file navigation. So if we are borrowing the funcionality of directories and folders, might as well borrow the current GUI concepts.
This is a feature I'd like to see included too. Agreed with Gabriel regarding the mockup. KISS (Keep It Simple Stupid), something analagous to a file/directory tree in Nautilus, Thunar etc. would be great.
Something similar to Layersets in Photoshop would be nice, where it's in more of a tree format then the dropdown format shown in the mockup.
*** Bug 401021 has been marked as a duplicate of this bug. ***
*** Bug 414314 has been marked as a duplicate of this bug. ***
I am taking myself off of the CC list because this bug is not being fixed and I'm getting annoyed by the "CC added" spam I get each time another bug is marked as a duplicate of this bug.
May be a solution would be something "CC except CC changes"?
This can be adjusted in the preferences.
Soory - it is (and I have it swiched off) - but it do not work with duplicates (comment added).
*** Bug 415639 has been marked as a duplicate of this bug. ***
So, how's it going? Are there any group layer support coming in any foreseeable future?
(In reply to comment #42) > So, how's it going? Are there any group layer support coming in any foreseeable > future? Yes, foreseeable but distant future. The support for layer groups will not be included in GIMP 2.4, but may be part of 2.6 or a later version that integrates GEGL.
The plan for 2.6 includes porting the core to GEGL and introducing Cairo rendering. I don't think that we want to do large changes such as introducing layer groups. But then, it mostly depends on whether someone finds the time and motivation to work on it.
there is lot of stuff behind the idea of layers and i accept of course, that it takes time to integrate all those facilities. Another aspect is it, that your xcf project will get very confusing, if you are using a lot of layers. And in fact, many photoshop projects of me result in this. So i try another approach: is it possible to add layer groups/folders with just two features as soon as possible: - you can collect layers in it - open/close of the group/folder will show/hide the inherited layers With larger projects you have at least a chance to manage the amount of layers.
let me just add an easy example calculation to show the problem: just imagine you want to manage the map of a country, where you dynamically add cities with names and drop shadowed icons. Having about 33 cities in it (and this is NOT very much) results in - 33 text names - 33 icons - 33 shadows - 1 background with the map => 100 layers for a quite simple project! And we still don't have layers for border lines, rivers and so on. Maybe i can convince you people for this first entry into folders ;-)
Peter, there is absolutely no need to educate us about the importance of layer trees or layer groups. Your comments are inappropriate for a bug-tracker.
Peter, the gimp-developer mailing list (http://www.gimp.org/mail_lists.html) is a more appropriate place to discuss issues like this and argue about the importance of some features. However, this was already discussed several times and we are fully aware of the importance of layer groups. I am affected by that myself, having some images with a large number of layers. But implementing this feature is not trivial: it requires changes in the user interface and documentation, usability reviews, etc. It would also change the file format because the information about layer groups and their current state has to be stored somewhere.
sven : accepted, at least i have not been inpolite ;-) raphael: thx, it helped me to understand the right way/place and the difficulties, why it must wait
*** Bug 461788 has been marked as a duplicate of this bug. ***
*** Bug 499162 has been marked as a duplicate of this bug. ***
*** Bug 499164 has been marked as a duplicate of this bug. ***
The attachment mockup is a but strange though I would go for a simpler structure layer 1 layer 4 group 1 [img of visible layers in group] + Layer 2 + Layer 3
I agree with that, simple but very useful!
*** Bug 519312 has been marked as a duplicate of this bug. ***
I have been looking for some layer group functionality for The Gimp and I haven't been able to find any. Perhaps this is in development in The Gimp but I haven't been able to find it. I do web development and I receive large PSD files with many layers that were created from layer groups. My job is to lay out the HTML/CSS so I cut the images as well. I do occasionally have to make modifications to the images themselves and Gimp is great for this since I am on an Ubuntu Gutsy system. I wrote a Script-Fu script to fudge the layer group functionality for basic operations (show/hide/link, drop-shadow, etc). I did this because I know it may be a while before this functionality is native to The Gimp. It is not meant to be, nor does it have the capability to be, a full-featured implementation of layer groups. It is, however, a quick-and-dirty solution for people who need to be more productive managing many layers until such a native Gimp solution is provided. You download the script and see how to use it at http://www.calcmaster.net/personal_projects/gimp/ Please feel free to let me know what you think. I will also be happy to receive feature requests if you have something specific in mind and I'll see what I can do. As you can see, I wanted drop-shadows so I added this for my use.
I have an updated version with some help from Miguel Oliveira that supports sub-groups within the layers. The basic layer arrangement stuff is included here, as well as a demo of the drop-shadow to show how this could be applied to an entire group. Please contact me for specific requests about more operations to apply to a layer group.
Interesting! Could you please attach a patch against SVN trunk with the changes you are talking about? (Does this count as "contact me"?). You should know however that there currently is work ongoing in trunk with an explicit goal of implementing this feature request, so chances are that your changes are conflicting.
This is only done through a hacked-up Script-Fu setup and I doubt that it would be desirable for inclusion. I did it this way because it was relatively fast and easy to develop and it seemed to be the fastest way to get it to users rather than waiting for a compiled release.
Work is ongoing in trunk regarding this, setting milestone to 2.8.
The current consensus is that 2.8 will be too early, setting milestone to 2.10.
given that the question interests me also to me! I wanted to suggest as an alternative to the usual folder group that also uses krita or Photoshop etc ... the possibility of the use of levels as the outline of Blender, namely with the concept of parent that contains levels that children suffer most of the variations possible with this and saves space!
I don't think that I do really understand your comment.
Hi Roberto, i also don't understand your english comment #62. It's not an english text, just english words ;-) Is there a chance, that you ask english speaking friends for help?
Attempted translation of comment #62: I want to suggest as an alternative to the usual folder group that is also used by Krita and Photoshop, the Outliner system as used in Blender (http://wiki.blender.org/index.php/Doc:Manual/Data_System/The_Outliner). I don't know Blender, but I think the concept Tamburrino is referring to is that settings on a parent of the tree also have effect on every descendant of that tree. For example, when you set opacity on a top node of a layer tree, that opacity is inherited in every descendant (except when the descendant set it's own opacity). Tamburrino, please correct me if I misunderstood.
Can you guys please stop discussing this feature in our bug tracker and instead move it to the gimp-developer mailing list where it reaches a much larger audience? Thanks!
*** Bug 590427 has been marked as a duplicate of this bug. ***
With mitch's excellent work on this, layer groups are now 2.8 material, changing milestone accordingly.
Closing as fixed because layer trees are almost complete in master. What remains is bugs to be found (and filed separately), optimizations and a PDB interface.
(In reply to comment #69) > Closing as fixed because layer trees are almost complete in master. > What remains is bugs to be found (and filed separately), optimizations > and a PDB interface. I downloaded git version from 8/31/2009 and compiled it just to be able to use the layer trees. I can't find the functionality. I created a new image with defaults, created three layers, one with white, one with black, one with transparency, but I don't see anything about layer trees in the layers toolbox or in the menu. Did I download the wrong thing or am I not looking in the right place?
There is a "Folder button in the layers dialog. The UI needs improving, but the feature is really there :)