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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
_______________________________________________
compiz mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/compiz
