Not possible right now. Future development could change this. Could you make a "Wish" bug in the bug tracker please, with some use cases and other explanations of why it's important, so we don't forget about it?
It's possible in allowed by the OpenRaster spec, and we use a tree _view_ widget for showing the list. The underlying model(s) are all flat lists however: those would need some significant work to change.
Out of curiosity, why is it not possible? An ORA file created in Krita preserves the program's layer grouping just fine by nesting <stack> tags. Do you mean the Gtk widget you're using won't allow you to show groups?
I don't see a wish report for this on the tracker yet, so I started one myself, because this is a really nice feature to have. The report is here:
https://gna.org/bugs/index.php?20359 complete with a failed attempt at using the tracker's autonumbering markup
Repeating the use cases here, for easier reading and discussion here as well:
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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
