I'm used to using Thunar to open multiple files at once in the same application (in this case Audacious). The .desktop file for Audacious has %U in the Exec line, meaning that the program should be invoked with multiple URI's on the command line rather than running a separate instance for each URI (see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html). Thunar respects this only when multiple files *of the same type* are selected. For example, if I open 6 .ogg files in Audacious, only one instance is run, and the playlist contains those six files. But if I instead open 6 .ogg files and one .mp3 file, suddenly Thunar tries to run 7 different instances of Audacious, each one with only a single file in the playlist. (In practice, the number of Audacious windows that actually pop up varies between 2 and 4, rather than 7, since Audacious tries somewhat unsuccessfully to keep only one instance running.)
Created attachment 3790 Use proper hash function The problem is the way a hash table is used in thunar_launcher_open_files(). The equality test used is g_app_info_equal(). But the hash function used is g_direct_hash(). This is wrong because two "equal" GAppInfo structs may still have different pointers and therefore different hash values according to g_direct_hash(). My patch uses g_str_hash() on the return value of g_app_info_get_executable(). This does assume that two "equal" GAppInfo structs will refer to the same executable.
(In reply to comment #1) > My patch uses g_str_hash() on the return value of > g_app_info_get_executable(). This does assume that two "equal" GAppInfo > structs will refer to the same executable. I'm not sure that's an assumption we can make.
Well, if you don't want to make any assumptions at all, you can use a hash value of zero for everything. But that defeats the purpose of using a hash table in the first place.
Created attachment 3791 Hash function that makes no assumptions
Ok, summary: GIO freslhy allocates GAppInfo objects all the time, it does not return the same GAppInfo object across multiple g_app_info_get_default_for_type() calls (not even with the same content type). So, you're correct, if we use a hash table for this, we need our own hash function. I'd rather put this into thunar-gio-extensions.{c,h} though than into thunar-launcher.c. And I'm thinking about dropping the hash table and going for a plain GList instead. There are not that many GAppInfos to iterate over anyway.
I've pushed the fix to master. I will also apply it to the stable xfce-4.8 branch. commit 16055b933c938886488c06b402e68e7383318a3a Author: John Lindgren <john.lindgren@aol.com> Date: Sun Feb 26 18:52:24 2012 +0000 Fix handling %U when launching multiple files with an app (bug #7456). GIO returns a newly allocated GAppInfo every time g_app_info_get_default_for_type() is called. This means that if we use a GHashTable and g_direct_hash() to associate GAppInfos with files to be launched with each of them, we will actually end up with multiple GAppInfos that are the same, and each of them will only have a single file associated. To fix this, we now use a fake hash function that causes GHashTable to always search the GAppInfo in the collision list.