JDK-8222258: Add exclusion scope for LightBase

Kevin Rushforth kevin.rushforth at oracle.com
Tue Apr 30 12:18:25 UTC 2019


In that case, as long as you write tests for the case where there are 
bindings (both unidirectional and bidirectional), moving it from one 
list to another seems fine to me.

-- Kevin


On 4/29/2019 7:43 PM, Nir Lisker wrote:
> The scope is a TrackableObservableList with a single onChanged that 
> marks dirty the changed nodes. In my preliminary implementation in the 
> Webrev, when adding a node to a scope, there is an attempt to remove 
> it from he other one, which if successful, calls its onChange and 
> marks the node dirty. I don't see the added complexity compared to 
> giving precedence to one of the lists.
>
> On Mon, Apr 29, 2019 at 3:53 PM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>
>     On 4/27/2019 1:23 PM, Nir Lisker wrote:
>>     Hi Kevin,
>>
>>         For the second question, you outlined three possibilities. My
>>         initial
>>         thought is that the complexity of moving it from one list to
>>         another
>>         (which is what happens with child nodes of a parent) is not
>>         worth the
>>         effort.
>>
>>
>>      The effort is essentially just an attempt to remove the node
>>     from the other list, or am I missing something?
>
>     The complexity comes because of binding. It isn't horrible, but it
>     isn't as simple as it might initially seem. See the use of
>     VetoableListDecorator in Parent.
>
>     -- Kevin
>
>
>>     On Sat, Apr 27, 2019 at 10:09 PM Kevin Rushforth
>>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>     wrote:
>>
>>         Hi Nir,
>>
>>         This seems like it would be a useful addition to the JavaFX
>>         3D lighting
>>         API. You highlighted the two things that need to be clearly
>>         defined in
>>         terms of semantics:
>>
>>         1. Parent node in the inclusion list, descendant node in the
>>         exclusion
>>         list (or vice versa)
>>         2. A node in both lists
>>
>>         I think your main idea about the rules for the first question
>>         seems
>>         exactly right: a node that is in one list or the other
>>         overrides any
>>         ancestor node and that will applies to all descendants which
>>         are not in
>>         one of the lists of scopes. If the inclusion list is empty,
>>         it behaves
>>         exactly the same as if the root node were the only node in
>>         the inclusion
>>         list.
>>
>>         For the second question, you outlined three possibilities. My
>>         initial
>>         thought is that the complexity of moving it from one list to
>>         another
>>         (which is what happens with child nodes of a parent) is not
>>         worth the
>>         effort. I would recommend that one or the other take precedence
>>         (probably the exclusion).
>>
>>         -- Kevin
>>
>>
>>         On 4/18/2019 9:54 PM, Nir Lisker wrote:
>>         > Hi Kevin/Johan,
>>         >
>>         > I submitted an enhancement request to add an "exclusion
>>         scope" to LightBase
>>         > [1]. The "exclusion scope" is a list of nodes which should
>>         not be affected
>>         > by the light. It's a convenient alternative for adding all
>>         of the nodes to
>>         > the scope except for the ones which should be excluded.
>>         >
>>         > I've written a preliminary Webrev and a sample app that
>>         demonstrates the
>>         > behavior.
>>         >
>>         > Please evaluate,
>>         > Nir
>>         >
>>         > [1] https://bugs.openjdk.java.net/browse/JDK-8222258
>>
>



More information about the openjfx-discuss mailing list