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.

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

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.

Dennis
_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz