This probably has to be improved (at least Copy() sometimes causes weird
icon view behavior when copying a lot of files to an open window).
Move transfer jobs work fine.

This helps removing thumbnails from the on-disk cache that are no longer
needed because the original file no longer exists. It does a pretty good
job at that but there's more work to do to integrate Copy(), Move() and
Delete() in all the jobs.

This one also uses a queue and a timeout of 250ms to group Copy() D-Bus
method calls.

We again use something like the wait queue in the old ThunarThumbnailer
here for grouping Move() and Delete() calls. The same will be done for
Copy(). It performs really well, moving 200 images from one folder to
another only generates a single Move() request with all images. At least
on my fast machine.

The actual calls to thunar_thumbnail_cache_move_file() and
thunar_thumbnail_cache_delete_file() in the transfer and I/O jobs still
have to be added.

With this tumblerd can just copy the thumbnail and adjust its meta data
when a file is renamed. We thereby avoid regenerating thumbnails for
files that are simply renamed but whose contents don't change at all.

We probably need some extra code to check whether the file type has now
changed or become incompatible with tumbler. In that case we will have
to drop the thumbnail. But how often does this really happen?

This is the second part of redesigning how thumbnails are requested in
Thunar. Each ThunarStandardView now has a ThunerThumbnailer object.
On scroll and resize events and whenever a new directory has finished
loading, ThunarStandardView now schedules a timeout or idle handler
(depending on the situation) to request thumbnails for all visible items
of the view.

This timeout/idle handler is rescheduled whenever the user starts
or continues scrolling or resizing. This avoids sending requests while
the user is scrolling and its important to not have D-Bus interfere with
the Thunar main loop. We now have a much more responsive thumbnailing
and scrolling experience!

Requests are also dropped by each view when a directory is closed/left.
This means that we no longer generate thumbnails the user is not
interested in any more.

This commit also uses the proper D-Bus method for cancelling thumbnail
requests (it's called "Dequeue", not "Unqueue").

The properties dialog is updated to match changes in the
ThunarThumbnailer API.

This commit also drops ThunarThumbnailer in ThunarIconFactory and adds
it to ThunarPropertiesDialog. There will be one ThunarThumbnailer for
each ThunarStandardView soon in order to bring back normal thumbnail
generation.

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

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.

New status: 675 messages complete with 2 fuzzies and 1 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 661 messages complete with 13 fuzzies and 4 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 289 messages complete with 0 fuzzies and 4 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 447 messages complete with 0 fuzzies and 231 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 673 messages complete with 3 fuzzies and 2 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 678 messages complete with 0 fuzzies and 0 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 1 message complete with 0 fuzzies and 292 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

New status: 439 messages complete with 0 fuzzies and 239 untranslated.

Transmitted-via: Transifex (translations.xfce.org).

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.