[Bug 170979] strange behaviour in "save as" dialog

[Aaron Peterson]

http://bugs.kde.org/show_bug.cgi?id=170979





--- Comment #16 from Aaron Peterson <alpeterson gmail com>  2008-10-17 08:03:20 ---
(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)


-- 
Configure bugmail: http://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.