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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz