On Sat, 11 Aug 2001, Carsten Pfeiffer wrote:

> On Samstag, 11. August 2001 12:07 Manuel Arriaga wrote:
> 
> > I have written a shared library which, when preloaded, intercepts calls to
> > GNU libc's unlink() function and makes sure that those files won't be
> > deleted, but rather stored in a different directory.
    ...[deletia]...
> 
> So, I guess I'll try this out in the next week when I find some time and I'm 
> confident that we can use this for KDE 3.0.

As a user, not a developer, my concerns are

+ I want the trash can to continue to work under KDE

+ I also want virtual consoles (in, e.g., konsole) to behave like they
  conventionally behave in Unix, i.e. rm removes files, permanently.  If
  I want to trash a file, I would prefer to add a command like "trash"
  rather than modify the meaning of rm.  I also would prefer not to have
  to set up an alias 'LD_PRELOAD="" xterm' for when I want to have a
  normal Unix console.

Hence, I would prefer that libtrash be a configurable option, with at
least 2 settings (these are not the exact wording for end-users, but you
get the idea):

  * Enable trash can (i.e., libtrash) for GUI deletion only
  * Enable trash can for all deletion

The former, I assume, would load libtrash only for the file browsing/view
parts (Konqueror's file view & kfile), and the latter would set libtrash
to preload during KDE startup (I assume kdeinit would then infect all
child processes, including shells, with libtrash).

(Q: does libtrash support dynamic loading for the GUI-only scenario?  If
not, I assume it would be fairly easy to write a libtrash-compatible
library that does.)

I guess this was all probably mentioned on that IRC chat you talked about,
but I thought I'd give my input anyway.

~k.lee