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>
*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>
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.
<matchhandler>
<handler>
<match>title</match>
<!-- optional command to be run to get the attribute for a window
-->
<command>xprop | grep ^WM_NAME | ...</command>
</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>
*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>
<!-- 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>
Regards
Mike
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>> > *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.> <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.> </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.> *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.> <!-- 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. Regards Dennis
On Mon, 2007-05-21 at 14:01 +0100, Mike Dransfield wrote:> 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> > > *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> > > 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. > > <matchhandler> > <handler> > <match>title</match> > <!-- optional command to be run to get the attribute for a window --> > <command>xprop | grep ^WM_NAME | ...</command> > </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> > > *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> > <!-- 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>Some good ideas here. I suggest that we add things as a use for it is implemented and not add everything we can think just in case it might be used. I recommend that any configuration or control utility that is interested in compiz metadata is implemented in such a way that in can include it's own set of additional metadata for known plugins. New tags can first be added to the additional metadata files and if they make sense and are useful for other configuration utilities we'll move them into the official metadata files. -David