[compiz] meta data update

[Dennis Kasprzyk]

Am Freitag, 11. Mai 2007 17:09 schrieb 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.
>
Currently there is one one system that provides automatic sorting of plugins 
and this is the ccs (compiz configuration system) at git.opencompositing.org 
and it is still under heavy development. But I would really happy if 
the "current" dependency checking code would be removed from the core.

> > > 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.
>
For such basic checks we should really add a screenGrabExists function to 
core.

Dennis