[compiz] Some suggestions for extra metadata

[Mike Dransfield]

Dennis Kasprzyk wrote:
> Am Montag 21 Mai 2007 15:01:49 schrieb Mike Dransfield:
>   
>> Here are a few extra attributes which I have not seen mentioned yet
>> which I think would be useful.  Any comments would be appreciated.
>>
>> *Version*
>>
>> The version of the plugin, I think the reasons for this are obvious.
>>
>> <version>
>>     <major>0</major>
>>     <minor>1</minor>
>>     <patch>0</patch>
>> </version>
>>     
> A more general plugin info struct should be better
> <info>
> 	<author>bob "bob at bar.com"</author>
> 	<author>alice "alice at bar.com"</author>
> 	<license>GPL</license>
> 	<version>0.1.0-git</version>
> 	<infourl>http://www.example.com/plugin-info.html</infourl>
> </info>
>   

Thats OK too, but the version should be split up or we end up
with 1001 different versioning schemes and 1001 parsers
for them.

Info is basically metadata so we probably don't need the
extra info tags at all.


>   
>> *Addition to features*
>>
>> Just add an attribute to the features tag so that features can be unique
>> or non-unique.  This will mean that we can add lots more features
>> like 'config', 'matchhandler', 'imageloader' etc etc.  They need to be
>> defined somewhere so that plugin developers can check a list of
>> official features like this (whilst still adding their own if needed).
>>
>> <feature unique="true">largedesktop</feature>
>>
>>     
> We should handle <feature> not as uniqe and use conflict feature rules for 
> features that should be unique.
>   
>> This should default to true if not provided.
>>
>> *Match Handler Tag*
>>
>> If a plugin provides window matching functionality then it could provide
>> tags like this.
>>
>>     
> I see no reason for this.
>   

It would allow a config app to know what window matching features
are available and provide a gui for them.

>> <matchhandler>
>>     <handler>
>>         <match>title</match>
>>        <!-- optional command to be run to get the attribute for a window
>> --> <command>xprop | grep ^WM_NAME | ...</command>
>>     
> This is a big security risk.
>   

In what way?

The app can decide whether or not to trust the source of the
xml.

Its only a suggestion to the app, it does not have to run it but
it would be easier than telling the user to execute that in a
terminal, or each app providing its own database of how to get
each piece of information.

Untrusted software can include xml files too so if people install
unknown software from unknown sources, it can do whatever
it likes anyway.


>>     </handler>
>>     <handler>name</handler>
>>    etc...
>> </matchhandler>
>>
>> *Option Group*
>>
>> Some plugins and the core have options which work in groups.  Hints
>> can be provided to group these options so that configuration tools
>> will be able to display them as a grid rather than as individual options.
>>
>> <optiongroup>
>>     <option name="opacity_match" />
>>     <option name="opacity_values" />
>> </optiongroup>
>>
>>     
> What about the subgroup tag that we already use in the opencomposite.org 
> plugins?
> <subgroup>
> 	<short>Foo</short>
> 	<option name="opacity_match">
> 		...
> 	</option>
>         <option name="opacity_values">
> 	...
> 	</option>
> </subgroup>
>
> The setting application should detect if all options in a subgroup have the 
> list type and provide the right interface for it.
>   

Its a different type of grouping.  Your way would stop
whatever you are using subgroup for from working if there
are 2 list options in a group which are not grouped in this way.

A simple example would be cube cap images and cube face images.
They are both lists and could both be categorized as Appearance ->
Images.  They would not have to have their order related in the
same way.

>   
>> *Web based information*
>>
>> I think it would be a very nice feature to add some web based
>> attributes which means things can be easily updated without
>> the user updating the plugin.  There are probably others that
>> could be added.
>>
>> <info>
>>     <!-- xml file with update info -->
>>     <updateurl>http://www.example.com/plugin-update.xml</updateurl>
>>     
> Security risk again. 
> Distributions don't like individual binary update systems.
>   

The updates can always go into ~/.compiz/plugins which is nothing
to do with the distributions.

>>     <!-- html page with additional information about the plugin -->
>>     <infourl>http://www.example.com/plugin-info.html</infourl>
>> </info>
>>
>> <screenshots>
>>     <screenshot
>> mime="text/html">http://www.example.com/plugin.html</screenshot>
>>     <screenshot
>> mime="image/jpeg">http://www.example.com/plugin.jpg</screenshot>
>>     <screenshot
>> mime="application/swf">http://www.example.com/plugin.swf</screenshot>
>> </screenshots>
>>
>>     
> This should be on the plugin info page and not part of the metadata.
>   

This would allow config apps to display screenshots internally
without the user having to go to a separate website.

> Regards
> Dennis
>
>
>
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>