[compiz] meta data update

[Dennis Kasprzyk]

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.

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

Dennis