david.grieve at oracle.com
Sun Apr 5 22:58:30 UTC 2015
On 4/5/15 3:56 AM, Tom Eugelink wrote:
> I have another interesting behavior involving CSS. The gauge has a
> text representation of the value of the needle, which can be formatted
> using DecimalFormat. The format string can be set with a styleable
> In the example this property is set, via setStyle(), to something with
> a unit postfix, e.g. "##0.0W" so the gauge will show watts. This
> works. But as soon as totally unrelated classes are removed from the
> gauge, the styleable property reverts to its initial value, but the
> style string is unchanged!
> This behavior is introduced in 8u20, in 8u00 it works as intended.
And in 8u40?
> On 4-4-2015 08:14, Tom Eugelink wrote:
>> After loads of trail and error I pinned it down to the fact that
>> scaling of the node in question was not taking into account when
>> positioning it; it is centered and I use its width to do that, but it
>> was the width-before-scaling. So it was a miracle it was in the right
>> place at all. What really would be needed here (and I think anyone
>> who has done HTML with CSS will agree) is a
>> which-property-is-set-by-which-CSS-class-and-file, like the debug
>> view in browsers. Does the CSS engine keep track of this information?
When it comes time to pick the style for a property, the CSS engine does
not know which CSS file a property came from. The APIs mentioned below
are all you have when it comes to finding what styles apply to a node.
These methods are, in fact, the methods that Scene Builder uses for its
>> On 3-4-2015 22:19, David Grieve wrote:
>>> When you add or remove style-classes, CSS for the node (and all its
>>> children) is totally re-calculated. This means that cached data for
>>> that node is tossed out and the node is styled from scratch, as if
>>> it were just added to the scene-graph.
>>> You are much better off using pseudo-class state for what you are
>>> trying to do. Changes in pseudo-class state just causes evaluation
>>> of what styles are applied in that state, which is relatively low
>>> overhead compared to re-calculating styles.
>>> To debug, you should try using Scenic View
>>> You can also use the Node API Map<StyleableProperty<?>,List<Style>>
>>> impl_findStyles(Map<StyleableProperty<?>,List<Style>> styleMap).
>>> Note that this is deprecated API
>>> On 4/3/15 2:13 PM, Tom Eugelink wrote:
>>>> One addition: the move happens if, for example, "segment0-active"
>>>> is added to the skinnable. Even if that class is empty or even not
>>>> defined in the CSS.
>>>> On 3-4-2015 19:48, Tom Eugelink wrote:
>>>>> I'm pushing the envelope a bit -I think- concerning the use of
>>>>> CSS. I have setup a control (gauge) in such a way that, depending
>>>>> on the position of the needle, certain CSS classes are added or
>>>>> removed from the control. For example a "errorSegment-active"
>>>>> class if the value comes into the 90-100 value in a 0-100 gauge.
>>>>> In this class a CSS variable -fx-error-indicator-visibility is set
>>>>> to "visible" and that again shows some kind of indicator on the
>>>>> gauge. Works great.
>>>>> What is strange is when this class is assigned to the control, a
>>>>> totally unrelated node (the value in the needle) suddenly moves
>>>>> out of position. I do not understand this, because the CSS only
>>>>> involves colors and visibility, never any transformation.
>>>>> Is there any way to debug what CSS settings are applied to nodes?
>>>>> I really would like to find out what causes that node to move.
More information about the openjfx-dev