[compiz] re-work option initialization

[Dennis Kasprzyk]

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

Dennis