Am Sonntag, 1. April 2007 18:30 schrieb David Reveman: > On Sun, 2007-04-01 at 01:39 +0200, Dennis Kasprzyk wrote: > > Am Samstag, 31. März 2007 10:12 schrieben Sie: > > > 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? > > Yes, feel free to start working on some patches for this if you like. I > wont have time to do it in the next couple of days. > > - David
Ok. I will start now. I will do it at the beryl git server (the compiz directory is currently not available for anonymous download yet / gitweb.beryl-project.org is available). Dennis _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz