Debugging CSS

[David Grieve]

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 
> property.
>
> 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?
>
> Tom
>
> 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 
CSS analyzer.
>> Tom
>>
>>
>> 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 
>>> (http://fxexperience.com/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.
>>>>
>>>> Tom
>>>>
>>>> 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.
>>>>> https://github.com/JFXtras/jfxtras-labs/blob/8.0/src/main/resources/jfxtras/labs/internal/scene/control/gauge/linear/SimpleMetroArcGauge.css 
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> Tom
>>>>
>>>
>>
>