Better prompting in Tracker file operations

[anevilyak]

When Tracker does a file copy/move involving directories, it currently is not as fine grained as it should be with respect to letting the user control which files get replaced and left alone, especially in the case of a directory merge. This will involve some modifications to several parts of FSUtils, most notably TrackerCopyLoopControl.

[anevilyak]

(In #3296) No problem :)

[aldeck]

Upping priority and milestone, as i'd like to have that for R1. I'm busy with my branch currently, but might work on that in the near future.. i.e "anyone feel free to start before me" ;)

@ usability team, there's also some research to do concerning the desired behavior we want to implement.

[humdinger]

Nice you're planning to work on that Alex[[BR]] I have thought a bit about it... Where do you want to discuss it? I could open a thread on the ​usability mailing list. Would be a nice anniversary too, with the last post there being made about one year ago... :)

[aldeck]

Where do you want to discuss it?

I guess here is fine, i find discussions are quite productive here, or as second choice, the dev ml, i don't really favor those obscure mailing lists ;)

[humdinger]

OK. The following is a possibility I came up with to start the discussion. Basically it's in a worst case a 3 step process.

1. Copy/move a folder, but there's already a folder with that name present

Alert:

A folder with that name already exists at $ParentDestFolder(link-to-show-in-Tracker).

 [Button: Replace existing folder]		[Button: Merge files]

---

If "Merge files" or when copying/moving some files:

2. Some of filenames to be copied/moved already exist at the destination

Window:

There [is|are] [a|$NumberOfClashingFiles] file[s] with [an] identical name[s]
in $ParentDestFolder(link-to-show-in-Tracker).

[Expander-view: List of clashing files in $ParentDestFolder.]
{You can open/rename/getinfo/move/copy files directly in this list and display any attribute column.}

 * Prompt for every file [default]
 * Skip clashing file[s]
 * Overwrite older file[s]
 * Overwrite [all] file[s]
 
 [Button: Cancel]		[Button: OK, [prompt|skip|overwrite older|overwrite all]]

---

If "Prompt for every file":

3. When encountering the clashing file

Window:

There's already a file with the name $ClashingFileName in $ParentDestFolder(link-to-show-in-Tracker).

Select the file to keep.

			Clashing file			Existing file

Last modified:		$date				$date
Size:			$size				$size
Checksum:		$md5sum				$md5sum
  [if image|video:]
Dimensions:		$dimensions			$dimensions
  [if video|audio:]
Runtime:		$runtime			$runtime
  [if image|video|audio:]
			Thumbnail|MediaPlayer		Thumbnail|MediaPlayer

[ ] Use this choice for all clashing files in this operation.
    [only needed when there is more than one file]

[Button: Abort]	  [Button: Skip this file]   [Button: Keep [clashing|exisiting file]]

The "Clashing file vs. Existing file" columns are selectable, click anywhere and the the whole thing is marked for keeping. As long as there is no file selected, the "Keep" button is inactive.

---

This is my first jab at it. Too much? Not enough?
I'm not sure about what attributes should all be available in the clashing/existing file columns in 3), but I do like to have a visual comparison side by side.
Maybe an option to rename the clashing/existing file in a certain pattern (e.g. adding a suffix like "(2)" or "new"/"old" etc.) would also be nice.

Just brain-storming...

[Meanwhile]

