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

List:       kfm-devel
Subject:    Re: Trash can
From:       Manuel Arriaga <m.arriaga () ip ! pt>
Date:       2001-08-17 4:54:11
[Download RAW message or body]

On Wed, Aug 15, 2001 at 07:08:54AM -0700, Keunwoo Lee wrote:
> As a user, not a developer, my concerns are
> [snip]
> 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 think you have a point, but I really don't know how we might achieve this
inside libtrash.

Perhaps it would be easier to, depending on the setting chosen by the user,
either enable libtrash at startup (if the user wishes an "always-on" trash
can) or just use the regular KDE trash can (which only works with programs
that invoke the KDE-specific unlink() function). Then the main problem
would be making sure that libtrash and the KDE trash can use the same
directory for storing files and don't step on eachother's feet...


- Manuel

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