[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-compiz
Subject:    Re: [compiz] Some suggestions for extra metadata
From:       Dennis Kasprzyk <onestone () opencompositing ! org>
Date:       2007-05-21 14:44:59
Message-ID: 200705211644.59858.onestone () opencompositing ! org
[Download RAW message or body]

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@bar.com"</author>
	<author>alice "alice@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



_______________________________________________
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
[prev in list] [next in list] [prev in thread] [next in thread]