Re: [compiz] Some suggestions for extra metadata
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. > > > 0 > 1 > 0 > > > *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). > > largedesktop > > 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. > > > > title > >xprop | grep ^WM_NAME | ... > > name >etc... > > > *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. > > > > > > > *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. > > > > http://www.example.com/plugin-update.xml > > http://www.example.com/plugin-info.html > > > > mime="text/html">http://www.example.com/plugin.html > mime="image/jpeg">http://www.example.com/plugin.jpg > mime="application/swf">http://www.example.com/plugin.swf > 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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
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. > >> > >> > >> 0 > >> 1 > >> 0 > >> > > > > A more general plugin info struct should be better > > > > bob "[EMAIL PROTECTED]" > > alice "[EMAIL PROTECTED]" > > GPL > > 0.1.0-git > > http://www.example.com/plugin-info.html > > > > 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). > >> > >> largedesktop > > > > We should handle 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. > > >> > >> > >> title > >> xprop | grep ^WM_NAME | ... > > > > 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. > > >> > >> name > >>etc... > >> > >> > >> *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. > >> > >> > >> > >> > >> > > > > What about the subgroup tag that we already use in the opencomposite.org > > plugins? > > > > Foo > > > > ... > > > > > > ... > > > > > > > > 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. > >> > >> > >> > >> http://www.example.com/plugin-update.xml > > > > 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. > >> > >> http://www.example.com/plugin-info.html > >> > >> > >> > >> >> mime="text/html">http://www.example.com/plugin.html > >> >> mime="image/jpeg">http://www.example.com/plugin.jpg > >> >> mime="application/swf">http://www.example.com/plugin.swf > >> > > > > 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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz _
Re: [compiz] Some suggestions for extra metadata
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. >> >> >> 0 >> 1 >> 0 >> >> > A more general plugin info struct should be better > > bob "[EMAIL PROTECTED]" > alice "[EMAIL PROTECTED]" > GPL > 0.1.0-git > http://www.example.com/plugin-info.html > > 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). >> >> largedesktop >> >> > We should handle 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. >> >> >> title >> xprop | grep ^WM_NAME | ... >> > 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. >> >> name >>etc... >> >> >> *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. >> >> >> >> >> >> >> > What about the subgroup tag that we already use in the opencomposite.org > plugins? > > Foo > > ... > > > ... > > > > 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. >> >> >> >> http://www.example.com/plugin-update.xml >> > 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. >> >> http://www.example.com/plugin-info.html >> >> >> >> > mime="text/html">http://www.example.com/plugin.html >> > mime="image/jpeg">http://www.example.com/plugin.jpg >> > mime="application/swf">http://www.example.com/plugin.swf >> >> >> > 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/compiz > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
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. > > > 0 > 1 > 0 > A more general plugin info struct should be better bob "[EMAIL PROTECTED]" alice "[EMAIL PROTECTED]" GPL 0.1.0-git http://www.example.com/plugin-info.html > > *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). > > largedesktop > We should handle 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. > > > title > xprop | grep ^WM_NAME | ... This is a big security risk. > > name >etc... > > > *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. > > > > > > What about the subgroup tag that we already use in the opencomposite.org plugins? Foo ... ... 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. > > > > http://www.example.com/plugin-update.xml Security risk again. Distributions don't like individual binary update systems. > > http://www.example.com/plugin-info.html > > > > mime="text/html">http://www.example.com/plugin.html > mime="image/jpeg">http://www.example.com/plugin.jpg > mime="application/swf">http://www.example.com/plugin.swf > > 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
[compiz] Some suggestions for extra metadata
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. 0 1 0 *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). largedesktop 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. title xprop | grep ^WM_NAME | ... name etc... *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. *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. http://www.example.com/plugin-update.xml http://www.example.com/plugin-info.html http://www.example.com/plugin.html http://www.example.com/plugin.jpg http://www.example.com/plugin.swf Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
