[compiz] re-work option initialization

[Mike Dransfield]

Dennis Kasprzyk wrote:
> Am Freitag, 30. März 2007 17:48 schrieben Sie:
>> 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.
>>
>>     
> In this system a plugin developer would have to create metedata information 
> for each storage backend, what is a stupid idea to me.
>   

I thought the idea was that this sort of thing could be
generated at compile-time using whatever system
necessary.

I think the plugin developer should provide at least short
description because that gives people a clue as to what it
actually does.  I think the extra attribute stuff should be
added by other people to give a more human readable
version.


>> 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.
>>
>>     
> I think that there is no reason to keep short desc in the plugin if we move 
> other metadata out of the plugin. We should be consistent in this case.
>
>   

The short description provides at least a basic > 1 word
explanation of the what the option does, otherwise people
will need to work it out from just the name.

>> 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)
>>
>>     
> BSM has it's own storage system and will not use the ini or the gconf plugin.
>   

I thought you were planning a libbs plugin instead of
linking core to libbs directly?  This way you are free to
add whatever information you like, but other plugins do
not depend on them just to compile.

It will also mean that people will be able to modify or
extend these attributes without changing code.

>> 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.
>>     
> With my proposal dbus would provide the metadata that comes from libconmpiz.
>
>   

But you would need to modify core every time you wanted
to add some extra information about the option.

This idea could be further extended so that other plugins
can read this extended information.