[compiz] Couldn't activate plugin 'rotate'

[David Reveman]

On Thu, 2007-08-02 at 17:04 +0200, Dennis Kasprzyk wrote:
> 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.

It seems over-engineered to me. The simple stack based plugin system
that we have today seems sufficient. I did some experimenting with a
non-stack based plugins system when I first started writing compiz and
that stacked based solution proved much easier to maintain, especially
as long as we allow wrapping of function pointers. Wrapping of function
pointers and a non-stack based plugins system doesn't go well.

> 
> 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);

Yes, this should definitely be done. I'd also like to move the core ABI
version into an option and have the plugins check this in much the same
way they check plugin versions.

> 
> 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. 

That image loading plugins need to be loaded before plugins that use
them is not a problem to me. I think that's a good design.

-David