The nautilus-open-terminal extensions appends a menu item for opening Midnight Commander, but only if it is installed and the functionality is activated via GConf. Whether it is installed is currently checked via
g_find_program_in_path ("mc")
which does synchronous I/O and therefore blocks the UI when the disk spins up after standby (bug report). I see two obvious ways of fixing this:
- Only do the check once at startup. As a user, I’d hate this because if I installed Midnight Commander during runtime, I’d expect the menu item to show up immediatly.
- Use PackageKit instead of the above call for checking whether the midnight commander is installed
Clearly, it is preferrable to use PackageKit for such a task due to its caching facilities. But I need some help from the PackageKit experts out there: How are the names of the packages standardized, especially those not shipped with GNOME? The libpackagekit API description seems to suggest cryptic names like “hal;0.0.1;i386;fedora”. How can I specify the package name in a cross-distribution way? Wouldn’t we need a package-naming-spec, similar to the icon-naming-spec?
Update
Some interesting comments:
- Oliver asks whether MC installs any .desktop file and proposes to check its extistence. hron84 points out that MC doesn’t.
- Richard Hughes who started PackageKit provides sample code that synchronously calls a certain PackageKit D-Bus method for checking whether a certain package is installed, and says that package naming is inconsistent between distros which I shouldn’t care about because they can patch my code.
- Xavier Claessens points out that PackageKit reads from disk too, and proposes to use an async. version of g_find_program_in_path().
- foo proposes to call a threaded version of g_find_program_in_path() and wait with the UI addition until it returns.
- Morten Wellinder says that package checking through the distro does not answer the question whether the “mc” binary is present, since a user could have installed it manually as well.
Regarding comments 3.+4.: The idea of an asynchronous version seems to be attractive, but the way Nautilus currently manages its extensions does not allow that easily because all extension menu items are added synchronously as Nautilus notices that the displayed files or the selection changed.
Regarding comment 5.: I agree that it seems to be somewhat wrong to ask the package management system whether a binary is present, but the idea behind it was that the package management can have an in-memory cache and track whether any packages have been installed since the last access such that no disk access is required at all. At least if the package management has been written with efficient file monitoring. On the other hand, the $PATHs are not cached and monitored. I also agree that manual installations of packages are possible, but this is somewhat rare for a “low-level” package like mc.
That said, an interesting third solution may be: Add a GIO-powered g_find_program_in_path() variant that uses file monitoring to track changes to all directories in the $PATH, and only does as few disk accesses as possible. Of course, in general it does not make sense to keep the entire contents of the $PATHs in memory, but just add a hash table of all programs that were requested and whether they were present or not. I don’t know how reliable file monitoring is, though.