Counterintuitive copying

[Richard Spooner]

Whilst I consider UltraRecall the best thing since sliced bread, the following issues causes me a little frustration.

This is best described with a little picture, see attached.

If 'item 3' holds a copy of 'item 1' and a link to 'item 2' I would expect that a copy of 'item 3' would contain the same, ie a copy of 'item 1' and a link to 'item 2'.

As can be seen from the picture this is not the case, the copy of 'item 3' holds a copy of 'item 1' and a copy of 'item 2'.

Is this correct? Are there any advantages to the current implementation?

[kevina]

You are correct about the current behavior on copy (duplicate). I see the image you posted has been downloaded several times (20+ at this point). Obviously there is some interest in this Ultra Recall functionality.

We designed this feature not really considering the copy method you prefer, how do others think copy should behave? Is the consensus that copy should not duplicate all links but rather maintain them? [I tend to agree that perhaps it should work as you mention; favoring Logical Linking is more aligned with how UR was designed and how we use it internally]

Currently all the keyboard "modifiers": Shift, Alt, Ctrl are being used for to specify other copy/move/link alternatives. Other than providing a system option to specify the default "copy" behavior, I can't think of an easy way to allow Ultra Recall to copy either way... Or maybe the suggested behaviour should simply be how UR operates... Any suggestions on this topic?

You can either post your suggestions to this forum, or email them to support@kinook.com.

[xja]

How about adding the suggested option to the Paste Special menu and to the right-button drag menu, perhaps calling it "Duplicate Single with Child Links" because that is what it is, right? Why not assign it to the Shift key... Doesn't the Shift key currently just do the same things as a drag without any modifier key? So, it is not really being used.

Speaking of the right button drag, it would be clearer if it said "Duplicate here" instead of "Copy here" and "Duplicate single" instead of "Copy single"... since these are really different Paste options. Or maybe it should read "Copy (duplicate)" or "Copy (duplicate single)"... either way, it would more clearly associate the action with the same action on the Paste Special menu.

On a somewhat related note, here's an obscure bug I found with the shortcut arrow on multilinked items. Try this:

- in Tasks, create child items A, B, and C.
- create 2 children of A and call them A1 and A2.
- link A1 to B (note that both A1 icons now properly show shortcut arrow)
- link A to C (note that both A icons now properly show shortcut arrow)
- shift-delete the item A that is a child of C... here's the bug: note that the shortcut arrows on both A1 items disappear, even though A1 is still linked to both A and B.
- now, delete (NOT shift-delete) the item A1 that is a child of B, then Undo. The shortcut arrows reappear on both A1 items now, as they should be.

[Richard Spooner]

Just to make my position clear. I believe the current implementation is wrong :-)

In addition to using UR to manage my personal data I am also considering using it to implement a configuration control system for a large project I am working on, the current solution is show stopper for this.

[xja]

OK, what I was suggesting was that a duplicate copy of an item would have either "copies" of the original children, or "links" to the original children.

It sounds like what Richard is suggesting is that you have copies of children that are NOT linked to other items (eg, item 1) and links to children that ARE already linked (multilinked) to other items (eg, item 2).

While I can see why you might want to have some children copied and some linked, basing it on whether they already happen to be multi-linked seems a little arbitrary, and not necessarily "correct". Maybe there is a better way to indicate that certain children (for instance contacts that are linked to multiple projects) should be linked rather than duplicated when the parent is duplicated. Perhaps it should be an attribute (you could set it in the Template)... for instance, "Contacts" are always linked and "Tasks" are always copied when their parents are duplicated.

In any case, if you do add what Richard is suggesting as an option, I do know that I wouldn't want to preclude the "copy all children" option (the way it works now) or "link all children" option (the new option I suggested in my post above).

[xja]

Another rationale:

If UR worked like Windows file system, then I would agree with Richard that what he is suggesting is the one and only correct way. ie, If a folder "contained" an item (item 1) and a link (or shortcut in Windows parlance) to another item (item 2), then a copy of that folder should contain a copy of item 1 and a link to item 2.

However, UR does not work like Windows (thanks, Kinook!). UR items do not "contain" or "hold" any items. They just have logical links to other items. Item 3 has 2 links, one link to item 1 and one link to item 2. It just so happens that item 2 is linked to something else so it has a shortcut arrow on it (by the way, using that shortcut arrow is confusing because, coupled with the Explorer-like tree, it makes you think it works like Windows shortcuts).

