So, I thought some more about the content type guessing. The current code allows you to read files from all sorts of backends, and enumerate the various places you can read from (volume monitor), if you add to this a content type and a way to get at the lowlevel identifiers for the volumes (so that you can optionally map them to other libraries and get more details) this is quite powerful for many apps.
However, I'm not sure its the right place the actual content type guessing API. Lets take a step back and consider the whole desktop. Any time you mount something you want to guess the content on that so that you can spawn the default operation. Another user of the content type would be the f-spot photo import dialog, which would default to only show "photo" type devices and mounts. However, at this points its not ideal to have to start sniffing all the mounts before bringing up the dialog, as that is kinda slow. So, it seems to me, that the ideal approach is to sniff content types each time something is mounted, and to remember that for further (cross-process) use. And a good place to put the sniffing would be where the "open default content action" guessing happens. I'm not sure where/how to store this though, as its a per-session thing really (some mounts are session local, and session settings might affect the results), and hal is system wide. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
