What if we add a method like:
StyleableObjectProperty#runWithOutOriginTracking(Runnable r)
Tom
On 20.05.14 15:10, David Grieve wrote:
> What I meant was that I don't like that you have to be aware from
> library code that calling setXXX(value) screws up CSS so you have to use
> applyStyle(null, value). I wish there was some way of knowing that the
> setXXX is happening inside library code so this kind of usage wasn't an
> issue.
>
> It would be best to have a bug to track this.
>
> On 5/20/14, 8:45 AM, Tom Schindl wrote:
>> Would it be better to simply use a boolean flag instead of modifing the
>> property, something along:
>>
>> try {
>> disableAnimation = true;
>> // ...
>> } finally {
>> disableAnimation = false;
>> }
>>
>> Tom
>>
>> On 20.05.14 14:26, David Grieve wrote:
>>> Good find. The code needs to save off the StyleOrigin and use applyStyle
>>> instead of set. I don't like that you have to deal with this level of
>>> detail, but I haven't figured out any way around it yet. I'm open to
>>> ideas.
>>>
>>> // save and set tab animation to none - as it is
>>> not
>>> a good idea
>>> // to animate on the same data for open and close.
>>> TabAnimation prevOpenAnimation =
>>> openTabAnimation.get();
>>> StyleOrigin prevOpenOrigin =
>>> ((StyleableProperty<TabAnimation>)openTabAnimation).getStyleOrigin();
>>> TabAnimation prevCloseAnimation =
>>> closeTabAnimation.get();
>>> StyleOrigin prevCloseOrigin =
>>> ((StyleableProperty<TabAnimation>)closeTabAnimation).getStyleOrigin();
>>> ((StyleableProperty<TabAnimation>)openTabAnimation).applyStyle(null,
>>> TabAnimation.NONE);
>>> ((StyleableProperty<TabAnimation>)closeTabAnimation).applyStyle(null,
>>> TabAnimation.NONE);
>>> for (int i = c.getFrom(); i < c.getTo(); i++) {
>>> permutatedTabs.add(tabs.get(i));
>>> }
>>>
>>> removeTabs(permutatedTabs);
>>> addTabs(permutatedTabs, c.getFrom());
>>> ((StyleableProperty<TabAnimation>)openTabAnimation).applyStyle(prevOpenOrigin,
>>>
>>> prevOpenAnimation);
>>> ((StyleableProperty<TabAnimation>)closeTabAnimation).applyStyle(prevCloseOrigin,
>>>
>>> prevCloseAnimation);
>>> getSkinnable().getSelectionModel().select(selTab);
>>>
>>>
>>>
>>> On 5/20/14, 7:26 AM, Tom Schindl wrote:
>>>> Hi,
>>>>
>>>> This question is mostly for David but others might be able to
>>>> support my
>>>> feeling that TabPaneSkin works against the CSS-Engine inside its
>>>> initializeTabListener-method where it does something like this:
>>>>
>>>>> // save and set tab animation to none - as it is
>>>>> not a good idea
>>>>> // to animate on the same data for open and
>>>>> close.
>>>>> TabAnimation prevOpenAnimation =
>>>>> openTabAnimation.get();
>>>>> TabAnimation prevCloseAnimation =
>>>>> closeTabAnimation.get();
>>>>> openTabAnimation.set(TabAnimation.NONE);
>>>>> closeTabAnimation.set(TabAnimation.NONE);
>>>>> for (int i = c.getFrom(); i < c.getTo(); i++) {
>>>>> permutatedTabs.add(tabs.get(i));
>>>>> }
>>>>>
>>>>> removeTabs(permutatedTabs);
>>>>> addTabs(permutatedTabs, c.getFrom());
>>>>> openTabAnimation.set(prevOpenAnimation);
>>>>> closeTabAnimation.set(prevCloseAnimation);
>>>> if I now appropriately understand the working of the CSS-Engine it will
>>>> never set a value from CSS afterwards because the property origin is
>>>> set
>>>> to user.
>>>>
>>>> Minor detail - the code of remembering and restoring the state should
>>>> most likely be wrapped in a try-finally statement.
>>>>
>>>> Tom
>
