Lets say that i have a few items in the actions tree like this
Item 1
--- Item 2
--- Item 3
--- Item 4
Item 5
Then i want to move item 2 to the same level as item 1, but item 3 and 4 must stay in the level they are currently in. I always move my items with the ctrl + shortcut. When i do this with item 2 the items 3 and 4 will become children of item 2 instead of staying children of item 1.
I think that this is a bug. I don't know if anyone ever complained about this? But it is very anoying. Or i should always place the item at the bottom of the list and then move it one level up or do a cut and paste action.
Thanks for reporting your annoyance. This is actually the "as designed" behaviour, it's an attempt to retain the runtime order of the actions when moving left and right.
The easiest way to get the right behaviour is to cut/paste as you suggested, or use Ctrl-Down to move the action into the correct vertical position, then Ctrl-Left to get the hierarchy correct.
It's hard for us to know what "correct" behaviour is in these cases, because sometimes behaviour like this is what you'd expect, but sometimes not, depending on your intentions.
We're not entirely dogmatic about keeping the behaviour like this, though, so we're open to suggestions.
Thanks for your reply. Now that i know that this is intended behaviour, it is easier to except. Not than i'm totaly happy with it. Maybe there is a way to add another shortcut to move the items. "ctrl + arrow" moves one item, "ctrl + shift + arrow" moves the item and keeps the items under the moved item as children.
I've never been too keen on this behaviour either. The biggest problem is that carelessly moving one node can totally rearrange *other* nodes, and with no undo function, you can seriously mess up your project.
Ctrl+right, up and down are all pretty logical and safe. It's only ctrl+left which is the problem, because currently it makes itself a sibling of its parent, but also takes all the nodes which follow it, and turns them into children node. And there's no simple way of reversing it.
Perhaps the behaviour could be as follows:
A
B
-C
-D
-E
F
Press ctrl+left on D:
A
B
-C
-E
D
F
This has the advantage that E is not affected, and you can reconstruct the original tree by manipulating D only (ctrl+right, ctrl+up). Pressing ctrl+left on a top-level node (A, B or F in the original diagram) would have no effect, just has pressing ctrl+right has no effect on the first child of a node (C).
I agree with you. It is easier to reconstruct your mistake of moving a child from right to left when it doesn't take the nodes that are next in the chain with it as child nodes.
To be honest moving a node from right to left without placing the next nodes as children under it is the behaviour i did expect the first time i did it.. And i still make sometimes the mistake of moving a node from right to left and then hit myself for doing it without placing it first at the bottom of the chain.
So my suggestion is make the moving of a node from right to left straight forward without placing the next nodes in the chain as children under it. If i wanted the next nodes in the chain to be childern of the node i'm moving i would have placed them there in the first place.