[compiz] Couldn't activate plugin 'rotate'

David Reveman
Tue, 31 Jul 2007 17:45:19 -0000

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