[compiz] meta data update

[David Reveman]

On Fri, 2007-05-11 at 17:36 +0100, Mike Dransfield wrote: 
> 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.
> >
> >   
> 
> This is not strictly true.
> 
> My web based settings tool does automatic plugin ordering based
> on the data provided by dbus.
> 
> I think RYX also has a python library which does this.
> 
> >>>> 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 think the point is that plugins should not be aware of other
> plugins at all and should not do anything bad if those plugins
> are not loaded.
> 
> They should be written in such a way that it does not matter if
> the dependencies are not loaded, they will just lack some
> functionality.  ie.  It should be possible to load rotate without
> cube and it would not behave badly, the same for loading rotate
> before cube.

Eventually, I'd like to see no conditionals or code at all that depend
on the existence of other plugins.

Cube/rotate is always a bad example. That separation started out as a
test and it's a shame that it still works like that. The rotate
functionality should be part of the cube plugin. If we want to be able
to separate that kind of functionality into different plugins, it should
be done through "plugin plugins" and not in the horrible way that
cube/rotate currently works. I'll start another thread on "plugin
plugins", which is basically an idea I have that will allow us to use
the existing plugin loading system to provide a very convenient way for
plugins to have sub-plugins.

- David