[compiz] meta data update

[David Reveman]

On Fri, 2007-05-11 at 18:50 +0200, Dennis Kasprzyk wrote:
> 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.

Whether one, zero or a bunch of systems currently support sorting
doesn't matter.

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

I was talking about bailing out at initialization time. Refuse to load
if some other plugin is already loaded.

- David