In Windows if you deleted the "original" item 2, then the item 2 link/shortcut would then be invalid (it would point to nothing). In UR, if you delete the first instance of item 2 in the tree, the data still exists and it is still linked to item 3. Of course, if that were the only parent link item 2 had, then the shortcut arrow would even go away and it would appear "contained", but of course it is still just linked.

I know I am not telling anyone anything new about how UR works, but I just wanted to point out that if you just implement the method that Richard describes, you are making it work like a directory system and limiting the power that is already built-in to UR.

Personally, I think the default action on a duplicate command should be to link to, not duplicate, all children, but offer an ability to copy children, either as a Paste Special command (ie, "Duplicate All Children") or as an attribute in each child.

[Richard Spooner]

It is counterintuitive, see attached definitions.

duplicate
adj 1: identically copied from an original; "a duplicate key"
2: being two identical [syn: matching, twin, twinned]
n 1: something additional of the same kind; " he always carried
extras in case of an emergency" [syn: extra]
2: a copy that corresponds to an original exactly; "he made a
duplicate for the files" [syn: duplication]
v 1: make or do or perform again; "He could never replicate his
brilliant performance of the magic trick" [syn: reduplicate,
double, repeat, replicate]
2: duplicate or match; "The polished surface twinned his face
and chest in reverse" [syn: twin, parallel]
3: make a duplicate or duplicates of; "Could you please
duplicate this letter for me?"
4: increase twofold; "The population doubled within 50 years"
[syn: double]

copy
n 1: a reproduction of a written record (e.g. of a legal or
school record) [syn: transcript]
2: a secondary representation of an original; "she made a copy
of the designer dress"
3: matter to be printed; exclusive of graphical materials [syn:
written matter]
4: material suitable for a journalistic account; "catastrophes
make good copy"
v 1: copy down as is; "The students were made to copy the
alphabet over and over"
2: reproduce someone's behavior or looks; "The mime imitated
the passers-by"; "Children often copy their parents or
older siblings" [syn: imitate, simulate]
3: imitate in behavior or appearance; "She is imitating the
comedian very well!" [syn: imitate]
4: make a replica of; "copy that drawing"; "re-create a picture
by Rembrandt" [syn: re-create]

[Richard Spooner]

I just can't stop :-)

To use my proposed application as an example.

Suppose I build a complex info item to describe the configuration of my product. This item has many children and grandchildren items which are a mix of both linked and stored types. Suppose now I wish to create a new configuration based upon the old one. With the implementation as it stands I cannot just copy the original configuration and make a few minor changes, I have to build the item from scratch to preserve the linked items.

With all due respects the current implementation has no advantages (does it?).

[xja]

OK, I'll bite.

First, I am confused by what you are asking for now. In your original example, you were talking about differentiating between children that were single-linked (has a "logical link" to only one parent) and multi-linked (has a "logical link" to more than one parent).

In the last post, you talk about differentiating between stored type (which means the info item contains the contents of a document) and linked types (which means the info item contains a URL attribute that references an external document such as a web page).

Currently, the Paste Special>Duplicate command does maintain the latter (ie, stored/linked status) of all children. With regard to the former (single/multi-linked), I do agree with you that there needs to be a way to specify whether children are duplicated or linked to when their parent is duplicated. I just disagree with how that should be determined.

Assuming that you ARE still referring to the single/multi-linked status, the current implementation may not have advantages in your example but it has advantages in other examples (see below). I think it should be maintained but the flexibility should be added that allows the user to have some children duplicated and some children linked when their parent is duplicated. That would address your situation.

