This is actually a duplicate of the older bug bug #18317. But since this one has more info I am keeping it open and closing the older one.

I submitted about groups to the mailing list. Sorry, didn't know it was on forums. Now it on three places.

Well, from what I gathered playing about month

1) Moving single layer as is, then moving children in finalizer works fine. (in my fork on gitorium there are no groups per se, but layers are linked by name and can have child layers)

I'm actually not sure that moving all layers in dran'n'drop is a good idea: moving one single layer 1500x2500 is shaky already so I can clearly see tiles. Moving ten of them probably would be nightmare.

Maybe add translate_x, translate_y into Layer, use it to render layer and perform actual movement in finalizer of LayerMoveMode?
(Though honestly I didn't figure out yet where layers are actually being rendered and if it possible to translate their rendering without huge work)

2) Changing opacity is simple to implement already(I did it in fork). You need only to modify effective_opacity to multiply opacity it by effective_opacity of parent. (It's probably wise idea to cache multiplier, but that's not the point)

3) I'm not sure about layer group visibility.

Very often I want to disable visibility of the whole group, but leave one layer visible(like Home key, but for group). Personally I think that visibility should be determined as follows:

1) If layer is not visible, do not do not display layer
2) If parent group is not visible, do not display layer
3) Ignore parent group visibility if layer is visible and this setting was done later then parent's visibility.

E.g. we have group G, and inside layers L1, L2, L3.
We

• turn off visibility of L1: it became invisible,
• turn it on: L1 became visible
• turn off G: L1, L2, L3 became invisible
• turn visible on L2: it became visible because even though its group invisible, its own visibility setting was set after group visibility and therefore overrides it.

What do you think about this approach?

Thank you for reporting it so concisely and thoroughly! Post-1.1, I think: it's quite a lot of work, just internally since the code currently makes a lot of assumptions about stack layout.

There are also some workflow questions we may just need to experiment with in the code (sometimes that's the easiest way to stumble across questions you haven't thought to ask yet!). Off the top of my head...

• Layer move - what happens if you move the bottom layer of a tree? Presumably the whole stack will have to move with it. Not fun with a tiled memory structure, but at least we have much of the work done.
• Layer and stroke pick - is this affected?
• Dragging in the layers list, adding new layers (inside current, top level), merging...

... there'll be a lot of stuff to play with.

As suggested by achadwick on the forums (post: http://forum.intilinux.com/mypaint-development-and-suggestions/group-layers/msg11826/#msg11826 ), a wish report for layer grouping, with examples of use cases.

I'm not the one that requested layer grouping on the forums, but I would like to see the feature implemented as well, so I decided to make the report and get things started.

USES

1. Organisation of complex documents. Being able to expand and collapse groups of layers helps simplify navigation of the layers list in a large file with many layers. Collapsing groups you don't need currently can reduce scrolling. Grouping also allows you to rearrange multiple layers in the stack simultaneously, by moving the group to a new place in the stack. Things like reference images can be grouped, reducing visible layer clutter.

1. Visually, it can be easier to find certain groups and layers within them due to the nested structure. In a scene with three characters, for example, you could make a group for each character, and then have layers for pencils, inks, flats, and shading in each group. Instead of having to check every layer in the list, you can find the appropriate group, and then check inside it for the layer you want.

1. Grouping is a more flexible, powerful, and obvious concept than layer linking. If you have three layers inside a group, you can still perform layer operations on the individual layers like normal, but if you select the group and perform the interaction, it affects all members of the group, akin to linking. A well-organised document can be easier to make adjustments to because of this. For example, a layer group containing all of a scene's background elements on separate layers. You can move or toggle visibility of the entire background as needed in a single action, but you can still manage each element separately to fix problems like scale or positioning.

1. Following on #3, grouping allows you to set certain layer traits to an entire group instead of on each layer, giving more control over layer interaction. You can set the opacity and layer blending modes of the group instead of the layers, and it acts on the composite of the grouped layers, rather than each layer separately. For example, two layers with normal blend mode, 100% opacity, inside a group that has has 50% opacity and overlay mode: the layers would combine normally, with the higher layer obscuring parts of the lower, and the resulting composite is then used for the 50% opacity overlay.

1. Can help reduce layer clutter. Some features of layer grouping can be emulated without grouping through use of layer duplication and merging, but this requires keeping extra copies of layers. This is the sort of thing the software could (should?) handle so the user can focus on doing what he or she wants instead of coercing the software.

1. Consistency with Krita. Krita currently saves layer grouping information inside ORA files, but this gets obliterated in a Krita<->MyPaint workflow. They're good tools to use together, and it would be nice for MyPaint to not massacre the information, even if it doesn't make use of it. (I believe gimp obliterates the grouping data too, but this isn't about gimp)

Well, that's everything I can think of right now. Thanks for reading.