From nicciglen at gmail.com Tue Apr 9 20:08:02 2019 From: nicciglen at gmail.com (Glen & Nicci Johnson) Date: Tue, 9 Apr 2019 21:08:02 +0100 Subject: Wanting to contribute to 1. updating JavaFX Developers Guide, 2. JavaFX Accessibility Development and Documentation Message-ID: Hello OpenJFX Community I?ve just rejoined the OpenJFX community with a desire to contribute to its current path of development (documentation and code). Just a quick introduction. I?m an experienced Software Developer who has been using Java consistently since the 90s. As I have an interest in areas like User Interface development and computer graphics, I?ve followed the evolution of JavaFX over the last decade. I am passionate about Digital Accessibility design and development, and am good (so I?m told) at Technical Writing. This leads me to ask two questions: 1. Latest JavaFX Official Developers Documentation / Guide Since Java 8, and the changes to the release schedule following Java 9, the (official) JavaFX Developers Documentation does not appear to have been maintained / updated. The last available version dates back to Java 8. This appears to have created confusion for some developers wanting to get deeper into developing with more recent releases of JavaFX e.g. ver. 11 or 12. I?m aware there is a short ?Getting Started with JavaFX? guide. However, people who don?t already have a deep understanding of the inner workings of JavaFX may need a lot more than this quick introduction and the JavaDoc API to guide them. [1]. I know there are a fair number of good JavaFX books and also various useful tutorials sprinkled over the web, but I think it would be good to get the official JavaFX Developer Documentation updated and available for more recent releases. I would like to help with this if possible please. What?s the best way to contribute to bringing the JavaFX developer documentation up to date with JavaFX 11 and 12? Is there already a public facing repository that holds the Oracle JavaFX developer docs source text that others (such as myself) can contribute towards to expand, update and improve? Are the Oracle JavaFX 8 developer docs licensed under Open Source, or would I / we have to start writing an official developer guide from scratch? 2. JavaFX Accessibility Developer and User Guides About 5 years ago, when Peter Korn was still part of the Java team at Oracle as Accessibility Principle, there was a fair amount of development effort and investment into making JavaFX accessible. Since Peter?s departure to Amazon, I can see from the OpenJFX repository that bug fixes and improvements relating to the JavaFX Accessibility API have continued to some extent. However, the impetus behind Java Accessibility seems to have waned in recent years. There are indeed a few JavaFX accessibility tutorials scattered across the web and the OpenJFX WIKI (on java.net) has a few brief (and much outdated) pages pertaining to Accessibility development [2]. However, there doesn?t seem to be an up to date and official JavaFX Accessibility Development and User Guide available for versions 11 and 12. If I?ve missed it, please let me know where I can find it. In recent years, the priority given to Digital Accessibility has risen significantly as businesses have realised it?s revenue earning potential. Furthermore, in many countries around the world it is now illegal for a website or app to be inaccessible to those with disabilities (in the public sector at least) [3]. For JavaFX to be a good contender in this respect, especially to be highly regarded in general by accessibility designer and developer communities, I think it would be beneficial for more prominence to be given to making sure the JavaFX accessibility APIs and tools continue to be in excellent shape and receive all the due diligence that this endeavour needs. Of course, these efforts also need to include creating and maintaining a comprehensive Java FX Accessibility Guide for Developers and Users. Is Gluon perhaps already contributing to efforts in this area? Are there ways in which I can contribute towards these? Looking forward to getting feedback from the community on these points. [1] [2] , [3] Best regards Glen Johnson LinkedIn: https://www.linkedin.com/in/glenjohnsonsofteng/ From nlisker at gmail.com Tue Apr 9 22:00:02 2019 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Apr 2019 01:00:02 +0300 Subject: Wanting to contribute to 1. updating JavaFX Developers Guide, 2. JavaFX Accessibility Development and Documentation In-Reply-To: References: Message-ID: Hi Glen, 1. Latest JavaFX Official Developers Documentation / Guide > This has been reported, but no update is planned. See [1]. They are not part of the OpenJFX codebase so there's no easy way for us to update them. That's all I know. - Nir [1] https://bugs.openjdk.java.net/browse/JDK-8210360 On Tue, Apr 9, 2019 at 11:10 PM Glen & Nicci Johnson wrote: > Hello OpenJFX Community > > I?ve just rejoined the OpenJFX community with a desire to contribute > to its current path of development (documentation and code). Just a > quick introduction. I?m an experienced Software Developer who has been > using Java consistently since the 90s. As I have an interest in areas > like User Interface development and computer graphics, I?ve followed > the evolution of JavaFX over the last decade. I am passionate about > Digital Accessibility design and development, and am good (so I?m > told) at Technical Writing. This leads me to ask two questions: > > 1. Latest JavaFX Official Developers Documentation / Guide > > Since Java 8, and the changes to the release schedule following Java > 9, the (official) JavaFX Developers Documentation does not appear to > have been maintained / updated. The last available version dates back > to Java 8. > > This appears to have created confusion for some developers wanting to > get deeper into developing with more recent releases of JavaFX e.g. > ver. 11 or 12. I?m aware there is a short ?Getting Started with > JavaFX? guide. However, people who don?t already have a deep > understanding of the inner workings of JavaFX may need a lot more than > this quick introduction and the JavaDoc API to guide them. [1]. > > I know there are a fair number of good JavaFX books and also various > useful tutorials sprinkled over the web, but I think it would be good > to get the official JavaFX Developer Documentation updated and > available for more recent releases. I would like to help with this if > possible please. > > What?s the best way to contribute to bringing the JavaFX developer > documentation up to date with JavaFX 11 and 12? Is there already a > public facing repository that holds the Oracle JavaFX developer docs > source text that others (such as myself) can contribute towards to > expand, update and improve? Are the Oracle JavaFX 8 developer docs > licensed under Open Source, or would I / we have to start writing an > official developer guide from scratch? > > 2. JavaFX Accessibility Developer and User Guides > > About 5 years ago, when Peter Korn was still part of the Java team at > Oracle as Accessibility Principle, there was a fair amount of > development effort and investment into making JavaFX accessible. Since > Peter?s departure to Amazon, I can see from the OpenJFX repository > that bug fixes and improvements relating to the JavaFX Accessibility > API have continued to some extent. However, the impetus behind Java > Accessibility seems to have waned in recent years. There are indeed a > few JavaFX accessibility tutorials scattered across the web and the > OpenJFX WIKI (on java.net) has a few brief (and much outdated) pages > pertaining to Accessibility development [2]. However, there doesn?t > seem to be an up to date and official JavaFX Accessibility Development > and User Guide available for versions 11 and 12. If I?ve missed it, > please let me know where I can find it. > > In recent years, the priority given to Digital Accessibility has risen > significantly as businesses have realised it?s revenue earning > potential. Furthermore, in many countries around the world it is now > illegal for a website or app to be inaccessible to those with > disabilities (in the public sector at least) [3]. For JavaFX to be a > good contender in this respect, especially to be highly regarded in > general by accessibility designer and developer communities, I think > it would be beneficial for more prominence to be given to making sure > the JavaFX accessibility APIs and tools continue to be in excellent > shape and receive all the due diligence that this endeavour needs. Of > course, these efforts also need to include creating and maintaining a > comprehensive Java FX Accessibility Guide for Developers and Users. Is > Gluon perhaps already contributing to efforts in this area? Are there > ways in which I can contribute towards these? > > Looking forward to getting feedback from the community on these points. > > [1] < > https://www.reddit.com/r/java/comments/auczwq/official_javafx_11_documentation/ > > > [2] >, > > [3] > > Best regards > > Glen Johnson > > LinkedIn: https://www.linkedin.com/in/glenjohnsonsofteng/ > From nlisker at gmail.com Wed Apr 10 10:01:10 2019 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Apr 2019 13:01:10 +0300 Subject: Emissive component for PhongMaterial Message-ID: Hi Johan/Kevin, Iv'e submitted an issue for adding an emissive component to PhongMaterial [1]. This component is the single-color counterpart of the self-illumination map. It functions the same way as diffuse color is to diffuse map and specular color is to specular map. Emissive colors are used to simulate an object giving off light since they do not interact with external lighting. Implementation will consist of simple changes to both 3D rendering pipelines. Please evaluate, Nir [1] https://bugs.openjdk.java.net/browse/JDK-8221720 From kevin.rushforth at oracle.com Wed Apr 10 10:54:35 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Apr 2019 03:54:35 -0700 Subject: Emissive component for PhongMaterial In-Reply-To: References: Message-ID: <20c7261b-b06a-6029-68d4-e179d923c60a@oracle.com> Hi Nir, It seems like a straight-forward addition. On the one hand, an application can use the self-illumination map to accomplish the same thing. However, a separate emissive color does allow changing it without creating a new 1x1 image each time, and makes it possible to combine a self-illumination map with a modulating emissive color without combining the two in the application, so I can see it being a nice convenience. Presuming there is no measurable performance hit, this seems fine to me. -- Kevin On 4/10/2019 3:01 AM, Nir Lisker wrote: > Hi Johan/Kevin, > > Iv'e submitted an issue for adding an emissive component to PhongMaterial > [1]. > This component is the single-color counterpart of the self-illumination > map. It functions the same way as diffuse color is to diffuse map and > specular color is to specular map. > Emissive colors are used to simulate an object giving off light since they > do not interact with external lighting. > > Implementation will consist of simple changes to both 3D rendering > pipelines. > > Please evaluate, > Nir > > [1] https://bugs.openjdk.java.net/browse/JDK-8221720 From mp at jugs.org Wed Apr 10 12:10:02 2019 From: mp at jugs.org (Michael Paus) Date: Wed, 10 Apr 2019 14:10:02 +0200 Subject: JavaFX and eGPUs Message-ID: Hi, I have a question which may be of interest to others too. The question is: Does JavaFX support the use of an eGPU in general and with a Mac (Thunderbolt 3, Mojave) in particular? The question is relevant because not all software can make use of an eGPU and JavaFX in particular does not support all graphics hardware. Michael [1] https://support.apple.com/en-us/HT208544 From nlisker at gmail.com Sat Apr 13 17:07:50 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 13 Apr 2019 20:07:50 +0300 Subject: Emissive component for PhongMaterial In-Reply-To: <20c7261b-b06a-6029-68d4-e179d923c60a@oracle.com> References: <20c7261b-b06a-6029-68d4-e179d923c60a@oracle.com> Message-ID: This might not be as simple as I thought. Even though adding the self-illumination color naively works, I suspect I need to add new blend modes for the combinations of the self-illumination color and the map. That is, in D3DPhongShader.h, 'SelfIlllumTotal = 2' should be replaced with an enum and get the same treatment the specular component gets. This means the number of pixelShaders doubles and many blending combinations (the ShaderFunction functions) are added, which need to be generated via the build.gradle file. Is this correct? On Wed, Apr 10, 2019 at 1:54 PM Kevin Rushforth wrote: > Hi Nir, > > It seems like a straight-forward addition. On the one hand, an > application can use the self-illumination map to accomplish the same > thing. However, a separate emissive color does allow changing it without > creating a new 1x1 image each time, and makes it possible to combine a > self-illumination map with a modulating emissive color without combining > the two in the application, so I can see it being a nice convenience. > Presuming there is no measurable performance hit, this seems fine to me. > > -- Kevin > > > On 4/10/2019 3:01 AM, Nir Lisker wrote: > > Hi Johan/Kevin, > > > > Iv'e submitted an issue for adding an emissive component to PhongMaterial > > [1]. > > This component is the single-color counterpart of the self-illumination > > map. It functions the same way as diffuse color is to diffuse map and > > specular color is to specular map. > > Emissive colors are used to simulate an object giving off light since > they > > do not interact with external lighting. > > > > Implementation will consist of simple changes to both 3D rendering > > pipelines. > > > > Please evaluate, > > Nir > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8221720 > > From kevin.rushforth at oracle.com Mon Apr 15 12:36:45 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Apr 2019 05:36:45 -0700 Subject: Emissive component for PhongMaterial In-Reply-To: References: <20c7261b-b06a-6029-68d4-e179d923c60a@oracle.com> Message-ID: <03cef29b-c8bf-22c8-492d-29ca37d30821@oracle.com> A doubling of the number of shaders was what I was hoping you could avoid (else I question the value proposition of doing this). I haven't looked at the logic recently, but my thought when I initially replied was that you could use the "self-illum" shaders if either the self-illum map was non-null or the new emissive component was non-zero. You would probably need to pass in a pre-computed map of all 0s in the case where emissive is used, but self-illum map is not. -- Kevin On 4/13/2019 10:07 AM, Nir Lisker wrote: > This might not be as simple as I thought. Even though adding the > self-illumination color naively works, I suspect I need to add new > blend modes for the combinations of the self-illumination color and > the map. That is, in?D3DPhongShader.h, 'SelfIlllumTotal = 2' should be > replaced with an enum and get the same treatment the specular > component gets. This means the number of pixelShaders doubles and many > blending combinations (the ShaderFunction functions) are added, which > need to be generated via the build.gradle file. > > Is this correct? > > On Wed, Apr 10, 2019 at 1:54 PM Kevin Rushforth > > wrote: > > Hi Nir, > > It seems like a straight-forward addition. On the one hand, an > application can use the self-illumination map to accomplish the same > thing. However, a separate emissive color does allow changing it > without > creating a new 1x1 image each time, and makes it possible to > combine a > self-illumination map with a modulating emissive color without > combining > the two in the application, so I can see it being a nice convenience. > Presuming there is no measurable performance hit, this seems fine > to me. > > -- Kevin > > > On 4/10/2019 3:01 AM, Nir Lisker wrote: > > Hi Johan/Kevin, > > > > Iv'e submitted an issue for adding an emissive component to > PhongMaterial > > [1]. > > This component is the single-color counterpart of the > self-illumination > > map. It functions the same way as diffuse color is to diffuse > map and > > specular color is to specular map. > > Emissive colors are used to simulate an object giving off light > since they > > do not interact with external lighting. > > > > Implementation will consist of simple changes to both 3D rendering > > pipelines. > > > > Please evaluate, > > Nir > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8221720 > From nlisker at gmail.com Fri Apr 19 04:54:38 2019 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 19 Apr 2019 07:54:38 +0300 Subject: JDK-8222258: Add exclusion scope for LightBase Message-ID: 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 From kevin.rushforth at oracle.com Sat Apr 27 19:08:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 27 Apr 2019 12:08:50 -0700 Subject: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: Message-ID: 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 From nlisker at gmail.com Sat Apr 27 20:23:47 2019 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 27 Apr 2019 23:23:47 +0300 Subject: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: Message-ID: 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? On Sat, Apr 27, 2019 at 10:09 PM Kevin Rushforth 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 > > From kevin.rushforth at oracle.com Mon Apr 29 12:53:12 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Apr 2019 05:53:12 -0700 Subject: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: Message-ID: <53694f4b-7972-bb95-dd14-71a61c94d68b@oracle.com> 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 > > 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 > From nlisker at gmail.com Mon Apr 29 18:29:20 2019 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 29 Apr 2019 21:29:20 +0300 Subject: Emissive component for PhongMaterial In-Reply-To: <03cef29b-c8bf-22c8-492d-29ca37d30821@oracle.com> References: <20c7261b-b06a-6029-68d4-e179d923c60a@oracle.com> <03cef29b-c8bf-22c8-492d-29ca37d30821@oracle.com> Message-ID: After some testing, I'm not sure I completely understand the need for a self-illum color-specific shaders. The visual results of combining diffuse, specular and self-illum colors seem fine with and without a self-illum map. How would a new shader affect this? - Nir On Mon, Apr 15, 2019 at 3:36 PM Kevin Rushforth wrote: > A doubling of the number of shaders was what I was hoping you could avoid > (else I question the value proposition of doing this). I haven't looked at > the logic recently, but my thought when I initially replied was that you > could use the "self-illum" shaders if either the self-illum map was > non-null or the new emissive component was non-zero. You would probably > need to pass in a pre-computed map of all 0s in the case where emissive is > used, but self-illum map is not. > > -- Kevin > > > On 4/13/2019 10:07 AM, Nir Lisker wrote: > > This might not be as simple as I thought. Even though adding the > self-illumination color naively works, I suspect I need to add new blend > modes for the combinations of the self-illumination color and the map. That > is, in D3DPhongShader.h, 'SelfIlllumTotal = 2' should be replaced with an > enum and get the same treatment the specular component gets. This means the > number of pixelShaders doubles and many blending combinations (the > ShaderFunction functions) are added, which need to be generated via the > build.gradle file. > > Is this correct? > > On Wed, Apr 10, 2019 at 1:54 PM Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Hi Nir, >> >> It seems like a straight-forward addition. On the one hand, an >> application can use the self-illumination map to accomplish the same >> thing. However, a separate emissive color does allow changing it without >> creating a new 1x1 image each time, and makes it possible to combine a >> self-illumination map with a modulating emissive color without combining >> the two in the application, so I can see it being a nice convenience. >> Presuming there is no measurable performance hit, this seems fine to me. >> >> -- Kevin >> >> >> On 4/10/2019 3:01 AM, Nir Lisker wrote: >> > Hi Johan/Kevin, >> > >> > Iv'e submitted an issue for adding an emissive component to >> PhongMaterial >> > [1]. >> > This component is the single-color counterpart of the self-illumination >> > map. It functions the same way as diffuse color is to diffuse map and >> > specular color is to specular map. >> > Emissive colors are used to simulate an object giving off light since >> they >> > do not interact with external lighting. >> > >> > Implementation will consist of simple changes to both 3D rendering >> > pipelines. >> > >> > Please evaluate, >> > Nir >> > >> > [1] https://bugs.openjdk.java.net/browse/JDK-8221720 >> >> > From nlisker at gmail.com Tue Apr 30 02:43:34 2019 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 30 Apr 2019 05:43:34 +0300 Subject: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: <53694f4b-7972-bb95-dd14-71a61c94d68b@oracle.com> References: <53694f4b-7972-bb95-dd14-71a61c94d68b@oracle.com> Message-ID: 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 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> 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 >> >> > From kevin.rushforth at oracle.com Tue Apr 30 12:18:25 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Apr 2019 05:18:25 -0700 Subject: JDK-8222258: Add exclusion scope for LightBase In-Reply-To: References: <53694f4b-7972-bb95-dd14-71a61c94d68b@oracle.com> Message-ID: 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 > > 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 >> > >> 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 >> >