>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, <div>On 2/26/07, David Reveman <<a href="mailto:davidr@novell.com">davidr@novell.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 </blockquote></div> -- Thank you Ben Reeves