Konqueror delete unification

[b.walter at free.fr]

> On Monday 14 July 2003, Aaron J. Seigo wrote: 
 
> > That's only a question of improving usability for advanced users or 
> > normal users. 
> 
> but it ignores the common case where simply moving it to a specified 
> folder, which is what KDE's trash does, is not acceptable. killing one 
> usability problem only to create another is not good, IMHO. 
 
Of course moving files to a specific folder seems oversimplified... This 
concept can probably be improved using a more complex "Trash IO Slave", but I 
am not sure that the current Trash is a big usability issue. At least it does 
work as it is expected to, and that is the most important. Other features such 
as "Restore to original place" and "Compress files" would be useful, but not 
necessary. Anyway we should really avoid "smart" functions, such as 
automatically destroy "old" or "large" files. 
 
 
> > Most users do not make a difference between "Move to Trash" and 
> > "Delete". 
> 
> yes, this is very true. the problem is real; the proposed solution is not. 
 
Merging these 2 actions is the only solution, I don't see how we can avoid 
this confusion in keeping them separated... Can you please describe your 
solution ? 
 
 
> > Renaming "Delete" to "Destroy File" would help a little bit, 
> > anyway, keeping the 2 entries by default is dangerous and will remove 
> > many advantages of using a trash. 
> 
> if one decides to Move To Trash, there is indeed an advantage to using the 
> trash. that has nothing to do with being in proximity to Delete. 
 
It removes MANY advantages of using a trash, not all of them. But the most 
important one is providing a way to correct previous errors. If Delete is 
present, most users will use it. The problem is the same in a terminal, I'm 
sure you still use 'rm -rf' most of the time, and have already destroyed 
important data, don't you ? 
It is only after the action that you can really know if you need the trash or 
not, especially for new users. 
 
 
> > For the rare cases where you really want to avoid Trash (very large 
> > file), using a key-shortcut is not a problem. 
> 
> if you know about it. KDE's "submarine features" are, not surprisingly, not 
> well known. even amongst KDE developers. 
 
It should not be well known. To remove a file from hard-disk, you can still 
remove it from the Trash, a key shortcut is only a ... shortcut ! 
 
 
> > Keeping the dangerous options as 
> > easy to access as other actions (even with a confirmation dialog) would 
> > be a big mistake. 
> 
> i've never heard of a context menu item that is covered by a confirmation 
> dialog as being "easy to access" ;-) ok, so the items are also in the Edit 
> menu, which makes them a bit more accessable, but i'd still hesitate to say 
> they are easily accessable. 
 
The confirmation dialog is quite the same, wether you choose "Delete" or "Move 
to Trash". I often look at the behaviour of users : after some time, they do 
not read the confirmation dialog anymore and choose "Yes". 
 
 
> > And for advanced users, it would be easy, and would not take too much 
> > place to add in the configuration dialog : 
> 
> the configuration dialogs in konqueror are a mess. this is a 
> microconfiguration issue that masks the _real_ problem/issue. is making the 
> config dialogs more crowded with difficult to understand issues only to 
> treat the symptoms and not the problems a good idea? 
 
It think it is worth adding "something as fundamental as deletion of files" in 
the configuration, it does not mean that the configuration dialogs cannot be 
cleaned. But this kind of option should be there somewhere, otherwise the 
problem won't be solved. 
In the current dialog, there is already an option to enable/disable 
confirmation dialogs for file deletion (ask confirmation for 
trash/delete/shred), adding the options here would be very logical. 
But if I understand well, that's the kind of options that would be present in 
the configuration dialog of a Trash IO Slave, so that's just a matter of 
choosing where these options will be located :-) 
 
 
> also consider that many "average" users go through the config dialogs, 
> while context menus are the realm of fewer (and usually more skilled) 
> users. so we'd be shifting the bad situation from a place fewer people are 
> affected and are better able to deal with it, to one where more people need 
> to deal with it. 
 
"average" users use context menu to delete a file (very few are using toolbar 
icons). 
 
 
> and we still don't solve the problem, and in fact create a less 
> satisfactory result for some (cf. all the discussion regarding remote / 
> removable media, file sizes, etc) 
 
David HJ already proposed a solution regarding these "new created problems". 
 
 
> > But please do not leave these 2 actions together by default ! 
> 
> i agree with this sentence. i don't agree with the proposed solution. (in 
> case that wasn't abundantly clear ;) 
 
Well, I still think that all these ideas are very close. That's a problem of 
choosing where the options should be added... Anyway, the proposed solution is 
a huge step-forward, and everybody seemed to agree before the patch was 
sent...