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. 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? -- Thank you Ben Reeves -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.freedesktop.org/archives/compiz/attachments/20070222/86a70d09/attachment.html
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
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