Monthly Archives: December 2005

Thomas: that behaviour looks like a bug. Are all of those volumes mountable by the user? The drive mount applet is only meant to show icons for the mount points the user can mount.

Note also that the applet is using the exact same information for the list of drives as Nautilus is. If the applet is confusing, then wouldn’t Nautilus’s “Computer” window also be confusing?

To help debug things, I wrote a little program to dump all the data provided by GnomeVFSVolumeMonitor:

http://www.gnome.org/~jamesh/code/gvfs-list-drives.c

Does the output look sane for you? In particular, are any drives or volumes marked “user visible” that should not be?

In my previous article, I outlined the thought process behind the redesign of the drive mount applet. Although it ended up without any preferences, I don’t necessarily think that it doesn’t need any preferences.

A number of people commented on the last entry requesting a particular preference: the ability to hide certain drives in the drive list. Some of the options include:

1. Let the user select which individual drives to display
2. Let the user select which classes of drive to display (floppy, cdrom, camera, music player, etc).
3. Select whether to display drives only when they are mounted, or only when they are mountable (this applies to drives which contain removable media).

Of these choices, the first is probably the simplest to understand, so might be the best choice. It could be represented in the UI as a list of the available drives with a checkbox next to each. In order to not hide new drives by default, it would probably be best to maintain a list of drives to hide rather than drives to show.

It does bring up the question of how to identify what a “drive” is. On my Ubuntu system, the first USB mass storage device I plug in usually gets the same mount point. If we identify drives by their mount point, hiding that mount point will effectively hide all of those drives. Perhaps the HAL UDI would be appropriate here.

The third choice is also interesting: why display an icon for a removable media drive if there is no media in the drive? This sort of feature could probably be implemented independently of the previously discussed choice. It is also the sort of change that probably needs to be addressed in gnome-vfs and HAL though. Fixing it at that level would also provide the same benefit to other GnomeVFSVolumeMonitor using apps, such as Nautilus.

As most people know, there has been some flamewars accusing Gnome developers of removing options for the benefit of “idiot users”. I’ve definitely been responsible for removing preferences from some parts of the desktop in the past. Probably the most dramatic is the drive mount applet, which started off with a preferences dialog with the following options:

• Mount point: which mount point should the icon watch the state of?
• Update interval: at what frequency should the mount point be polled to check its status?
• Icon: what icon should be used to represent this mount point. A selection of various drive type icons were provided for things like CDs, Floppys, Zip disks, etc.
• Mounted Icon and Unmounted Icon: if “custom” was selected for the above, let the user pick custom image files to display the two states.
• Eject disk when unmounted: whether to attempt to eject the disk when the unmount command is issued.
• Use automount-friendly status test: whether to use a status check that wouldn’t cause an automounter to mount the volume in question.

These options (and the applet in general) survived pretty much intact from the Gnome 1.x days. However the rest of Gnome (and the way people use computers in general) had moved forward since then, so it seemed sensible to rethink the preferences provided by the applet:

1. Nautilus’s volume handling has matured a lot since then, and been pushed down to the platform as the GnomeVFSVolumeMonitor API. This API makes it possible to enumerate mounted volumes and mount points on the system, so we can do a lot better than providing an entry box and file chooser to select a mount point.
2. The GnomeVFSVolumeMonitor provides asynchronous notification of mount/unmount events, removing the need for the applet to poll the status. If the applet isn’t polling, then there is no reason for it to provide the update interval preference.
3. The GnomeVFSVolumeMonitor API provides icon names for volumes depending on the drive type. If we can detect that a disk is a floppy or a cdrom or whatever, why ask them what sort of icon to use? This change also means that the icon can be picked from the user’s selected icon theme, providing better integration with the rest of the desktop (not to mention the accessibility benefits when the HighContrast icon theme is used).
4. Certain types of volumes always make sense to eject on unmount. Other volumes don’t. Since we know the volume type, we should be able to just do the right thing.
5. Since the applet is no longer directly checking the mount point status, the “Use automout-friendly status test” preference doesn’t make sense. But even if it was applicable, it is the sort of preference that only has one sane value: assuming both types of status check work, why wouldn’t you want to use the one that works with automounters?

The other major change I made was due to a change in the types of volumes people mount: USB devices. If you have a fixed number of mount points/devices you care about, then the old model works pretty well. If you have a large number of devices, and rarely plug them all in at once, you probably don’t want to create drive mount applets for all of them. My solution was to alter the drive mount applet to display a button for each user mountable volume on the system rather than one applet per mount point.

The result was an applet with no preferences. However, I’d contend that it has more features than before. It has been improved further since then, to provide media-type specific options (e.g. start the movie player if you insert a DVD Video disc).

Glynn: I suspect that the Pixmap memory usage has something to do with image rendering rather than applets in particular doing something stupid. Notice that most other GTK programs seem to be using similar amounts of pixmap memory.

To help test this hypothesis, I used the following Python program:

import gobject, gtk
win = gtk.Window()
win.set_title('Test')
win.connect('destroy', lambda w: gtk.main_quit())
def add_image():
    img = gtk.image_new_from_stock(gtk.STOCK_CLOSE,
                                   gtk.ICON_SIZE_BUTTON)
    win.add(img)
    img.show()
gobject.timeout_add(30000, add_image)
win.show()
gtk.main()

According to xrestop, this program has low pixmap memory usage when it starts, but jumps up to similar levels to the other apps after 30 seconds.

Update: of course, this issue has already been debugged by markmc. It is the SHM segment allocated for drawing pixbufs.