mgarin
commented
6 years ago We had a discussion with my colleague on the future addition of variables and how they should probably end up looking in the XML to make their usage convenient and we came up with a slightly different approach.
Here is how I initially though they will end up being:
<skin xmlns="http://weblookandfeel.com/XmlSkin">
<!-- Skin variables -->
<variables>
<!-- Light skin -->
<light>
<foreground>
<normal>black</normal>
<disabled>120,120,120</disabled>
</foreground>
<size>
<common>12</common>
<title>13</title>
<accelerator>10</accelerator>
</size>
</light>
</variables>
</skin>Basically I wanted to provide easy way to structure them allowing complex references like {light.foreground.disabled} to be used in XML styles and code.
Although that concept lacks definition of variable types which will force me to more or less "guess" them every time or to provide some additional way of defining type. Also it is highly questionable whether you would actually need a complex variables structure for the styles as you will still be referencing specific variables by flat identifier and most commonly there will only be 20 to 30 variables in a full-fledged skin.
Also this way variables will lack some agility they might have with a different implementation. To be more specific - various currently existing styles define multiple states only for the sake of changing one or two settings.
So we came up with something different to solve these problems - stateful variables:
<skin xmlns="http://weblookandfeel.com/XmlSkin">
<!-- Skin variables -->
<variables>
<!-- Text foreground -->
<color id="control">
<state id="default">black</state>
<state id="disabled">120,120,120</state>
</color>
<!-- Border color -->
<color id="border.focusable">
<state id="default">170,170,170</state>
<state id="focused">85,130,190</state>
<state id="disabled">lightGray</state>
</color>
<!-- Shadow size -->
<integer id="shadow.outer.small">2</integer>
<integer id="button.shadow.inner">
<state id="default">0</state>
<state id="pressed">6</state>
</integer>
<!-- Shadow opacity -->
<float id="shadow.outer.opacity">
<state id="default">2</state>
<state id="pressed">0</state>
<state id="disabled">0</state>
</float>
<!-- Round -->
<integer id="round.small">2</integer>
<integer id="round.medium">3</integer>
<!-- Background -->
<Background id="button">
<state id="default">
<GradientBackground>
<color>white</color>
<color>223,223,223</color>
</GradientBackground>
</state>
<state id="pressed">
<ColorBackground color="210,210,210" />
</state>
</Background>
</variables>
</skin>This approach gives a decent way to define and validate variables in XML as well as allowing us to simplify styles XML by a good chunk. Let's look at current button.xml to see how exactly it can help us:
<skin xmlns="http://weblookandfeel.com/XmlSkin">
<!-- Button -->
<style type="button" padding="2,4,2,4">
<painter>
<decorations>
<decoration>
<WebShape round="3" />
<WebShadow type="outer" width="2" />
<LineBorder color="170,170,170" />
<GradientBackground>
<color>white</color>
<color>223,223,223</color>
</GradientBackground>
<ButtonLayout>
<ButtonIcon constraints="icon" />
<ButtonText constraints="text" color="black" />
</ButtonLayout>
</decoration>
<decoration states="focused">
<LineBorder color="85,130,190" />
</decoration>
<decoration states="pressed">
<WebShadow type="outer" opacity="0" />
<WebShadow type="inner" width="6" />
<ColorBackground color="210,210,210" />
</decoration>
<decoration states="disabled">
<WebShadow type="outer" opacity="0" />
<LineBorder color="lightGray" />
<ButtonLayout>
<ButtonText color="120,120,120" />
</ButtonLayout>
</decoration>
</decorations>
</painter>
</style>
</skin>This is the default current button style.
And this is how we can pack this style using variables from above:
<skin xmlns="http://weblookandfeel.com/XmlSkin">
<!-- Button -->
<style type="button" padding="2,4,2,4">
<painter>
<decorations>
<decoration>
<WebShape round="{round.medium}" />
<WebShadow type="outer" width="{shadow.outer.small}" opacity="{shadow.outer.opacity}" />
<WebShadow type="inner" width="{button.shadow.inner}" />
<LineBorder color="{border.focusable}" />
<Background reference="{button}" />
<ButtonLayout>
<ButtonIcon constraints="icon" />
<ButtonText constraints="text" color="{control}" />
</ButtonLayout>
</decoration>
</decorations>
</painter>
</style>
</skin>Basically we can delegate most (or in some cases all) of the state-related changes to the variables and have a clean style.
You might have also noticed that two different backgrounds are represented by single variable reference - <Background reference="{button}" /> - this is one of the more complex options for variables. The idea is to provide reference-like implementations for each of the base features like IBorder, IBackground or even IContent to allow using them directly from variables as they are also shared between multiple styles.
Potentially that might allow simplifying styles down to something like this:
<skin xmlns="http://weblookandfeel.com/XmlSkin">
<!-- com.alee.laf.button.WebButton -->
<!-- Button -->
<style type="button" padding="2,4,2,4">
<painter>
<decorations>
<decoration>
<Shape reference="{button}" />
<Shadow reference="{button.outer}" />
<Shadow reference="{button.inner}" />
<Border reference="{button}" />
<Background reference="{button}" />
<ButtonLayout>
<ButtonIcon constraints="icon" />
<ButtonText constraints="text" color="{control}" />
</ButtonLayout>
</decoration>
</decorations>
</painter>
</style>
</skin>Advantages of this approach are not obvious if you only look at this example as the biggest advantage is that those elements are reusable between different styles without necessity to override or extend anything - you can simply reference desired element where you need it without defining it all over again from scratch.
On the other hand this might interfere with currently existing features like extending and overriding styles as it will be quite hard to tell what exactly going to happen whenever some settings are modified in the extending or overriding style. So eventually I might end up only doing simplified variables.
daWoife
In case your application supports multiple skins it is quite often necessary to tie some specific settings to the specific skin. For example it could be some
Coloror simpleStringtext (or language key) that cannot really be set into its destination from the style itself, but needs to be bound to each specific skin.Simple example of this case with
ColorisExamplesFramein WebLaFDemoApplication- it needs to use different element highlights for nodes and, most importantly, for legend text based onWebStyledLabel. While nodes renderer for the tree can actually be configured to provide different states for node highlights you can still only change the whole label foreground, but it would be really hard and inconvenient to change color for different text parts inside single label.There are also many other small cases like that one where styling system seems limiting or simply missing some functionality that is required - skin variables. To put it simple I want to be able to store various objects (or settings/properties/data - doesn't really matter how you call it) and be able to retrieve them in runtime from the currently used skin.
Those objects might be or might not be used within skin styles, but you should be able to retrieve them from the skin at any given time.
Definition
This is how I currently imagine simple variables would look like in skin's XML:
Probably it is also worth adding multi-level variables support right away:
To avoid clunky names like "disabledTextColor" or "tooltipTextSize" and general mess which would certainly be there without any ability to structure custom variables.
Usage in style
I'd love to see quite straightforward variables usage within styles, here is a small example based on the current
JLabelcomponent style:Benefits of such variables usage is quite obvious - you can avoid copy-pasting same settings between different components over and over again. Settings like default text colors, font sizes, rounding values, shadow widths etc.
Usage in code
Variables should be easily accessible from any part of the code:
Or for structured variables:
There should be various convenient methods for most common settings and basic one for
Object:You should also be able to retrieve these variables directly from loaded skin instance:
Probably access to variables can also be bridged into
Web-components to simplify it even further and to avoid static method calls:It would certainly be helpful if you are mostly using
Web-components as you won't really ever need to callStyleManagerdirectly. But those extra methods might intersect with existing ones so this part might require further investigation.Scope
Variables can be defined in any parts of a skin (probably just 1 block per XML file?) and should be accessible right after they have been defined, even if they were defined in a different skin file which was included.
All variables should be gathered in a single tree-like data structure. The ones using same identifiers and having the same type should replace each other, ones having different types should probably throw an exception to notify about obvious issue in the style.
Fonts
There is already a topic with a discussion of a somewhat similar enhancements, just less broad ones - related only to application skins: #331
I'm not yet sure if fonts should be a part of variables system or be a separate thing, so this is certainly a topic open for the discussion.