I can confirm this. This is a kdelibs bug.

I wouldn't expect what you say. If your system is "single-click" your file will be asked to be overwritten. From my POV this behavior is the expected one in a single click environment.

Rafael, this is true (it *is* the expected behavior) but from a usability POV, this is not what the user expects in the save as dialog. In the open file dialog, this is ok (you click the file and it opens immediately), but in the save as dialog, the user expects what is described above. If you don't think this is right, at least, it would be nice to make this thing configurable.

This sounds a bit shizophrenic. Either it is the expected behaviour, which means its what the user should expect/does expect. Or its not.

Anyway, can you please provide the usability tests/data you have to back up your claim.

Besides, the original reporter seemingly doesn't know about the auto-completion in the filename field. 

(In reply to comment #4)
> This sounds a bit shizophrenic. Either it is the expected behaviour, which
> means its what the user should expect/does expect. Or its not.

Um, yeah, sorry, I wrote this very quickly and I didn't make myself clear. What I was trying to say is that this dialog is programmed to do what it does when a user clicks on a file (so, it's not technically a bug), but the user doesn't expect that.

> Anyway, can you please provide the usability tests/data you have to back up
> your claim.
> 
> Besides, the original reporter seemingly doesn't know about the auto-completion
> in the filename field. 

Wow!! I didn't know about autocompletion either...  It seems good :D
Actually I think autocompletion gives that functionality back, but it will take time to get used to it... I don't know, I am used to the old style. As far as I can remember, in kde3 this was different. The save as dialog acted as in double click mode (do I remember right?). Anyway, I am not a usability expert. What does the usability team say about that?

For me the current behaviour is broken too, I would expect a single click to copy the file name to the "Name" input field in the "Save As" dialog, not in the open dialog

I see the same behaviour on my system where I have specifically set the "Double-click to open files and folders (select icons on first click)" rule. See http://bbs.archlinux.org/viewtopic.php?pid=424636.

Another Archlinux user who is using the standard packages (I'm using kdemod) also reports the same behaviour.

This is most definitely a *critical* bug and not the expected behaviour. People have already lost data as a result.

See:
https://bugs.kde.org/show_bug.cgi?id=69676 (might be a dupe)

Actually the other guy in bug 69676 is going one step further and is saying that only double clicking on a file should select the file for overwriting and that normal clicking should not do anything. After reading this, I think that most of us would agree to make the behavior of this dialog configurable so that is satisfies all usage scenarios. What do you think?

Btw, while reading bug 69676 I hit a link to a mozilla bug (by the same guy...) https://bugzilla.mozilla.org/show_bug.cgi?id=255602 which states one very good reason for why the correct behavior is "single click to select, double click to overwrite". This is that GTK, KDE3, Windows and OSX all behave with that rule. Why break this now and confuse kde4 users?

My thoughts here is that data integrity is more important than convention. Unfortunately, the rule of thumb cannot fit all situations.

When using "single-click", clicking on the file could go as far as to move focus to the [Save] button but shouldn't actually go ahead. Keyboard users (ppl who don't like the mouse) might not like that, though they're not likely to be using "single-click" mode anyway. Double-click isn't *supposed* to feature when using the "single-click" rule though it would be convenient to make double-click "go ahead". I believe this would prevent unintentional overwrites.

When using "double click", single-clicking should select and NOT move focus to the [Save] button. Double-click should "go ahead".

I believe the only debate left is whether or not a single-click, under "double-click" rules, updates the "Location" text box with that selected file's name.

My personal preference is to update the Location with the file's name. This is the precedent on previous versions of KDE as well as other non-KDE systems.

An example where updating the Location text is more convenient is if you have a folder open with 1000s of log files named by date. Autocomplete won't be a help here at all.

I also just noticed that the "Open" dialog box has the exact same "single-click" behaviour even when I've chosen the "Double-Click" rule. Changes to the Save dialog should probably be made to the Open dialog as well for consistency. At least opening a file isn't naturally destructive. :)

Expected behavior in save as dialog:

doubleclick on folder, chdir to that folder
singleclick on folder, select the folder, (can do rename or other normal file manager tasks)

doubleclick on file - replace the text in the filename for the saveas with the filename.
single click on a file -- select the file (Does not change the save as filename text)

