GNOME Bugzilla – Bug 510417
[gio] make non-experimental
Last modified: 2009-07-11 16:01:49 UTC
Hi, it would be nice if the gio plugin could be moved to gst-plugins-base for the next release. Not sure if gst/gio or ext/gio would be correct as gio is part of GLib, just needs a newer version than our lowest GLib requirement. Tim suggested that we move the plugin right after the coming core/base releases and mark it experimental for now to prevent conflicts between bad and base. The plugin has documentation (although not complete yet) and a test in tests/check/pipelines. Bye
I'm OK with moving it to base as long as it is definitely marked experimental. That means that it won't appear in the next -bad release at all, right? I have no way to test it on gutsy. It would be nice if someone else who can run it would chime in with a +1 and confirm that it runs and is valgrind clean. The docs do need a lot of beefing up. In particular, giostreamsrc and giostreamsink have the launch lines for giosrc/giosink, but all 4 elements need lots more.
Plugin moved to -base. I made an attempt at only building it with --enable-experimental, but can't test whether I got it right. Please check it. This bug is now a blocker for the next -base release, pending updated docs and confirmation of valgrind cleanliness.
Oh, and I forgot to move the existing docs bits from docs/plugins - could someone do that?
docs and example code is now there and the docs are integrated into the build system again. Now we only need someone to confirm that it's valgrind free and GLib 2.16.0 to stop it from being marked as experimental :)
There's no glib-2.16 as of yet, and I'm not really convinced the gio plugin is ready yet for this (0.10.18) -base release. I'd suggest we punt this for now.
It's needed for Totem to work on samba shares (or even the trash) on GNOME 2.22. I guess it would be fine if it was only enable with the experimentals plugins.
We'll aim to mark it non-experimental for the 0.10.19 release then -> removing blocker marker.
Hi. Just FYI I tried this plug-in on cdda:// and gphoto2:// gvfs mounts and ran into an area of gvfs that remains to be implemented; we can't get the size of the file we're trying to play back. Which makes at least totem and totem-audio-preview not work with gvfs daemon mounts. See bug 520244 for details.
As an update to comment 8: bug 520244 comment 8 shows playback from a gvfs source using a not-appropriate-for-mainline gvfs patch.
Ok, what still needs to be done for this element is: a) some way of telling the application that it needs to mount the location, maybe with feedback to the element that mounting happened. Or some way of mounting inside the element and letting the application provide authentication data (currently impossible as mounting is only possible async and does things with the default main context). b) Don't block in start() and stop(), opening and closing the stream may block and we need a way around this. Should be possible once bug #517137 is fixed by using async functions with our own main context and main loop.
Are there plans to attack this again?
> Are there plans to attack this again? It stil needs new API in gio (so we can use a custom main context), and possibly new API in GStreamer for the async authentication stuff.
(In reply to comment #10) > a) some way of telling the application that it needs to mount the location, > maybe with feedback to the element that mounting happened. Or some way of > mounting inside the element and letting the application provide authentication > data (currently impossible as mounting is only possible async and does things > with the default main context). > Can't you make the gio elements have a GMountOperation property that can be set? If the mount operation is NULL, you fail if the file isn't mounted, if it is non-null, you assume a main context is there and do the async mount? This is not very friendly to apps without a main loop, but those will likely not use gio elements, will they?
(In reply to comment #13) > (In reply to comment #10) > > a) some way of telling the application that it needs to mount the location, > > maybe with feedback to the element that mounting happened. Or some way of > > mounting inside the element and letting the application provide authentication > > data (currently impossible as mounting is only possible async and does things > > with the default main context). > > > Can't you make the gio elements have a GMountOperation property that can be > set? If the mount operation is NULL, you fail if the file isn't mounted, if it > is non-null, you assume a main context is there and do the async mount? This is > not very friendly to apps without a main loop, but those will likely not use > gio elements, will they? That would be very very useful for Totem and Rhythmbox...
(In reply to comment #13) > (In reply to comment #10) > > a) some way of telling the application that it needs to mount the location, > > maybe with feedback to the element that mounting happened. Or some way of > > mounting inside the element and letting the application provide authentication > > data (currently impossible as mounting is only possible async and does things > > with the default main context). > > > Can't you make the gio elements have a GMountOperation property that can be > set? If the mount operation is NULL, you fail if the file isn't mounted, if it > is non-null, you assume a main context is there and do the async mount? This is > not very friendly to apps without a main loop, but those will likely not use > gio elements, will they? I guess that would be easy to do but would require blocking in open until the async callback is called
..and should be possible to get finished until July 6th (next core/base freeze).
I'm working on that now btw, Bastien, how do you want to use it in totem? Get the source of playbin2 and if it's giosrc set a GtkMountOperation? I'll probably use use totem as my test application with that approach ;)
(In reply to comment #17) > I'm working on that now btw, Bastien, how do you want to use it in totem? Get > the source of playbin2 and if it's giosrc set a GtkMountOperation? I'll > probably use use totem as my test application with that approach ;) Yes, something like that.
Implementing this is a problem because of some fundamental design issues or broken apps (depending on how you look at it), see bug #586939. Apart from this I have the mounting implemented... and some other things fixed.
commit ce08823dc5bab446e07ecae0c78420751fd416d7 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed Jul 8 15:52:35 2009 +0200 gio: Post a custom "not-mounted" message on the bus This allows applications to mount the GFile if possible and restart the pipeline instead of simply giving an error. I also have a proof of concept patch for totem that uses this message but it needs some cleanup... I'll file a bug for totem with that patch later.
Bug #588079 contains the totem patch, this should be ready for committing now I guess. Is there anything else to do before the gio plugin can be made non-experimental? :)
commit 29627032dc462697e8bd262c68bb93c8eb17ee98 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Fri Jul 10 11:24:57 2009 +0200 gio: Remove the experimental status from the GIO plugin Fixes bug #510417.