Depends on whether it is usable from SceneBuilder and FXML, and the following: - We must *not* expose a ReadOnly property for these properties (and I don't think we do) - The FXML changes must be backwards compatible (they should be but we need to verify) - The SceneBuilder can do something reasonable as is (not sure).
Richard On Oct 4, 2013, at 1:08 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > Certainly for divisions there is no reason to keep them immutable. For > fixedEyeAtCameraZero, I don't think the reasons for keeping it immutable are > compelling. > > Making either change in FX 8 is a different matter, though, given how late we > are. The implementation assumes immutability and we would need to change it, > implement it, test it, and then fix any bugs as a result. Seems like we could > add mutability in a subsequent release. > > -- Kevin > > > Richard Bair wrote: >> >> I would turn that around and say that unless there is a compelling reason >> for something to be immutable, it should be mutable. Mutability is important >> for tools as well as for FXML as well as for developers. >> >> Immutable state is awesome for thread-safety or any type of concurrency. But >> these types of classes are not of that nature, they're UI only classes, and >> as such their state should be mutable (and like all mutable state in FX, the >> range of possible values should not be hindered by the evil "unbind" >> pattern). >> >> Richard >> >> On Oct 4, 2013, at 12:46 PM, Kevin Rushforth <kevin.rushfo...@oracle.com> >> wrote: >> >> >>> Yes, that pretty much captures the thinking behind it. >>> >>> My thought is that there is no real reason that subdivisions need to be >>> immutable, although I wouldn't want to change it at this late date for FX 8 >>> unless it is needed for FXML support. >>> >>> The fixedEyeAtCameraZero mode is not something I think should be mutable, >>> since the camera behaves fairly differently in each mode. Having said that, >>> there is no reason it couldn't be made mutable in a subsequent release if >>> there was a good reason to do so. >>> >>> -- Kevin >>> >>> >>> Chien Yang wrote: >>> >>>> We did discuss making divisions in the predefined 3D shapes mutable in >>>> earlier meeting. However we decided against it since it is a heavy weight >>>> operation as the supporting mesh will has to be regenerated. I believe the >>>> constructor with the divisions argument will not have much use in the >>>> future when we move away from mesh implementation of our predefined 3D >>>> shapes. >>>> >>>> The fixedEyeAtCameraZero flag in PerspectiveCamera is a setup flag to the >>>> camera and once set it shouldn't be changed. The perspective projection >>>> matrix is constructed differently depending on the flag. In the default >>>> mode, JavaFX controls the eye to achieve a projection plane at Z=0 so that >>>> simple adding of 3D shapes into a 2D scene looks intuitive. The other >>>> mode, where eye is fixed a camera zero, is well suitable for movable >>>> camera in the 3d space. >>>> >>>> - Chien >>>> >>>> On 10/4/2013 9:28 AM, Richard Bair wrote: >>>> >>>>> Why are they not? It isn't immediately obvious to me why these are not >>>>> mutable? I was reading https://javafx-jira.kenai.com/browse/RT-29577 and >>>>> this struck me as odd. >>>>> >>>>> Richard >>>>> >> >>
