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

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

Using strlen() for the number of characters is unrealistic when dealing
with multibyte strings.

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

I'd like to see if this has an impact on make distcheck. It could be
that only modules using XDT_FEATURE_DEBUG(), like xfconf and Thunar,
break due to this error in the scanner code generated by gtk-doc:

thunarx-scan.c: In function ‘describe_signed_constant’:
thunarx-scan.c:884: error: comparison between signed and unsigned

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

This reverts commit 40684e73.

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

We now have startup notification support in the Thunar D-Bus interface
which adds a startup ID parameter to some of the D-Bus methods.

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

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

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

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)