Repost: Thunar update

[Jannis Pohlmann]

On Sat, 20 Jun 2009 18:33:37 -0700
Josh Saddler <nightmorph at gentoo.org> wrote:

> Jannis Pohlmann wrote:
> >   - Another big change: thumbnails are now requested from a D-Bus
> >     service. An implementation of this service is Tumbler
> >     (http://git.xfce.org/jannis/tumbler) which I wrote in the last
> > 1.5 months and which will see a release soon. I know this is a
> >     controversial decision. 
> 
> Why's this controversial? Because of speed/performance issues,
> requiring more dependencies to be built & installed, or something
> else? Please elaborate. :)

Well, it's still optional but it means that if you want thumbnails, you
need D-Bus. But you need D-Bus for the communication between xfdesktop
and Thunar and for things like xfconf anyway, so I guess most
distributions enable it.

The number one reason why this is controversal is indeed that people
fear performance issues.

There are quite a lot of D-Bus messages being sent (4 per file)
whenever you enter a directory. I've done some optimizing so that
messages are only sent for files that are supported by the thumbnailing
service (you can query supported MIME types), so this is not a problem
unless you enter a directory with tons of "thumbnailable" files. But
even then, communication with D-Bus happens asynchronously and files
are updated in idle sources, so thumbnail requests don't block the GUI
at all. In addition, Thunar only generates thumbnails for files that
are visible in the view (which doesn't really help if you scroll around
like crazy though).

I know that on a reasonable fast machine, there is no performance
problem at all. It might be a little slower than before but compared to
the time it takes to generate thumbnails for e.g. PDFs or large PNGs,
the D-Bus messages are hardly noticable.

I'm going to test this on slower hardware soon.

The good thing about the D-Bus thumbnailer service is that other
programs can use it too, like image viewers (e.g. ristretto) or
xfdesktop. Nokia is already using this concept on Maemo and
they are considering to switch from hildon-thumbnail to using the
implementation I wrote. Additional optimization is possible by trying
out different scheduling algorithms in the D-Bus service. 

> >   - If GVfs is installed, Thunar can browse/open files over
> >     and possibly more (like gphoto).
> 
> What about, say, obex://? I know nautilus can do this, but I'm not
> clear on whether or not it does that with gvfs, or with
> gnome-vfs-obexftp or something similarly deprecated.

Hmm, no idea. I'd have to check what URI scheme GVfs supports.

> >   - GIO itself has no volume management feature. This is provided by
> >     GVfs in the form of a HAL volume monitor. The problem is, GVfs
> >     depends on GConf and gnome-keyring. While gnome-keyring is
> > really useful, GConf is something we probably don't want. In their
> > Git repository, GVfs even depends on gnome-disk-utils because they
> >     decided to use that instead of directly talking to
> > DeviceKit-disks.
> 
> Disagree. gnome-keyring is not useful for all of us, especially those
> of us who, like me, do not want any trace of Gnome on their systems.
> Having gnome-keyring pulls in lots of Gnome dependencies, which means
> a lot of bloatware I have to compile and install, and then not use at
> all . . . as I don't have encrypted volumes.

gnome-keyring is required by GVfs for the password management stuff
(e.g. SSH or FTP credentials). That's not going to change and if you
want to be able to browse SSH, you will have to install it. Maybe we
can encourage maintainers to make gnome-keyring drop its GNOME
dependencies.

gnome-keyring only depends on GConf, libgcrypt, libtasn1, PAM, HAL and
D-Bus. So the only problem here is GConf. 

For now, I only care about volume management. We had volume management
without GNOME dependencies, and that should not change. Everything
else, like SFTP or FTP is a bonus and you'll need GVfs for that. Well,
at least unless someone decides to write a GIO backend for those URI
schemes.

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20090621/71cc8383/attachment.pgp>