[compiz] Couldn't activate plugin 'rotate'

[David Reveman]

On Tue, 2007-07-31 at 00:19 +0200, Dennis Kasprzyk wrote:
> Am Montag, 30. Juli 2007 16:28:27 schrieben Sie:
> > On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote:
> > > Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie:
> > > > On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote:
> > > > > Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj:
> > > > > > First, I would like to compliment you all for a great work you put
> > > > > > in developing compiz. I have it running for more that a month and
> > > > > > it did not crash. Stability is very good. Great work!
> > > > > >
> > > > > > Today I updated compiz from git tree and found that rotate
> > > > > > generates this error:
> > > > > >
> > > > > > compiz (core) - Error: Couldn't activate plugin 'rotate'
> > > > >
> > > > > The problem is that the "load after cube" got removed from the rotate
> > > > > metadata. I reverted it now.
> > > > > The ccs configuration system doesn't handle "require" rules
> > > > > automatically as "load after" rules. There is also a case where we
> > > > > have a "require" and a "load before" rule for the same plugin (3d).
> > > >
> > > > I don't think it should be allowed to ask for some plugin to be
> > > > required but loaded after. Plugins that do this should be fixed so they
> > > > don't have to ask for such a relationship and the "load after cube"
> > > > information in the rotate metadata should be removed again.
> > > >
> > > > -David
> > >
> > > We removed the whole plugin order system from core to make it more
> > > flexible. That's the reason why we shouldn't mix now requirements with
> > > relations and limit the functionality. But if you want I can remove the
> > > "load after cube" information in the rotate metadata and add this to the
> > > internal configuration system metadata file.
> >
> > We're not limiting functionality by having requirements also implicitly
> > mean that the plugin must be loaded after. We're just making the
> > existing tags make more sense. If you like some metadata information
> > that indicate that a plugin must be loaded after, then you can always
> > add that through a new tag.
> >
> > The reason I like to have the requirement tag also implicitly mean "load
> > after" is that a plugin that requires another plugin to be loaded after
> > seems to be designed poorly and I think we should do our best not to
> > encourage that. However, you're welcome to prove me wrong and show that
> > requiring that another plugin is loaded after necessarily isn't bad
> > design, in which case I'm happy to allow the requirement tag not to
> > implicitly mean "load after".
> >
> > -David
> 
> The problem is here that we have a plugin (3d) that has to be loaded before 
> cube but also requires cube. It needs to be loaded before cube because it's 
> paintTransformedOutput needs to be called for each cube face, but it also 
> needs some variables from cube to work correctly. To get into cube it uses 
> then init/finiPluginForDisplay. 
> 
> So we have a plugin that requires another plugin but needs to be loaded before 
> that plugin. That is the reason why I don't like requirement tag also 
> implicitly mean "load after".

cube plugin should provide hooks that allow 3d to be loaded after cube
and hook in where appropriate and not use paintTransformedOutput.

-David