GNOME Bugzilla – Bug 510392
Migrate from GnomeVFS to GIO
Last modified: 2009-07-11 16:08:54 UTC
GnomeVFS is going to be deprecated, new vfs framework for GNOME and GTK+ application is GIO/GVFS, available from glib 2.16.0. Rhythmbox should be ported to GIO API.
In short: "GIO is a gobject-based library that abstracts out various forms of
I/O, designed to separate out dependencies by allowing apps to depend on abstract APIs, and then letting various implementations fill in these APIs. GVFS is one such implementation, similar to gnome-vfs, which plugs into gio."
For references see:
1. Nautilus for GNOME 2.22 will use GIO, this could make some troubles
with d'n'd from/to non local filesystems (URI != file://)
2. The trash location in GIO is $XDG_DATA_HOME/Trash, while in GnomeVFS
is ~/.Trash. This means that files trashed whit GnomeVFS will be invisible
to GNOME 2.22 users (while a migration script should be executed as startup)
3. GIO provides only VFS features, so no more service discovery. Howover, in
GNOME 2.22 the blessed avahi version is 0.6.22, with libavahi-ui and
4. Currently the only binding available for GIO is in glibmm (no python)
5. Currently GStreamer don't use it
So, while is not a really urgent task, I suggest start the investigation for a GIO port, maybe opening a new branch on SVN.
Filed a bug for gstreamer too. Add dependence.
I started working on this a while ago. Nowhere near complete, though.
gio doesn't give us every item on our wishlist (I don't think it'll let us resume http downloads), but I don't think we'll have any problems with it.
The http:// implementation in gvfs is using latest libsoup. But feel free to open bugs/ask to Alex Larsson, I think he will love developers point of view :-)
Looks like resuming downloads should be possible now, if I'm reading things correctly.
Since a number of python plugins use gnome-vfs currently, we're also waiting for the python gio bindings. I wouldn't be surprised if they already provide all the features we need, though.
GIO landed in gst-plugins-base
$ gst-inspect gio
Description: GIO elements
Source module: gst-plugins-base
Binary package: GStreamer Base Plug-ins CVS/prerelease
Origin URL: Unknown package origin
giosink: GIO sink
giosrc: GIO source
giostreamsink: GIO stream sink
giostreamsrc: GIO stream source
+-- 4 elements
And it works :-)
$ gst-launch giosrc location=smb://redrum/condivisi/DDTS.mp3 ! flump3dec ! autoaudiosink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock
*** Bug 516993 has been marked as a duplicate of this bug. ***
Created attachment 106154 [details] [review]
use gio for trash
This uses gio for move-to-trash only, which might make sense on a 2.22 desktop. I have tested it with one (1) file, which it apparently handled successfully. The logic it uses to decide whether to use gio or the existing code is not very smart. It just uses gio if available.
(In reply to comment #7)
> This uses gio for move-to-trash only, which might make sense on a 2.22 desktop.
Yes, this will be really appreciated.
BTW and OT: shouldn't RB remove from its database the trashed file too? I didn't checked, but the last time I trashed a file in RB, it was listed in missing files...
(In reply to comment #8)
> BTW and OT: shouldn't RB remove from its database the trashed file too? I
> didn't checked, but the last time I trashed a file in RB, it was listed in
> missing files...
The point of move-to-trash is that it's reversible. If we delete the database entry, you can't get your rating, play count, etc. back. The current situation isn't great, but it looks like the new trash stuff in gio should enable us to provide much better trash integration.
Back on the main topic, I've got a gio port of rhythmbox that at least builds now, with everything but the jamendo and magnatune plugins ported. A couple of things actually work, but it is in no way ready for general testing. When it's getting somewhat usable, I'll publish a git tree or something.
(In reply to comment #9)
> When it's
> getting somewhat usable, I'll publish a git tree or something.
A rhythmbox-gio branch on svn.gnome.org (like nautilus in past months)?
I'm not really interested in using svn for this. The frequent small commits
I'm making would be too painful to do with svn.
I have podcast download resumption working now (but podcast downloading is
otherwise pretty broken).
I've committed the gio trash patch based on a few reports of it working.
git tree at http://methlab42.itee.uq.edu.au/~jonathan/rhythmbox-gio.git for the intrepid.
I've got enough of it working that it might be worthwhile for other people to test it. None of the python plugins have been ported (bindings aren't ready), and removable media stuff needs rethinking.
A lot of the changes are actually just dropping compatibility with older versions of libraries (libnautilus-burn, totem-pl-parser, libsoup, howl, ..), removing internal copies that we don't need any more (gsequence), and so on.
I can't seem to be able to get the whole tree, or it's very very slow to clone. Is there any chance the branch could be merged, or at least an up-to-date TODO list for this bug be added along with a working repo?
Never mind, I managed to finish the cloning. The request for a TODO list still stands though.
The git repo on methlab42 is fairly out of date, but I'll be able to update it again in a couple of days. I'm surprised that it would be slow to clone, though.
The main thing that's left to do is porting the python plugins. I haven't checked where the python gio bindings are up to lately.
The git repo is up to date now. I usually bring it up to date with respect to svn when I make gio-related changes, but it doesn't otherwise track svn.
Python gio bindings are still not ready, although apparently they should be soon.
Bug 537551 has been closed as fixed on June 17th, so we now have GIO bindings in PyGObject SVN.
I plan to commit this pretty soon after releasing 0.11.6, whether the python plugins are ported or not.
We now have a pygobject 2.15 release including GIO bindings.
I've committed the port now, leaving the python plugins as they were.
Crazy idea: what about provide an (optional) gvfsd daemon for rhythmbox-library:// location to browse your music library with file manager? Playlists included.
It's just a toy, but maybe sometime you could need to browse your music library using the file manager for some obscure reason :)
(In reply to comment #22)
> Crazy idea: what about provide an (optional) gvfsd daemon for
> rhythmbox-library:// location to browse your music library with file manager?
> Playlists included.
> It's just a toy, but maybe sometime you could need to browse your music library
> using the file manager for some obscure reason :)
It's just a bad idea. Because you wouldn't be manipulating songs or podcasts anymore, but files. Which really isn't something we want to see Rhythmbox do. I'm sure you could write a crack fuse plugin for that though...
(In reply to comment #21)
> I've committed the port now, leaving the python plugins as they were.
So this bug remains open because of the plugins that have not been ported?
Yes. The gio bindings are almost at the point where we could port all of our python plugins, but where it doesn't make sense to keep the gnome-vfs code around, I don't really want to do that until a suitable pygobject release is available.
Any news here after nearly half a year, or still as described in comment 25?
Nothing much has changed. I don't have much motivation to work on this.
(In reply to comment #27)
> Nothing much has changed. I don't have much motivation to work on this.
Yeah. Nobody has, and that's why GNOME 3 will never happen.
I have actually been working on this a bit lately.
> (In reply to comment #27)
> > Nothing much has changed. I don't have much motivation to work on this.
> Yeah. Nobody has, and that's why GNOME 3 will never happen.
Please stop this. Passive aggressive whining is probably the least helpful thing anyone can do.
2009-02-22 Jonathan Matthew <email@example.com>
Restructure, rewrite, add two new classes: one for loading URI
contents by chunks (for downloading large files, progressively parsing
huge xml documents, etc.), one for performing file modification time
checks. Implement all of these using both GIO and gnome-vfs. GIO
implementations require pygobject 2.16.0. The loader classes are now
intended to be single use (they have state) and operations are
Add a helper function to use gtk.show_uri() if available, falling back
to gnome-vfs otherwise.
Rewrite various bits to create loader instances as required, rather
than sharing them between submodules.
Add a GIO implementation of the local cover art search. Requires GIO
2.15.3 or newer.
* lib/rb-file-helpers.c: (rb_find_user_file),
Add function for migrating user cache files from ~/.gnome2 to XDG
cache directory, add python bindings for various directory helper
Rewrite the catalogue downloading and parsing stuff to use the new
loader classes. Rework the download/parse logic a bit so we don't
parse the catalogue twice if we're downloading a new copy on startup.
Rewrite all the catalogue and purchasing code using the new loader
classes. The purchasing code is completely untested, but at least the
idea is right as far as I can tell.
Add code to get the mime type of the icon using gio, falling back to
gnome-vfs if that doesn't work
While gnome-vfs code remains, it's only there as a fallback.
Thanks a lot, and sorry for my stop energy.