[Bf-funboard] Re: OOPS-based Object Manager mock-up

[Karim Nassar]

 > With Containers = Groups no difference from what I was thinking about.

I agree... Naming really isn't a big deal. I called the Objects 
containers, though, since the word implies a concrete object.

 > I think this it not realy useful. You can't save space, because you
 > would have to rearrange the layout all the time. There's not much to
 > gain in clearness, but you need an additional control.

You're probably right. An alternative that might be more useful is a 
global shade control that collapses/opens all of the blocks in the view.

 >> 5) Layer Bit Indicator - Which Layer the object is on. Rt-click to 
change.

 > As Luke has brought up, using actual shortcuts instead of just numbers
 > might be of advantage.

Agreed

 >> 6) Primary Dependents - Shows the primary (default) dependency of the
 >> object. Clicking the (+) shows Children, (-) hides Children. 
Rt-Click >> to change settings.

 > The (+) and (-) could be misleading: Look at the "Background" block
 > that has nothing attached to it. One could expect that clicking on the
 > (+) will add something.

Well, True, this is one case where a Platform-universal functionality 
seems to have platform specific controls. In Windows, those symbols mean 
Collapse/expand. On a Mac, They use a rotating arrow. Other OSs use some 
other variation.

I think that what the specific widget is doesn't reall matter as long as 
it is 100% consistent within Blender.

 > And as always with indicating states the problem is, it is
 > not clear in advance if the current state, or the state to switch to,
 > is indicated. It's better to indicate actions instead. But I have to
 > admit that it's not easy and I have no idea how it should look like
 > right now.

That will always be a problem, but it is mitigated by choosing a 
reasonably standard widget.

 >> Changes to a Parent's settings will change Children as
 >> well. Shown as the Primary Dependency is "Interactivity" which includes
 >> Visibility, Editability (lock), and Render Toggle. (9)

 > So childrens visibility is synced to that of the parent?

I would say that making a change to a parent synchs all the children. 
This way, there is a simple logic and the burden of resolving conflicts 
falls to the user... It's a 100% transparent solution, because the 
system is never "thinking" for the user.

An extension to this might be a Ctrl- or Alt- Click that operates ONLY 
on the individual. May be usefull.

 > What if I want to hide just one of children?

Then you Show the parent, and then hide the child.

 > Can one object be in more than one container in your proposal?
 > If so, you would need some way of resolving conflicts because
 > of synced visibility. If not, that would be quite a limitation.

I don't see why not, though it presents some interesting issues, as you 
point out. However, Remember that this does not replace the existing 
Layer's Functionality, so I'm not sure how it imposes limitations, since 
you can't do ANY of this right now.

One thing that I didn't do a good job of showing is that any Object can 
have multiple dependencies and multiple dependents. So I suppose the 
most straight-forward way of having an object in multiple groups would 
be to set up a secondary dependency (Materials would fall into this 
class) as the same type as the primary dependency. Since Control of 
dependencies is exerted on the dependency, not on the object itself, 
there would be no conflicts to handle in such a case, since toggling the 
visibility of one dependency chain would not affect the other (The only 
except would be the object itself, whose behavior can be worked out by 
further discussion.)

 > Looks too much like a disclosure triangle.

Well, Like I said in the intro, I don't really care about the widgets. 
They could be anything. Blender widgets seem to be in flux anyway, so 
argueing about the widgets right now seems as pointless as argueing 
about naming. ;)


 >> Since a Container object does not have a "body" to select, selecting
 >> Container automaticlaly selects its contents, but (?) selecting a
 >> non-container Object that has children does NOT select the children.

 > There could be a context menu option for selection of children.

:) There is :) "Select Contents"

> The advantage of such a network view regarding grouping for whatever 
> purpose is, that you can show show inclusion in multiple groups with 
> showing the object in multiple instances. But you need much space 
> for this, and keyboard navigation is problematic. 

Too True. However, with the ability to expand & collapse branches of the 
tree, and with a really competent tree-rendering function, I think that 
the space requirements could be reduced to a managable level.

But I remain convinced that with proper development, this view could 
become VERY usefull.

> Tree and network views could coexist in Blender. Both could have 
> some options (filters) of what is shown and what not.

Agreed.

> You basic idea of how to integrate grouping and visibilty management 
> into a network view is interesting. But I think it would have to 
> coexist with other things along the lines of parenting, tracking, 
> constraints. So there's much more to take into account for redesigning 
> OOPS window.

Again, Agreed :) I just present this as another path that might (or 
might not) be taken.

> BTW, Karim, may I download all your images relating to layers to 
> put them directly on my page? 

Sure. No problem. Let me know when you've got them and I'll take down my 
copies.

--Karim