Windows setup influences... Re: [Bf-funboard] Manager update 2

[Luke Wenke]

> Based on what Luke wrote I see 2 possibilities:
>
> - Using a 3rd state for VRE [visibility-render-editable]
> settings for groups _and_ object-entries.

Individual objects would either be visible or not (and rendered or not, and
editable or not). i.e. they'd have two states. I think the only way they
could have the 3rd state (partially enabled) is if those objects are made up
of parts - but each part would be fully visible or fully not visible, etc.

> Indicating for groups if all members are visible (...) or not. For
> object entries indicating if the visible setting comes to effect through
> at least one group. This 3rd state would not be under user control, but
only
> used to differentiate the ON state.

> - Or using a rel 3rd toggable state. It could be 'inherit from parent' for
> object-entries, or alternatively a 'overwrite members' for groups state.
> But I wanted to avoid 3 state toggling, it's rather ugly and
> feels slow.

To avoid three-state toggling you could make it that if you click on a
partial state, it goes to disabled (and clears the children), and if you
click on a disabled state, it goes to enabled and so do the children. If you
click on an enabled state then it and the children go to disabled. This is
how it works in Windows XP setup. You can only toggle through 2 states using
that method (even though you can begin with the 3rd state). You can get back
to that partial state by changing some of the children. (Or changing the
state of another group that has a child in common)

I don't think "inherit from parent" is such a good idea. I mean what if
you've been adjusting the states of some of the children (so that the parent
is now in the partial state)...? What happens if you used "inherit from
parent" on one of the children? Would that child become enabled or disabled?
If the parent had a definite state then all of the children would already be
in that state anyway. My suggestion based on Windows XP setup already does
that "overwrite members" thing (see previous paragraph).

 > Now I guess this is realy the weak point of my proposal.
> I still think that dealing with VRE on per object and group level
> is a good thing.

The problem with my suggestion is that if you toggle the entire group
settings, then the group member settings are lost (they all become the same)
but at least it allows you to deal with VRE at the object and group levels
quickly. As I mentioned in my last email, some earlier Microsoft software
toggles between partially enabled and disabled and back again if you keep
clicking on a partially enabled group. So that means that adjusting the
group as a whole doesn't cause you to lose information about unique
individual settings. Perhaps that method is better than the one I had been
talking about (the Windows XP one). The user could still enable the whole
group by shift-clicking and/or using a right-click menu. The problem is that
would make it hard to get back to the unique settings where some where
selected and some weren't...
The user could solve that problem themselves by making a group for the
enabled members of the group and a group for the rest. If they want all the
items enabled they could just enable both groups.

> But it should better be obvious wich
> objects are visible or will be rendered without thinking.

Yeah, and my idea lets you easily see if a group member isn't enabled, just
by looking at the parent member. (So people can spot if one [or more] of the
items is different from the rest in the group - perhaps due to you changing
the settings of a group that has member(s) in common)

> I'm very busy this month, so don't expect an update. But I'm always open
> for suggestions and discussion.

Ok. And hopefully this discussion will be useful for the blender developers.
Perhaps to get an idea implemented it's better to be a programmer. (going
off topic a bit)
- Luke.