[compiz] Plugin Dependencies

[Ben Reeves]

>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?

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.

>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..)

Thanks
Ben,

On 2/26/07, David Reveman <davidr at novell.com> wrote:
>
> On Thu, 2007-02-22 at 15:46 +0000, Ben Reeves wrote:
> > I'm continuing to work on compiz-settings now. The most common
> > complaintat the moment is the way it activates plugins, a lot will
> > fail to activate due to being loaded in the wrong order. At the moment
> > It has a small db of known plugins and has load_before and load_after
> > for each one, however if a plugin is unknown it will be loaded last
> > and will fail to activate.
>
> 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 think it would be much better if every plugin carries it's own
> > load_before, load_after and depends_on options and the core then
> > decides in what order to activate the plugins. This would make writing
> > a settings manager much easier, make it easier to start compiz and
> > save duplicated effort so that each settings manager doesn't have to
> > do it's own form of dependency generation. To activate a plugin the
> > settings manager could simply send a dbus signal activate "cube" and
> > the core would return whether it has activate any dependencies e.g.
> > activated "rotate" and if plugin activation was successful or not.
> >
> > What do you think?
>
> 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.
>
> - David
>
>


-- 
Thank you
Ben Reeves
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/compiz/attachments/20070227/41008913/attachment.html