Ross: I like your signal emission proposal! Sadly, GnomeVFSDrive doesn’t have any padding.
On the application startup itself: If we use the MIME type approach, it may be neccessary to add a hidden desktop file for each application (like gthumb-camera-handler.desktop), since the “Exec” line might not be appropriate.
I’ve also noted that “ghumb –import” doesn’t take any additional arguments. Shouldn’t it receive the BUS/Device/ID triple of the camera? Maybe we need new positional parameters for these very special use cases.
Update
Murray points out that one does not have to specify default signal handlers in the class vtable upon signal registration, which obviously renders my concerns pointless. This proves how well-thought out and flexible our core GObject system is. Kudos to Matthias Clasen and all the other hackers :).
On an unrelated sitenote: g_signal_override_class_closure seems to provide a mechanism to override the default handler for subclasses, although this isn’t relevant for GnomeVFSDrives. The g_signal_add_emission_hook API also looks very interesting.
In case it helps, you don’t need to increase the struct size to add a signal to a GObject – you don’t need to have a vfunc default signal handler.
Ghumb? Ghumb! Ghumb. Ghumb. Ghumb. Ghumb. Ghumb!!!!