I can try to trap the Interrupt at a lower level and inform the gtkmm application.
No, that is a kernel space activity. Fortunately, the kernel does report the outcome of certain events via interfaces accessible from userland.
It's a little ambiguous in your question whether you want to detect when a block device is attached, or when a filesystem is mounted (although it seems to be more the former). If your system uses automounting (they usually do by default), it will mount filesystems from block devices when they are attached, otherwise you have to do it manually (e.g., with
Either way, you want to poll/parse/scan a kernel file node based interface. I've done this before in an application (a C++ GTK one, in fact) that tracks both attached block devices and mounted filesystems via
/etc/mtab. This is a straightforward, language agnostic method. Some people find it a little distasteful at first because it involves reading files/directories, but these interfaces do not actually exist on disk, so there is no heavy I/O overhead, and remember:
read() is a system call. Reading the file nodes in kernel interfaces amounts to the same thing as a
listAttachedDevices() style API, except again, it is language agnostic. When you go to read from these nodes, the kernel passes you the information they represent directly.
/dev directory lists attached devices as special device node files -- e.g.
/dev/sda. These are added and removed by the kernel as devices are plugged in and out, so if you track it by polling at intervals (say every 5 seconds), you can detect what's new and what's gone. The only complication here is that since there's no callback style API, you have to create your own thread for this if you do want a continuous check (perhaps why
gparted requires you to click
Refresh Devices instead).
A probably better alternative to
/dev would be the stuff in
/sys/block. Note that there is a significant difference between
/proc (see below) or
/sys in so far as the nodes in the latter contain information about things such as devices, whereas the nodes in
/dev are an actual connection to the device (so if you scan
/dev, don't bother reading the individual files, just note they exist).
/etc/mtab now-a-days is a symlink (see also the
-s switch in
man ln) to
/proc is a major swiss army knife kernel interface (see
man proc). This lists mounted filesystems; if you use automounting things will appear and disappear from there when stuff is plugged in/out. The information in
/sys is usually in the form of ASCII text, so you can look at these files with
cat, etc, and parse it with string(stream) functions.
WRT to other kinds of devices, such as a fingerprint scanner,
/sys is a good place to start --
/sys/dev contains a
block and a
char directory. Block devices are usually storage; the information on them can be randomly accessed. Char devices exchange information with the system in a stream, which would include things like scanners, cameras, HID stuff (human interface device, e.g. mice and keyboards). I notice that gtkmm does have some high level stuff for attached HID things, presumably since these are significant in interacting with the GUI.