[compiz] Plugin Dependencies

[David Reveman]

On Tue, 2007-02-27 at 16:01 +0000, Ben Reeves wrote:
> >You shouldn't keep a small db of known plugins. The dbus plugin
> should
> >be able to give you the dependencies of any plugin so you can sort
> them
> >properly and generate proper error messages if some plugin can't 
> >possibly be loaded due to some conflicts.
> 
> I haven't being following compiz development for a while now, so i'm
> not sure whether this has been changed or not. But wouldn't reading
> the dependency options via dbus require the plugin to be activated
> first, making this method rather pointless, as you need to know the
> options before activation? Or has a semi-activated plugin state been
> implemented now? 

Sort of, you can query available plugins which is something that depends
on active plugin loaders. Hence, something that can't be done properly
outside compiz. You can query metadata for any available plugin, it
doesn't have to be activated. So yes, you can get dependencies for
non-active plugins.

> 
> Also I found many of the dependency options within the plugins to be
> incomplete. For example the cube plugin i think (I don't have access
> to a compiz install right now) requires to be loaded before switcher
> and scale. When in reality for it to work it needs to be loaded after
> gconf and dbus, before rotate and with rotate as a dependency. 

Yes, I'm sure the current dependencies are very incomplete and I'm happy
to correct them as you find problems.

> 
> >I don't see any good reason to why we would want the dependency order
> >resolved by the core. We can add an utility function and put it in
> core
> >or better in some shared library which can be used to solve
> dependencies 
> >at the plugin or application level. What do you think?
> 
> >That plugins can be stacked differently, is a feature. It might not
> be
> >incredibly useful right now but I think it will be later on so I'd
> like 
> >to keep it.
> 
> Yes a shared library would be very useful, maybe just a few functions
> thats can be accessed through compiz.h? Or maybe there could even be a
> new plugin to handle automatic activation/dependancies? (Maybe this
> plugin could also be used to determine which settings backend to use,
> now there is an ini settings plugin, but that is a seperate issue..)

We could add options to the gconf and ini plugins which will make them
resolve dependencies. However, I can imagine that some configuration
utilities prefer to do this on it's own so having this in a shared
library makes sense to me. gconf and ini plugin can still of course use
this library to resolve dependencies if we want that. Creating a
libcompiz or libcompiz-util for this would be a good idea as I'm sure we
got a lot of other utility functions that could go in there too.

- David