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