The dependency checking currently provided is clearly not good enough.
There's currently two issues with the plugins that exist in the compiz
repository.
plane plugin conflicts with cube and rotate plugin, zoom plugin should
probably work with either cube or plane but currently only loads when
cube plugin is used.
Adding a
{ CompPluginRuleBefore, "cube" }
to the plane plugin and a
{ CompPluginRuleBefore, "plane" }
to the cube plugin will solve the conflict but it's not perfect as it
means that all plugins sort of needs to be aware of all other plugins.
Having the zoom plugin load if either the cube plugin or the plane
plugin is loaded is currently not possible.
I'm suggesting that we add some way to register and depend on features.
E.g. the cube and plane plugins would both register a "largedesktop"
feature. zoom plugin could depend on the "largedesktop" feature
instead
of the cube plugin and it wouldn't be possible to load two plugins that
provide the same feature.
Adding a feature list to the plugin vTable and a
CompPluginRuleNeedFeature rule that can be used to depend on specific
features should do it.
-David
Hello, We already done something similar in beryl to fix these conflicting plugins issues. What we did was to introduce two new rules, CompPluginRuleConflicts and CompPluginRuleAfterAlt. The first one prevents two incompatible plugin from being loaded at once, and the later one allows a plugin to require only one plugin in a list of alternatives. Anyway, I really like your Feature idea, it's probably the best way to handle such problems, and it'd be much more flexible than my silly alternatives rule (since with Features one plugin may need several Features). About the implementation, I just wonder if it'd be better to extend the current Dependencies system with two new rules (CompPluginRuleProvideFeature and CompPluginRuleNeedFeature) or extend the plugin API as you suggested. Both approachs sound acceptable. If you're ok with that, I'll write a first draft tomorrow. Regards, Guillaume Seguin 2006/10/7, David Reveman <davidr@novell.com>:> The dependency checking currently provided is clearly not good enough. > There's currently two issues with the plugins that exist in the compiz > repository. > > plane plugin conflicts with cube and rotate plugin, zoom plugin should > probably work with either cube or plane but currently only loads when > cube plugin is used. > > Adding a > { CompPluginRuleBefore, "cube" } > to the plane plugin and a > { CompPluginRuleBefore, "plane" } > to the cube plugin will solve the conflict but it's not perfect as it > means that all plugins sort of needs to be aware of all other plugins. > > Having the zoom plugin load if either the cube plugin or the plane > plugin is loaded is currently not possible. > > I'm suggesting that we add some way to register and depend on features. > E.g. the cube and plane plugins would both register a "largedesktop" > feature. zoom plugin could depend on the "largedesktop" feature instead > of the cube plugin and it wouldn't be possible to load two plugins that > provide the same feature. > > Adding a feature list to the plugin vTable and a > CompPluginRuleNeedFeature rule that can be used to depend on specific > features should do it. > > -David > > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz >
Hi List ! David said :> I'm suggesting that we add some way to register and depend on features. > E.g. the cube and plane plugins would both register a "largedesktop" > feature. zoom plugin could depend on the "largedesktop" feature instead > of the cube plugin and it wouldn't be possible to load two plugins that > provide the same feature.David, what you describe looks a lot like the Eclipse RCP bundle model based on OSGi specifications. A very very flexible system : First, everything is a plugin and is described - by an id - a description ans some usual informations - a list of required previoulsy loaded plugins And now the meal :) - a list of extension points defining how other plugins can contribute to it being by code, ressources, strings etc... (ex : ext point org.freedesktop.compiz.largedesktop must be a desktop handling plugin and is unique) - a list of contributions (called Extensions) to other plugins ( ex : contribute to org.freedesktop.compiz.largedesktop with a class named Cube implementing an accordingly interface ILargeDesktop) Sadly, most if not all OSGi plugins systems are build around Java, but I think it can be a great inspiration for any plugin system like the compiz' one. (OT : A C or C++ implementation would be a nice fullfeatured freedesktop.org project !) Happy coding ! -- Alexandre Mazari Eleve Ing?nieur 5eme Ann?e Epitech Responsable Technique poly/son (poly-son.pfe.epitech.net)