Can we please have a cloning feature?


Since I first started using OmniOutliner back in 2008, I remember a recurring request on the forums to please consider adding “clone” functionality. This used to be a very common feature back in the days when we had more outliners to choose amongst. In this day and age, it would still be very useful and serve as another example why we are using OmniOutliner as a specialized application vs. just getting by with the outline mode in Word?
Thanks for your consideration!


I haven’t used OO for quite that long—would you mind explaining what you mean by cloning? Is it more elegant than selecting either an OO file or items within an OO outline and hitting ⌘D?


@TheWart - A clone of an item is a duplicate that remains linked to the content of its ancestor. If you update one, the other changes accordingly.

The old OmniOutliner forums have some good discussions and use cases, e.g.


Yeah, c’mon. More had this!

(sorry, I had to ;-)


I want thaaaaaaaaaat!


seriously, this would be a great feature when doing data modeling
example to have multiple references to the same object

- email
- password
- address
-- number
-- postal code

somewhere else in the same doc:

-- number
-- postal code

updating at one place automagically update the other


Neat … especially if it the changes to a template (separate doc) would update a child.


I too remember this as a constant request back along, and I too would find it extremely useful. Is it that difficult to implement? or is there some reason why Omni just seems to ignore the obvious demand?


It’s a complex feature, and we’ve spent a lot of time thinking about this over the years. In simple outlines, clones are not that difficult. But OmniOutliner supports very complex outlines, with parent rows which have column values calculated based on their current context in the outline. (What happens when you clone those rows to another location? Do they adopt the values from the new location, or was the whole point to get those values copied to their new location? If you’re copying the original’s values, how do you keep track of which location is the “master” copy that calculates its values and propagate them to the other locations? What happens if you delete the master copy but want to leave the cloned copies in place?)

So, yes, this is a long-standing request, but it’s not a very frequent one and it tends not to come up nearly as often as issues like customer confusion caused by hierarchical styles.


Thanks for the comprehensive answer Ken. Your questions are of course entirely valid ones, but rather than seeing them as a reason for not having clones I see them as meriting answers. In the first place it seems that rows with column values derived from their position in the outline is a bit of an edge case, and I would be perfectly happy for those columns in those rows to retain their contextual values because a) this is not a circumstance I am going to meet very often, and b) when I do that is probably the best solution anyway. This would not be the only part of the OO interface where you could be tripped up by ambiguous behaviour, and as in all such cases provided there is a clear IF x THEN y logic to follow, we all can (and do) live with it.

It would be a very small price to pay for the convenience of having straightforward clones in uncomplicated outlines. As it happens a case arose with me today: I have a current outline listing a nest of issues connected with a website design, one issue or sub-issue per row. Once I hit the buffers with a particular issue, it gets colour-coded blue and added to a list in another part of the outline for passing over to technical support. I want to keep track of the same issue in both places, and for both instances to stay in sync. Clones would be perfect for this.


[quote=“NickSloan, post:10, topic:28243”]
Your questions are of course entirely valid ones, but rather than seeing them as a reason for not having clones I see them as meriting answers.[/quote]

To be clear, I was simply trying to explain why we don’t have clones today, not to provide justification for never adding them. We’d love to work through all of these questions (and more) to find answers that meet everyone’s needs.

Good to know!

In your example, would you expect the clone to carry over its blue formatting? I assume it could have different sets of children in the two locations? (I.e., one entry might not have children while the other might?) So you’re wanting to clone across the values in the row, not everything about the row that doing a copy and paste would copy?


Good to be having this conversation Ken![quote=“kcase, post:11, topic:28243”]
In your example, would you expect the clone to carry over its blue formatting?

I would. There is a logic to why contextually determined column values might differ, but by default all the properties of one clone should be reflected in the other.[quote=“kcase, post:11, topic:28243”]
I assume it could have different sets of children in the two locations? (I.e., one entry might not have children while the other might?)

I would actually assume that the children would copy, since they are “owned” by the row, therefore a property of it. This is actually a much more significant question than the column values: is the clone the row or the row + descendants? To my mind it has to be the latter, from which of course it follows that any changes to a child of the cloned row will be reflected in the “original” (though in fact both instances have equal status). To isolate a row from the structure and allow clones different children would break the logic. If you delete a row you delete it’s children: they are a part of the parent row.


Just to think through some aspects of the interface: at present, rows may be copied by Option-dragging (and of course dragging the parent includes the children.) It would be logical if Command-Option-dragging created a clone: analogous to a Finder alias. (Unless I am missing something, this modifier combination currently does nothing else.)

I am very reluctant to suggest anything that complicates the interface, but there probably needs to be a way for the user to identify that the row they are interacting with is a clone. At it’s quietest, this could be a checkbox in the Inspector, which could be unchecked to break the link. (For rows which are not clones, the checkbox would either not be present or greyed out: this would not be the GUI element for making clones, only for separating them.

Another possibility for a quiet indication would be an alert when deleting a cloned row or its children to remind the user that they will be deleting it in both places. This warning could be turned off for users who are happy to manage their own risk.

Finally, just as rows with notes are badged, cloned rows might have a discreet badge (optional?) to indicate their status. Users could of course choose to prefix/suffix/italicise row titles in whatever way makes sense to them.

I really hope you can find a way to make this work with OO Ken.
Thanks, Nick



kcase, the hypothetical questions you’ve posed is a matter that belongs and need be resolved within OmniGroup…get coding!!!