[compiz] re-work option initialization

[Dennis Kasprzyk]

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

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