Bug 1686

Changed status to PATCHAVAIL

> Changed status to PATCHAVAIL
Michele, no comment is necessary. Just toggle the check box and submit. :-)

I tested the patch. Works well and saves me keystrokes to obtain focus for the obvious renaming change.

Before and after the patch, I never saw the progress dialog except for large files. For small files the dialog never appears for me.

Slavek, the patch seems safe and sane and should be pushed to git.

An observation. Using Konqueror I copied files from one directory to another, which caused the confirmation dialog to appear because the files had the same name as existing files. Thus I expected the confirmation dialog to appear.

As the dialog focus is now the text box rather than the Cancel button, for a moment I was thrown off because through the years I had developed the habit of pressing the Left Arrow button on the keyboard to select "Overwrite all" button. The patch now requires me to change my habits by pressing Alt-V to select the desired button.

I suspect the patch will cause other users to "freeze" momentarily if they have developed similar habits from the KDE3 days. :-)

> I suspect the patch will cause other users to "freeze" momentarily if they have
> developed similar habits from the KDE3 days. :-)
Hi Darrell, if necessary we could had an option to let the user choose where to have the focus when the dialog opens, but I think that would be going a little too extreme with configurability.
Another option could be to set the focus to the file name line edit only if we are copying a single file, but would give the user an inconsistent behavior when copy one or multiple files.
Or we can even ignore this patch if you think this might be a problem.
My view is that after the initial 'freeze' as you said, users will quickly get used to pressing 'Alt+V', while still having the benefit of saving useless clicks when they want to rename the file.

I posted my observation only as a forewarning. As I had already tested one variety of the confirmation dialog, I was aware of the new behavior when a different variety of the dialog appeared. I was still momentarily "frozen" and wanted to share the experience as a forewarning only.

On my part I have no problem adapting to the new behavior. I suspect that overall the new behavior is more efficient.

Not pushing the patch at all is an option because we are dealing with a dialog that is used daily by all Trinity users. I suspect somebody will file a bug report against the new behavior, which we then explain as the new default behavior and close the report.

Or somebody will file a bug report to restore the old behavior. In the latter case a configuration option then makes sense.

Initially I was not in favor of a configuration option. I thought a configuration option would be too confusing. Now after I have written the previous paragraphs, I'm thinking a check box in the Behavior settings might be appropriate, with the default behavior being the focus on the Cancel button as is the case without the patch.

Possibly the new check box would look something like this:

|_| Copy overwrite confirmation focus is 'Suggest New Name' text box

We would need an associated What's This popup:

When copying files into a directory that already have existing files of the same name, a confirmation dialog appears to confirm overwriting the existing files. The default focus of the overwrite confirmation dialogs is the Cancel button. Enabling this check box changes the dialog focus to the Suggest New Name text box rather than the Cancel button.

> I suspect somebody will file a bug
> report against the new behavior, which we then explain as the new default
> behavior and close the report.
> 
> Or somebody will file a bug report to restore the old behavior. In the latter
> case a configuration option then makes sense.
> 

Maybe that would be the case, or maybe not.
I am usually not in favor of UI changes that affect user habits, but we are talking about a change that is really minimal: instead of pressing 'left arrow' the user has to press 'Alt+V' and after a few times that would become a habit as well. We are not talking about mouse usage or complicated sequences of keyboard strokes.
Is it really worth it to put up all the code for a check box config option for such small change?

We obviously have different views on this point (and neither mine or yours is either better or worse I think), so it would be good to hear from Slavek and Tim as well. What do you think?

Option list:
1) don't push the patch at all (which is also fine for me, I will keep it as a local patch on my computer)
2) push the patch as it is (no checkbox)
3) create a config option and related code

I like the patch but I'm part of the testing team. I therefore receive forewarning about these types of changes. Non testing users will have no such warning. They will only notice the respective dialogs behave differently since the days of KDE3.

I'm only playing devil's advocate here. :-)

I'm not against users learning new habits --- that is part of any software project. In the past we have not issued a README to note such changes and perhaps we should. The changes affecting R14 will be many and a README seems almost a necessity this time, but all of us involved will have to help write that document because of the many changes.

Pushed to GIT in hash 645993e7