The previous commit wasn't actually related to this bug. The problem
here was that the xfwm4 tab window now allows themes to change the size
of the displayed window icons but Thunar still hard-coded its own window
icons to 48px.

From this commit Thunar on uses thunar_file_get_icon_name(current_dir)
to get an icon name for the current directory and and then calls
gtk_window_set_icon_name() rather than asking ThunarIconFactory for a
48px GdkPixbuf that cannot be scaled up nicely. This is ok because we
only ever set icons for directories and for those ThunarIconFactory
never returns anything but a GdkPixbuf based on an icon name anyway. It
never returns a GdkPixbuf loaded from an absolute path or anything.

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.