JDK-8222258: Add exclusion scope for LightBase

[Kevin Rushforth]

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
>>
>