Re: [compiz] re-work option initialization
On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman: Dennis Kasprzyk and I have been discussing some changes to how options are initialized. Problems with how options are currently initialized. 1. Helper functions are not used to initialize options, which means that if we make a change to the option structure, all option initialization code needs to be updated. Using helper functions will also reduces the amount of duplicate code. 2. No convenient way to get the initial value of an option once it's been modified. 3. An option can't be initialized without compiz running. 2 and 3 are of interest to configuration backends that like to be able to do offline readout of option information and some kind of standard default value. 3, might be hard to provide for all kind of plugins as some might rely on a unique plugin loader to be present so I'm not sure that I want to recommend a configuration backend to do this. However, it's easy to provide for plugins built as shared libraries and I don't want to prevent anyone from doing this if they wish to. Here's our current idea for how we can solve these issues: Add typedef Bool (*InitPlugin(Display|Screen)OptionProc) (CompOption *o, intindex); or typedef Bool (*InitPlugin(Display|Screen)OptionsProc) (CompOption **o); and the number of display and screen options to the plugin vTable. I prefer the function prototype with the index as it's a bit more flexible. We can add a set of option initialization macros to compiz.h or helper functions to a library, which will make the initPluginOption function in each plugin minimal. Action options will be changed to contain a string or KeySym instead of the current key-code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Currently there are two types of configuration tools. Some with fixed functionality and some autogenerated. To improve the quality of the autogenerated tools I would like to make this proposal about additional values in the CompOption struct and the plugin vtable. Additions to the CompOption struct: char * group/char * subgroup : Ability to group sets of options and to give this sets a name. char *hints : A semicolon separated list of string that inform the configuration tool to handle this option in a special way. A string value could have a hint image or file to inform the configuration tool to open a file dialog when the user wants to set this option. We all could workout here a set of hints, that all configuration tools would understand. Additions to the plugin vTable: char* category: A plugin can define to belong to a category like effects or accessibility, so that a configuration tool can group plugins together. We could workout possible categories later here. All this values would be optional and could be exposed over the dbus plugin or any other configuration system. I've read the whole thread. To summarize, there's a desire to assign much more meta-data than the current short/long descriptions to plugins, which to me seems like a very valid request. Question is how we allow this in the best possible way. Mike made a good point about the plugin writer not always being the best person to be responsible for providing all meta-data. However, I think it will be the best solution in most cases and it's always going to be easy to have a table of meta-data in the configuration tool that will override the plugin provided data so I'm not very concerned about this. Adding new fields to the plugin vTable every time someone comes up with some new useful meta-data seems very inconvenient. The most obvious way to provide this meta-data is to have an xml file paired with each plugin. That way new tags can easily be added as desired. I think that this is what we want in most cases but I'm still very interested in allowing plugins to be fully functional without any external file references. Imagine compiz running on a machine without a writable file-system and loading plugins remotely or plugins that dynamically create other plugins... My suggestion is that we remove the two description fields from the vTable and add a char *metadata field that contains meta information as xml data. A helper function that reads meta data for an option from an xml file could easily be provided for those plugins that like to keep this in an external xml file. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fade vs. Animation conflict resolution
Hello, according to the fade description in compiz.schemas, this plugin is supposed to fade windows _only_ when being mapped/unmapped, isn't it? Actually, its other effects are quite annoying for me in combination with bs or widget plugins, fade is making them act much slowly than they were designed to. (On the other hand, I find very useful the fading when a window becomes irresponsive, which is holding me from switching from fade to animation.) Unfortunately, in the current fade architecture, solving this seems nearly impossible, or does anybody have any ideas? Vasek Hi, Here is a simple patch that adds an option to the Fade plugin to enable/disable fading on minimize/open/close window events. This option is on by default but can be disabled to avoid conflicts with the Animation plugin. Fading on other stuff (fade during nonresponding app. desaturation, during switcher, and visual bell) shouldn't be affected (which is the main point of this patch). Regards, Erkin ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] re-work option initialization
Am Samstag, 31. März 2007 10:12 schrieb David Reveman: On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman: Dennis Kasprzyk and I have been discussing some changes to how options are initialized. Problems with how options are currently initialized. 1. Helper functions are not used to initialize options, which means that if we make a change to the option structure, all option initialization code needs to be updated. Using helper functions will also reduces the amount of duplicate code. 2. No convenient way to get the initial value of an option once it's been modified. 3. An option can't be initialized without compiz running. 2 and 3 are of interest to configuration backends that like to be able to do offline readout of option information and some kind of standard default value. 3, might be hard to provide for all kind of plugins as some might rely on a unique plugin loader to be present so I'm not sure that I want to recommend a configuration backend to do this. However, it's easy to provide for plugins built as shared libraries and I don't want to prevent anyone from doing this if they wish to. Here's our current idea for how we can solve these issues: Add typedef Bool (*InitPlugin(Display|Screen)OptionProc) (CompOption *o, int index); or typedef Bool (*InitPlugin(Display|Screen)OptionsProc) (CompOption **o); and the number of display and screen options to the plugin vTable. I prefer the function prototype with the index as it's a bit more flexible. We can add a set of option initialization macros to compiz.h or helper functions to a library, which will make the initPluginOption function in each plugin minimal. Action options will be changed to contain a string or KeySym instead of the current key-code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Currently there are two types of configuration tools. Some with fixed functionality and some autogenerated. To improve the quality of the autogenerated tools I would like to make this proposal about additional values in the CompOption struct and the plugin vtable. Additions to the CompOption struct: char * group/char * subgroup : Ability to group sets of options and to give this sets a name. char *hints : A semicolon separated list of string that inform the configuration tool to handle this option in a special way. A string value could have a hint image or file to inform the configuration tool to open a file dialog when the user wants to set this option. We all could workout here a set of hints, that all configuration tools would understand. Additions to the plugin vTable: char* category: A plugin can define to belong to a category like effects or accessibility, so that a configuration tool can group plugins together. We could workout possible categories later here. All this values would be optional and could be exposed over the dbus plugin or any other configuration system. I've read the whole thread. To summarize, there's a desire to assign much more meta-data than the current short/long descriptions to plugins, which to me seems like a very valid request. Question is how we allow this in the best possible way. Mike made a good point about the plugin writer not always being the best person to be responsible for providing all meta-data. However, I think it will be the best solution in most cases and it's always going to be easy to have a table of meta-data in the configuration tool that will override the plugin provided data so I'm not very concerned about this. Adding new fields to the plugin vTable every time someone comes up with some new useful meta-data seems very inconvenient. The most obvious way to provide this meta-data is to have an xml file paired with each plugin. That way new tags can easily be added as desired. I think that this is what we want in most cases but I'm still very interested in allowing plugins to be fully functional without any external file references. Imagine compiz running on a machine without a writable file-system and loading plugins remotely or plugins that dynamically create other plugins... My suggestion is that we remove the two description fields from the vTable and add a char *metadata field that contains meta information as xml data. A helper function that reads meta data for an option from an xml file could easily be provided for those plugins that like to keep this in an external xml file. - David Great idea. Should we do the same for the options? Dennis ___ compiz mailing list
