[compiz] Some suggestions for extra metadata

Mon May 21 09:41:30 PDT 2007

Am Montag 21 Mai 2007 17:37:25 schrieben Sie:
> 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.
>
Autotools and pkgconfig seam to work well with one version string.
> Info is basically metadata so we probably don't need the
> extra info tags at all.
>
But this improves readability.
> >> *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.
>
Maybe you should not use beryl-settings here as example here. But if you want 
we could add a autojoin="true" attribute to the subgroup tag.
> >> *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.
>
Something like this can work for python plugins but not for compiled c 
binaries.
> >>     <!-- 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.
>
If you want screenshots then they should be a part of the plugin package.
> > Regards
> > Dennis
> >
> >
> >
> > _______________________________________________
> > compiz mailing list
> > compiz at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/compiz