We've previously discussed if we should add some sort of selection option type and not use string options and string restrictions for that purpose. I don't think we need a new option type for this. The integer type should do just fine. The attached patch changes the blur plugin's filter option from string to integer type and adds the relevant metadata. I suggest that we change all existing options that use string restrictions in a similar way and remove the string restrictions completely. Questions? Does it sounds OK? - David -------------- next part -------------- A non-text attachment was scrubbed... Name: blur-filter.diff Type: text/x-patch Size: 9520 bytes Desc: not available Url : http://lists.freedesktop.org/archives/compiz/attachments/20070510/de2d323f/attachment.bin
With an easy metadata setup, this sounds like a very good idea in my opinion. Restricted string options are a pain especially for i18n, as obviously the restricted values are in C/en_US but we need to display to the end user the proper i18n'd value, which would be far easier in this method, as the value in this method is the int and the text is merely pretty-printing. (it seriously cleans up the API to any relevant settings library such as libccs) On Thursday 10 May 2007 15:24:02 David Reveman wrote:> We've previously discussed if we should add some sort of selection > option type and not use string options and string restrictions for that > purpose. > > I don't think we need a new option type for this. The integer type > should do just fine. The attached patch changes the blur plugin's filter > option from string to integer type and adds the relevant metadata. I > suggest that we change all existing options that use string restrictions > in a similar way and remove the string restrictions completely. > > Questions? Does it sounds OK? > > - David
Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman:> We've previously discussed if we should add some sort of selection > option type and not use string options and string restrictions for that > purpose. > > I don't think we need a new option type for this. The integer type > should do just fine. The attached patch changes the blur plugin's filter > option from string to integer type and adds the relevant metadata. I > suggest that we change all existing options that use string restrictions > in a similar way and remove the string restrictions completely. > > Questions? Does it sounds OK? > > - DavidI like the idea, but I would prefer a different XML style. <desc> <_name value="1">Foo</_name> <_name value="2">Foo2</_name> <_name value="3">Foo3</_name> </desc> Would be much shorter but I'm not sure that this would work with the translation system. Dennis
On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote:> Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: > > We've previously discussed if we should add some sort of selection > > option type and not use string options and string restrictions for that > > purpose. > > > > I don't think we need a new option type for this. The integer type > > should do just fine. The attached patch changes the blur plugin's filter > > option from string to integer type and adds the relevant metadata. I > > suggest that we change all existing options that use string restrictions > > in a similar way and remove the string restrictions completely. > > > > Questions? Does it sounds OK? > > > > - David > > I like the idea, but I would prefer a different XML style. > <desc> > <_name value="1">Foo</_name> > <_name value="2">Foo2</_name> > <_name value="3">Foo3</_name> > </desc>I wanted the <desc> tag to look the same for every option type and not all option type values can be represented as strings. e.g. actions. All option values in the meta data are currently within tags, hence it makes sense to keep these values within tags as well. - David
On Fri, 2007-05-11 at 18:53 +0200, Dennis Kasprzyk wrote:> Am Freitag, 11. Mai 2007 17:15 schrieb David Reveman: > > On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote: > > > Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: > > > > We've previously discussed if we should add some sort of selection > > > > option type and not use string options and string restrictions for that > > > > purpose. > > > > > > > > I don't think we need a new option type for this. The integer type > > > > should do just fine. The attached patch changes the blur plugin's > > > > filter option from string to integer type and adds the relevant > > > > metadata. I suggest that we change all existing options that use string > > > > restrictions in a similar way and remove the string restrictions > > > > completely. > > > > > > > > Questions? Does it sounds OK? > > > > > > > > - David > > > > > > I like the idea, but I would prefer a different XML style. > > > <desc> > > > <_name value="1">Foo</_name> > > > <_name value="2">Foo2</_name> > > > <_name value="3">Foo3</_name> > > > </desc> > > > > I wanted the <desc> tag to look the same for every option type and not > > all option type values can be represented as strings. e.g. actions. All > > option values in the meta data are currently within tags, hence it makes > > sense to keep these values within tags as well. > > > > - David > > Maybe you should provide some kind of final layout description (also for the > dependency rules), so that we can start to implement it. Getting everything > together from different mails is painfull.The dependency rules are unrelated to this and should be implemented independently. I don't see any reason for merging the changes or the discussions. This string restriction change is easy as it can be done incrementally once we've agreed on what XML style to use. Someone could maintain a .dtd with all standard tags but plugins and configuration tools are always allowed to extend it in whatever way they want. - David
On Fri, 2007-05-11 at 17:39 +0100, Mike Dransfield wrote:> Dennis Kasprzyk wrote: > > Am Freitag, 11. Mai 2007 17:15 schrieb David Reveman: > > > >> On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote: > >> > >>> Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman: > >>> > >>>> We've previously discussed if we should add some sort of selection > >>>> option type and not use string options and string restrictions for that > >>>> purpose. > >>>> > >>>> I don't think we need a new option type for this. The integer type > >>>> should do just fine. The attached patch changes the blur plugin's > >>>> filter option from string to integer type and adds the relevant > >>>> metadata. I suggest that we change all existing options that use string > >>>> restrictions in a similar way and remove the string restrictions > >>>> completely. > >>>> > >>>> Questions? Does it sounds OK? > >>>> > >>>> - David > >>>> > >>> I like the idea, but I would prefer a different XML style. > >>> <desc> > >>> <_name value="1">Foo</_name> > >>> <_name value="2">Foo2</_name> > >>> <_name value="3">Foo3</_name> > >>> </desc> > >>> > >> I wanted the <desc> tag to look the same for every option type and not > >> all option type values can be represented as strings. e.g. actions. All > >> option values in the meta data are currently within tags, hence it makes > >> sense to keep these values within tags as well. > >> > >> - David > >> > > > > Maybe you should provide some kind of final layout description (also for the > > dependency rules), so that we can start to implement it. Getting everything > > together from different mails is painfull. > > > > Even just an example xml file with all the different option types > and a quick comment for each tag would be useful.Someone should start working on a document type definition and it makes sense to have it maintained separately from the core. The core and the plugins that wishes could use it to validate all meta data files when running 'make check'.> > Explanation of why some tags have leading underscores would > be nice too ;)The underscores are not part of the XML style. They only tell intltool that the contents of those tags should be translated and they will not be present in the final .xml files. - David