[compiz] re-work option initialization

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