Lightning already has a pretty nice inheritance model for settings (which I as a Programmer used to OO obviously…
Lightning already has a pretty nice inheritance model for settings (which I as a Programmer used to OO obviously like). But it is missing one thing: Global default options.
I would like to see:
– default options for all containers (only the ones shared by all types) (I know we already have some of these in the “General” section)
– and separate ones for each container type (which inherit from the generic defaults)
– “Unset” renamed to “Inherit” because that’s really what it does.
]]>(Next Post) I updated my Music Metadata script. »
D5 Creation
< ![CDATA[
This is a complex topic. It has already been discussed but I couldn’t go further yet. I can see multiple chains of inheritance:
A) inherit from the type: this would be useful to classify containers, for instance to make sure that all folders share the same appearance, regardless of the desktop in which they are.
B) inherit from the parent container regardless of its type: this would mainly cover item properties but could also include some container properties although maybe less useful than item properties (not too sure about this).
C) inherit from a named style, when specified, or inherit from the style of the parent container otherwise (recursively). The style wouldn’t be something you apply to a container manually, but a named set of properties that can be modified at any time and all objects would be updated accordingly.
A and C could possibly mixed: the container could first inherit from its type style, then from its user specified style, a kind of overlay of two styles.
B is probably the most natural behavior from the user point of view. But C will behave as B if no style is specified and leave the ability to apply a style when needed. Or maybe several styles.
Hummm… Maybe I have gone too far and this doesn’t match the real need, and maybe it’s too far from your suggestion.
But the more I think at this, the more I like the idea of defining the container properties as an addition (or overlay) of styles:
0) root style
1) style defined for the type of container
2) style defined by the parent container
3) to N) one or more user defined styles
The style being a set of properties, not the full set of available properties.
]]>
< ![CDATA[
So higher numbers overlay lower ones? I like it.
]]>