|
Thank you for your answer and excuse me for my not understanding.
Let's drop the copying / cuttying / pasting; as said before, it works like a dream, and I'm delighted with that.
My problem is, I have, in a given dabase, an item "original". Then I clone it, that item is the "clone" - but of course, the common title of the two items is "commontitle".
In this item commontitle, which exists two times, in two places, there is a search term, lets say "searchterm". I then search for searchterm.
Now, in the search results pane, I get commontitle, ONE TIMES ONLY, and without any indication of its position of the tree. What I want to say is, in the tree there might be selected another, third item which has nothing to do with the original and the clone, but where the focus was when I did the search for searchterm (not being in the third item).
In the text pane, there is displayed the search pane.
Then I click on the (one only) item commontitle in the search results pane, and then, the text pane displays the text of the item commontitle, but it is unclear if this represents the original or the clone. (As said before, any other, formerly selected item is selected in the tree, not one of the items commontitle.)
For the text, this is totally unimportant, of course, since any changes will be automatically synched, from clone to original, and from original to clone(s).
But it makes a difference for the position in the tree, of course, for my "being in the context of the original or being in the context of the clone".
So I double-click on the item commontitle in the search results pane, and then, in the tree, the original (not the clone) is selected, so by double-clicking commontitle, you get to the original's position in the tree, but not to the clone's.
Let me give an example why this "positioning" within the tree, from search results, is important.
Let's assume we have 10,000 items in various subtrees, and we want to make a Getting Things Done or any other task managing system.
Then, a task being somewhere deep in its context has searchterm, and when you want to work on it in context, you double-click, and you're done. If you want to see the item in the "ToDo" context, you cannot go to it this way, but you must go to this "ToDo" context manually, but let's assume this context is on top of your tree, so this is not too much trouble.
But whenever you CATEGORIZE an item under different categories, not a "normal context" and a "ToDo" context, but real, different, systematic categories, you are in trouble since you cannot go to the item but in its original context, not in the (equally important and equally deeply hidden) context to which some time in the past you had cloned it.
As an example, let's consider 1,000 items in chronological order, within 10 ranges of time, let's say 50 items in range 1, 150 items in range 2, and so on, let's say historic ranges of centuries or of 10 years, 10 times 10 years of a century, and the occurrings in those ranges of 10 years.
All those items / occurrings / historical facts must be cloned to several systematic categories, let's say Power, People, Science, whatever, let's say 20 or more categories, and each historical fact is cloned into at least one of those.
This "has it been categorized at least once" problem is gladly resolved by the fact that every entry must have the curbed arrow indicating its cloning status; if ever an item does not have that arrow, categorizing has to be done yet (so you check by sight).
But now, the problems arise:
You don't want to have a real mess in the search results, so since UR always shows the original, not any clone by double-click in the search results (and this even when the clone, in the tree, is above the original), you MUST enter every item first in the chronological category, in order to have those double-clicks aim at this head category "chronological"; if ever you are in any systematic category, and you want to create a new item, you must first go manually into the concerned chronological category (let's say "1830-1839"), in order to create the original there, and then only you'll go back to the corresponding systematic category, to do the clone there, since if you worked in a natural way, your original would be in the systematical category, when the clone would be in your chronological category, and this way, any double-click on commontitle would once put you in the chronology, once in the systematic categories, depending on where you created your original.
This is most akward, I think; a solution would be to not differenciate original and clone anymore, internally, but that double-click on a commontitle in the search results pane would put you to the FIRST occurence of any original or clone in the tree.
This way, if you are doing heavy work on your cloned things, and if you normally want to be put into the chronology of your subjects, by searching for search terms, you could put your chronology, in the database, BEFORE the categories; or the other way round, when you want your searching putting you into the categories, you would first put them before your chronology; the same considerations would apply to any other categorization: If you want your search to lead you to categories "A", you would put those above categories "B", and vice versa; the same would apply to multiple "level a" categories, A, B, C, D...: Their order in the tree would then decide upon your double-click showing the occurrence of your search result, be it the original or one of its multiple clones.
Or then, by option perhaps, the search results pane would display ALL occurrences of commontitle, original, clone, etc. - in tree order. This way, looking for hits in category A, you would know that the first occurrence must be double-clicked, and for hits in category C, you would double-click the third occurrence of commontitle in the search results, and so on.
The above problem is widened by the fact that the double-click on the (only) commontitle item in the search results pane SHIFTS this pane to a "children" pane, so there is not a solution given by perhaps double-clicking a second time on commontitle in order for the tree selecting the second occurence / the clone of commontitle.
As it is, hits in clones are simply not found, since the tree invariably displays the original, not the clone. I hope I could explain why this should be amended?
I think any solution that would give the first occurrence in the tree, instead of the "original" occurrence, would be rather simple to implement and a big step ahead, since users could work as they feel, in creating the original or the clone first (for users, it would not make any difference, that is, even if on a technical level, it would be the other way round), and the positioning in the tree of their big categories would then decide on where searchterm searches would put the user in the tree.
|