[compiz] meta data update

[David Reveman]

On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote:
> Am Montag, 7. Mai 2007 18:22 schrieb David Reveman:
> > The switch to the new metadata system is almost complete. All plugins in
> > the fdo repo except plane and ini have been converted. I'll probably go
> > ahead and convert those plugins as well sometime soon unless the
> > original authors of those plugins tells me not to.
> >
> > The horrible gconf-dump plugin has been removed and replaced by a simple
> > xslt stylesheet. gconf schemas are now generated from the xml meta data
> > files as part of the build process and the stylesheet and a compiz-gconf
> > pkg-config file is installed so a command similar to this:
> >
> > xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir
> > compiz-gconf`/schemas.xslt plugin.xml
> >
> > can be used to generate a schema file for a plugin outside the fdo
> > repository.
> >
> > Plugin dependencies have not yet been moved to the meta data system. I'd
> > like some feedback before we do this. I suggest that we use tags similar
> > to this:
> >
> > <compiz>
> >     <plugin name="cube">
> >         <feature>large-desktop</feature>
> >         <deps>
> >             <requirement>
> >                 <plugin>png</plugin>
> >                 <feature>some-feature</feature>
> >                 <some_property>name-of-required-property</some_property>
> >             </requirement>
> >             <conflict>
> >                 <plugin>plane</plugin>
> >                 <feature>some-other-feature</feature>
> >             </conflict>
> >         </deps>
> >     </plugin>
> > <compiz>
> >
> > It will make it easy to add new meta data tags that can be used as
> > requirements or conflicts.
> >
> I like the idea but we should really define <before> and <after> tags. 
> 
> > The other thing that needs to be discussed related to this is whether
> > the core should be aware of any of these dependencies. I think that not
> > having the core be aware of any dependencies is definitely the best
> > solution. 
> I would also like this, but I see here problems with users that don't use a 
> config tool and create a wrong active plugin list directly in gconf/ini and 
> report bugs because there are problems with some plugins.

If there's actually bugs, then those should be fixed and not avoided
through dependencies. If it's not working the way they want it to
because they're miss-configuring it that's not our problem. They should
use a configuration tool if they can't configure it manually.

> 
> > It's up to the plugins to deal with conflicts. Whether that is 
> > to fail when loading or lack functionality doesn't matter but they will
> > of course not be allowed to crash.
> If each plugin will have it's own conflict checking code, it will end that 
> each plugin will have nearly the same conflict checking system, and we will 
> have to move it to core.

Most plugins are not going to need any conflict checking at all. Some
might need a simple check to see if some other plugin is loaded and bail
out if that's the case. I believe that a good plugin shouldn't need any
checking at all, it should work in well-defined way no matter what other
plugins are loaded. It's important that the core is designed in a way
that allow this.

I'm convinced that not having the core provide support for any
dependency checking is good in the long run. It will give us better
plugins and make sure that the hooks provided by the core are properly
designed.

- David