Back in the GNOME 2.x days, device hotplug management was done entirely by Nautilus; you know, those dialogs that pop up when you plug your photo camera or your USB drive. This worked fine, as Nautilus was always running in the session, being it also the process drawing the desktop. The desktop itself provided a way to eject the devices, by right clicking on their icon and selecting the appropriate menu action.
In the 3.0 era Nautilus moved away from being a central component of the user experience, and if you used GNOME 3, you will have seen we actually dropped the desktop metaphor by default already; that unfortunately left us with no place to access the list of devices plugged into our machine; in fact, in 3.0 you have to open Nautilus manually to eject an USB drive. Also, the code for handling autorun notifications was moved to gnome-settings-daemon, which will trigger the old-style GTK+ dialog when a device is plugged in.
Clearly, we could do a lot better. A while ago I started a design whiteboard page to analyse the current state of the art in this area, and last week I finally sat with Jon thinking about the user experience we want to achieve here. You can read more about it in the tentative design section of the whiteboard page.
Shell Integration
We decided to implement the feature with using notifications in gnome-shell
When a new device is plugged, the shell will trigger a notification (after having consulted the settings from the ‘Removable Media’ panel in gnome-control-center) containing a list of applications suitable for handling that device. This is similar to what we used to have in 2.x; if you plug in a blank optical disc, you will find “CD/DVD Creator” (Brasero) in that list, if you plug an iPod we’ll show “Rhythmbox” or your default music player, if you plug your photo camera Shotwell will be shown…you get the idea; you can also eject the device directly from the notification.
After you dismiss the notification, you will be able to access the list of your devices from the message tray, which will grow a ‘Removable Devices’ item as long as there’s at least one device connected to the system.
From this menu you can still activate the default autorun action by clicking on the device name/icon, or you can eject it, by clicking on the button on the right hand side. If the device cannot unmount, due to a file still open on it, we will show a nice dialog from where you can get to the application directly, or force unmount if you prefer.
Generic drives
One problem the 2.x implementation didn’t really tackle is what to do when generic drives (like, say, an external hard disk, or a random USB pendrive) were attached. I believe the default was just to run Nautilus in those cases, or worse, we would show a meaningless autorun dialog with no choices inside it.
In my new implementation, I wrote a small crawler program that gets DBus-activated by the mounter process (in this case the shell) and tries to gather as much information as it can about the content type of the files in the device. Of course, we don’t want to hammer your 2TB drive with a full scan, so the crawler has a hard time-limit not to do I/O for more than a fixed amount of time (I empirically found 1.5 seconds is a good value for this). The crawler doesn’t care about the specific mime type of the files (say, FLAC vs OGG) but rather what the file is about (say, Music vs. Video), so it will return a list of up to three “generic” mimetypes for the drive content, ordered by relevance; applications that claim to handle those generic mimetypes will appear in the notification. As a last fallback, if we don’ t have any of these applications available, we will show an entry to open the drive in Nautilus from the notification. This aims to integrate with the upcoming application design for Finding and Reminding.
What’s next
I need to post my current iteration of the patchset for review, but I already have some further improvements and polish planned in the pipeline:
- we need to handle password-protected volumes (e.g. encrypted USB sticks) directly from the notification, e.g. having an entry there to unlock the device directly
- we probably want to show an entry in the device list if the laptop is plugged into a docking station. Clicking the eject button there would be equivalent to pushing the hardware button on the dock itself.
- we need to find a good story for fallback mode. I think we can just keep the current gnome-settings-daemon plugin in place, and activate it only if fallback mode is detected, but this is currently not implemented.
34 comments ↓
I dont know why but for some reason i particularly love the 3rd screenshot…
Oh no – you’re going to add a Windows-esque “what do you want to do” when I plug in a generic USB key which has music and pictures on it 🙁
Ah well – you can’t please all of the people all of the time 🙂
what happens when I dont run gnome-shell? e.g. the classic session or unity?
I won’t bash GNOME for leaving this out earlier, but I do hope that a valuable lesson has been learned here.
Haste. Makes. Waste.
Here’s hoping for a better (much better) 3.2…
Nice, but keep an eye on consistent terminology. You use the term ‘eject’ in one screenshot, and ‘unmount’ in another.
Great work! It is great seeing this kind of polished items in 3.x 🙂
@Pavel: you definitely won’t get what I showed here. Depending on how the fallback code path will be implemented and how those OSes interact with gnome-settings-daemon, you might get your volumes auto-mounted though, and the old-style GTK+ autorun dialogs. Note that I want to support fallback mode, but there’s no such thing as a classic GNOME session anymore, and I don’t have any interest in supporting Unity.
The crawler process might end up living in GVfs though, so it could possibly be reused from other OSes without depending on gnome-shell.
@Simon: thanks. The ‘Unmount Anyway’ string comes directly from GIO, so it should be fixed there. I plan to use ‘Eject’ consistently.
Doesn’t this kind of thing belong in the top bar? I mean, we have icons there for managing wireless connections, sound, battery, and presence. Surely attached storage devices fit?
There are already some gnome-shell extensions that make attached storage devices visible on the top bar, and they work well and stay out of my way. If I’ve just plugged in a thumb drive, I don’t need a notification – I just need an obvious place to access it.
Have a look at gnome-shell-extensions-drive-menu. Simple and effective. It doesn’t appear until a drive is connected. If you must add Windows-esque “What would you like to do with the disk?” prompts, please be sure to allow us to disable them.
Oh no not in the gnome-shell message tray! I try my best to never go down there, it’s such a usability nightmare (undiscoverable, moving targets, inconsistent click areas, bleh).
As others have noticed, the message tray might be a bad choice.
Not because of its UI problems (if there are problems, they should be fixed), but because the message tray is supposed to be for messages signalling changes in system status or user-aimed communication.
If I power on my system with a USB HD attached – very common use case in desktops- I will not get a notification for hotplug, and a notification stating that I have a piece of hardware connected would be really out of place. But my system includes an attached device that I might need to unplug or “launch” from the get go.
The attached devices availability is more of a static system feature and as such conceptually belongs to a system indicator on par with network connection and audio, not to a message tray stack.
Just talking out loud here but has anyone ever used that ‘What do you want to do?’ prompt to do anything other than open the drive in a file browser and if so, did it work as expected?
It would be nice if the following was also implemented:
If you plug in an external hard drive that has multiple partitions on it, you currently have to unmount each partition separately. When you unmount a partition, it could detect that there are other partitions still mounted of the same disk and offer the choice of unmounting these too:
[Eject only this partion] [Eject whole disk]
(Mac OS X has this, and it’s a nice touch.)
Have you considered adding a small disk usage bar to the Removable Devices menu (2nd shot). We have this in the current Netbook UX (I found a screenshot here: http://meegoarena.com/wp-content/uploads/2010/05/meego-netbook-devices-panel.png) and it turns out that users love it.
This looks sooo nice and well integrated. Finally, there is a device manager like in KDE SC 4. That one is so convinient.
But the people are right, get it to the top panel. In KDE the Icon for the device manager disappears when there are no devices to interact. So the user knows if there is an usb drive plugged in. Isn’t that possible in Gnome Shell, too?
Anyway,good Work dude!
Why do you want to add the “Open in Nautilus” option only as last resort? Isn’t it be a valid choice for every disk mount?
Otherwise – nice! 🙂
Oh, and I disagree with the placement, I think it should be in the top bar somewhere as that is where all the other hardware menus are. With this design the bottom would be for application notifications *and media*, which seems rather arbitrary.
This is looking pretty nice in many ways. I would agree that it should be on the top bar, with the other hardware and system items rather than in the ‘bottom bar’, with programs.
Also a tiny bit more richness and action discoverability about the notifications themselves (i.e. status of device if relevent, capacity and ideally a positive action to do something with the device other than unplug it would be good).
We’d also like to see how MTP devices (which can behave like USB mass storage, but don’t need to be ejected before removal) would be displayed.
Still, great work!
In the first screenshot, the list of possible actions really shouldn’t be in rows. You’re wasting a lot of space, and making them harder to hit. They should be in columns so that there’s less aiming involved.
In addition, you *don’t* want the eject button to be easy to hit, so it should be above the other actions, a little spaced apart, and smaller.
You can perhaps have a maximum of four columns, with additional rows for more actions, or maybe just limit the no. of actions shown to four, and have a button on the side for “more”.
One more thing: it’s not immediately obvious that the user can click those things. They remind me of the chat lines in the IM bubbles.
But I like the overall plan a lot! This has been one of the “missing things” in GNOME 3.0 for me.
Looks exactly how it should be. What about network mounts, will they be shown? I.e. “volume is busy” should be quite useful for network file systems.
Rolandixor: You cannot just do everything at once. Some stuff gets added later on.
Having everything perfect at x.0 might be nice/needed in theory, but in practice it is just not feasible.
While I know implementation-wise, using a system modal dialog from the Shell is easier, are you sure that’s the best solution as regards usability? System modal dialogs are currently used for authentication and logging out, which are system-wide actions. Force-ejecting a drive isn’t the same: it shouldn’t appear like a critical operation.
Thus, I’d rather use a standard GTK+ dialog like the current one, or maybe another notification, which makes sense since you’ve just clicking on a notification bubble when you eject a drive. That notification could also be used to say “Please wait while ejecting…” and “You can now safely remove the drive” when done.
Forgot to say: the general plan sounds great, that’s really what we lack in 3.0! 😉
USB Audio devices hotplug!
When I plug my usb headset, I want to have pulseaudio input device set to the headset microphone by default. Maybe audio too, but it would be _great_ to route only videoconference programs output audio to the output device in the headset.
[…] sistema aquí o allá. Precisamente es lo que nos cuenta uno de los desarrolladores de gnome en su blog. Recordando aquellos tiempos en Gnome 2.x cuando al montar un dispositivo usb (cámara, memoria […]
[WORDPRESS HASHCASH] The comment’s server IP (74.200.247.239) doesn’t match the comment’s URL host IP (76.74.254.120) and so is spam.
@Nick Richards: MTP devices (driven by GVfs’ libgphoto2 backend), and for that matter iPhones and modern iPods (driven by GVfs’ AFC backend) are handled exactly the same way as Mass Storage devices thanks to how the GIO abstractions work
What does “Open with Documents” actually mean? Opening a random document that happens to be located on the device is pointless. There should be always an “Browse with Filemanager” item here as it is by far the most common task that is done after plugin a device. The only other thing that makes sense is music, photo and video players (mp3 players, cameras, DVDs). Every other application that is supposed to work with a specific file is rather pointless because there is no way to guess which file user is intended to open or if he/she wants to view a document at all and not just move a file on the drive.
[…] may have read about this on Cosimo’s blog, but he’s already a way along with making device hot plugging work nicely with the shell. […]
[WORDPRESS HASHCASH] The comment’s server IP (216.151.210.18) doesn’t match the comment’s URL host IP (76.74.254.123) and so is spam.
[…] es la gestión fácil de los dispositivos extraíbles, pero por suerte, los desarrolladores ya pensaron en eso y le están dando solución al problema. ¿Cómo? Puede añadiendo el montaje de los dispositivos […]
[…] pode ter lido sobre isso no blog de Cosme , mas uma vez concluído esse trabalho, você receberá notificações adequadas quando você […]
[WORDPRESS HASHCASH] The comment’s server IP (174.120.239.194) doesn’t match the comment’s URL host IP (174.120.239.217) and so is spam.
I didn’t read all the comments, so sorry if it’s duplicate, but the third screenshot shows a typical “developer’s design”. It does not tell you which instance of the Document Viewer is the problem and it does not tell you which file is the problem.
It basically tells you that something is wrong and that you have to fix it, but not HOW to fix it. Ideally it wouldn’t need to tell you, but instead just offer a solution.
Also, the menu should be at the top. Managing connected volumes fits managing network connections, audio volumes, etc.
[…] Link: http://blogs.gnome.org/cosimoc/2011/06/23/hotplug-hotness/comment-page-1/#comment-129 […]
[WORDPRESS HASHCASH] The comment’s server IP (96.248.216.98) doesn’t match the comment’s URL host IP (96.248.216.99) and so is spam.
@Mike: I kind of agree with your point about that force unmount dialog (Evince shouldn’t really keep the file open on the device while viewing it though).
The problem here is more a technical one than a design one, since all you get from GIO for this kind of errors is a list of the pids for the processes blocking the unmount. In this specific case, Evince spawns a different process for each file, so it’s not a problem, but I see how it could become confusing for other applications.
when a drive or media is inserted into the system there is a notification asking for us to either choose its menu or click on its borders to make it go away,while we are busy working at something else.
It doesnt automatically slide down with the routine notifications and it stays there until u respond to it.
how to disable these notifications?
Leave a Comment