[Bf-funboard] Visibility and locking hierarchy

Thorsten Wilms bf-funboard@blender.org
Fri, 16 Jan 2004 18:17:03 +0100


On Fri, Jan 16, 2004 at 05:29:29PM +0100, Janek Kozicki wrote:

> wow! I like the idea *very* much.

Glad you like it, allthough I'm not sure I got the idea across in all detail ...
 
> whole hierarhy/tree will be shown in its own window, right? (just like
> 3d view, or OOPS schematics)

Yep!

> vertices can have some properties, like color: each vertex may have a 
> different color, will this be included too, in the tree view?

Didn't think of this. Colour per vertex group might be interesting. But the  
default would be to inherit colour from the object.

  
> so we will have two options to click near each object (perhaps an icon
> drawn right to the object's name?), like:
> - left-click will unlock/lock this object *only*, 
> - middle-click will unlock this object_and_all_parents_needed_to_make_
>   _this_object_truly_unlocked,
>             or will lock this object and all parents [*]
> - right-click would bring some additional options?
> 
> the second icon near the object's name would be for visibility. same functionality.
> - left-click toggles visibility (if parents are invisible, and object is 
>                                  visible, then it's grayed out)
> - middle-click displays object and all parnets to make it actually visible
>                or hides this object and all parents [*]
> - right-click changes display mode (wireframe, shaded, ....)
> 
> [*] to be decided whether all parents will be affected, or only actual
> object. I prefer affecting all parents, since it gives symmetry:
> lock/hide_chain, unlock/show_chain.
> 
> It is yet to be discussed whether LMB,MLM,RMB will do what I suggested,
> or will they be swapped to act differently. Nonetheless I think 
> that a *TOOLTIP* may appear when the mouse cursor is hovered over 
> the icon. And the tooltip will tell everybody what each mouse button does.
 

I think that's too complicated. I could imagine some functionality around those  
lines in a RMB context menu. But that's all secondary, I'd rather discuss the 
more central aspects for now. 

 
> >   One can also think of the positive (vis on, lock off) state of a boolean 
> > setting of an item in the hierarchy to mean 'bypass', so the individual 
> > settings of the children come to effect. But negative (vis off, lock on) 
> > means: overwrite childrens settings (would be shown grayed out)!
> 
> I think I just described this above, right?

I fear you didn't. There should be just one toggle icon for each visibilty, 
rendering and locking. Nothing but single leftclicks to operate them. 


> >   If an object is in one locked group and another not locked group, it's
> > not locked.
> 
> no, I disagree. Each object is only one, no matter how many times it
> appears in the tree. So locking this object, or toggling its visibility
> affects ALL apperances of the object in the tree.

If you lock the object directly, it sure is locked. But indirectly locking 
through a group is different, because one object can be in more than one 
group. There must be either a priority given to locked or unlocked states. 
Because of the logic of my proposed system and consistency with visibilty 
it has to be unlocked state. (It would be very weird if an object would 
not show up, even though it's visible in one visible group.)


> So you can toggle the visibility icon on the object, see it disappear
> from 3d view. And see the visibility_icon_status changing right to the
> ALL apperances of the object in the tree.

The icons should not flip without direct user interaction. If an object is 
set to visible, but the parent is invisible, the icon should be just grayed 
out. This way it's obvious the objects visibility is affected by the parent, 
and the individual settings are kept without a doubt.


> >   If an object is in one locked group and another not locked group, it's
> > not locked.
> 
> ahhh I've read this again. You mean that in one chain some prants are
> locked, while in another chain all parents are unlocked? So an object
> has several parents in different states. Well, then:
> 
> depends what we do want to do with an object. If the change affects
> object through the locked parent then the object cannot be changed. If
> the change affects object through unlocked parent then it can be changed.
> 
> so if the parent "position" is unlocked, and parent "texture" is locked,
> then the object's position can be changed, and object's texture cannot
> be changed. (those are just examples)


Locking is supposed to mean: not editable (or maybe even not selectable in 
3d view). The proposal contains nothing about affecting an object through 
a group, other than the visibility and locking settings (allthough I still 
have inheritance in mind, but that's a different story).


Maybe someone can try to explain my proposal in his own words, hopefuly 
in a more clear language than I'm able to? I will see if I can come up 
with some diagrams to help bringing the message acrosss.


---
Thorsten