use true trees (with exposed root node)

[brainchild0]

Currently, documents are not true trees, at least not as they are exposed to the user through the interface. The topmost hierarchical level is a sequence of cards, in comparison to a true tree which requires a single root node. I understand that such a simplification may be more intuitive to many users, but my past experience with this design pattern leads me to consider that it often leads to unwanted effects at some later stage of development, without passing a comparable benefit to the user of clarity or any other kind.

It may be useful to consider a document structure constrained by a single, irremovable root note (card).

[SquidLord]

Or you could just imagine that there is a singular, un-modifiable root node which is not editable or changeable by the user in order to support the rest of the tree, and the system simply doesn't allow presentation of it in order to keep it that way.

Bang, problem solved.

[brainchild0]

Use of the bug label for this issue was an error. The issue does not represent an immediate problem, or any that may be resolved through imagination. The problem is that without following a true tree, a structure becomes more difficult to manage as the complexity and feature set in an application expand. It may be best to avoid these problems beforehand.

[AdrianoFerrari]

@SquidLord is correct, there is indeed internally a non-modifiable blank root node for every tree. In other words, it is a tree data structure, but the user can't see/modify the root.

[brainchild0]

there is indeed internally a non-modifiable blank root node

I understand, but the suggestion is to expose the root node to the user and make it editable.

Whether a phantom node is represented internally or not is hardly the point, only whether it is populated with user content.

In the current case, adding a tree, having the feature of an empty root, as a subtree to another tree, creates the dilemma of leaving an empty node in the middle of the resulting tree, or flattening the children of the root node, such that they would become siblings of the existing nodes that are also children of the same node to the which the (empty) root of the subtree was inserted as a child.

As both options strike me as unappealing, I suggest exposing a traditional tree structure to the user instead.

[AdrianoFerrari]

Noted. Until we have embedding of subtrees, it's not an immediate problem though (as you pointed out).

[brainchild0]

Until we have embedding of subtrees, it's not an immediate problem

Constructing a new tree from two sources is just one example of how things might go better with a more conventional data model. From experience, I imagine that other problems might appear from the empty root nodes.

I understand though that you find no reason to make the change into a high priority.

[AdrianoFerrari]

Ah yes, that is a concrete (and less distant) use-case. The workaround is simple, if I understand correctly: simply make all your top-level cards the children of a new "root" card that you define. Then you can copy/paste that root card in order to merge it into another tree.

[brainchild0]

Yes, correct, but the choice that appears to me is, on the one hand, to break a standard tree model, and then place workarounds here and there, quite likely more and more as time passes, or, on the other hand, to follow a standard tree model, and have no difficulty that needs to be worked around.

(And to repeat my earlier comment, the workaround you described is only one of at least two. Another is to flatten the two children lists into one list of children of the existing node in the tree receiving the subtree. The problem with making the new root node, as in the solution you reiterated, is that it awkwardly imposes an empty node amidst the content.)