Konqueror delete unification

[Aaron J. Seigo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 14 July 2003 03:24, b.walter at free.fr wrote:
> > On Monday 14 July 2003, Aaron J. Seigo wrote:
> 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. 

don't get me started ;-) had Nat Friedman really wanted to make a good point 
regarding KDE's usability he should've picked on our trash implementation, 
not the clock dialog ;-)

> At least it 
> does work as it is expected to, and that is the most important. Other

well, not really... i've run into the situation Michael describes several 
times: two files with the same name from different places == bad things 
happen.

> features such as "Restore to original place" and "Compress files" would be
> useful, but not necessary.

yes, obviously not necessary. but like many other things the environment is 
incomplete without them.

> Anyway we should really avoid "smart" functions,
> such as automatically destroy "old" or "large" files.

why? the best addition i ever found for my Mac Classic back in ... what, 1990? 
1991? was a program called Trashman that did exactly that. it was 
horrendously useful as it allowed me to use the trash without having to 
maintain it manually.

> > > 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 ?

yes, merging them is fine. but ONLY once we have some mechanism that can 
satisfactorially manage the resulting action(s) of that one item. simply 
picking one action for the item is bad, for all the reasons everyone else put 
forward thus far, and also this: if the same action means completely 
different things on different systems, especially since it is a destructive 
action, the user will no longer be able to "trust" that action from machine 
to machine. this makes the interface too variable at the micro level.

> > 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

i really don't understand this. the ONLY thing it does is make the user choose 
what they want to do. it does not affect the trash itself in any way.

> important one is providing a way to correct previous errors. If Delete is
> present, most users will use it.

do you have data to back this up? or is this a supposition? and which "users" 
are you talking about?

> 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 ?

yes, of course. that's because my CLI doesn't have a "Move To Trash" option.

> It is only after the action that you can really know if you need the trash
> or not, especially for new users.

sure, and i agree. unfortunately, by removing the second option and trying to 
force users to use the system in a certain way we are creating new usability 
issues, which have been discussed.

> > 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 !

causing more work for people (which means using the environment is less 
efficient) by forcing them to use a Trash "system" that does NOT work (i've 
lost data to it in the past... hooray for the "safety" of the Trash), and 
we're IGNORING the fact that in many cases moving to the Trash *is not an 
option*. we simply can't ignore how people use their tools and the nature of 
human beings in general; the tools must fit the people as they really exist.

usability does not mean ignoring reality.

> > 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,

do other OS's have such configuration options in their filemanagers? (honest 
question; i'm not aware of any that do, but i've hardly done an exhaustive 
search). this sort of thing just does not belong in the filemanager's config: 
it's too much of a detail item, it's too much work to change when you need it 
changed momentarily (which is what i usually do need), and it probably won't 
make it easier for users to understand things...

> it does not mean that the configuration dialogs  cannot be cleaned.

but it would mean that we've made it harder to clean them up.

> But this kind of option should be there somewhere, 
> otherwise the problem won't be solved.

"solved" as in "bodged". there are real solutions that don't include the 
further putrification of our configurations and fm usability.

> 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.

perhaps... give them an option to Move To Trash, Delete or Cancel may be 
better done from there, yes.

> 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 :-)

yes, that's a large part of it: put them where they don't make sense and still 
don't work properly, or make it work properly and move them to where it makes 
sense. the current patch provides the former.

> "average" users use context menu to delete a file (very few are using
> toolbar icons).

i'd love to see the data that says that. you are missing the other 
possibilities: DnD to the trash icon, using the menus in the menubar, hitting 
the Delete key on the keyboard. 

> > 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".

i suppose i missed them. or perhaps i did read them and just found them 
unsatisfactory. can you provide a link to the list archives containing his 
solutions?

> > > 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.

not really. we agree on the symptoms, but not the disease.

> That's a problem 
> of choosing where the options should be added... Anyway, the proposed

that's only part of the issue, one that get's "fixed" by treating the real 
problem.

> solution is a huge step-forward, and everybody seemed to agree before the
> patch was sent...

no, it is not a huge step forward. we remove ONE menu item from a menu that 
we've heard NOTHING about either on IRC, on bugs.kde.org, etc... no, instead 
we are changing it based on the concept that it is poor for usability. those 
are the least solid reasons for doing so. and in turn we're going to get a 
series of new problems.

i will guarantee you that with this change, i WILL start hearing complaints 
about it on the IRC user help channels. these are exactly the sorts of 
changes that will have a tangible positive effect for very few and a negative 
tangible effect for more than a few. this change will result in a net loss of 
usability unless the real problem is dealt with, IMHO.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE: The 'K' is for 'kick ass'
http://www.kde.org       http://promo.kde.org/3.1/feature_guide.php
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/FCVM1rcusafx20MRAoj6AJ4ydgjddXl+vJ6ZHTFZCrMxQui9bwCfRUSy
pA2kD4uucYO+b7jJPiQO3/k=
=umQo
-----END PGP SIGNATURE-----