From freedesktop-compiz Mon May 21 16:41:30 2007 From: Dennis Kasprzyk Date: Mon, 21 May 2007 16:41:30 +0000 To: freedesktop-compiz Subject: Re: [compiz] Some suggestions for extra metadata Message-Id: <200705211841.30674.onestone () opencompositing ! org> X-MARC-Message: https://marc.info/?l=freedesktop-compiz&m=117976576109500 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 "bob@bar.com" > > alice "alice@bar.com" > > 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 _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz