[Thunar-dev] Thunar Extension Framework

[Benedikt Meurer]

As said earlier I have been working on the extension framework for
Thunar lately. I just commmitted the first bunch of changes which
includes support for menu and property page providers (in a way mostly
compatible with Nautilus).

I've uploaded the current developer documentation to
http://thunar.xfce.org/documentation/thunarx-1/. It describes the core C
API and the background. If all goes well (real life bothers me quite
often recently), there'll be Python bindings available soon, and with
the Python bindings in place other binding-writers should be able to
write the support for their languages quite easily.

Ok, that were the raw facts.

The Thunar Extension Framework (thunarx) is (to some degree) similar to
the extension framework found in Nautilus (as of version 2.5). The main
difference is that Nautilus loads extensions once at startup and never
unloads them again. This makes writing Nautilus plugins very easy, as
you don't need to care about unloading cleanly (and in fact 99% of the
Nautilus plugins I checked would break if Nautilus would ever start to
unload plugins). But the bad news is, that this increases memory usage
if you have a lot of (probably unused) plugins installed.

So, that's not the way to go for Thunar. Thunar loads plugins on-demand
and unloads them when no longer needed (this can turn into a problem for
live-cds, but that's another story). Some extensions just won't work
with unloading (e.g. dependency on a library that registers static
types, or whatever reason), and for these plugins, Thunar provides the
possibility to make them "memory resident".

Ok, that's the good news about Thunar here. But as usual there's the
dark side of the story: Each and every extension installed will increase
the memory overhead and will certainly also decrease the performance
when opening the context menus or the properties dialog (tho, it is very
unlikely that you'll notice the difference with fewer than 100
extensions installed). This is a fact. The more extension you install,
the more memory will be consumed by Thunar. So don't come here and
complain after you installed 20 plugins!

A special note about the Python bindings: For the Python bindings Thunar
will run its own instance of the Python interpreter. This means in
effect, that the Thunar process will not only run the file manager, but
also a complete Python environment with PyGTK and whatever the
extensions use. For this very reason, the Python bindings will live in
its own package "thunarx-python", so users cannot install it accidently
while installing Thunar, but will need to install it separately and
hopefully be aware of what they are doing.

To actually "see" the extensions framework in action, you can install
the open-terminal-here example (see the README in the folder).

And last but not least: The answer to the question "Why do we need that
in Thunar?"; and guess what, the answer is simple: People will request
exotic features sooner or later, that's for sure (e.g. "I want that Open
Terminal Here in the context menu", or "I want a Create Tarball action
there" and so on). And, since I'm not going to add such weird stuff to
the main code base, we need a way for people to add whatever they want
to the context menus (BTW: "Create Tarball" and such actions are better
realized using desktop actions, which will be supported by Thunar soon).
So from now on, whenever somebody asks for a not generally useful action
in the context menu (like the multi-rename requested by Jannis), I'll
tell him to write an extension. ;-)

Benedikt