[compiz] re-work option initialization

[Mike Dransfield]

Dennis Kasprzyk wrote:
> Am Donnerstag, 29. März 2007 18:33 schrieben Sie:
>   
>> Dennis Kasprzyk wrote:
>>     
>>> The problem is that we already have additional data in the plugins. So we
>>> should be consistent here and remove also the long/short decriptions of
>>> the option struct and or the plugin vtable and move it to an additional
>>> file or have everything in the plugin. A mixture of both is simply
>>> stupid. I can live with both because I can use bcop to generate what I
>>> want.
>>>       
>> To me, it would make more sense to pull out
>> the descriptions rather than add extra identifiers.
>>
>> This might be tricky to implement.  Maybe each config
>> backend could also be responsible for loading these
>> extra pieces of information.  That way each distro can
>> easily change defaults as well as descriptions if they
>> choose.  Dbus etc would then also have access to this
>> information.
>>
>> Then if you need extra information for your particular
>> backend you can include it in your data.
>>     
>
> Let me summarize what options do we have:
>
> 1. We keep the current system (lon/short decription in the plugin) and add 
> additional descriptions to a special file. This is stupid because all 
> descriptions should be a the same place.
>
> 2. We add everything to the plugin. This makes it easy for other plugins 
> (dbus) to get the information, but don't really makes sense because this 
> information's are not needed for the functionality of the plugin.
>
> 3. We move everything out of a plugin into a XML file and generate also the 
> options code for the plugin out of the XML file. We have BCOP that already 
> does it, but this would force everyone to use it, and there are some things 
> that cannot be done with BCOP.
>
> 4. We move everything that ins not needed for plugins functionality 
> (long/short descriptions ...) to a special file. I would prefer to do it in a 
> ini file style:
>
> [PLUGIN]
> short=foo
> long=lonf FOO
> author=
> email=
> category=
> ...
>
> [SCREEN/"option name"]
> short=
> long=
> group=
> subgroup=
> hints=
> ...
>
> To prevent that other plugins/configuration tool need to create a parser for 
> that files, we could provide a library that would be a part of the core, that 
> would read this plugin.info files. There are already plans to have the system 
> to readout of options without a running compiz in a library so we could also 
> add this to the library. With this plugins and configuration tools would have 
> an easy access to the additional plugin/options data. For 
> internationalisation we could simply create plugin.info.es_ES ... files that 
> would contain the translated values. The library would provide access to get 
> translated and original values.
>
> With this system there should be no problem to create configuration system 
> dependent files (gconf schema). 
>
> I don't think that we should store the default values in such file. The 
> default value is a part of the plugin. Each configuration system should 
> provide a system for distribution specific defaults. This is easy for dbus, 
> but should be also doable for other configuration systems.
>
> Dennis
>
>   

We could always add an option 5 where there a getOptionMetaData
function which the storage plugins could be responsible for wrapping
They could then choose how to store this information.

Maybe shortDesc could be kept and everything moved to a metadata
category.  That way you could run Compiz with any storage plugin
and any external app will be able to relay whatever data it needs to get.

If the backend does not support something then it can just return blank
and the application can deal with that.  ie.  if the ini plugin does not 
support
the group attribute then it will always return blank, this way BSM could be
used with any settings plugin, but it would maybe not group things as well
(for example)

dbus could easily be modified to include this as part of the existing 
getMetadata
function, it would just return a dict of extra attributes along with all 
the core
information.