[compiz] Couldn't activate plugin 'rotate'

[Dennis Kasprzyk]

Am Dienstag, 31. Juli 2007 19:45:19 schrieb 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

Maybe we could try to make the plugin plugins system independent of the plugin 
loading order. My idea is to provide two additional wrapable functions 
pluginLoaded( CompPlugin *p, CompDisplay *d) and preparePluginUnload( 
CompPlugin *p, CompDisplay *d). pluginLoaded would be called if a plugin has 
been fully initialized (display/screens/windows) and preparePluginUnload 
before compiz calls the fini(window|screen|display) functions of a plugin. 

With such a system a plugin plugin could be loaded before it's main plugin 
gets loaded and the initialization of the "plugin connections" would be done 
in the pluginLoaded/preparePluginUnload functions. This would also increase 
the flexibility for plugins that offer some functionality but if another 
plugin gets loaded it hooks into it and provides more features.

Maybe we should also provide a convenience function to hook into other 
plugins. I'm thinking about something like Bool getPluginPrivateIndex( 
CompDisplay *, char * name, int abi_version, int * privateIndex);

Another function we could add is pluginListChaged. It would be called by 
compiz after all plugins of the plugin list has been initialized. This 
function could be used in plugins that use the image loading system for 
example. This would remove the dependency to load image plugins before the 
plugins that use them, because most of this plugins load their images during 
initialisation. 

Dennis