Click save button with a filename that already exists:
	prompt: would you like to overwrite this file? yes / [No]   No default
		if no selected, go back to save as dialog.
		if yes is selected save and close the save/save as dialog.

click save button with a nonexistant filename, save and close.
	

Note, for systems with the single click as default, doubleclick can be replaced with another "catproof" method to select action.

(note, the way I see it is there are "catproof" and "hair trigger" selection methods...  doubleclick is an example of catproof, and single click is close to a hair trigger (depending on how still your mouse has to be before the system recognizes an action)

So in a single click environment, I  a plain single click should still not nuke the filename I carefully typed in the field.  I would expect a dialog, or better yet an unobtrusive message expanded into the save-as dialog like the IE / Firefox web browsers have less obtrusive messages expand in the content wrapper.

Single Click could be the best, but the single click only systems without catproofing will cause severe loss of work.

If a user clicks on a file in the "save as..." dialogue, this can mean different things:

- selecting the file to change it's name, e.g. my_essay_2.xyz instead of my_essay.xyz
- overwriting the file with the currently opened one

In the latter case, this means that the user wants to overwrite the existing file, which has a different content with the currently opened file, not just a new version of the same content, i.e. the user wants to overwrite dog.jpg with cat.jpg.

If those files had the same content or were just a new version, the user would either pick "save" and not "save as...", in case the cat became a dog or would want to "select+rename" that filename because he wants to keep that old version, i.e. dog.jpg -> dog and cat.jpg.

So the use-case, of using "save as..." to overwrite a file is far less likely than the usecase of "save as.." to generate a new version of a document.

Autocompletion is for people using konsole, i.e. cannot be expected as "everybody knows this".

If you really think this is expected behaviour, then you have to make sure that the most common use-case is handled and not just implement something that falls flat in terms of usability by ignoring the user's needs but being correct in terms of single-click (which I doubt btw).

The user currently only gets a dialogue asking whether to "overwrite" or "cancel", so where is the use-case of "rename"? It can be found in every other KDE file-dialogue that tries to overwrite something, but is lacking here. Surely not something that can be justified by the user chose single-click and hence a usability bug.

a. the user often doesn't choose to click.

   all it takes is a gummy mouse ball and a user can miss click.

b. "rename" does not make sense in a save-as dialog warning that a file would overwrite another.

the user would not know what is being renamed -- the file that they are overwriting or the file that they are saving.

If a user downloads a file such as "ItunesSetup.exe" where the idiotic company that provides it doesn't provide version information in the name, and the user hopes to add some sort of version information -- It could be possible for the user to make a new folder and save the file in a new folder.  This is easily done in the existing dialog box, and no new functionality is needed.

c.  Now, you bring up a good point that the user may want to have a new version of a file take over for an old version of a file.

This is what symlinks are for, and I believe there might be a place for selecting a symlink as a "save as" target and have another dialog poping up as " This file is a symlink pointing to---location, would you like to replace the symlink with this file, redirect the symlink to point to the new file, cancel

at that point if the redirect the symlink to point to the new file, another save-as dialog comes up.

d.
You mentioned the difference between save and save-as.   Save behavior must start with a new file (such as Untitled3), or replace the same file, or overwrite an existing file after a choice to abort (default abort)

(In reply to comment #13)
> a. the user often doesn't choose to click.
> 
>    all it takes is a gummy mouse ball and a user can miss click.

So? There is still the cancel button and those users can use the slider in the dialogue (might be 4.2) to increase the size of the items. I won't argue about how good most users motoric abilities are and how mice are using light and so on...

> b. "rename" does not make sense in a save-as dialog warning that a file would
> overwrite another.
> 
> the user would not know what is being renamed -- the file that they are
> overwriting or the file that they are saving.

Really? If I copy files to a folder, I am saving them to that folder and I get a dialogue that states the old and the new filename. And you are saying that the user does not know what file he is overwriting? If you think users are that stupid they won't be able to differentiate between single- and double-click.

> If a user downloads a file such as "ItunesSetup.exe" where the idiotic company
> that provides it doesn't provide version information in the name, and the user
> hopes to add some sort of version information -- It could be possible for the
> user to make a new folder and save the file in a new folder.  This is easily
> done in the existing dialog box, and no new functionality is needed.

So you want the user to create a new folder for each version of an essay? Does not sound like what I see people do in real-life. They add to the filename, a date or a number, but surely do not create a new folder.

> c.  Now, you bring up a good point that the user may want to have a new version
> of a file take over for an old version of a file.
> 
> This is what symlinks are for, and I believe there might be a place for
> selecting a symlink as a "save as" target and have another dialog poping up as
> " This file is a symlink pointing to---location, would you like to replace the
> symlink with this file, redirect the symlink to point to the new file, cancel
> 
> at that point if the redirect the symlink to point to the new file, another
> save-as dialog comes up.

Symlinks? Are you kidding? That's even more out of space then auto-completion for most users.

> d.
> You mentioned the difference between save and save-as.   Save behavior must
> start with a new file (such as Untitled3), or replace the same file, or
> overwrite an existing file after a choice to abort (default abort)

You should check your applications. Open OO or any other application with an existing document add to it and click on save. It saves without any warning and I hope you are not arguing that it should be changed, since it does not make sense in most cases and those few where it does are handled already.

I did not find any sensible arguments in your post against showing the user the default overwrite file-dialogue he already knows from the filemanager and incorporating "rename" in that way.

Created attachment 27959 [details]
This has a really good feature in a save / save as dialog

(In reply to comment #14)

This guy has it right
http://chitchat.at.infoseek.co.jp/vmware/vfd.html


> > a. the user often doesn't choose to click.
> So? There is still the cancel button and those users can use the slider in the
> dialogue (might be 4.2) to increase the size of the items. 

it would be absolutely insane not to have the cancel button. The problem is cancel is not the default choice--  and enter is pressed very often, and it is super easy to missclick, and enter on a dialog box should always be a safe choice.  Having the default action be to simply overwrite a file is not ok.


> > b. "rename" does not make sense in a save-as dialog warning that a file 
> Really? If I copy files to a folder, I am saving them to that folder and I get
> a dialogue that states the old and the new filename. And you are saying that
> the user does not know what file he is overwriting? If you think users are that
> stupid they won't be able to differentiate between single- and double-click.
Ok, you are talking about copying.  That is an essential part of what save-as is.
I really don't know what "old" and "new" files you are referring to. They can be interpeted different ways.    The file that gets overwritten could be old, the file that is new doesn't make sense...  The file that I am downloading may be older than the file I am overwriting or visaversa.    You may be referring to source and destination...  still I don't understand your point.

Yes We/ users are Both potentially stupid and potentially really smart and knowledgeable of our shortcomings/ low coordination.   Say, a cat for example-- even a really smart one will delete our term papers for us.  Or a person who gets distracted, or my friend who had ALS...  





> > If a user downloads a file such as "ItunesSetup.exe" where the idiotic company
> > that provides it doesn't provide version information in the name, and the user
> > hopes to add some sort of version information -- It could be possible for the
> > user to make a new folder and save the file in a new folder.  This is easily
> > done in the existing dialog box, and no new functionality is needed.
> 
> So you want the user to create a new folder for each version of an essay? 

No.  I'll gladly let some people overwrite their own stuff if they are my enemy and are not overwriting the damming evidence to their crimes.
Also, folders are combersome. It would have to be transparent to the user. I believe that clunky interfaces can cause more trouble than they save...
Basically it's kinda like time machine for macs. 
the functionality would be this:

The user starts downloading a file that is schedualed to overwrite a file that  already exists. The md5 sum is compared to the one that is already on the disk. The user is prompted "overwrite, displace, synchronise, cancel".  The file is downloaded and the md5 is calculated for both files. If the file is the same -- the user gets a note that the files were the same. (an option should exist accessible by config files _on_same_dl_update date times-on or off.)
if overwrite occurs, it nukes it like normal.  If displace is chosen, the old one gets renamed to filename.ext-displaced_date_md5sum.

The itunes example is one where folders make sense -- the potential solution above helps with that.

> Does
> not sound like what I see people do in real-life. They add to the filename, a
> date or a number, but surely do not create a new folder.

Yes, people are really really daft in real life. I mean look at me! It definately takes one to know one, and I need something I can use. The problem with adding a date or number to a file that needs to be compaired to one that was retrieved from a server.. is that the names don't match anymore! Still you are absolutely right that adding extentions is a completely valid part of the solution. These displaced files should go into a folder.

> 
> > c.  Now, you bring up a good point that the user may want to have a new version
> > at that point if the redirect the symlink to point to the new file, another
> > save-as dialog comes up.
> 
> Symlinks? Are you kidding? That's even more out of space then auto-completion
> for most users.
 That's one of the uses of symlinks.. Now, that reminds me that they are not transferable to other systems... and I think you are right that adding a suffix / or prefix to filenames has winning advantages.


> 
> > d.
> > You mentioned the difference between save and save-as.   Save behavior must
> > start with a new file (such as Untitled3), or replace the same file, or
> > overwrite an existing file after a choice to abort (default abort)
> 
> You should check your applications. Open OO or any other application with an
> existing document add to it and click on save. It saves without any warning and

 I wrote poorly.  note, I started with the behavior you expect. now replace "an existing file" with "a different file" replace same file is supposed to mean overwrite the one that is in use.  Yes having save save is expected.  Now,open office save-as does it right.. If I try to overwite a file in the save as, it warns me, and the default option is to not overwrite.

I can see you you might interpret what I wrote that way.


It would be possible to add this "displace" feature to effectively be versioning in all kde applications because KDE is so great/modular!



> I did not find any sensible arguments in your post against showing the user the
> default overwrite file-dialogue he already knows from the filemanager and
> incorporating "rename" in that way.

I'm still comming up with terminology.  "rename" doesn't make much sense --- I'm thinking about displace and of course this is diverging from the topic --

KDE's default behavior in a save as dialog is to overwrite a file. (it offers only a whimper of a warning)

Does anyone actually work on this bug - either by changing the way the save as dialogue works now, or by making it configurable?

http://websvn.kde.org/trunk/KDE/kdelibs/kfile/kfilewidget.cpp?view=markup

Hurm,
http://websvn.kde.org/trunk/KDE/kdelibs/kio/kfile/kfiledialog.cpp?view=markup

A document with this name already exists.
Do you want to overwrite it?

is a string that shows up near some of the evil behavior.  (this is where default is erroneously yes) -- I haven't found this string yet. so I dont' know where it comes up.

http://api.kde.org/4.1-api/kdelibs-apidocs/kio/html/classKFile.html

I've been noticing a few other bugs with click behavior due to the globalisation of icon handling without handling special cases. 

 Alas, I'm trying to set up a development environment for KDE but I'm used to hand holding of gentoo and and the kdebuild script which is apparently discontinued.

(In reply to comment #17)
> Does anyone actually work on this bug - either by changing the way the save as
> dialogue works now, or by making it configurable?
> 

Yes, it has been fixed in svn. The default behavior now is that when you click a file, its name is inserted in the location field and the dialog doesn't close, even if you are working with single click mode. I am not sure who and when fixed that, but I tested it with svn a few days ago and it was fine.

PS: the same however applies now for the open file dialog, which was is not so expected, but at least the save as dialog works correctly :)

> PS: the same however applies now for the open file dialog [...

Does this mean that it is now possible to select several files in the File Open dialog? Because, as I see it, the current behavior in that dialog is also a bug since it makes the Cancel/OK buttons totally useless since you never get a chance to click them.

So, whoever fixed this finally: thank you a million times!! 

(In reply to comment #19)
I'm glad somebody took care of it. The way it worked was really annoying. Now I just hope that openSUSE is going to backport it to KDE 4.1.3.

Fixed on current trunk: clickin on a file doesn't activate the file dialog action. It is a good behaviour. This bug can be closed.

(In reply to comment #20)

> Does this mean that it is now possible to select several files in the File Open
> dialog? Because, as I see it, the current behavior in that dialog is also a bug
From looking at the code, This appears to be configurable by the application that calls it. It shouldn't apply to the save-as dialog ;)

Thank you guys for fixing the bug!
I'll try to help describe the "allow overwrite" checkbox in Bug 175543
 Hopefully I'll be able to get a working KDE build environment up.

*** Bug 176782 has been marked as a duplicate of this bug. ***