Em Sexta-feira 26 Junho 2009, às 15:19:48, stefan.k...@nokia.com escreveu: > hi, > > the spec [1] only talks about > XDG_DATA_DIRS/HOME -> e.g. icons, docs, ... equiv of e.g. /usr/share > XDG_CONFIG_DIRS/HOME -> settings, equiv of /etc > XDG_CACHE_DIRS/HOME -> e.g. a plugin cache, equiv of /var/cache > > but there is nothing for plugins (equiv of /usr/lib). E.g. the user aquired > the gstreamer mp3 decoder plugin from fluendo (which sits right now in > ~/.gstreamer-0.10/plugins). If this would justify xdg where should t go > instead? Would it make sense to add a XDG_LIB_HOME -> $HOME/.local/lib > gstreamer could then use $XDG_LIB_HOME/gstreamer-0.10/ > > Would we also want this for executables? > XDG_BIN_HOME -> $HOME/.local/bin > > As usual the names can be discussed as well :)
I think those could turn out to be useful.
However, I just don't see why you'd want that right now.
XDG stuff is there because it's shared among different applications, libraries
and toolkits. They need to know how to find the information that they require,
in order to interoperate with other applications and the desktop.
Plugins are hardly that case. They are very much application- or library-
specific. Therefore, those can store the plugins anywhere where the FHS allows
them to.
Unless you're thinking of a form of XDG plugin system, I don't see the use-
case. Can you elaborate on why you thought of this?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Software
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
