Greg or Todd could give you the official answer, but I think it is meant to
ensure that access to the skin always occurs via the StyleDictionary. That
way the code would be able to run with a different theme, or merely a
different skin for the component.
You could always extend TerraTreeViewSkin and add your code into that
class. Then you *know* that 'indent' and 'spacing will be there, and it
would be fine to access them directly.
CustomTerraTreeViewSkin extends TerraTreeViewSkin {
public void myMethod() {
int indent = getIndent();
int spacing = getSpacing();
...
}
}'
You could then create a CustomTreeView and associate it with your
CustomTerraTreeViewSkin in the Theme, so that any instance of
CustomTreeView would use CustomTerraTreeViewSkin.
Chris
On 15 June 2011 23:14, Edvin Syse <[email protected]> wrote:
> Den 15.06.2011 18:02, skrev Chris Bartlett:
>
>> On 15 June 2011 22:50, Edvin Syse <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> TerraTreeViewSkin skin = (TerraTreeViewSkin)
>> getSkin();
>> int baseNodeX = path.getLength() *
>> (skin.getIndent() + skin.getSpacing());
>>
>>
>> If all you need are the 'indent' and 'spacing', they are properties of
>> the skin, and therefore available as styles via the TreeView. You can
>> avoid casting the skin to TerraTreeViewSkin and accessing its properies
>> directly.
>>
>> treeView.getStyles().get("indent");
>> treeView.getStyles().get("spacing");
>>
>> In reality that doesn't really help much though, as you are still
>> relying on those styles being there, and also relying on the fact that
>> they behave exactly as they do in TerraTreeViewSkin.
>>
>
> Absolutely :) I'll rewrite my utility class to use the indent and spacing
> styles anyway, since a new skin is more than likely to be based on Terra.
> Later on I could add special cases based on the skin maybe. I see
> Component.getSkin() is protected - why is that? Would be nice to be able to
> check what kind of skin was installed on a component.
>
>
