This commit improves the handling of leading zeros of numbers in file
names. Previously, the order was not always predictable and was also
often incorrect.

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.

Whenever we release the GFileMonitor of a ThunarFolder, we also need to
disconnect from its signals. Otherwise one of the signal handlers might
still be called, potentially with corrupted user data (which was the
case here).

Whenever show-thumbnails is toggled, we need to either show thumbnails
again immediately or cancel any pending requests to put tumbler back
into idle mode.

Fix by Lionel Le Folgoc<lionel@lefolgoc.net>.

Sigh... I forget this too often.

Patch by Alex Henrie<alexhenrie24@gmail.com>.

Patches provided by Ambroz Bizjak and Axel Sommerfeld.

This reverts commit 61c04e04.

Apparently, the commit breaks SMB browsing (see bug #7774 for more
information). We will have to find another solution for the crash with
mountable drivers that have no media.

This reverts commit 5ce61f48.

There are other ways to achieve the same effect: load the icon and the
name of items in the side pane first and only resolve the real files
when users click on them. But this was easier. Also, I expect the side
pane to be redesigned soon and this fix makes it easier to apply the
change to the 4.8 branch.

This fixes a crash when hovering CD drives with a special icon in
computer://.

Signed-off-by: Jannis Pohlmann <jannis@xfce.org>

Error spotted, reported and solved by Ambroz Bizjak.

This fixes a regression introduced in 4.8. In thunar-vfs we did the same
thing we do now: when a desktop entry is to be renamed we only replace
the Name field instead of renaming the file itself.

This also affects xfdesktop which uses Thunar's rename feature through
D-Bus.

These icons were part of older gnome-icon-theme releases but have now
disappeared. There are no useful equivalents in the icon naming
specification or the GTK+ stock icons (well, there is GTK_STOCK_COPY,
but no appropriate replacement for "stock_folder-move"), so for now it's
best to ship the icons ourselves, I think.

This avoids a segmentation fault when creating files like '%s' or '%S'
using File => Create Document => Empty File.

Apparently, the GVfs trash backend only allows top-level directories in
the trash to be modified. Children can be deleted implicitely but e.g.
when emptying the trash, only the top-level items may be deleted.

To give an example: g_file_delete() fails for "trash:///test/foo.txt"
but succeeds for "trash:///test".

This problem is covered in the trash specification under
"Implementation notes".

The last character of all key names was always left out when storing the
key/value pair in the TDB file. As a consequence, two similarly named
files (e.g. x1 and x2) were treated the same (x) and both were assigned
the same emblems.

This was a regression compared to the Thunar code based on ThunarVFS.
When creating a symbolic link with a name for which a file already
exists, we need to try alternative names such as "link to foo", "another
link to foo" and "4th link to foo", just like we do when copying files.

This commit hopefully fixes this and also makes the "Make link(s)"
action in the "Edit" menu work again.