[compiz] Core option sorting in metadata

[David Reveman]

On Thu, 2007-07-12 at 02:17 +0200, Dennis Kasprzyk wrote:
> Am Donnerstag 12 Juli 2007 00:40:41 schrieb David Reveman:
> > On Wed, 2007-06-13 at 16:48 +0200, Danny Baumann wrote:
> > > Hi,
> > >
> > > currently, all sorting order of the core and core plugin options inside
> > > the metadata files is based on the order they are listed in the C source
> > > files. Unfortunately, that's not optimal for automatic settings manager
> > > GUI generation.
> > >
> > > DO you think it's ok to sort them by functional groups? This would have
> > > the advantage of settings managers being aware of the functional
> > > grouping, which would help a lot in creating them.
> > >
> > > I have attached a patch which re-sorts the core options a bit to reflect
> > > that - what do you think about it? Is this change ok to go in?
> >
> > A function attribute or function element should be added to the option
> > element if functional groups are desirable.
> >
> 
> We already do grouping with the group/subgroup tags. We also add this 
> information to the core/plugin options inside of the ccs configuration 
> system. The problem here is that, if the options a,b,c,d,e are stored in this 
> order in the metadata file and we group b,d,e, then they will also have the 
> b,d,e order in the group even if e,b,d would make more sense (e,b,d,a,c could 
> also make more sense without grouping). Changing the order inside of the 
> configuration system will unnecessary increase complexity. The inclusion of 
> the group/subgroup tags to the core metadata files should be handeled in a 
> separate thread.

Why would e,b,d make more sense in your example? Sounds to me like you
just have an additional relationship between options that the existing
group mechanism doesn't cover. Can you provide a real example?

-David