GSoC11 - Pondering the channels hierarchy (1 - Top Level Stuff)

It's now been over 2 years ago (!) since I first put into place the current way that the channel lists are organised. Having used it a bit, and listening to people using it, it seems that some things aren't quite right.

To keep things manageable, for now I'll just focus on more top level stuff - like how Objects, Materials, Lights, Textures, etc. - are arranged in the list relative to each other, since this does affect how much of the old structure I'll need to port over to the cleaned up filtering code I'm currently working on (main targets for that are splitting up visibility filters, and replacing the "check then do" with "grab to temp then bundle up").

Dealing with F-Curve Groups stuff is NOT a priority/focus/goal at this point, though I will address this LATER. +1 comments hounding about this will be removed.

With that out of the way, let's have a look at what the current list looks like.

1) Cube Object Expander
2) Cube Object-Level Animation Data Expander
3) A Group within CubeAction
4) A F-Curve within Group: Location
5) Another F-Curve within Group: Location
6) One more F-Curve within Group: Location
7) Subsurf  Modifier F-Curve. Rooted @ ob-level
8) Cube Materials-List Expander
9) Cube Animated Material 1 Expander
10) A F-Curve for a material setting
11) Another F-Curve for a material setting
12) Yet another F-Curve for a material setting
13) A F-Curve for Texture Slot 1 - a mapping setting


The focus here is really on looking at how the Bold+Underlined items are grouped relative to each other. That is, how the datablocks are presented in this list.

To understand the current grouping, let's have a look at the ideas+assumptions underlying how this was conceived:

1. The datablocks are grouped according to a similar hierarchy to the one you see in the Outliner, which is based on the general mental model of how we know that these are related to each other. 
• i.e. Materials are grouped under Objects, so to find the animation for material used for some object, just go under that object. Same goes for texture on that material, and so on.
2. You may not always want a whole list of sub-datablocks shown, however, you still want to edit them on a general level
• i.e. When editing Object-transform animation, you may not want to see the list of Materials datablocks and/or the Particle Settings datablocks, so you close the "Cube Material-List Expander" for example.
3. Sub-datablocks are only used once in the scene, especially if animated.
• i.e. Material 1 (e.g. "skin") is only used for one object in the scene. Other objects may be using things like "plastic shell 1/2/3/4", etc.

However, this seems to fall a bit short in real usage. It turns out that the "Material list Expander" and the "Particle Settings List Expander" often just get in the way of getting to your materials, and cause them to get quite indented, leaving stuff like textures getting indented quite deeply. Admittedly, this ends up feeling like a bit too much work!

-----------------

An alternative which I think I once considered, and might bring back now will look like:

Where we do away with the material/particle-list-expanders, and just dump these inline (or out one level). These would still be the materials that Object "cube" (in this example) would be using.

One factor which I now think I forgot about when doing this earlier was that there are datablock filters, i.e.

these can be used to effectively remove those lists anyway if they cause clutter. And probably with smarter expand/collapse tools, managing the aforementioned problem would not be a problem here.

--------------

But what about textures and node trees. No longer are these always to be found linked to object-data datablocks (i.e. Lamp, Material) or World-data, but rather, in increasingly varied places, including brushes. Where do all these come in?

My current thinking is that perhaps generally relinkable Node Groups and Textures should perhaps get their own headings on the same level as Objects and Scenes, though perhaps instead of each Texture or each NodeGroup being one top-level heading, there could be a "Textures" and "Node Groups" entry, with the various texture/nodegroup datablocks being listed under that.

Hmm... describing that sounds a bit weird, so maybe that won't work that well :/

Anyways, as you can see, this is actually quite tricky to get right. More updates when I think of some other ways...