[Libvisual-devel] Desktop files and libvisual

[Max H. <max...@me...>]

I rather fancy little screenshot images from each visualisation on demand. =
And=20
a little meta data. A good way in my mind to get this stuff without having =
to=20
dlopen any plugins is to use freedesktop desktop files. In amaroK we use=20
desktop files to fish for our engine backends, they look a little like this:

[Desktop Entry]
Type=3DService
Name=3Dxine Engine
Name[sv]=3DXine-gr=C3=A4nssnitt
ServiceTypes=3DamaroK/Plugin
X-KDE-amaroK-plugintype=3Dengine
X-KDE-amaroK-name=3Dxine-engine
X-KDE-amaroK-authors=3DMax Howell
X-KDE-amaroK-email=3Dm...@me...
X-KDE-amaroK-rank=3D254
X-KDE-amaroK-version=3D1
X-KDE-amaroK-framework-version=3D3

The specification for the files is here:=20
http://freedesktop.org/wiki/Standards_2fbasedir_2dspec

well it should be, but currently freedesktop.org seems to be broken.

We use ktrader to get plugin information, which is fast because kde caches =
the=20
data in a kind of "registry" file. I'm sure there is an equivalent for=20
glib/gnomelib clients.

So each actor could have a screenshot.png in some share/ directory and the=
=20
desktop for that actor could have a set of entries like:

X-libvisual-type=3Dactor
X-libvisual-name=3Dfoobar
X-libvisual-screenshot=3D/path/to/png

etc.

The advantages is the lower load time for information, and that you don't h=
ave=20
to recompile to change these details. But I dunno if that's a good enough=20
reason as you could always make a plugin cache. But this way you don't have=
=20
to make more functions for extra meta data, nor update the api for new=20
metadata, and clients don't have to use new tools to get the data.

There's probably more pros/cons, but I'm not extremely experienced with the=
ir=20
use.

Max
=2D-=20
Max Howell; MK, UK; http://www.methylblue.com/