It seems to me that the plugin dependencies are not flexible enough for most plugins. The particular problem I am thinking about is animation/group and fade. They both specify RuleAfter but compiz interprets that as 'load after AND require it', there is a Require rule, but this relates to features not plugins. I would like to propose these changes and definitions, they seem more logical unless I am missing something. CompPluginRuleBefore - If this plugin is loaded, make sure I am loaded before it. CompPluginRuleAfter - If this plugin is loaded, make sure I am loaded after CompPluginRuleRequire - Require this plugin to be loaded if I am loaded. This can be combined with other rules. This is roughly what RuleAfter is now. CompPluginRuleRequireFeature - Requires a feature to be loaded. What do you think? RuleBefore might be tricky to implement because it is checked retrospectively. It would probably take 2 passes for each check, but maybe we could find a better way.
Am Mittwoch, 11. April 2007 19:45 schrieb Mike Dransfield:> It seems to me that the plugin dependencies are not flexible > enough for most plugins. > > The particular problem I am thinking about is animation/group > and fade. They both specify RuleAfter but compiz interprets > that as 'load after AND require it', there is a Require rule, but > this relates to features not plugins. > > I would like to propose these changes and definitions, they seem > more logical unless I am missing something. > > CompPluginRuleBefore - If this plugin is loaded, make sure I am > loaded before it. > > CompPluginRuleAfter - If this plugin is loaded, make sure I am > loaded after > > CompPluginRuleRequire - Require this plugin to be loaded if I > am loaded. This can be combined with other rules. This is roughly > what RuleAfter is now. > > CompPluginRuleRequireFeature - Requires a feature to be > loaded. > > What do you think? RuleBefore might be tricky to implement > because it is checked retrospectively. It would probably take > 2 passes for each check, but maybe we could find a better way. > > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compizI have already discussed this problem with David, and we came to that conclusion to remove the rule checking code from compiz during the switch to xml metadata and let the configuration tools check the rules. The rules will be a part of the xml metadata file. Dennis
without implying knowledge of the mechanism in use, it seems to me that the plugn before/after dependency list can be derived from the 'features' rules, thus should be removed. it's better to only look at the features rather than plugins and leave it to the core to derive the plugin dependencies from that. Having a feature-rule and a plugin-rule means you can express something that conflicts (the feature-rule says something and the plugin-rule says the opposite) , which implies your representation has some redundancy, which should be avoided (a general rule of thumb). Mike Dransfield wrote:> It seems to me that the plugin dependencies are not flexible > enough for most plugins. > > The particular problem I am thinking about is animation/group > and fade. They both specify RuleAfter but compiz interprets > that as 'load after AND require it', there is a Require rule, but > this relates to features not plugins. > > I would like to propose these changes and definitions, they seem > more logical unless I am missing something. > > CompPluginRuleBefore - If this plugin is loaded, make sure I am > loaded before it. > > CompPluginRuleAfter - If this plugin is loaded, make sure I am > loaded after > > CompPluginRuleRequire - Require this plugin to be loaded if I > am loaded. This can be combined with other rules. This is roughly > what RuleAfter is now. > > CompPluginRuleRequireFeature - Requires a feature to be > loaded. > > What do you think? RuleBefore might be tricky to implement > because it is checked retrospectively. It would probably take > 2 passes for each check, but maybe we could find a better way. > > _______________________________________________ > compiz mailing list > compiz@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz >