[Thunar-dev] Thunar Extension Framework

[Emil Jacobs]

Hey all
A short question about usability: will the plugin install method be
similar to that of firefox's?
With a checker on the background that checks for updates and so on?
I think this would be a nice step forwards, but I don't know if this
is the plan or has been suggested before, sorry if it did :)
Cheers

Emil

On 9/11/05, Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de> wrote:
> 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
> _______________________________________________
> Thunar-dev mailing list
> Thunar-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/thunar-dev
>