[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Superlous configuration?
From:       Michael Nottebrock <michaelnottebrock () gmx ! net>
Date:       2005-01-05 20:14:33
Message-ID: 200501052114.38643.michaelnottebrock () gmx ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday, 5. January 2005 20:57, Guillaume Laurent wrote:

> > Having an
> > RMB menu that provides that option certainly seems logical to me.
> > Removing an option for the sake of some nebulous algorithm that'll decide
> > whether to delete it or move it to trash seems counter-intuitive, and
> > almost MS-Windows-like.
>
> Oh please. Millions of people do real work on Windows and OS/X-based
> machines every day, and manage to do it without having to worry about
> "trashcan vs. delete". So it would seem that these OSes are doing something
> right here.

Actually the whole concept of a trashcan is a pretty mediocre idea. If its 
usage isn't enforced (by filemanagers defaulting delete-operations to 
move-to-trashcan for example), people don't use it (AmigaOS for instance has 
such a trashcan - the single most useless icon on any Workbench :-).

If the usage is enforced, people use it and are surprised by their harddisks 
suddenly being full when they don't expect them to. Result: Warning dialogs 
about low-space conditions on filesystems (with an option to empty the trash 
to make room), a Microsoft invention.

I reckon a smarter mechanism for file-recovery would have the potential to be 
quite a showstar, however all ideas that cross my mind there would best be 
implemented at file-system (or VFS) level (and people could add GUI 
front-ends in desktop environments to that).

-- 
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]