[compiz] re-work option initialization

[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 at 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