After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 509759 - Migrate from GnomeVFS to GIO
Migrate from GnomeVFS to GIO
Status: RESOLVED FIXED
Product: gnome-applets
Classification: Other
Component: trash applet
2.21.x
Other All
: Normal major
: ---
Assigned To: gnome-applets Maintainers
gnome-applets Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-01-15 21:49 UTC by Luca Ferretti
Modified: 2008-08-14 18:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
quick patch (26.68 KB, patch)
2008-01-23 04:29 UTC, Matthias Clasen
none Details | Review

Description Luca Ferretti 2008-01-15 21:49:27 UTC
This will fix a major regression in GNOME 2.21: the trascan location in GnomeVFS is ~/.Trash while in GIO is (fd.o trash spec compliant[1]) ~/.local/share/Trash (or, better, $XDG_DATA_HOME/Trash).

Currently, the only really working feature is "Open Trash", 'cause it opens the trash:// location, shared between gvfs and GnomeVFS.

[1] http://www.ramendik.ru/docs/trashspec.html
Comment 1 Alexander Larsson 2008-01-16 11:40:19 UTC
Trashing is pretty easy in gio. Just call g_file_trash()
Comment 2 Matthias Clasen 2008-01-23 04:29:38 UTC
Created attachment 103518 [details] [review]
quick patch
Comment 3 Matthias Clasen 2008-01-23 04:31:07 UTC
First attempt at a patch. Notes:

- not sure that the way it monitors the number of files in the trash is ideal

- no progress when emptying the trash
Comment 4 Alexander Larsson 2008-01-23 09:28:35 UTC
Looks ok to me from a quick lookover, at least for an initial version (having progress would be nice eventually).
Comment 5 Luca Ferretti 2008-01-23 09:41:06 UTC
(In reply to comment #3)
> First attempt at a patch. Notes:

Applied on my jhbuid sandbox: it works fine.

BTW and OT: we have an issue in nautilus: it don't moves files out from trash, but create copies :-|

> 
> - no progress when emptying the trash
> 

Do we really want to reimplement a progress dialog? Can't Nautilus provide some D-Bus magic to show its own (waiting for something in GTK+)?
Comment 6 André Klapper 2008-02-11 11:03:07 UTC
regression.
Comment 7 Allison Karlitskaya (desrt) 2008-02-12 18:54:45 UTC
i just reviewed (so far just the monitoring part).

i agree that the way it does the monitoring is not ideal.  it's also subject to a race since the monitor isn't registered until after the initial count is made.  even if it was the other way around, though, it would be subject to the opposite race.

imagine: 1 file in trash

== add monitor ==

*new file added to trash*

== count ==

(see 2 files)

== return to glib mainloop, dispatching monitor ==

(receive "new file" event), conclude "3 files in trash!"


i think a far better approach is something like:

gboolean
is_empty (dir)
{
  dp = open (dir)
  if (iterate (dp))
    return FALSE; /* at least one file -> not empty. */
  else
    return TRUE;
}

this is_empty function will be fast since it doesn't scan the entire directory.

2) keep track of "is empty" instead of count

3) on receiving "new file" event, obviously the directory is no longer empty

4) on receiving "deleted file" event, manually check the is_empty().  if you're worried about thrashing then schedule a 1-second work-deferal timer to check is_empty() (and keep rescheduling it as long as you're getting new delete events).

Comment 8 Allison Karlitskaya (desrt) 2008-02-13 01:04:31 UTC
Committed revision 10648.
Comment 9 Alexander Larsson 2008-02-13 13:56:30 UTC
Re: empty detection
I talked to mclasen about this, and i think the best approach would be if the toplevel trash:/// location had a trash::num-items value with working change notification. Then it would be easy for apps to update counts and empty/full notifications.

I've not had time to do this though. 
Comment 10 André Klapper 2008-07-19 10:27:31 UTC
Guys, there still is a single reference to gnome-vfs in SVN trunk code:

./trashapplet/src/trashapplet.h:#include <libgnomevfs/gnome-vfs.h>

can this be removed?
Comment 11 André Klapper 2008-08-14 18:23:53 UTC
(In reply to comment #10)
> Guys, there still is a single reference to gnome-vfs in SVN trunk code:

Fixed in
http://svn.gnome.org/viewvc/gnome-applets?view=revision&revision=10910