Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
On Tue, 2007-05-08 at 07:28 +0200, Danny Baumann wrote: 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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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 beforesomeotherplugin1/before aftersomeotherplugin2/after /loadorder /plugin /compiz Sure but I would prefer something like this: compiz plugin deps relation type=before pluginsomeplugin/plugin /relation /deps /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. Good, it's seems like everyone is OK with this so I think we can start updating plugins. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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
Re: [compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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
[compiz] meta data update
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 featurelarge-desktop/feature deps requirement pluginpng/plugin featuresome-feature/feature some_propertyname-of-required-property/some_property /requirement conflict pluginplane/plugin featuresome-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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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
featurelarge-desktop/feature
deps
requirement
pluginpng/plugin
featuresome-feature/feature
some_propertyname-of-required-property/some_property
/requirement
conflict
pluginplane/plugin
featuresome-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
From 007ae679212cd349da8aed3e79d25fae768130b1 Mon Sep 17 00:00:00 2001
From: Mike Dransfield [EMAIL PROTECTED]
Date: Tue, 8 May 2007 00:41:42 +0100
Subject: [PATCH] Update ini to use metadata
---
metadata/Makefile.am |1 +
metadata/ini.xml.in |6 ++
plugins/ini.c| 19 ++-
3 files changed, 25 insertions(+), 1 deletions(-)
create mode 100644 metadata/ini.xml.in
diff --git a/metadata/Makefile.am b/metadata/Makefile.am
index 6b99330..d52a73e 100644
--- a/metadata/Makefile.am
+++ b/metadata/Makefile.am
@@ -10,6 +10,7 @@ xml_in_files = \
fade.xml.in \
fs.xml.in \
gconf.xml.in \
+ ini.xml.in \
inotify.xml.in \
minimize.xml.in \
move.xml.in \
diff --git a/metadata/ini.xml.in b/metadata/ini.xml.in
new file mode 100644
index 000..3c3b32b
--- /dev/null
+++ b/metadata/ini.xml.in
@@ -0,0 +1,6 @@
+compiz
+plugin name=ini
+ _shortIni/_short
+ _longIni Flat File Backend/_long
+/plugin
+/compiz
diff --git a/plugins/ini.c b/plugins/ini.c
index f2d7dc4..1c5faac 100644
--- a/plugins/ini.c
+++ b/plugins/ini.c
@@ -53,6 +53,8 @@
static int displayPrivateIndex;
+static CompMetadata iniMetadata;
+
/*
* IniFileData
*/
@@ -1428,9 +1430,18 @@ iniFiniScreen (CompPlugin *p, CompScreen *s)
static Bool
iniInit (CompPlugin *p)
{
+if (!compInitPluginMetadataFromInfo (iniMetadata, p-vTable-name,
+ 0, 0, 0, 0))
+ return FALSE;
+
displayPrivateIndex = allocateDisplayPrivateIndex ();
if (displayPrivateIndex 0)
+{
+ compFiniMetadata (iniMetadata);
return FALSE;
+}
+
+compAddMetadataFromFile (iniMetadata, p-vTable-name);
return TRUE;
}
@@ -1448,10 +1459,16 @@ iniGetVersion (CompPlugin *plugin, int version)
return ABIVERSION;
}
+static CompMetadata *
+iniGetMetadata (CompPlugin *plugin)
+{
+return iniMetadata;
+}
+
CompPluginVTable iniVTable = {
ini,
iniGetVersion,
-0, /* GetMetadata */
+iniGetMetadata,
iniInit,
iniFini,
iniInitDisplay,
--
1.5.0.7
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