Finally, since you asked (and to prevent Kinook from "fixing" something that isn't broken), here's an example (picture attached) where the current implementation is advantageous. Let's say I have an item called ProjectA. Linked to ProjectA, I have Task1 and Task2. I have a Text item (eg, a contract) called Contract that specifically contains language regarding ProjectA but is logically linked to both Task1 and Task2 (say, both Tasks have something to do with that contract). Now, let's say I have another project very similar to ProjectA so I want to duplicate ProjectA, which I do and then rename it to ProjectB. With the current method, both the Tasks and the Contract items would be duplicated. Then I could customize the Contract item under ProjectB to contain language specific to ProjectB without it affecting the Contract item in ProjectA. Note in the picture that I edited the name of the Contract under ProjectB and the Contract under ProjectA stayed the same.

With your proposed method, since the original Contract item was multi-linked to both Task1 and Task2 (and hence its icon showed the shortcut arrow), when I duplicated ProjectA (and its Tasks), the Contract linked to Task1 and Task2 in ProjectB would be the same item as the one linked to Task1 and Task2 in ProjectA. I couldn't edit it to contain language specific to ProjectB. So even though Contract in ProjectA is multi-linked, I still want it duplicated when I duplicate ProjectA.

[Richard Spooner]

The image you sent shows the functionality I want. When I create a duplicate I do not get this???

Please see attached image.

file.doc at the top of the image represents a stored file.

This item item is then logically linked into configuration 1 (as can be seen from icon).

Suppose that I now want to create a second configuration identical to configuration 1. I copy configuration 1 and paste a duplicate of it. But it note that it is not a true duplicate, the file.doc is not a logically linked item, it is a new stored item.

Not good.

Want a fight :-)

[xja]

Originally posted by Richard Spooner
[B]The image you sent shows the functionality I want. When I create a duplicate I do not get this???

It is??? I don't think so. The contract under ProjectB is a duplicate of the one under ProjectA (notice the title is different). You were asking that when duplicating ProjectA, that the duplicate Project be linked to the original Contract (through the Tasks). It isn't. (Again, I think you are misunderstanding how the shortcut arrow is used in UR.)

Bottom line: UR doesn't do what you are asking for. It would be nice if an option were added to allow one to specify which children are duplicated and which are linked to when a parent is duplicated. That would address your need.

[Richard Spooner]

Hope Kevin knows what I mean.

[wussery]

Originally posted by xja
How about adding the suggested option to the Paste Special menu and to the right-button drag menu, perhaps calling it "Duplicate Single with Child Links" because that is what it is, right? Why not assign it to the Shift key... Doesn't the Shift key currently just do the same things as a drag without any modifier key? So, it is not really being used.

Speaking of the right button drag, it would be clearer if it said "Duplicate here" instead of "Copy here" and "Duplicate single" instead of "Copy single"... since these are really different Paste options. Or maybe it should read "Copy (duplicate)" or "Copy (duplicate single)"... either way, it would more clearly associate the action with the same action on the Paste Special menu.

On a somewhat related note, here's an obscure bug I found with the shortcut arrow on multilinked items. Try this:

- in Tasks, create child items A, B, and C.
- create 2 children of A and call them A1 and A2.
- link A1 to B (note that both A1 icons now properly show shortcut arrow)
- link A to C (note that both A icons now properly show shortcut arrow)
- shift-delete the item A that is a child of C... here's the bug: note that the shortcut arrows on both A1 items disappear, even though A1 is still linked to both A and B.
- now, delete (NOT shift-delete) the item A1 that is a child of B, then Undo. The shortcut arrows reappear on both A1 items now, as they should be.

There should be an option to "replicate" the exact structure that one wants to duplicate. It's like relative or absolute copying of formulas in Excel. One should have the option to do either. The more options the better.

[kevina]

Version 1.3 (recently released) addresses the request in this thread with a new Paste Special | Copy (also the default Ctrl+Shift+V behaviour instead of Duplicate) that functions.

Paste Special | Duplicate functions the same as before (other than no longer being the Ctrl+Shift+V default), which only preserves logical links in the data being copied (existing logical links to non-copied data are not preserved, but those underlying items are duplicated).

The new Paste Special | Copy preserves existing logical links to data not being copied as well as logical links in the copied items.

Here is an example:

Root Item
-+Child A
-+Child B
--+Child C
----+Child D (logically linked)
--+Child D (logically linked)
---+Child A (logically linked)
-+Child E

Child B is copied to the clipboard, then Child E is selected
-- if Paste Special | Copy is used, Child D will remain logically linked, and Child A will remain logically linked (to the root)
-- if Paste Special | Duplicate is used, Child D will remain logically linked, but Child A will be duplicated under the new Child B

Hope that is clear...

[Richard Spooner]

Thanks Kevin. Thats just what I needed. Congratulations on the new release.