[compiz] Metadata additions

[David Reveman]

On Thu, 2007-07-12 at 03:54 +0200, Dennis Kasprzyk wrote:
> With this mail I would like to make a proposal to add additional informations 
> to the core and plugin metadata files. Currently these tags are already 
> handled in the ccs configuration system. Ccs  automatically adds this 
> informations to the core/plugin option set, but I think that it would make 
> more sense to add this to the official files, to allow similar features in 
> other configuration systems. 
> 
> 1.) Group and subgroups:
> 
> <plugin>
>   <display>
>     <option .../>
>     <option .../>
>     <group>
>       <short>This is a functional group</short>
>       <option .../>
>       <option .../>
>       <subgroup>
>          <short>This options belong together</short>
>          <option .../>
>          ...
>       </subgroup>
>     </group>
> ...
> There are often a lot of different opinions how options should be grouped, but 
> this could be discussed after we have decided to add group/subgroup tags.
> Currently the core has two lists (opacity_matches and opacity_values) that 
> should be handled together, because the opacity of the opacity_values list 
> will be assigned to the corresponding match in the match list. In ccs we 
> automatically combine such values if all options inside a subgroup have the 
> list type, but we could also add a combine=”true” attribute to the subgroup 
> tag, to make this functionality configurable.

Sure, this seems OK.

It makes a lot of sense to slit up the action options we have today into
multiple less complex options and just group them together using
metadata. It will simplify the configuration system a lot.

> 
> 2.) Option hints:
> 
> A string option (there may be others too) can be used for different things 
> like commands,files, and images. To allow a configuration to handle such 
> options in a spacial way (open a file open dialog), I would like to add a 
> <hints> tag to such options. The hints tag would contain a semicolon 
> separated list of strings that inform the configuration system to handle this 
> options in a special way. These are the possible hints:
> 
> command; = open a file dialog to select an executable file
> image; = open a file dialog that already filters all image files that are 
> currently supported by currently loaded image plugins and shows previews of 
> the images
> file; = open a file dialog that allows you to select any file
> file:txt,doc; = open a file dialog that allows you to select *.txt and *.doc 
> files

Sounds good.

> 
> 3.) Plugin categories:
> 
> Currently we have a lot of plugins and we will have more in the future. I 
> think that it makes sense to group plugins to functional categories 
> like “Effects”, “Window management” and “Image loaders”. A <category> tag 
> could be added the <plugin> section to achieve this functionality. There are 
> currently 3 different ways how the contents of this tag could be handled:
> - We define short category definitions like fx,wm and image and the 
> configuration system will need to have the “long” names and their 
> translations.
> - We add directly the English long category names like “Effects”, “Window 
> management” and “Image loaders”, and the configuration system will need to 
> have translations for them. This has the disadvantage that the configuration 
> system would need to have a list of all long names to be able to 
> automatically generate a .pot file for translations.
> - We add long category names to the metadata and translate them with the 
> current translation system like we do for option descriptions. This has the 
> disadvantage that plugins from different sources could also have different or 
> none translations for the same category and the configuration systems would 
> need a way to find the best solution.

I definitely prefer that we add long category names to the metadata. We
can make it possible for external plugins to use the po files from the
core repository when translating metadata.

-David