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 "[EMAIL PROTECTED]"</author> > > <author>alice "[EMAIL PROTECTED]"</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@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz
_______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
