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
> 

Reply via email to