GNOME Bugzilla – Bug 594649
Have a way to detect optical drives
Last modified: 2018-05-24 11:58:36 UTC
+++ This bug was initially created as a clone of Bug #580779 +++ To make the "Eject" keyboard button a bit more clever, we'd like to replace the current code (which calls eject) by a gvfs call. We want to only eject optical devices, or drives that can do a mechanical eject of the media (Zip, LS-120 floppies, not USB card readers). g_drive_can_eject and g_mount_can_eject aren't sufficient for detecting such drives.
Pasting some comments from IRC <davidz> hadess: we probably need a GDriveType enumeration <davidz> hadess: we might really want that for other things too <hadess> davidz: an "is-optical" property would do me fine <davidz> hadess: I think GDriveType as a flags enumeration is better <davidz> hadess: it's probably too late in the game for GLib 2.22 - unless you can talk mclasen into accepting it (I'd be happy to implement it) <hadess> davidz: don't you remember the list of media types in gnome-vfs? :) <davidz> hadess: file a bug against GIO so I don't forget? <hadess> http://git.gnome.org/cgit/gnome-vfs/tree/libgnomevfs/gnome-vfs-volume.h#n93 zip drives! jaz! <davidz> hadess: yeah, that enumeration in gnome-vfs is a funny mixture of different things - in GIO it's much cleaner because we make a distinction between drives, volumes and mounts (gnome-vfs's drive ~= gio volume, gnome-vfs's volume ~= gio mount) <alex> even then its a pain to do an enumeration like that you'll either have not enought stuff there, or you have to add all know device types in existance <davidz> alex: doesn't really have to be - there's on that many different drives <alex> and then you run into issues with things that are not strictly one or the other, but more like many of them <davidz> alex: that's why you want flags alex: this is what it looks like in DKD: http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:drive-media-compatibility alex: and http://hal.freedesktop.org/docs/DeviceKit-disks/Device.html#Device:drive-media alex: we don't need it to be that fine grained in GIO though <alex> second issue is that we can't realibly detext most stuff on some backends <davidz> alex: that's not really a problem - such platforms just fall back (it is namespaced) <alex> so, we must have some reasonable semantics wher you can't rely on it <davidz> right I wouldn't propose having all the optical disc media types if an app wants more precise info it can probe the device itself, look at udev data or look at dkd data <alex> or even wrong, if we guess from the mount name in the old-school backend so, what apps want unprecise info? <davidz> alex: hadess just wants to know if the media can be automatically ejected alex: e.g. if the drive "pops out the media" so to speak since that is the expected behavior of the eject button on the keyboard e.g. "press the eject button and media will come flying out" maybe we can just export such a property <davidz> maybe we just want g_drive_get_will_media_come_flying_out_if_eject_is_called() since that's really the question for that specific app hadess, alex: anyway, suggest that hadess files a bug and we can discuss it there <davidz> (I'm actually not kidding that it might be useful to just export that method (better name wanted though) - but we need to consider what apps in general wants to do so maybe it is shortsighted to just add such a method - I don't know) <hadess> davidz: done <davidz> hadess: great, thanks I remember that the Brasero guys wanted a way to detect optical drives too for their nautilus extension might be nice if their nautilus extension won't have to poke the drive or udev or dkd
So I think we basically just want a GDriveFlags enumeration where we can add new flags in the future as needed. We won't try to be as precise as DKD or cover a lot of odd ball cases, we'll just add what apps might need (and we only have 32 bits... so we need to be conservative). Looking at what different apps wants, I think typedef enum GDriveFlags { G_DRIVE_FLAGS_NONE = 0, G_DRIVE_FLAGS_OPTICAL = (1<<0), G_DRIVE_FLAGS_OPTICAL_WRITER = (1<<1), G_DRIVE_FLAGS_PHYSICALLY_EJECTS_MEDIA = (1<<2), }; fits the bill for now. Things like media types is already encoded in get_icon() and get_name() so apps need not to worry. If the app needs more detail, it can probe the device itself or collect data from udev or DeviceKit-disks or whatever.
That would certainly be really helpful in libbrasero-media (though we'd still have to poke the drive to get the other information we need).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/241.