Re: [compiz] removing string restrictions
With an easy metadata setup, this sounds like a very good idea in my opinion. Restricted string options are a pain especially for i18n, as obviously the restricted values are in C/en_US but we need to display to the end user the proper i18n'd value, which would be far easier in this method, as the value in this method is the int and the text is merely pretty-printing. (it seriously cleans up the API to any relevant settings library such as libccs) On Thursday 10 May 2007 15:24:02 David Reveman wrote: We've previously discussed if we should add some sort of selection option type and not use string options and string restrictions for that purpose. I don't think we need a new option type for this. The integer type should do just fine. The attached patch changes the blur plugin's filter option from string to integer type and adds the relevant metadata. I suggest that we change all existing options that use string restrictions in a similar way and remove the string restrictions completely. Questions? Does it sounds OK? - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
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] removing string restrictions
Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: We've previously discussed if we should add some sort of selection option type and not use string options and string restrictions for that purpose. I don't think we need a new option type for this. The integer type should do just fine. The attached patch changes the blur plugin's filter option from string to integer type and adds the relevant metadata. I suggest that we change all existing options that use string restrictions in a similar way and remove the string restrictions completely. Questions? Does it sounds OK? - David I like the idea, but I would prefer a different XML style. desc _name value=1Foo/_name _name value=2Foo2/_name _name value=3Foo3/_name /desc Would be much shorter but I'm not sure that this would work with the translation system. 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
[compiz] WARNING ONLY A PROOF OF CONCEPT: copy texturing to fix maximum texture size restrictions
Hi,
this mail contains a core patch that enables wrapping of texture functions and
a plugin that uses this functions to realize the so called copy mode. The
pure copy code is quite simple and mostly clean. The most hacky part is
the code that fixes the maximum texture size limitations of some graphic
cards. But maybe we can use this as a basis to create a proper interface to
this problem. The pure copy part of the plugin can also be used to provide a
system that replaces the texture from pixmap extension for some buggy graphic
card drivers.
DO NOT USE THIS FOR PRODUCTIVE WORK !
Dennis
diff --git a/include/compiz.h b/include/compiz.h
index 5e52c8c..dd4f2df 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -26,7 +26,7 @@
#ifndef _COMPIZ_H
#define _COMPIZ_H
-#define ABIVERSION 20070506
+#define ABIVERSION 20070510
#include stdio.h
#include sys/time.h
@@ -1250,11 +1250,12 @@ typedef Bool (*DrawWindowProc) (CompWind
Region region,
unsigned int mask);
-typedef void (*AddWindowGeometryProc) (CompWindow *window,
- CompMatrix *matrix,
- int nMatrix,
- Region region,
- Region clip);
+typedef void (*AddWindowGeometryProc) (CompWindow *window,
+ CompMatrix *matrix,
+ int nMatrix,
+ CompTexture *texture,
+ Region region,
+ Region clip);
typedef void (*DrawWindowTextureProc) (CompWindow *w,
CompTexture *texture,
@@ -1325,11 +1326,12 @@ moreWindowIndices (CompWindow *w,
intnewSize);
void
-addWindowGeometry (CompWindow *w,
- CompMatrix *matrix,
- int nMatrix,
- Region region,
- Region clip);
+addWindowGeometry (CompWindow *w,
+ CompMatrix *matrix,
+ int nMatrix,
+ CompTexture *texture,
+ Region region,
+ Region clip);
void
drawWindowTexture (CompWindow *w,
@@ -1373,31 +1375,32 @@ typedef enum {
} CompTextureFilter;
struct _CompTexture {
-GLuint name;
-GLenum target;
-GLfloatdx, dy;
-GLXPixmap pixmap;
-GLenum filter;
-GLenum wrap;
-CompMatrix matrix;
-Bool oldMipmaps;
-Bool mipmap;
-intrefCount;
+GLuint name;
+GLenum target;
+GLfloat dx, dy;
+GLXPixmap pixmap;
+GLenum filter;
+GLenum wrap;
+CompMatrix matrix;
+BoololdMipmaps;
+Boolmipmap;
+int refCount;
+ CompPrivate *private;
};
void
-initTexture (CompScreen *screen,
+compInitTexture (CompScreen *screen,
CompTexture *texture);
void
-finiTexture (CompScreen *screen,
+compFiniTexture (CompScreen *screen,
CompTexture *texture);
CompTexture *
-createTexture (CompScreen *screen);
+compCreateTexture (CompScreen *screen);
void
-destroyTexture (CompScreen *screen,
+compDestroyTexture (CompScreen *screen,
CompTexture *texture);
Bool
@@ -1429,7 +1432,7 @@ iconToTexture (CompScreen *screen,
CompIcon *icon);
Bool
-bindPixmapToTexture (CompScreen *screen,
+compBindPixmapToTexture (CompScreen *screen,
CompTexture *texture,
Pixmap pixmap,
int width,
@@ -1437,11 +1440,11 @@ bindPixmapToTexture (CompScreen *screen
int depth);
void
-releasePixmapFromTexture (CompScreen *screen,
+compReleasePixmapFromTexture (CompScreen *screen,
CompTexture *texture);
void
-enableTexture (CompScreen*screen,
+compEnableTexture (CompScreen*screen,
CompTexture *texture,
CompTextureFilter filter);
@@ -1456,7 +1459,36 @@ enableTextureClampToEdge (CompScreen
CompTextureFilter filter);
void
-disableTexture (CompScreen *screen,
+compDisableTexture (CompScreen *screen,
+ CompTexture *texture);
+
+
+typedef void (*InitTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef void (*FiniTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef CompTexture * (*CreateTextureProc) (CompScreen *screen);
+
+typedef void (*DestroyTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef Bool (*BindPixmapToTextureProc) (CompScreen *screen,
+ CompTexture *texture,
+ Pixmap pixmap,
+ int width,
+ int height,
+ int depth);
+
+typedef void (*ReleasePixmapFromTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef void (*EnableTextureProc) (CompScreen*screen,
+ CompTexture *texture,
+ CompTextureFilter filter);
+
+typedef void (*DisableTextureProc) (CompScreen *screen,
CompTexture *texture);
@@ -1966,6 +1998,16 @@ struct _CompScreen {
OutputChangeNotifyProc outputChangeNotify;
+
+InitTextureProc initTexture;
+FiniTextureProc finiTexture;
+CreateTextureProccreateTexture;
+DestroyTextureProc destroyTexture;
+BindPixmapToTextureProc
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] removing string restrictions
Am Freitag, 11. Mai 2007 17:15 schrieb David Reveman: On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: We've previously discussed if we should add some sort of selection option type and not use string options and string restrictions for that purpose. I don't think we need a new option type for this. The integer type should do just fine. The attached patch changes the blur plugin's filter option from string to integer type and adds the relevant metadata. I suggest that we change all existing options that use string restrictions in a similar way and remove the string restrictions completely. Questions? Does it sounds OK? - David I like the idea, but I would prefer a different XML style. desc _name value=1Foo/_name _name value=2Foo2/_name _name value=3Foo3/_name /desc I wanted the desc tag to look the same for every option type and not all option type values can be represented as strings. e.g. actions. All option values in the meta data are currently within tags, hence it makes sense to keep these values within tags as well. - David Maybe you should provide some kind of final layout description (also for the dependency rules), so that we can start to implement it. Getting everything together from different mails is painfull. 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
Re: [compiz] xsltproc, schemas.xslt
On 5/11/07, David Reveman [EMAIL PROTECTED] wrote: On Fri, 2007-05-11 at 15:31 +0200, Travis Watkins wrote: It seems like a build dependency on xsltproc was added but not checked for in the build system. I have a patch (attached) to fix this. I though the check for libxml-2.0 would guarantee that xsltproc exists. In ubuntu we have a separate xsltproc package. Also, the schemas.xslt file does not seem to be copied into the build dir so the build fails. I have not been able to figure this one out yet. I think this should be fixed now. Indeed, the schemas.xslt file seems to be installed correctly now. Unfortunately mkinstalldirs seems to get overwritten as a broken symlink to config/mkinstalldirs now. Will try to figure it out but I'm not even sure where to start. - David -- Travis Watkins http://www.realistanew.com ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
