If anyone can point me at a good reason to use them, I'll happily add
them back. Until then they are just two more characters to read on the
screen in my opinion.

This makes it more obvious that Thunar has recognized the user's cancel
action and is about to cancel the job. Sometimes this takes a while, so
this text will help users in being patient. Suggested by Steve Dodier.

This is done by making it visible only when the progress dialog is
shown, not whenever a job is added or removed.

All operations that have only one target directory now have its display
name in the title of the corresponding ThunarProgressView, e.g.
'Copying files to "Test"...'.

This is accompanied by a new function called
thunar_file_cached_display_name() which takes a GFile and tries to
determine the display name of its cached ThunarFile, and otherwise falls
back to g_filename_display_name().

It still seems to reduce the CPU usage by about the same amount than
0.05 percent did (5-9% instead of 50%).

GIO generates a lot of calls to the progress callback. If we simply
forward those to the GUI in the form of 'percent' signals, we cause the
CPU usage of the X server to go up dramatically (up to around 50%).

A better solution is to only emit the 'percent' signal from time to
time but frequently enough for progress bars to advance smoothly. This
is what this commit changes. From now on 'percent' is only emitted when
the percentage has increased by more than 0.05 percent since the
previous emission.

This introduces a new view called ThunarProgressView which essentially
replaces the old ThunarProgressDialog. The new ThunarProgressDialog is a
container GtkWindow (I wonder about renaming it to ThunarProgressWindow)
for all the ThunarProgressViews associated with running file operations.

ThunarProgressDialog also creates a status icon that can be used to
toggle its visibility.

Things left on the TODO list:
- Check if we can lower the CPU usage of the dialog (X goes up to
  around 50% on my machine with the dialog visible), compare this to
  the situation before.
- Double-check if the use of gtk_window_present() is correct here.
- Either prepend (instead of append) new views or scroll down to them
  upon their creation.

Cancelling e.g. the credentials dialog is something users do on purpose.
Thus we don't need to show them a cancel error dialog. There is a bug in
GVfs however which results in a permission denied error instead of a
cancel error when the user presses the cancel button in the credentials
dialog. It was filed against GVfs (#594798 in GNOME's bugzilla).

I wonder how the trash even worked without returning the original path
from thunar_file_get_original_path()...

This requires deriving ThunarApplication from ThunarBrowser but that
should be fine. This way we also fix cases where the user passes URIs of
shortcuts or mountable files to Thunar.

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

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

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

Centering the icon is done by hiding the alignment in which the label
would otherwise be presented. The alignment wastes space even if the
label is empty or hidden.

Just like the rest of ThunarThumbnailer, this code is somewhat scary.
ThunarThumbnailer now queues individual thumbnail request in a wait
queue which is triggered at most every 100ms. All requests made in this
time slot are grouped and sent out as *one* request.

For each time slot, the local optimization is 3+n D-Bus messages (1
request, 1 started signal, 1 finished signal and n ready signals) as
compared to 4*n messages we had before (1 request and 1 started,
finished and ready signal for each individual file).

Of course this calculation is naive. In theory our users scroll up and
down like crazy, sometimes slower, sometimes faster, everyeone using
different Thunar window and icon sizes.

As a result the grouped requests are sometimes very small and sometimes
very large. It's worth noting that this optimization performs better,
the more files are visible in the window and the faster a user scrolls
(as this means that more files are made visible within 100ms and thus,
the size of group requests grows). So I guess we're good.

File system is also included in the placeholder as it is supposed to
appear between trash and network for consistency reasons. However, the
file system action is always added to the action group as it will of
course always be displayed.

Otherwise use it's display name in order to be consistent with the
translations of GVfs (or whatever trash implementation is being used).

With this commit, the trash icon is only displayed when the trash:// URI
scheme is supported by GIO. It also adds a network icon if network:// is
supported. Items have been re-arranged a bit. The order now is: home,
desktop, trash, file system, network.

This function checks whether an URI scheme is supported on the system or
not. It will be used by Thunar to find out whether to show/hide
important system paths like trash:// and network:// in the side pane and
in the go to menu.

We probably don't want to set the executable flag for files if we don't
know their UNIX mode. Using 0666 for files prevents Thunar from trying
to execute those files. We still need 0777 for directories though
because only with the execute bit, one can browse a directory.

This helps getting rid of a lot of unnecessary emblems (like for the
trash icon in the side pane).

With GIO, the size of the trash:/// directory no longer corresponds to
whether the trash is empty or not. Instead, we have to use the
G_FILE_ATTRIBUTE_TRASH_ITEM_COUNT attribute. This commit adds a new
method thunar_file_get_item_count() which is used the shortcuts pane and
the tree view to make the empty trash action sensitive or insensitive.

Also remove a few redundant g_file_info_has_attribute() checks.

This restores the old pre-GIO behavior. Remote file systems and schemes
like trash:// don't support trashing, thus we need to delete their files
permanently.

This didn't work before for several reasons: the trash attribute
namespace was not part of THUNARX_FILE_INFO_NAMESPACE and Thunar tried
to read trash::orig-file but it's actually trash::orig-path. Last but
not least, this one is not a normal but a byte string attribute.

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

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