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.
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. 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.
- David
David Reveman wrote:>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 attached patch should save you the trouble. I cannot commit it at the moment.>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: > >I suppose we will need to work out an xslt for the ini plugin, but I am not in any hurry at the moment. I assume everything will continue to work because the default values are loaded from the metadata, so maybe this would not be needed at all?>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. > >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. 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. > >Agreed>- David > >_______________________________________________ >compiz mailing list >compiz@lists.freedesktop.org >http://lists.freedesktop.org/mailman/listinfo/compiz > >-------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Update-ini-to-use-metadata.patch Type: text/x-patch Size: 2067 bytes Desc: not available Url : http://lists.freedesktop.org/archives/compiz/attachments/20070508/19a5141f/0001-Update-ini-to-use-metadata.bin
On Tue, 2007-05-08 at 00:48 +0100, Mike Dransfield wrote:> David Reveman wrote: > > >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 attached patch should save you the trouble. I cannot > commit it at the moment.Thanks. I've now also updated the plane plugin.> > >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: > > > > > > I suppose we will need to work out an xslt for the ini plugin, > but I am not in any hurry at the moment. I assume everything > will continue to work because the default values are loaded > from the metadata, so maybe this would not be needed at all?Not unless you like to store some default values in a system wide directory. I would avoid that if possible. You can read the default values for options at run-time from the meta data objects provided by each plugin. I remember that you were interested in this earlier. - David
Hi,> 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.Sounds good. What I am missing in your suggestion, however, is the definition of load order hints. Following your suggestion for requirements & conflicts, I would suggest the following: <compiz> <plugin name="someplugin"> <loadorder> <before>someotherplugin1</before> <after>someotherplugin2</after> </loadorder> </plugin> </compiz>> 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. 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.Sounds fine to me. Regards, Danny
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
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.> > > 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. - David
Dennis Kasprzyk wrote:> Am Freitag, 11. Mai 2007 18:36 schrieben Sie: > >> >> 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. >> >> > The point is here that some plugins extend or rely on functionality provided > by other plugins. And we should provide here a consistent system. > otherScreenGrabExists provides a functionality do do things like "I can only > do my job if no other plugin that I don't know has a screen grab". We miss > here the screenGrabExists function that would provide something like "I can > only do my job it one of the plugins I know is active". >Do you have any specific examples where this is the case and bad things happen if the other plugin is not loaded? Bad things would be crashing or total loss of functionality (ie. total distortion of the screen)>> 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. >> >> > I agree here but we should provide systems that makes it easy to for > developers to handle unusual plugin configurations. >You should be able to write a function like this Bool otherPluginLoadedBeforeMe (...) { return TRUE; } and everything should still work, if it does not then it is probably a limitation in core that needs to be fixed. Once the dependency code is removed it will be possible to load rotate without or before cube so it will be interesting to see what happens. Nothing should happen, even if the user tries to rotate without cube loaded.>>> Dennis >>> >>> _______________________________________________ >>> compiz mailing list >>> compiz at lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/compiz >>> > >