donleone, in this
https://www.donation...ndex.php?topic=37935RN thread, said,
"- RightNote can do internal Quick-Linking to another note using e.g. the shortcut CRTL+SHIFT+K,
but the quick-link only remembers as long as you refer to an item on the same page/tree.
For when namely a quick-link is made to a note, that then gets dragged over unto another page/tree,
it breaks the quick-link and says "This item has been deleted" (even though it's just on an other tab)
So the ability to sustain note-links across pages, is a missing ability yet or bug."
and I said,
"Correct me if I'm wrong, but "other tab" is other file (except for hoisting of course), other db, and you describe a problem that currently harms any one of those db-based outliners, whilst the text-based ones are even worse, do NOT allow even for intra-file cross-referencing. OMG, I see I develop this too much here, so I cut it out to a new thread!" - here it is:
That's why I, 22111, in outlinersoftware, some months ago, devised the concept of a better db-based outliner, in which there would not be 3 distinct db's for 3 tabs/trees, but where the trees=outlines would be stored distinctly, as lists, from which the trees then would be created in run-time, from a set of ALL items, which in that db would be totally independent from each other, i.e. there would be 2 db's, one for all items / single bricks, and another one for multiple architectures for which all those bricks would be available in every which combination (order, hierarchy, cluster, whatever macro compounds).
Of course, there are some conceptual difficulties with such a construct, since in that second db, the one containing trusses from which the individual trees would be created, there should be some "combine" functionality, i.e. it would be devoid of sense to ask the user to build each tree up from zero, so multiple "partial trees" would be to be combined, in myriads of compilations and combinations.
And of course, there would be a third (distinct) db (part) from which you would have access to these compounds listed in part 2, and the interaction of all within 2, and/or of 1 accessing compounds in 2, or managing some of that combination work, is both conceptually demanding, and especially difficult since most prospects are deemed to immediately run if such a project isn't presented to them in a way to make them feel very comfortable, i.e. the fear to be inadequate vàv such a "difficult" framework would make people do not touch it to begin with, the French call this phenomenon "l'embarras de richesse", i.e. the completeness of such a system would also be its evident complexity, whilst you must hide complexity instead, in order for the prospective user to give your IMS a chance.
In other words, part 1 (part 3 above, let's rearrange it top-down instead: 1 = project level, 2 = compound level, 3 = innumerable, independent items) should give access to compounds (trees, lists, e.g. from search results), but should be as clear as possible, whilst in part 2, there should be all the possibilities waiting, but it's evident such a system should start piano-piano here, whilst in fact, here would lie the incredible force of such a system.
In fact (and I developed this in length over there), today's THREE-pane outliners just put an intermediate flat list between tree and content/single item, instead of shuffling the tree into the middle pane, creating a new, master tree within pane 1, and you see from the implications of your imagining such a second tree hierarchically below the first below that of course, at a strict minimum, there should be some floating pane with a THIRD three, FROM WHICH TO CHOOSE FROM (i.e. single items, or whole trees/subtrees), and which (the pane) could then contain any subtree from tree 1, or also any search result, both, as said, to choose from, for tree 2, the single project tree you are going to populate), and of course, that "target tree", tree to be constructed, or then, afterwards, to be maintained from tree 1 (i.e. in tree 1, you select the tree to be displayed in pane 2, or in the special "source" tree pane), should be able both to contain part-trees from other trees, in their synched, original/currently-maintained-over-there(i.e. in the original source) form, and in individualized forms, i.e. some items of the original sub-tree cut out here since not needed here, others changed here, and so on, i.e. I'm speaking of cloned parts, and of copied parts, or rather of cloned parts that get into a "just-copied"/augmented state later on, and this individualized for sub-parts of those originally-cloned sub-trees...
Just imagine somebody in the legit profession who, for some trials/proceeds, needs some legal dispositions in current state, and others in the state of their version being in effect at the time of the facts!
Thus, there should always be complete clarity of the respective state of deliberate de-synch (be it item contents, be it item versions, be it similar but partly different item groupings), in any which context, so part 2 will not only be basic lists of item IDs and the hierarchy info for the respective tree, but these tree-info-db's in db2 will contain lots of info...
And of course cross-referencing info: to sub-tree/heading, to item, to paragraph in an item... of whichever tree, you clearly see here the interest of separating item info from simili-item-info which in fact is entirely dependent of the respective occurence of a(n even perfectly identical) item, in multiple trees:
Not only, in one tree, an item has got some position, and an entirely different position in some other tree, but then, in tree a that item is cross-referenced to item xyz in tree c, but the same item in tree b might be cross-referenced to heading mno in tree pqr, and so on, in countless possible combinations.
All this is suddenly possible with that overdue separation of items and trees, and as I developed over there, in a corporate environment, there could be multiple item db's, but again, there should be a "management layer" between all those item db's, and their tree use.
As it is, cross-referencing between items in different files, and then their maintenance beyond renames and moves, IS technically possible, but would take lots of necessary "overhead", the above-described setup of independent items, and then a structure maintaining multiple tries, together with any linking info, in a separate "just-trees-and-their-info" db is by far both more functional and more elegant;
again, there's a construction problem, and that problem how to "sell" such a sophistaced structure to the user, "selling" meaning here, how to devise the gui in a way that the prospective user will start in it with confidence in his grasping it all, in time... ;-)
EDIT: Some more development of the "multiple trees, with live cloning, in just one outline db" concept in "Reply number 9" = post 10 in this RightNote thread here:
https://www.donation...ex.php?topic=37935.0