First of all, it would be good if you gave the original text of the message/buttons that you think could be changed, and use it in a motivation as to why that change would be better (for example: what's you line of thought behind replacing 'items' with 'files').

The original message, which is: "An item named "[...]" already exists in this folder, and may contain items with the same names. Would you like to replace them with those contained in the folder you are copying?" does still cover the situation where a folder/file/item containing no folders/files/items is attempted to be copied to a folder, because it uses the word "may". Your proposed button-text "Merge files" just supposes there are always files present, thereby not covering all situations, and possibly raising confusion.

More remarks:

• I would use another term for 'clashing'. Sounds too dramatic and frightens off the novice computer user.
  
• "Checksum" is too much expert terminology, if not absolutely needed, please leave it out for the sake of user-friendliness.
  
• "Runtime" is also too much expert terminology. How about "length"?
  
• I'd like to see the windows the way the user sees them. Could you make mock-ups?

[humdinger]

The motivation: ATM, if you copy a folder to a location that already has one of that name, you can only choose between replacing the existing one completely or abort the operation. Therefore (1).
If you decide to merge the containing files (or files in general) it would be nice to have more options to deal with "clashing files". Therefore (2).
You should get more info to decide what file to keep. Therefore (3).

Items <-> files, clashing, checksum etc. are just words I used for discussing the feature in priciple. Nailing those down is the last step. "Runtime" BTW, is the currently used term.

As making mockups can be time consuming, I'd rather wait until there is an indication that a majority supports the general direction.

[Meanwhile]

Replying to humdinger:

The motivation: ATM, if you copy a folder to a location that already has one of that name, you can only choose between replacing the existing one completely or abort the operation. Therefore (1).
If you decide to merge the containing files (or files in general) it would be nice to have more options to deal with "clashing files". Therefore (2).
You should get more info to decide what file to keep. Therefore (3).

I already got that; it follows from the ticket description.
But how about the second paragraph of my first comment?

Items <-> files, clashing, checksum etc. are just words I used for discussing the feature in priciple. Nailing those down is the last step. "Runtime" BTW, is the currently used term.

As making mockups can be time consuming, I'd rather wait until there is an indication that a majority supports the general direction.

[humdinger]

Replying to Meanwhile:

The original message, which is: "An item named "[...]" already exists in this folder, and may contain items with the same names. Would you like to replace them with those contained in the folder you are copying?" does still cover the situation where a folder/file/item containing no folders/files/items is attempted to be copied to a folder, because it uses the word "may".

I'm not sure I completely understand "a folder/file/item containing no folders/files/items".
If copy "folder x" where already a "folder x" exists, I can now only either abort the operation or overwrite possibly already existing files without being promted which files will be overwritten. Even if the to be copied "folder x" doesn't contain any "clashing" files, you'll get that "may"-requester, though it's not needed. (1) will let you either replace the complete folder or leads to (2), showing what files "clash" and how to proceed with that. If there are no "clashing" files, you merge and are done.

Your proposed button-text "Merge files" just supposes there are always files present, thereby not covering all situations, and possibly raising confusion.

"Merging" is the alternative to replacing the whole folder. "Merging" can be overwriting, overwriting older versions, skipping, or prompting for the "clashing" files.

[anevilyak]

Replying to humdinger:

Your proposed button-text "Merge files" just supposes there are always files present, thereby not covering all situations, and possibly raising confusion.

"Merging" is the alternative to replacing the whole folder. "Merging" can be overwriting, overwriting older versions, skipping, or prompting for the "clashing" files.

His point is simply that the change to the use of the word "files" rather than "items" is not an improvement, since items covers files, folders and links equally well whereas the use of the word "files" specifically seems to imply only actual files need merging, which may well not be the case as he pointed out. As such, "items" is the better choice there.

[humdinger]

Replying to anevilyak:
I thought that was already cleared up.

humdinger:

Items <-> files, clashing, checksum etc. are just words I used for discussing the feature in priciple. Nailing those down is the last step. "Runtime" BTW, is the currently used term.

Also note that (1) is only applicable to folders. Other items jump right to (2). FWIW, I'm all for "items".

[Meanwhile]

Hmm, yes I've been reading too fast: the "may" from the original text refers to the contents of the folder at the receiving end (so to speak), and the rest of the original text assumes "the folder you are copying" contains something, so in that respect your (1) proposal is no deterioration of the original message.
--> Sorry for the confusion.
On the files/items issue, anevilyak's reaction says exactly what I meant.

[bonefish]

Just to throw in an alternative idea: Since it always annoys me, when a program performing a long task at some time in the middle of that task asks for feedback, how about presenting all the conflicts as early as possible, i.e. directly after the preflight phase? What I'm thinking of is a dialog containing a tree view with all the conflicting files and folders. The user can select items to show more information on them (e.g. the time stamps and other attributes) and assign actions to them (merge, replace, skip). When all conflicts have been assigned actions, the "Continue" button gets enabled and the process can be started.

Advantages: There'll only be a single dialog at the beginning of the process. No dialogs during the process, no unbounded number of dialogs for prompting on a per-file basis.

Disadvantages: The dialog is more complex for simple conflicts -- though that could be worked around e.g. by using a simpler dialog when there's only one conflict. The preflight phase would have to do more, particularly for possible merges.

[Meanwhile]

Replying to bonefish:

Just to throw in an alternative idea: Since it always annoys me, when a program performing a long task at some time in the middle of that task asks for feedback, how about presenting all the conflicts as early as possible, i.e. directly after the preflight phase? What I'm thinking of is a dialog containing a tree view with all the conflicting files and folders. The user can select items to show more information on them (e.g. the time stamps and other attributes) and assign actions to them (merge, replace, skip). When all conflicts have been assigned actions, the "Continue" button gets enabled and the process can be started.

Advantages: There'll only be a single dialog at the beginning of the process. No dialogs during the process, no unbounded number of dialogs for prompting on a per-file basis.

Disadvantages: The dialog is more complex for simple conflicts -- though that could be worked around e.g. by using a simpler dialog when there's only one conflict. The preflight phase would have to do more, particularly for possible merges.

Sounds good. It's like a manager that could be a separate application, not only automatically appearing when a conflict occurs, but also to be ran from the applications menu for serious archiving tasks.

[axeld]

I think the tree solution might be a bit too complex for the average user. However, posing all questions at the beginning, or, even better copy those files in the background that can be copied, and only leave those with conflicts until the user has selected an action for them.

[tangobravo]

I was going to suggest something similar to that proposed by Ingo. Having a single prompt sounds best. Instead of arbitrary-depth tree view, it could just have two levels, with folders on the highest level name "destination/sub/folder" or something. Perhaps do away with the expand button too, just give those rows a different background colour and make the keep/replace checkboxes affect all of their children items. I guess the problem then is whether to also affect subfolders, hmm maybe a full tree is best...

The problem with continuing to copy the rest is that the user might decide to change the entire operation - ie append "-copy" onto the destination folder name or something rather than have to deal with the conflicts.

I think it's important not to get too carried away with the potential options here - Tracker.NewFS presented far too many choices in this situation. Maybe the best thing is to come up with the most flexible thing we can, and then have a round of simplification after that.

[humdinger]

I have also thought about a one-prompt-window-to-rule-them-all when taking notes for window (2). But it appears to become pretty complex and I opted to have just a list of "clashing" items and leave the decisions what file to keep for window (3) where a side-by-side comparison is less messy.
In any case, Axel hit the nail en tete: All prompting should be done at the beginning of the operation, not sprinkled into the process when that particular file is reached. Also, the copying of the non-clashing files in the background is good idea. Also remember that Tracker is able to undo file actions, so an abort can be dealt with even if the copy process was already started.

[scottmc]

Moving this to "unscheduled" for now as it's unclear to me that this is even an R1 requirement. If someone adds it in then fine, but let's not hold anything up waiting on this one.