With DK-disks 007 (git head 2009-10-13), dk-disks does not check the ID_MEDIA_PLAYER udev attribute. In bug 24499 I provided a patch to set the correct icon, but that's just the smaller part of the problem: gvfs does not assign an "x-content/audio-player" MIME type to the mounts. My G1 just gets "x-content/image-dcf" (through the DCIM/ rule in shared-mime-info), and an Apple iPod currently does not get any (http://launchpadlibrarian.net/33552373/gvfs-mount). Neither gvfs nor gdu use gudev (and shouldn't really), so they can't query the ID_MEDIA_PLAYER flag directly. A quick'n'dirty hack would be to change gvfs to add that MIME type if the icon is "media-player.*", but oh well.. I think a proper fix would be to introduce a new DK-disks list property "presentation mimetypes" which gets "x-content/audio-player" assigned for ID_MEDIA_PLAYER, and then extend gdu to propagate this, and finally merge that list in gvfs. What do you think?
Created attachment 30378 [details] [review] workaround in gvfs Just in case it's useful for another distro, this is a kludge in gvfs which sets the content type based on the icon. Since the icon is set based on ID_MEDIA_PLAYER, it has the same effect, but of course isn't correct from an architecture POV. However, it will do for those of us who have a release to get out there..
(In reply to comment #0) > I think a proper fix would be to introduce a new DK-disks list property > "presentation mimetypes" which gets "x-content/audio-player" assigned for > ID_MEDIA_PLAYER, and then extend gdu to propagate this, and finally merge that > list in gvfs. > > What do you think? I think it would be better if GVfs used libgudev to check the udev attributes - there's really no need to involve DeviceKit-disks as the middle man - thoughts?
(In reply to comment #2) > I think it would be better if GVfs used libgudev to check the udev attributes - > there's really no need to involve DeviceKit-disks as the middle man - thoughts? Two thoughts: (1) Right now, gvfs only uses gdu, gdu only uses DK-disks, and DK-disks uses udev. This is a nice and clean layering that avoids complex dependencies and making gvfs dependent on OS specific bits (udev); i. e. right now BSD/Solaris etc. could theoretically provide their own backend in DK-disks, and the rest of the stack would magically work. (2) DK-disks already exposes GUI related properties which it does not use itself (the presentation icon at least, and arguably also the presentation policy), so if we don't want to have the content types in there for reasons of not "bloating" DK-disks, then we should perhaps consider moving out the other bits to gdu (or gvfs) as well? Then there's also media-player-info and how it should evolve. I think we soon want to/should support specifying a custom icon there, so that we can move this rule ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="1209", ENV{DKD_PRESENTATION_ICON_NAME}="multimedia-player-ipod-white" out of dk-disks into media-player-info (where it should really belong IMHO). Right now, Rhythmbox has an internal "libmediaplayerid" library which reads the .mpi files from media-player-info. One idea is to split this out, so that it can also be used by gvfs and Banshee, and add a method for "give me an icon for this media player", which would return the one from the .mpi, and default to the stock "media-player". Then gvfs would use gdu for "plain" storage devices as it does now, and libmediaplayerid for getting custom icons. It could then even do custom actions such as file format specific operations, such as deciding whether to bitwise copy a file (when the format is supported), or to call a converter to mp3 (when the format is not supported). I'm not sure whether we want that, though, but if we ever do, then I agree that it would be too much if all of this would be bolted onto dk-disks. So gvfs would then use gdu and libmediaplayerid, and only libmediaplayerid would use gudev to query for some ID_MEDIA_PLAYER attribute. What do you think? I also subscribed Christophe Fergeau for some input. Thanks, Martin
I still don't think media player stuff belongs in udisks so closing
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.