compiz - Jul 2007 - Metadata additions

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

Hi,
> 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:
> 2.) Option hints:
> 3.) Plugin categories:
I obviously are ok with these suggestions as I was involved in creating
them, but I'd like to propose another tag addition: Plugin load
suggestions.

This would be similar to the dependency tags and could tell the settings
manager that a certain plugin doesn't explicitly need another plugin to
work, but needs it to get full functionality.
Examples for that:
- cube could suggest rotate (cube without rotate works, but doesn't make
much sense)
- ring, scaleaddon, scalefilter and group could suggest the text plugin
(they work without, but need it to display text).

I would propose the following tag layout:


<compiz>
  <plugin>
    <deps>
    </deps>
    <suggestions>
      <plugin>foo</plugin>
      <feature>bar</feature>
    </suggestions>
  </plugin>
</compiz>

The feature suggestion most likely isn't needed at the moment, but IMO
it makes sense to add it because it might be needed later and it is in
line with the dependency tag layout.

Opinions about this?

Regards,

Danny

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