xffm idea for wastebaskets

[edscott wilson garcia]

El lun, 10-02-2003 a las 12:32, Jens Luedicke escribió:
> On Mon, 2003-02-10 at 17:35, edscott wilson garcia wrote:
> 
> > Try to make the file a dbh file. That will allow for easy adding and
> > removing entries. When creating the file, add entries for the xftree,
> > nautilus, kde and rox trash cans so they will be searched as well. Also,
> > only search those directories which lie beneath the path of the selected
> > entry when the trash collection operation is begun.
> > 
> 
> I attached what I have done so far. It uses a plain text
> file so store the path informations. 
> 
> 

on first patch:
You should create a new function and leave read_trash_locations()
unaltered. That way the brute force, search for wastebaskets will still
be available on demand.

on second patch:
I don't think the delete funtion should fail if you cannot open the file
with wastebasket paths,  but rather just a
 "print_diagnostics(treeview,ERROR_ICON,_("Cannot write to
file:",path,NULL);"

The main problem I view with the use of plain text files is that
removing stale entries implies rewritting the entire file each time.
The file may be very big for some users (like me). Also, there is no
easy way to structure it for an optimized search. And last but not
least, it will fail to collect from wastebaskets that are simply moved
by d+d by the user. 

By putting the code into remove.c, it would be better to just add the
deleted files into the dbh trashbin, which is just a file, and forget
about later collecting trash. A preference option could be added
"Collect trash on remove" and another "Hide wastebaskets".

The trash collection cache based on browsing would have to go in
add_folder.c where the dirctories are read. A g_hash would be necesary
to avoid opening the dbh file unnecesarrily (this would be populated on
startup). Testing would be necesary to check if it does not slow things
down with large directories.

Edscott