Outliner Software Forum RSS Feed Forum Posts Feed

Subscribe by Email

CRIMP Defined

 

Tip Jar

New member, first post: comments and question

< Next Topic | Back to topic list | Previous Topic >

Pages:  < 1 2 3 > 

Posted by Alexander Deliyannis
Apr 21, 2013 at 08:36 AM

 

Alexander Deliyannis wrote:
>If I’m right, UV Outliner expects you to first order D after E, and then
>to change its hierarchical level.

That should have been “D after A”

 


Posted by Stephen Zeoli
Apr 21, 2013 at 10:43 AM

 

My expectation would be yours, Rick. That is, that the promoted item would NOT become the parent of its former siblings that just happen to be below it. As Dr Andus and Alexander point out, there is an argument to be made that UV Outliner’s behavior is intentional and has its uses, but I’m more likely to believe that they just didn’t think this through. I’d suggest contacting them to see what they have to say. Perhaps they’ll change it or add the ability to optionally change the behavior, either with a preference selection or adding a key stroke.

Actually, the more I think about this, the more I think they’ve just made a lazy error. In an outliner with more “standard” behavior, you can easily achieve the same outcome that UVO has as its standard simply by demoting the subsequent items before promoting the original item. But the way they’ve got it set up is much less convenient if your intention is not to have that as the outcome, which is more often going to be the case (at least in my experience).

It’s getting these kinds of small details right that really set the quality applications apart from the posers.

Steve Z.

 


Posted by Stephen Zeoli
Apr 21, 2013 at 10:44 AM

 

By the way, it’s good to hear from another former GrandView user!

 


Posted by Dr Andus
Apr 21, 2013 at 11:13 AM

 

Stephen Zeoli wrote:
> As Dr Andus and Alexander point out, there is an argument
>to be made that UV Outliner’s behavior is intentional and has its uses,

I can’t comment on UVO, but the main idea in O4D is that this behaviour allows you to assign specific functions to a particular hierarchical level. So if you’re a stage or screen writer, Level 1 items are Acts, L2 are Sequences, L3 are Scenes, L4 are Beats etc.

If you have 7 scenes in Act 2, it makes good sense to keep those scenes in place when you decide to demote, promote or move the parent item for whatever reason.

But I agree with Steve that this sort of behaviour should be optional, and it is in O4D: all you need to do is collapse Act 2, and you will be able to move it and all its scenes etc. to a different location.

 


Posted by Stephen Zeoli
Apr 21, 2013 at 01:02 PM

 

Dr Andus, I just want to be clear about what I am talking about, because I am not quite sure we’re discussing the same behavior. (If we are, I’m sorry for this unnecessary post.)

The question I am concerned with (and how I read the original question from Rick) isn’t whether or not child items should stay with a parent when the parent is promoted or demoted—they should (although there should be some means of dis-lodging them from the parent, although that seems a bit more complicated). The question is whether sibling items should become child items simply because one of the siblings above them has been promoted?

Steve Z.

 


Pages:  < 1 2 3 > 

Back to topic list