Re: Focus Traversal API for JDK 9
Hi Jonathan, just a few thoughts about the API. When I was adding some of the functionality to traversal, I could not touch the public API. All we had there was the impl_ method for adding TraversalEngine. This means there is some functionality that IMO should have been directly in the scenegraph. First of all, the TraversalEngine serves for 2 different purposes: 1) overriding traversal algorithm for the given subtree 2) adding listener to the subtree. I think only the #1 should be really part of the TraversalEngine. It would be better to register listeners directly on the scene/parent. This would simplify the code as currently there are engines that are really just a containers for listeners and they need to be special-cased. The setOverriddenFocusTraversability/ isParentTraversable is there just for Toggle button traversability ( RT-36659). I don't think this should be part of the public API. This basically switches off the traversability of unselected nodes that are part of a Toggle group, so that only the selected one can be traversed to. The ParentTraversalEngine is misused there just mark the node has overridden traversability. I'm not sure how to replace it though. Too bad that Toggle/ToggleGroup is in control and traversal engine does not know about it, so it cannot check for it. This might be possibly marked by a property (?) directly on the node? It would be kind-of a property intended to be used by controls and not by the user, as the user already has his ways to control the focus. Anybody has a better idea here? Also, TopMostTraversalEngine probably shouldn't be exposed, unless there's public Scene property for it. This would allow to change the default algorithm for the Scene (one that can be then accessed in TraversalContext). The constructor for this is missing (still package-private) however. If you want this functionality, you should probably publish also (Sub)SceneTraversalEngine. If not, TopMostTraversalEngine is useless and may stay in the private API space. Cheers, -Martin On 2.10.2015 03:38, Jonathan Giles wrote: Hi folks. I'm continuing along with working on a few small API additions for JDK 9 to smooth off some of the rough edges due to Jigsaw modularity. Today there is a relatively big API to discuss - focus traversal. In summary, my plan is to essentially bring forward the focus traversal API out of com.sun.javafx.scene.traversal and move it to javafx.scene.traversal. I have done that on my machine, and along with a few cleanups to reduce the API surface area and to clarify some generic class names, it is ready for review. This isn't to say it is final, or even guaranteed to go in to JDK 9, but I wanted to get your thoughts on it so that we can move forward with the javadoc effort, etc. The JavaDoc that you see presently is unchanged from what was there previously, so a major task still to do is to fully document the new API. If it proves contentious, the likely plan would be to return to this again after JavaOne, and if things can't be resolved it might not make it into JDK 9. I've uploaded the latest javadocs for this API to my website, which you can see here: http://jonathangiles.net/javafx/jdk9/traversal/ Any thoughts you have would be welcome! Thanks, -- Jonathan
Re: Understanding Layout
Hi Scott,
On 18.12.2014 22:49, Scott Palmer wrote:
Short Version:
Is there good documentation on how JavaFX performs layout? (Not specific
layouts, but layout in general.)
Not an official documentation I'm afraid (at least I don't know of any),
just the javadoc and a few blog posts:
Amy Fowler made some short introduction about layouts here:
https://amyfowlersblog.wordpress.com/2011/06/02/javafx2-0-layout-a-class-tour/
I tried to explain some parts of the layout process that were confusing
people from time to time (based on the JIRA issues that were reported to
me):
https://blogs.oracle.com/jfxprg/entry/the_peculiarities_of_javafx_layout
(I'm sorry I never got to make part 2 :-( ).
Long Version:
I was looking into a layout issue in ControlsFX (BreadCrumbBar width is
reported incorrectly and it doesn't behave when right-aligned).
What I found is that Parent and SkinBase assume that layout has already
occurred on child nodes when computing the preferred width/height. The
JavaDocs indicate this is a known assumption:
* Calculates the preferred width of this {@code SkinBase}. The default
* implementation calculates this width as the width of the area
occupied
* by its managed children when they are positioned at their
* current positions at their preferred widths.
Parent.computePrefWidth(double height) javadocs contain the exact same
comment.
Note however that the Region class documents Region.computePrefWidth(double
height) differently. It simply states:
* Computes the preferred width of this region for the given height.
* Region subclasses should override this method to return an
appropriate
* value based on their content and layout strategy. If the subclass
* doesn't have a VERTICAL content bias, then the height parameter can
be
* ignored.
Node.prefWidth(double height), which is what
Control.computePrefWidth(double height) delegates to if there is no
SkinBase, clearly states:
Returns the node's preferred width for use in layout calculations.
It's the for use in layout calculations part, combined with the fact that
prefWidth relies on the layout having already happened, that confuses me.
Clearly layout is working in most cases, so this must all work out in the
general case. But as I understand it layout happens top-down, so
constraints imposed by the parent container must be accounted for when
positioning and sizing the children. That implies that the child nodes are
not yet laid out when their preferred size is queried.
I fixed the issues I was having with BreadCrumbBar by overriding the
implementation of computePrefWidth(double height) with one that does not
care about the current X position of the child Nodes. It still relies on
the layout bounds via Node.prefWidth(double height), and duplicates some of
the calculations that an actual layout will do, but it worked to solve the
problems of right-aligned layout and a widthProperty that was clearly lying.
I feel like I am missing something fundamental about how Layout works
though.
Is there documentation that explains the general layout algorithm and how
to make sense of the apparent circular dependency?
The way it should work is that pref* min* max* methods
should be able to compute the layout without the layout actually
happening. This is basically a kind-of 2-pass top-down layout:
take a root (or any other parent in a tree) you want to layout. First,
the computation of size hints happens (and might be traversing down the
tree).
After this stage, you know the size hints of the root's children, but no
layout happened yet.
Now the layout happens and the children are given their sizes (which
might not be equal to pref size), the layout is done recursively on the
children (now they know their final size they have all the information).
Theoretically, you could even cache the size hints in your skins (until
some of their prerequisites change) and use them at any stage of the
layout pass, even as the parent's sizes change during the layout.
This approach also means that size hints cannot depend on their
ancestor's size (which is something many people tried to do).
But it seems you already understand all this well.
Now the confusing parts:
* Some default implementation look like they rely on the layout, but
this is actually because they have no layout by default. Or more
commonly, the layout does just the resize, not movement. This means we
can use layout bound's x, y already at compute* methods as this is
something not managed by Parent and may be set through relocate()
explicitly by the developer. I see SkinBase does actually moves the
children by default (to contentX, contentY) and yet still uses layout
bounds in compute* methods. This might lead to a bug in certain cases
IMO, but usually would work as the position does not change. Maybe some
child's margin change could break this, I would have to play with it to
find out.
Probably one JIRA task here
Re: Focus Traversal Engine
Hi Alex, unfortunately, there's none. The simplest way would be to use ParentTraversalEngine with the risk that you will have to update the code once (and if) the traversal engine goes public. You can never get the 100% correct traversal with event filters as the first node that will be traversed will get picked by some outer traversal engine and only then you can start with your traversal. It's possible to workaround this by placing your preferred first node as the first focusable node in your control's tree and do the same for your preferred last node (for Shift+TAB traversal). The other difficulty event filters have is that you will disable internal traversal of embedded control too, so this is rather something that can be used when you want to handle all the traversable nodes inside your control. Hope it helps, -Martin On 24.11.2014 16:50, Casall, Alexander wrote: Hi, is there an elegant way to change the focus traversal order without using Private APIs (TraversalEngine) or creating an own mechanism using EventFilters? Cheers Alex
hg: openjfx/8u-dev/rt: Follow-up fix for RT-38418 - copy paste error when splitting the line length.
Changeset: 27e5fd37a940 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-18 08:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27e5fd37a940 Follow-up fix for RT-38418 - copy paste error when splitting the line length. ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
hg: openjfx/8u-dev/rt: RT-38418 Dashed border with width is broken
Changeset: f73646deab84 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-17 09:31 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f73646deab84 RT-38418 Dashed border with width is broken RT-38493 [Region] After RT-38297, rectangular Region borders are drawn incorrectly Reviewed by: flar ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java
hg: openjfx/8u-dev/rt: RT-38667 [SpltPane] Cannot set divider position in multiple splitpanes at once under certain conditions
Changeset: 26b2ed1d5d5b Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-17 09:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26b2ed1d5d5b RT-38667 [SpltPane] Cannot set divider position in multiple splitpanes at once under certain conditions Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java ! modules/controls/src/test/java/javafx/scene/control/SplitPaneTest.java
hg: openjfx/8u-dev/rt: [ComboBox] Popup does not respond to visibleRowCountProperty after it was shown for the first time
Changeset: 3d4cd94afd1c Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-16 08:26 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/3d4cd94afd1c [ComboBox] Popup does not respond to visibleRowCountProperty after it was shown for the first time Reviewed by: jgiles, snorthov ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java
hg: openjfx/8u-dev/rt: RT-38656 BorderStroke constructor doesn't respect widths
Changeset: 97e4b6fa0e98 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-16 08:45 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/97e4b6fa0e98 RT-38656 BorderStroke constructor doesn't respect widths ! modules/graphics/src/main/java/javafx/scene/layout/BorderStroke.java
hg: openjfx/8u-dev/rt: RT-38654 A ListView control's items do not refresh when placed inside a SubScene node.
Changeset: 787e23c568a5 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-16 09:57 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/787e23c568a5 RT-38654 A ListView control's items do not refresh when placed inside a SubScene node. ! modules/graphics/src/main/java/javafx/scene/Node.java
hg: openjfx/8u-dev/rt: RT-38458 [Charts, Axis] TickMark's textVisible property is ignored
Changeset: 522fe51196c8 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-12 09:20 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/522fe51196c8 RT-38458 [Charts, Axis] TickMark's textVisible property is ignored follow-up fix Reviewed by: jgiles, kcr ! modules/controls/src/main/java/javafx/scene/chart/Axis.java
hg: openjfx/8u-dev/rt: RT-38582 [Transform] transform(Bounds) and inverseTransform(Bounds) produce incorrect results
Changeset: 726b5622b633 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-12 09:34 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/726b5622b633 RT-38582 [Transform] transform(Bounds) and inverseTransform(Bounds) produce incorrect results Reviewed by: kcr, flar + modules/graphics/src/main/java/com/sun/javafx/geometry/BoundsUtils.java ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/transform/Transform.java ! modules/graphics/src/test/java/javafx/scene/transform/TransformOperationsTest.java
Re: Does JavaFX lack a public Property.getObservable() method?
Hi Randahl, why don't you use bidirectional binding for this purpose? -Martin On 09/12/2014 01:04 PM, Randahl Fink Isaksen wrote: I have noticed the lack of a getObservable() method of the property class, and I have come across a use case which might justify such a method, so I would like to discuss whether posting a new Jira issue for this is justified. I have implemented a simple toggle button with two states, on and off. The toggle button has a SimpleBooleanProperty value, and when the user switches the toggle button the value is negated. Now, in some cases I would like to bind the valueProperty to some observable boolean in my app, so that whenever that observable boolean is true, the button reflects that by switching to on. However, the problem is that if I bind the SimpleObjectProperty value to an observable boolean value, and then click the button to toggle it, a JavaFX exception tells me that I cannot negate the boolean value, since it is now bound. In such cases, I think it makes sense to have my toggle button change the state of the value it is bound to instead. But since the SimpleBooleanProperty does not have a getObservable() method, I have no way of accessing the value observed. Does this justify adding a public getObservable method to class Property? Yours Randahl
[8u40] Review Request: RT-38582 [Transform] transform(Bounds) and inverseTransform(Bounds) produce incorrect results
Hi Jim, Kevin, please review https://javafx-jira.kenai.com/browse/RT-38582 http://cr.openjdk.java.net/~msladecek/rt-38582/webrev.00/ Thanks, -Martin
hg: openjfx/8u-dev/rt: RT-38288 [DatePicker] Does not change to new selected value if modal window is shown in DatePicker-action
Changeset: 965623d2f60c Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 08:38 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/965623d2f60c RT-38288 [DatePicker] Does not change to new selected value if modal window is shown in DatePicker-action Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxListViewSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerSkin.java ! modules/controls/src/main/java/javafx/scene/control/ColorPicker.java ! modules/controls/src/main/java/javafx/scene/control/ComboBoxBase.java ! modules/controls/src/test/java/javafx/scene/control/ComboBoxTest.java
hg: openjfx/8u-dev/rt: RT-38448 [TextArea] Text scrolled and initial position of scrollbar moved from top (8u20) to bottom (8u40)
Changeset: 0332535f0cb2 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 09:01 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0332535f0cb2 RT-38448 [TextArea] Text scrolled and initial position of scrollbar moved from top (8u20) to bottom (8u40) Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/control/TextFormatter.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java
hg: openjfx/8u-dev/rt: RT-38490 [TabPane] The tab disappeared after the index changed
Changeset: ac98aaa7adc6 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 09:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ac98aaa7adc6 RT-38490 [TabPane] The tab disappeared after the index changed Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
hg: openjfx/8u-dev/rt: RT-38507 [Regression] Animation in Progress Bar is out of place
Changeset: 556c2af030c1 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 09:05 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/556c2af030c1 RT-38507 [Regression] Animation in Progress Bar is out of place Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressBarSkin.java
hg: openjfx/8u-dev/rt: RT-37715 [Chart] HelloStackedAreaChart has a missing symbol
Changeset: d94bd6d65452 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 09:06 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d94bd6d65452 RT-37715 [Chart] HelloStackedAreaChart has a missing symbol Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java
hg: openjfx/8u-dev/rt: RT-38458 [Charts] Strange for loop in javafx.scence.chart.Axis
Changeset: f5a981fe054b Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 09:07 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f5a981fe054b RT-38458 [Charts] Strange for loop in javafx.scence.chart.Axis Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/Axis.java
hg: openjfx/8u-dev/rt: TabPaneSkin: reverted accidental change in imports (from c98aaa7adc6)
Changeset: 0f7bad358c85 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-09 15:57 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0f7bad358c85 TabPaneSkin: reverted accidental change in imports (from c98aaa7adc6) ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TabPaneSkin.java
hg: openjfx/8u-dev/rt: RT-38407 RTL orientation, ComboBox popup is not aligned with the ComboBox.
Changeset: 77ee61dc5811 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-03 09:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/77ee61dc5811 RT-38407 RTL orientation, ComboBox popup is not aligned with the ComboBox. Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ComboBoxPopupControl.java
hg: openjfx/8u-dev/rt: RT-37879 ArrayindexoutOfBoundsException from Parent.updateCachedBounds
Changeset: eb251121a360 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-03 14:55 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/eb251121a360 RT-37879 ArrayindexoutOfBoundsException from Parent.updateCachedBounds ! modules/graphics/src/main/java/javafx/scene/Parent.java
hg: openjfx/8u-dev/rt: RT-38408 RTL orientation, ChoiceBox popup is not aligned with the ChoiceBox.
Changeset: 31335892f770 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-01 11:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/31335892f770 RT-38408 RTL orientation, ChoiceBox popup is not aligned with the ChoiceBox. ! modules/graphics/src/main/java/com/sun/javafx/Utils.java
hg: openjfx/8u-dev/rt: RT-38465 [SplitPane] Pixels cut off when GridPane inside SplitPane
Changeset: 481f8d61b1cd Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-09-01 15:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/481f8d61b1cd RT-38465 [SplitPane] Pixels cut off when GridPane inside SplitPane ! modules/graphics/src/main/java/javafx/scene/layout/GridPane.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java
Re: GridPane percent width.
Robert, with odd numbers, the space might be distributed unevenly (by a pixel), this is due to snapToPixel property of the GridPane. Setting it to false might lead to even distribution, but the border might be blurred. Anyway, if you are not sure if it is a bug, I would suggest you file a JIRA issue with some sample to reproduce the issue: https://javafx-jira.kenai.com. See also https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report Thanks, -Martin On 27.8.2014 17:16, Robert Fisher wrote: Hi all, I have a grid pane with 2 columns, with one child in each. The columns are each assigned 50% width. I find that for some sizes (maybe when the total width is an odd number of pixels), the right-most column of pixels of the right child are cut off and not rendered. Is this intentional? Or a known bug? Cheers, Rob
hg: openjfx/8u-dev/rt: RT-37329 [SplitPane] Cannot set divider position in multiple splitpanes at once on button setOnAction()
Changeset: 0e57456b1327 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-26 11:04 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0e57456b1327 RT-37329 [SplitPane] Cannot set divider position in multiple splitpanes at once on button setOnAction() Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/SplitPaneSkin.java
hg: openjfx/8u-dev/rt: RT-38165 A bound value cannot be set exception should print the name of the property that is causing the problem
Changeset: 44cac66ba3ed Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-26 14:23 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/44cac66ba3ed RT-38165 A bound value cannot be set exception should print the name of the property that is causing the problem ! modules/base/src/main/java/javafx/beans/property/BooleanPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/DoublePropertyBase.java ! modules/base/src/main/java/javafx/beans/property/FloatPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/IntegerPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/ListPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/LongPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/MapPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/ObjectPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/SetPropertyBase.java ! modules/base/src/main/java/javafx/beans/property/StringPropertyBase.java
API review: RT-38292,[SortedList] should provide a sort() method
Hello, based on the request in the JIRA, I propose to add SortedList.sort() and FilteredList.filter() methods that trigger the sorting or filtering operation in case the data on the last sort were outdated and it is not possible to use FXCollections.observableList(List, Callback) wrapper for some reason. More details in the JIRA: https://javafx-jira.kenai.com/browse/RT-38292 Thanks, -Martin
hg: openjfx/8u-dev/rt: RT-38329 [LineChart] Calling setForceZeroInRange doesn't update LineChart
Changeset: 191aab1d374d Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-22 10:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/191aab1d374d RT-38329 [LineChart] Calling setForceZeroInRange doesn't update LineChart Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/Axis.java ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java ! modules/controls/src/main/java/javafx/scene/chart/ValueAxis.java
hg: openjfx/8u-dev/rt: RT-38189 CategoryAxis.tickLabelRotation doesn't work properly with autoRanging
Changeset: 4c2f04e9e358 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-22 10:15 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/4c2f04e9e358 RT-38189 CategoryAxis.tickLabelRotation doesn't work properly with autoRanging Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/Axis.java
hg: openjfx/8u-dev/rt: RT-38297 Region is not properly clipped when defined by a shape
Changeset: ba193bd5c30a Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-22 10:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ba193bd5c30a RT-38297 Region is not properly clipped when defined by a shape Reviewed by: flar ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/javafx/scene/layout/Region.java
hg: openjfx/8u-dev/rt: RT-37855 Providing Node.localToWindow()
Changeset: bcd1f1059cc2 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-22 10:25 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/bcd1f1059cc2 RT-37855 Providing Node.localToWindow() Reviewed by: kcr ! modules/graphics/src/main/java/javafx/scene/Node.java
hg: openjfx/8u-dev/rt: RT-38388 [javadoc] Bad HTML in JavaBeanProperty and ReadOnlyJavaBeanProperty classes
Changeset: 7d6c721cfd7f Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-22 11:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7d6c721cfd7f RT-38388 [javadoc] Bad HTML in JavaBeanProperty and ReadOnlyJavaBeanProperty classes ! modules/base/src/main/java/javafx/beans/property/adapter/JavaBeanProperty.java ! modules/base/src/main/java/javafx/beans/property/adapter/ReadOnlyJavaBeanProperty.java
Re: NumberAxis alignment of ticks to multiples of tickUnit
On 08/20/2014 08:38 AM, Adam Granger wrote: So my question to the group is, would you consider including this functionality in the main NumberAxis class? - obviously making it configurable and defaulting to current behaviour. Adam, please file a JIRA issue for that (https://javafx-jira.kenai.com), so your request is not lost. Thanks, -Martin
hg: openjfx/8u-dev/rt: Incorrect method reference fix
Changeset: 59e71e06a1c6 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-21 14:34 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/59e71e06a1c6 Incorrect method reference fix ! modules/base/src/main/java/javafx/collections/transformation/SortedList.java
hg: openjfx/8u-dev/rt: RT-36453 [ColorPicker, Modena] Colorpicker changes size depending on the currently selected color
Changeset: 029bcb15c1e5 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-20 15:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/029bcb15c1e5 RT-36453 [ColorPicker, Modena] Colorpicker changes size depending on the currently selected color Reviewed by: jgiles ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ColorPickerSkin.java
hg: openjfx/8u-dev/rt: RT-38285 [Axis] Y-Axis can not handle big values
Changeset: 9130fc16c129 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-20 15:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9130fc16c129 RT-38285 [Axis] Y-Axis can not handle big values Reviewed by: jgiles ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java
hg: openjfx/8u-dev/rt: RT-38285 [Axis] Y-Axis can not handle big values (cont.): follow-up fix
Changeset: adba413b52d3 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-20 15:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/adba413b52d3 RT-38285 [Axis] Y-Axis can not handle big values (cont.): follow-up fix ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java
hg: openjfx/8u-dev/rt: RT-38285 [Axis] Y-Axis can not handle big values (cont.): follow-up fix
Changeset: 798a93a61616 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-20 15:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/798a93a61616 RT-38285 [Axis] Y-Axis can not handle big values (cont.): follow-up fix ! modules/controls/src/main/java/javafx/scene/chart/NumberAxis.java
hg: openjfx/8u-dev/rt: RT-38344 [Ensemble] Add TextField with formatter sample to Ensemble
Changeset: b5b649ef6d8d Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-19 08:36 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b5b649ef6d8d RT-38344 [Ensemble] Add TextField with formatter sample to Ensemble Reviewed by: kselle ! apps/samples/Ensemble8/src/generated/java/ensemble/generated/Samples.java ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdt ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fdx ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.fnm ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.frq ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.nrm ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.prx ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tii ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/_0.tis ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/listAll.txt ! apps/samples/Ensemble8/src/generated/resources/ensemble/search/index/segments_1 + apps/samples/Ensemble8/src/samples/java/ensemble/samples/controls/text/textformatter/TextFormatterApp.java + apps/samples/Ensemble8/src/samples/resources/ensemble/samples/controls/text/textformatter/preview.png
hg: openjfx/8u-dev/rt: RT-38278 [ScrollPane] minViewport{Height, Width} are taking effect only after changing prefViewport{Height, Width}
Changeset: 36a242b77366
Author:Martin Sladecek martin.slade...@oracle.com
Date: 2014-08-19 08:37 +0200
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/36a242b77366
RT-38278 [ScrollPane] minViewport{Height,Width} are taking effect only after
changing prefViewport{Height,Width}
Reviewed by: jgiles
!
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java
[API] RT-37785 Provide some useful TextInputControl.Formatter implementations
Hello, as RT-14000 (https://javafx-jira.kenai.com/browse/RT-14000) - text formatter for TextInputControl has been pushed recently, it's time to discuss what implementations of Text Formatter should be included in 8u40 release. I added some ideas to (https://javafx-jira.kenai.com/browse/RT-37785), where all the comments should go. Here's some short summary: * StringFormatter for converting between String and arbitrary object using toString and valueOf (or String constructor), which would do similar job as DefaultFormatter in swing. * MaskFormatter (similar to the class of the same name in swing) - it would support String mask, defining own placeholder character, escape character or even defining own map (as a MapCharacter, UnaryOperatorCharacter), where the unary operator for the map either returns null (if not accepted) or the same/modified character if accepted. * A TextFormatter that takes java.text.Format and does the filtering and converting using the Format object. Thanks, -Martin
hg: openjfx/8u-dev/rt: RT-38130 A node remains invisible if clip has been set while it was not visible
Changeset: 83f2a3753ad6 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-19 14:40 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/83f2a3753ad6 RT-38130 A node remains invisible if clip has been set while it was not visible ! modules/graphics/src/main/java/javafx/scene/Node.java
hg: openjfx/8u-dev/rt: RT-38221 [LineChart] Javafx 8 Line Chart does not plot data in order
Changeset: 14219b05f178 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-18 10:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/14219b05f178 RT-38221 [LineChart] Javafx 8 Line Chart does not plot data in order Reviewed by: snothov, kcr ! modules/controls/src/main/java/javafx/scene/chart/LineChart.java
hg: openjfx/8u-dev/rt: RT-14000 Add Formatted TextField control (cont.) : 2 missing classes
Changeset: 13f33b110a99 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-15 07:58 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/13f33b110a99 RT-14000 Add Formatted TextField control (cont.) : 2 missing classes + modules/controls/src/main/java/com/sun/javafx/scene/control/FormatterAccessor.java + modules/controls/src/main/java/javafx/scene/control/TextFormatter.java
hg: openjfx/8u-dev/rt: RT-14000 Add Formatted TextField control
Changeset: 290274db83f7 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-15 07:57 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/290274db83f7 RT-14000 Add Formatted TextField control Reviewed by: kcr, snorthov ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java
hg: openjfx/8u-dev/rt: Reverted unrelated test comitted with RT-38723 fix
Changeset: d92ede143b5e Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-13 10:29 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d92ede143b5e Reverted unrelated test comitted with RT-38723 fix ! modules/base/src/test/java/javafx/util/converter/FloatStringConverterTest.java
hg: openjfx/8u-dev/rt: RT-25980 Add Window setUserData and user data to other non-Node classes
Changeset: 7ec4725320d0 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-12 09:55 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7ec4725320d0 RT-25980 Add Window setUserData and user data to other non-Node classes Reviewed by: kcr, snorthov Contributed by: tom.schi...@bestsolution.at ! modules/controls/src/main/java/javafx/scene/control/ToggleGroup.java ! modules/controls/src/test/java/javafx/scene/control/ToggleGroupTest.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/stage/Window.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java ! modules/graphics/src/test/java/javafx/stage/WindowTest.java
hg: openjfx/8u-dev/rt: RT-33696 RTL orientation, submenu overlaps its parent menu.
Changeset: 42903ea10084 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-12 10:00 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/42903ea10084 RT-33696 RTL orientation, submenu overlaps its parent menu. Reviewed by: snorthov, kcr ! modules/controls/src/main/java/javafx/scene/control/PopupControl.java
hg: openjfx/8u-dev/rt: RT-37824 [Charts] Series: NPE when adding data items multiple times
Changeset: d515c3182f1c Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-30 10:51 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/d515c3182f1c RT-37824 [Charts] Series: NPE when adding data items multiple times Reviewed by: snorthov, jgiles ! modules/controls/src/main/java/javafx/scene/chart/AreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/BarChart.java ! modules/controls/src/main/java/javafx/scene/chart/LineChart.java ! modules/controls/src/main/java/javafx/scene/chart/ScatterChart.java ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java ! modules/controls/src/main/java/javafx/scene/chart/XYChart.java
Re: Skin layoutChildren: when to get bounds of child nodes?
I created some simple diagrams for this blog post:
https://blogs.oracle.com/jfxprg/entry/the_peculiarities_of_javafx_layout
-Martin
On 07/29/2014 03:15 PM, Mikael Grev wrote:
Richard,
Is there a sequence diagram (or similar) where the layout process is described
in detail?
It’s hard to in text get a clear and precise view on how the layout process in
the Node hierarchy is happening.
The sequence diagram would be good to have as a constraint for building layout
panes. Otherwise its easy to time things incorrectly with strange layout
artefacts as a result.
It’s especially important for devs to know which methods are called for the
pre-layout (size measuring) phase and them for the actual layout phase.
Cheers,
Mikael
On 28 Jul 2014, at 07:38, Martin Sladecek martin.slade...@oracle.com wrote:
The super.layoutChildren should size every child of the control (which is
VBox), but not child's children. The control must finish the layout before
children can do theirs. If you need to do layout on some child before that, you
can call .layout() on it. It will do it's layout using it's current size. You
should have all the bounds correct after that call.
But that would not work in your case anyway. You have both childs in a HBox,
which takes care of resizing the children. This means you need to layout the
HBox to get children size and in order to do that, you need HBox to be at it's
final size, which will happen during the VBox layout. So your steps would be:
1) super.layoutChildren() - VBox is resized to Controls content size
2) now the VBox is resized, you can call vbox.layout()
3) now HBox is resized, so call hbox.layout()
4) children are resized. They have correct layout bounds now. But in order to
get correct boundsInParent (but maybe you really need layout bounds?), you need
to call .layout() on children too.
Even if you do all these steps, calling setPrefWidth() on child2 marks the
whole tree dirty again. Because HBox needs to resize child2 using it's new
PrefWidth. This also means, HBox prefwidth will be different, so it's parent
(VBox) must do the same. Ditto with the control. Also, the HBox (VBox, control)
may not have enough size to resize child2 to it's pref width, so child1 might
be shrinked as a result, which breaks your invariant. You are basically
changing the input for HBox's layout (child2.pref size) based on it's output
(child1 size), which makes this a loop.
So in order to really make this work, you need to manage the child nodes
directly and compute your layout by yourself. This can be done either by using
your own subclass of Pane and overriding it's layoutChildren. Or if you want to
do everything in Skin's layoutChildren, you can make the children unmanaged,
but then it doesn't really matter where they are in the scenegraph, HBox won't
be managing them.
Hope this helps!
-Martin
On 25.7.2014 18:56, Richard Bair wrote:
Hmmm. The first question I have is whether boundsInParent is really what you
want to use, vs. layout bounds. But assuming it is what you want, why are the
bounds zero? This is during the layout pass, which is the right place to be
doing what you’re doing. The super layoutChildren call will size everything
based on the contentX, contentY, contentWidth, contentHeight
(http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/4b8d06211312/modules/controls/src/main/java/javafx/scene/control/SkinBase.java).
Is it possible that the parent itself is size 0? boundsInParent should always
be invalidated automatically whenever the width/height/transforms/etc changes.
If not that is definitely a bug (that you can write a simple test case for to
prove).
But my first guess is maybe the parent is size 0 as well, due to something else
(maybe the pref size of the control is 0 to start with or something…)
Richard
On Jul 24, 2014, at 3:34 AM, Werner Lehmann lehm...@media-interactive.de
wrote:
Hi,
inside a control skin I have the following code pattern:
protected void layoutChildren(...)
{
super.layoutChildren(...);
Node child1 = ...
Bounds bip = child1.getBoundsInParent();
if (!animating) {
Node child2 = ...
child2.setTranslateX(bip.getMinX();
child2.setPrefWidth(bip.getWidth());
}
}
The skin scene graph looks roughly like this:
VBox
HBox { ..., child1, ...}
child2
...
Everything is layouted just fine but I want to adjust child2.translateX and
prefWidth based child1 bounds. This does not work initially because
boundsInParent returns zero components leading to incorrect initial display of
the control.
Seems as if boundsInParent is not yet updated. I guess I could use a binding
for that but it would conflict with an animation I also have on translateX and
prefWidth.
Maybe there is a better time to make those adjustments on child2?
Rgds
Werner
Re: Skin layoutChildren: when to get bounds of child nodes?
The super.layoutChildren should size every child of the control (which
is VBox), but not child's children. The control must finish the layout
before children can do theirs. If you need to do layout on some child
before that, you can call .layout() on it. It will do it's layout using
it's current size. You should have all the bounds correct after that call.
But that would not work in your case anyway. You have both childs in a
HBox, which takes care of resizing the children. This means you need to
layout the HBox to get children size and in order to do that, you need
HBox to be at it's final size, which will happen during the VBox layout.
So your steps would be:
1) super.layoutChildren() - VBox is resized to Controls content size
2) now the VBox is resized, you can call vbox.layout()
3) now HBox is resized, so call hbox.layout()
4) children are resized. They have correct layout bounds now. But in
order to get correct boundsInParent (but maybe you really need layout
bounds?), you need to call .layout() on children too.
Even if you do all these steps, calling setPrefWidth() on child2 marks
the whole tree dirty again. Because HBox needs to resize child2 using
it's new PrefWidth. This also means, HBox prefwidth will be different,
so it's parent (VBox) must do the same. Ditto with the control. Also,
the HBox (VBox, control) may not have enough size to resize child2 to
it's pref width, so child1 might be shrinked as a result, which breaks
your invariant. You are basically changing the input for HBox's layout
(child2.pref size) based on it's output (child1 size), which makes this
a loop.
So in order to really make this work, you need to manage the child nodes
directly and compute your layout by yourself. This can be done either by
using your own subclass of Pane and overriding it's layoutChildren. Or
if you want to do everything in Skin's layoutChildren, you can make the
children unmanaged, but then it doesn't really matter where they are in
the scenegraph, HBox won't be managing them.
Hope this helps!
-Martin
On 25.7.2014 18:56, Richard Bair wrote:
Hmmm. The first question I have is whether boundsInParent is really what you
want to use, vs. layout bounds. But assuming it is what you want, why are the
bounds zero? This is during the layout pass, which is the right place to be
doing what you’re doing. The super layoutChildren call will size everything
based on the contentX, contentY, contentWidth, contentHeight
(http://hg.openjdk.java.net/openjfx/8u-dev/rt/file/4b8d06211312/modules/controls/src/main/java/javafx/scene/control/SkinBase.java).
Is it possible that the parent itself is size 0? boundsInParent should always
be invalidated automatically whenever the width/height/transforms/etc changes.
If not that is definitely a bug (that you can write a simple test case for to
prove).
But my first guess is maybe the parent is size 0 as well, due to something else
(maybe the pref size of the control is 0 to start with or something…)
Richard
On Jul 24, 2014, at 3:34 AM, Werner Lehmann lehm...@media-interactive.de
wrote:
Hi,
inside a control skin I have the following code pattern:
protected void layoutChildren(...)
{
super.layoutChildren(...);
Node child1 = ...
Bounds bip = child1.getBoundsInParent();
if (!animating) {
Node child2 = ...
child2.setTranslateX(bip.getMinX();
child2.setPrefWidth(bip.getWidth());
}
}
The skin scene graph looks roughly like this:
VBox
HBox { ..., child1, ...}
child2
...
Everything is layouted just fine but I want to adjust child2.translateX and
prefWidth based child1 bounds. This does not work initially because
boundsInParent returns zero components leading to incorrect initial display of
the control.
Seems as if boundsInParent is not yet updated. I guess I could use a binding
for that but it would conflict with an animation I also have on translateX and
prefWidth.
Maybe there is a better time to make those adjustments on child2?
Rgds
Werner
hg: openjfx/8u-dev/rt: RT-35126 [Animation] Combinations of transitions don't work as expected (circle should fade in)
Changeset: e248baa75433 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-23 15:47 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e248baa75433 RT-35126 [Animation] Combinations of transitions don't work as expected (circle should fade in) ! modules/graphics/src/main/java/javafx/animation/SequentialTransition.java ! modules/graphics/src/test/java/javafx/animation/SequentialTransitionPlayTest.java
hg: openjfx/8u-dev/rt: RT-37994 [FXML] ProxyBuilder does not support read-only collections
Changeset: 23c345e7ea20 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-22 07:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/23c345e7ea20 RT-37994 [FXML] ProxyBuilder does not support read-only collections ! modules/fxml/src/main/java/com/sun/javafx/fxml/builder/ProxyBuilder.java + modules/fxml/src/test/java/com/sun/javafx/fxml/builder/ClassWithReadOnlyCollection.java ! modules/fxml/src/test/java/com/sun/javafx/fxml/builder/ProxyBuilderTest.java
hg: openjfx/8u-dev/rt: RT-37926 JavaBeanProperties fixed DescriptorListenerCleaner still causes memory leaks
Changeset: 321b64885bc3 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-15 09:29 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/321b64885bc3 RT-37926 JavaBeanProperties fixed DescriptorListenerCleaner still causes memory leaks Contributed by: marco.schu...@eckert-partner.it ! modules/base/src/main/java/javafx/beans/property/adapter/DescriptorListenerCleaner.java
hg: openjfx/8u-dev/rt: RT-37821 ConcurrentModificationException if an attempt is made to remove an accelerator whilst an accelerator callback is being processed
Changeset: 982a483303a5 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-15 13:02 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/982a483303a5 RT-37821 ConcurrentModificationException if an attempt is made to remove an accelerator whilst an accelerator callback is being processed ! modules/graphics/src/main/java/com/sun/javafx/scene/KeyboardShortcutsHandler.java + modules/graphics/src/test/java/javafx/scene/AcceleratorsTest.java
hg: openjfx/8u-dev/rt: RT-37928 [Monocle/Embedded] exception when using virtual keyboard
Changeset: ce73e967df61 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-15 07:37 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ce73e967df61 RT-37928 [Monocle/Embedded] exception when using virtual keyboard Reviewed by: kselle ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java
hg: openjfx/8u-dev/rt: RT-37407 [ScrollPane, TextArea] Introduce minViewportWidth and minViewportHeight properties
Changeset: 2e66062882e9 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-15 07:42 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2e66062882e9 RT-37407 [ScrollPane, TextArea] Introduce minViewportWidth and minViewportHeight properties Reviewed by: snorthov, kcr ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ScrollPaneSkin.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextAreaSkin.java ! modules/controls/src/main/java/javafx/scene/control/ScrollPane.java
hg: openjfx/8u-dev/rt: RT-37864 MenuBar in SubScene does not work
Changeset: 66696ac8abca Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-11 08:44 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/66696ac8abca RT-37864 MenuBar in SubScene does not work Reviewed by: dgrieve ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/MenuBarSkin.java ! modules/controls/src/test/java/javafx/scene/control/MenuBarTest.java ! modules/graphics/src/main/java/com/sun/javafx/Utils.java ! modules/graphics/src/main/java/com/sun/javafx/scene/SceneUtils.java ! modules/graphics/src/test/java/com/sun/javafx/UtilsTest.java
hg: openjfx/8u-dev/rt: [TEST] fixed failing tests caused by changeset 66696ac8abca (RT-37864 fix)
Changeset: 59ec777e8bf3 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-11 14:28 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/59ec777e8bf3 [TEST] fixed failing tests caused by changeset 66696ac8abca (RT-37864 fix) ! modules/web/src/test/java/javafx/scene/web/ScreenAndWindowTest.java
hg: openjfx/8u-dev/rt: RT-37497 javafx.animation.Animation#impl_finished swallows exceptions
Changeset: 9e28056c8de1 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-07 09:27 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9e28056c8de1 RT-37497 javafx.animation.Animation#impl_finished swallows exceptions ! modules/graphics/src/main/java/javafx/animation/Animation.java
hg: openjfx/8u-dev/rt: RT-37358 [FXMLLoader]: Null builderFactory makes it impossible to load many types of classes
Changeset: 23b4a850e32b Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-07 09:31 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/23b4a850e32b RT-37358 [FXMLLoader]: Null builderFactory makes it impossible to load many types of classes ! modules/fxml/src/main/java/javafx/fxml/FXMLLoader.java
hg: openjfx/8u-dev/rt: RT-37821 ConcurrentModificationException if an attempt is made to remove an accelerator whilst an accelerator callback is being processed
Changeset: dfc51c66d790 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-07 10:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/dfc51c66d790 RT-37821 ConcurrentModificationException if an attempt is made to remove an accelerator whilst an accelerator callback is being processed ! modules/graphics/src/main/java/com/sun/javafx/scene/KeyboardShortcutsHandler.java
8u40 API proposal: ScrollPane's minViewportWidth/minViewportHeight
Hello, I propose to add 2 additional properties to ScrollPane: minViewportHeight and minViewportWidth. They should work the same way as prefViewportWidth/prefViewportHeight, specifying the minimum size for the viewport, not ScrollPane as a whole. JIRA: https://javafx-jira.kenai.com/browse/RT-37407 webrev: http://cr.openjdk.java.net/~msladecek/rt-37407/webrev.00/ Thanks, -Martin
hg: openjfx/8u-dev/rt: RT-37576 “tickLableRotation” property can not work as expected
Changeset: a2afbc47aaea Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-04 10:03 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/a2afbc47aaea RT-37576 âtickLableRotationâ property can not work as expected Reviewed by: dgrieve ! modules/controls/src/main/java/javafx/scene/chart/Axis.java
hg: openjfx/8u-dev/rt: RT-37758 Relax restriction on creating Scene only on FX App thread
Changeset: 1efcff018597 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-03 09:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1efcff018597 RT-37758 Relax restriction on creating Scene only on FX App thread Reviewed by: kcr, anthony, snorthov ! modules/graphics/src/main/java/javafx/scene/Node.java ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/SubScene.java
hg: openjfx/8u-dev/rt: RT-37799 api doc of Task.call incomplete
Changeset: 27b166eab071 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-03 13:29 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/27b166eab071 RT-37799 api doc of Task.call incomplete ! modules/graphics/src/main/java/javafx/concurrent/Task.java
Re: Formatted text field API (RT-14000, RT-30881)
There's a new proposal here: https://javafx-jira.kenai.com/browse/RT-14000
I merged FormattedTextField and content filter to a single Formatter
class, that's now part of the TextInputControl.
-Martin
On 06/11/2014 10:50 AM, Martin Sladecek wrote:
Hello,
I would like to start some discussion about formatted text field API.
The related JIRA issues are RT-14000 (formatted text field) and
RT-30881 (content filter).
The RT-30881 defines a content filter for all text input controls (in
TextInputControl class), like TextField and TextArea. This was
originally implemented by Richard Bair and briefly discussed here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-December/004687.html.
I've tried to build formatted text field on top of that (and made some
changes to the API) since content filtering is something most
formatted text fields will use.
First, the TextInputControl additions:
* contentFilter property of type ObjectPropertyContentFilter
So let's look at the content filter and content change (both nested
classes of TextInputControl):
/**
* Content Filter specifies the filter to be used with {@link
TextInputControl#contentFilterProperty()}.
* It allow user to intercept and modify any change done to the
text content.
* To avoid content that's not valid for the filter, it's possible
to assign a default value supplier for the filter.
* p
* The filter itself is an {@code UnaryOperator} that accepts
{@link javafx.scene.control.TextInputControl.ContentChange} object.
* It should return a {@link
javafx.scene.control.TextInputControl.ContentChange} object that
contains the actual (filtered)
* change. Returning null rejects the change.
* p
* If default value supplier is provided, it is used when the
{@code ContentFilter} is assigned to a {@code TextInputControl}
* and it's current text is invalid. It is expected that the
provided default value is accepted by the filtering operator.
*/
public static class ContentFilter {
/**
* Creates a new filter with the providing filtering operator.
* @param filter the filtering operator
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter) {}
/**
* Creates a new filter with the providing filtering operator
and default value supplier.
* @param filter the filtering operator
* @param defaultValue the default value or null
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter,
SupplierString defaultValue) {}
/**
* The filtering operator of this filter.
* @return the operator
*/
public UnaryOperatorContentChange getFilter() {}
/**
* The default value provider of this filter
* @return the default value provider or null
*/
public SupplierString getDefaultValue() {}
/**
* Chains this filter with a filtering operator. The other
filtering operator is used only if this
* filter's operator rejects the operation. The default value
of the new {@code ContentFilter} is the same
* as of this filter.
* @param other the filtering operator to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(UnaryOperatorContentChange
other) {}
/**
* Chains this filter with a filtering operator of another
{@code ContentFilter}. The other filtering operator is used only if this
* filter's operator rejects the operation. The default value
of the new {@code ContentFilter} is the same
* as of this filter.
* @param other the filter to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(ContentFilter other) {}
}
/**
* Contains the state representing a change in the content for a
* TextInputControl. This object is passed to any registered
* {@code contentFilter} on the TextInputControl whenever the text
* for the TextInputControl is modified.
* p
* This class contains state and convenience methods for
determining what
* change occurred on the control. It also has a reference to the
* TextInputControl itself so that the developer may query any
other
* state on the control. Note that you should never modify the
state
* of the control directly from within the contentFilter handler.
* /p
* p
* The ContentChange is mutable, but not observable. It should
be used
* only for the life of a single change. It is intended that the
* ContentChange will be modified from within the contentFilter.
* /p
*/
public static final class
hg: openjfx/8u-dev/rt: RT-37586 [StackedAreaChart] Display problem with StackedAreaChart when the axis is not displayed
Changeset: c21b1705eb10 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-02 13:12 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c21b1705eb10 RT-37586 [StackedAreaChart] Display problem with StackedAreaChart when the axis is not displayed Reviewed by: dgrieve ! modules/controls/src/main/java/javafx/scene/chart/StackedAreaChart.java
hg: openjfx/8u-dev/rt: RT-37747 Additional app-thread checks should be added (back) after RT-17716
Changeset: 8cc538c3a7f8 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-07-02 13:17 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8cc538c3a7f8 RT-37747 Additional app-thread checks should be added (back) after RT-17716 Reviewed by: kcr, anthony ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/stage/Stage.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java ! modules/graphics/src/test/java/javafx/stage/PopupTest.java
Re: Deserializing javafx.event.EventType
Hi, EventTypes are serializable solely for the purpose of Event serialization (which is serializable because it inherits from java.util.EventObject). When you deserialize Events, the corresponding EventType objects are already initialized, so the EventTypes are correctly mapped. -Martin On 06/28/2014 09:29 AM, Kay McCormick wrote: Hello, I was poking around in javafx event dispatching and I noted the serialization of EventType. I've serialized MouseEvent.ANY to a file and in trying to deserialize it I got the error: java.io.InvalidObjectException: Cannot find event type INPUT (of EVENT) I realize this is because the static fields have not been initialized, but I am wondering what is the intended and proper use of serializing EventType. Is it a requirement that the static fields be initialized prior to deserializing? If so, how can this be ensured? I am not 100% familiar with the details of this. I will review documentation but I'd like to know how this can be used properly. thanks
hg: openjfx/8u-dev/rt: [TEST] RT-37752 Unit test failure in Snapshot1Test after fix for RT-17716
Changeset: 65cabfa41abe Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-30 09:53 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/65cabfa41abe [TEST] RT-37752 Unit test failure in Snapshot1Test after fix for RT-17716 ! tests/system/src/test/java/javafx/scene/Snapshot1Test.java
hg: openjfx/8u-dev/rt: [COMMENT-ONLY] removed obsolete comment after RT-37752 fix
Changeset: 030772161397 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-30 17:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/030772161397 [COMMENT-ONLY] removed obsolete comment after RT-37752 fix ! tests/system/src/test/java/javafx/scene/Snapshot1Test.java
hg: openjfx/8u-dev/rt: RT-17716 Some controls can only be created on the FX application thread
Changeset: 26d0acd8a72e Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-26 09:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/26d0acd8a72e RT-17716 Some controls can only be created on the FX application thread Reviewed by: anthony ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/stage/Window.java ! modules/graphics/src/test/java/javafx/scene/SceneTest.java ! modules/graphics/src/test/java/javafx/stage/PopupTest.java
hg: openjfx/8u-dev/rt: RT-37668 FilteredList reports a size of zero until a Predicate is supplied.
Changeset: c367a3e860f2 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-06-24 15:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c367a3e860f2 RT-37668 FilteredList reports a size of zero until a Predicate is supplied. ! modules/base/src/main/java/javafx/collections/transformation/FilteredList.java ! modules/base/src/test/java/javafx/collections/FilteredListTest.java
Formatted text field API (RT-14000, RT-30881)
Hello,
I would like to start some discussion about formatted text field API.
The related JIRA issues are RT-14000 (formatted text field) and RT-30881
(content filter).
The RT-30881 defines a content filter for all text input controls (in
TextInputControl class), like TextField and TextArea. This was
originally implemented by Richard Bair and briefly discussed here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-December/004687.html.
I've tried to build formatted text field on top of that (and made some
changes to the API) since content filtering is something most formatted
text fields will use.
First, the TextInputControl additions:
* contentFilter property of type ObjectPropertyContentFilter
So let's look at the content filter and content change (both nested
classes of TextInputControl):
/**
* Content Filter specifies the filter to be used with {@link
TextInputControl#contentFilterProperty()}.
* It allow user to intercept and modify any change done to the
text content.
* To avoid content that's not valid for the filter, it's possible
to assign a default value supplier for the filter.
* p
* The filter itself is an {@code UnaryOperator} that accepts
{@link javafx.scene.control.TextInputControl.ContentChange} object.
* It should return a {@link
javafx.scene.control.TextInputControl.ContentChange} object that
contains the actual (filtered)
* change. Returning null rejects the change.
* p
* If default value supplier is provided, it is used when the
{@code ContentFilter} is assigned to a {@code TextInputControl}
* and it's current text is invalid. It is expected that the
provided default value is accepted by the filtering operator.
*/
public static class ContentFilter {
/**
* Creates a new filter with the providing filtering operator.
* @param filter the filtering operator
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter) {}
/**
* Creates a new filter with the providing filtering operator
and default value supplier.
* @param filter the filtering operator
* @param defaultValue the default value or null
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter,
SupplierString defaultValue) {}
/**
* The filtering operator of this filter.
* @return the operator
*/
public UnaryOperatorContentChange getFilter() {}
/**
* The default value provider of this filter
* @return the default value provider or null
*/
public SupplierString getDefaultValue() {}
/**
* Chains this filter with a filtering operator. The other
filtering operator is used only if this
* filter's operator rejects the operation. The default value
of the new {@code ContentFilter} is the same
* as of this filter.
* @param other the filtering operator to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(UnaryOperatorContentChange other) {}
/**
* Chains this filter with a filtering operator of another
{@code ContentFilter}. The other filtering operator is used only if this
* filter's operator rejects the operation. The default value
of the new {@code ContentFilter} is the same
* as of this filter.
* @param other the filter to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(ContentFilter other) {}
}
/**
* Contains the state representing a change in the content for a
* TextInputControl. This object is passed to any registered
* {@code contentFilter} on the TextInputControl whenever the text
* for the TextInputControl is modified.
* p
* This class contains state and convenience methods for
determining what
* change occurred on the control. It also has a reference to the
* TextInputControl itself so that the developer may query any
other
* state on the control. Note that you should never modify the
state
* of the control directly from within the contentFilter handler.
* /p
* p
* The ContentChange is mutable, but not observable. It should
be used
* only for the life of a single change. It is intended that the
* ContentChange will be modified from within the contentFilter.
* /p
*/
public static final class ContentChange implements Cloneable{
/**
* Gets the control associated with this change.
* @return The control associated with this change. This will
never be null.
*/
public final TextInputControl getControl() {}
Re: Formatted text field API (RT-14000, RT-30881)
Binding the property would mean the text field can be edited (the field
is still editable), but it's content cannot be committed (by either
pressing ENTER or focusing out of the field), so it's content is
practically irrelevant.
If you think there's a reasonable use case for this, there should be no
problem with having writable value.
-Martin
On 11.6.2014 15:53, Scott Palmer wrote:
In FormattedTextField why is the value property returned as a
read-only property?
This control should allow bi-directional bindings to the value property.
Scott
On Wed, Jun 11, 2014 at 4:50 AM, Martin Sladecek
martin.slade...@oracle.com wrote:
Hello,
I would like to start some discussion about formatted text field API. The
related JIRA issues are RT-14000 (formatted text field) and RT-30881
(content filter).
The RT-30881 defines a content filter for all text input controls (in
TextInputControl class), like TextField and TextArea. This was originally
implemented by Richard Bair and briefly discussed here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-December/004687.html.
I've tried to build formatted text field on top of that (and made some
changes to the API) since content filtering is something most formatted text
fields will use.
First, the TextInputControl additions:
* contentFilter property of type ObjectPropertyContentFilter
So let's look at the content filter and content change (both nested classes
of TextInputControl):
/**
* Content Filter specifies the filter to be used with {@link
TextInputControl#contentFilterProperty()}.
* It allow user to intercept and modify any change done to the text
content.
* To avoid content that's not valid for the filter, it's possible to
assign a default value supplier for the filter.
* p
* The filter itself is an {@code UnaryOperator} that accepts {@link
javafx.scene.control.TextInputControl.ContentChange} object.
* It should return a {@link
javafx.scene.control.TextInputControl.ContentChange} object that contains
the actual (filtered)
* change. Returning null rejects the change.
* p
* If default value supplier is provided, it is used when the {@code
ContentFilter} is assigned to a {@code TextInputControl}
* and it's current text is invalid. It is expected that the provided
default value is accepted by the filtering operator.
*/
public static class ContentFilter {
/**
* Creates a new filter with the providing filtering operator.
* @param filter the filtering operator
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter) {}
/**
* Creates a new filter with the providing filtering operator and
default value supplier.
* @param filter the filtering operator
* @param defaultValue the default value or null
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter,
SupplierString defaultValue) {}
/**
* The filtering operator of this filter.
* @return the operator
*/
public UnaryOperatorContentChange getFilter() {}
/**
* The default value provider of this filter
* @return the default value provider or null
*/
public SupplierString getDefaultValue() {}
/**
* Chains this filter with a filtering operator. The other filtering
operator is used only if this
* filter's operator rejects the operation. The default value of the
new {@code ContentFilter} is the same
* as of this filter.
* @param other the filtering operator to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(UnaryOperatorContentChange other) {}
/**
* Chains this filter with a filtering operator of another {@code
ContentFilter}. The other filtering operator is used only if this
* filter's operator rejects the operation. The default value of the
new {@code ContentFilter} is the same
* as of this filter.
* @param other the filter to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(ContentFilter other) {}
}
/**
* Contains the state representing a change in the content for a
* TextInputControl. This object is passed to any registered
* {@code contentFilter} on the TextInputControl whenever the text
* for the TextInputControl is modified.
* p
* This class contains state and convenience methods for determining
what
* change occurred on the control. It also has a reference to the
* TextInputControl itself so that the developer may query any other
* state on the control. Note
Re: Formatted text field API (RT-14000, RT-30881)
Although I'm not sure the second one can be considered a use-case, I
agree that somebody might want uneditable field with some format (and
it's up to the developer to make it uneditable), so I'll make the value rw.
-Martin
On 11.6.2014 16:03, Scott Palmer wrote:
There are two cases for this:
- a regular binding could be used with a read-only FormattedTextField
for cases where you want the text representation shown in the UI and
have it selectable and readable for copy/paste.
- a bi-directional binding should just work
Scott
On Wed, Jun 11, 2014 at 9:59 AM, Martin Sladecek
martin.slade...@oracle.com wrote:
Binding the property would mean the text field can be edited (the field is
still editable), but it's content cannot be committed (by either pressing
ENTER or focusing out of the field), so it's content is practically
irrelevant.
If you think there's a reasonable use case for this, there should be no
problem with having writable value.
-Martin
On 11.6.2014 15:53, Scott Palmer wrote:
In FormattedTextField why is the value property returned as a
read-only property?
This control should allow bi-directional bindings to the value property.
Scott
On Wed, Jun 11, 2014 at 4:50 AM, Martin Sladecek
martin.slade...@oracle.com wrote:
Hello,
I would like to start some discussion about formatted text field API. The
related JIRA issues are RT-14000 (formatted text field) and RT-30881
(content filter).
The RT-30881 defines a content filter for all text input controls (in
TextInputControl class), like TextField and TextArea. This was originally
implemented by Richard Bair and briefly discussed here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-December/004687.html.
I've tried to build formatted text field on top of that (and made some
changes to the API) since content filtering is something most formatted
text
fields will use.
First, the TextInputControl additions:
* contentFilter property of type ObjectPropertyContentFilter
So let's look at the content filter and content change (both nested
classes
of TextInputControl):
/**
* Content Filter specifies the filter to be used with {@link
TextInputControl#contentFilterProperty()}.
* It allow user to intercept and modify any change done to the text
content.
* To avoid content that's not valid for the filter, it's possible
to
assign a default value supplier for the filter.
* p
* The filter itself is an {@code UnaryOperator} that accepts {@link
javafx.scene.control.TextInputControl.ContentChange} object.
* It should return a {@link
javafx.scene.control.TextInputControl.ContentChange} object that contains
the actual (filtered)
* change. Returning null rejects the change.
* p
* If default value supplier is provided, it is used when the {@code
ContentFilter} is assigned to a {@code TextInputControl}
* and it's current text is invalid. It is expected that the
provided
default value is accepted by the filtering operator.
*/
public static class ContentFilter {
/**
* Creates a new filter with the providing filtering operator.
* @param filter the filtering operator
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter) {}
/**
* Creates a new filter with the providing filtering operator
and
default value supplier.
* @param filter the filtering operator
* @param defaultValue the default value or null
*
* @throws java.lang.NullPointerException if filter is null
*/
public ContentFilter(UnaryOperatorContentChange filter,
SupplierString defaultValue) {}
/**
* The filtering operator of this filter.
* @return the operator
*/
public UnaryOperatorContentChange getFilter() {}
/**
* The default value provider of this filter
* @return the default value provider or null
*/
public SupplierString getDefaultValue() {}
/**
* Chains this filter with a filtering operator. The other
filtering
operator is used only if this
* filter's operator rejects the operation. The default value of
the
new {@code ContentFilter} is the same
* as of this filter.
* @param other the filtering operator to chain
* @return a new ContentFilter as described above
*/
public ContentFilter orApply(UnaryOperatorContentChange other)
{}
/**
* Chains this filter with a filtering operator of another
{@code
ContentFilter}. The other filtering operator is used only if this
* filter's operator rejects the operation. The default value of
the
new {@code ContentFilter} is the same
* as of this filter.
* @param other the filter to chain
* @return
Re: Formatted text field API (RT-14000, RT-30881)
I already posted a comment in JIRA (RT-30881) that we should make the
value writable.
Anyhow, we should move the discussion to JIRA to keep everything at one
place.
Thanks,
-Martin
On 11.6.2014 18:14, Scott Palmer wrote:
I already have a use for a bi-directional binding. I have a UI that
shows properties of a component. The component's properties can be
updated via the UI, and also by other events from background processes
that are running, or even just as a reaction to some other property
changing. So I need the binding from the model to the control to be
bi-directional. The UI view is both read/write. The properties can be
numbers, rational numbers expressed as fractions ##/###, times
HH:MM:SS, enum values, etc.
(My app has some complex requirements so in actual fact a simple
binding probably isn't enough. But in principle it could be.)
Or just think of a spreadsheet in Google docs being edited by two
people on a network... I want to be able to update a cell, and I want
to see when someone else updates it. Two different read/write fields
connected to the same model.
I just thought of something else. Can this be easily used as the field
for a editable ComboBox?
Scott
On Wed, Jun 11, 2014 at 10:08 AM, Martin Sladecek
martin.slade...@oracle.com mailto:martin.slade...@oracle.com wrote:
Although I'm not sure the second one can be considered a use-case,
I agree that somebody might want uneditable field with some format
(and it's up to the developer to make it uneditable), so I'll make
the value rw.
-Martin
On 11.6.2014 16:03, Scott Palmer wrote:
There are two cases for this:
- a regular binding could be used with a read-only
FormattedTextField
for cases where you want the text representation shown in the
UI and
have it selectable and readable for copy/paste.
- a bi-directional binding should just work
Scott
On Wed, Jun 11, 2014 at 9:59 AM, Martin Sladecek
martin.slade...@oracle.com
mailto:martin.slade...@oracle.com wrote:
Binding the property would mean the text field can be
edited (the field is
still editable), but it's content cannot be committed (by
either pressing
ENTER or focusing out of the field), so it's content is
practically
irrelevant.
If you think there's a reasonable use case for this, there
should be no
problem with having writable value.
-Martin
On 11.6.2014 15:53, Scott Palmer wrote:
In FormattedTextField why is the value property
returned as a
read-only property?
This control should allow bi-directional bindings to
the value property.
Scott
On Wed, Jun 11, 2014 at 4:50 AM, Martin Sladecek
martin.slade...@oracle.com
mailto:martin.slade...@oracle.com wrote:
Hello,
I would like to start some discussion about
formatted text field API. The
related JIRA issues are RT-14000 (formatted text
field) and RT-30881
(content filter).
The RT-30881 defines a content filter for all text
input controls (in
TextInputControl class), like TextField and
TextArea. This was originally
implemented by Richard Bair and briefly discussed
here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-December/004687.html.
I've tried to build formatted text field on top of
that (and made some
changes to the API) since content filtering is
something most formatted
text
fields will use.
First, the TextInputControl additions:
* contentFilter property of type
ObjectPropertyContentFilter
So let's look at the content filter and content
change (both nested
classes
of TextInputControl):
/**
* Content Filter specifies the filter to be
used with {@link
TextInputControl#contentFilterProperty()}.
* It allow user to intercept and modify any
change done to the text
content.
* To avoid content that's not valid for the
filter, it's possible
to
assign a default value supplier for the filter.
* p
Re: How to scale control properly?
That should work for non-resizable Nodes, but resizables would be tricky if not impossible. During the layout pass, we need to know min/pref/max size. In this case, it would have to be adjusted with the transformation (which can be a rotation, shear or doesn't have to be affine). The transformation can make widthheight depend on each other (like 45deg rotation makes the min/max width depend on height and vice-versa). Then there's a problem with Region's width/height properties which are being set by the layout pane. They should be without transformations (as internal layout uses them), so either the layout algorithms would have to undo the transforms and compute the right size or the logic would need to be in resize() call, which turns setWidth/setHeight to kind-of a pitfall. I think the best solution would be to add some scale styleable-only property to Control, as that's probably the most reasonable transform we want to include in layout bounds. As controls have another layer of layoutChildren() call which passes the width/height and do not (should not?) use getWidth()/getHeight() for their layout, it might be possible to hide the internal logic in some common Skin code. That would also mean adding a mandatory Pane to each control that would be the root of the skin, but a child of the control, to hide the internal transformations. -Martin On 10.6.2014 05:09, Richard Bair wrote: One thing we’ve always considered was adding some kind of convenience API to Node to toggle how the layout bounds are computed (whether they take into account transforms or not). Martin, how difficult would that be, do you think? Richard On Jun 5, 2014, at 11:41 AM, Rafal Leibzig rafal...@gmail.com wrote: Thanks for advice. I know this trick with wrapping in a Group, but as i wrote on stackoverflow, there is dropshadow effect after moving mouse over the control. This effect extends group's layoutBounds for a while. And when mouse leaves out the control, then group's layoutBounds shrink. I found the sources/css for this control: https://bitbucket.org/controlsfx/controlsfx/src/96f40eb0b579277139192e2398fbbaf7fd01f91e/controlsfx/src/main/resources/org/controlsfx/control/rating.css?at=default -- Rafal 2014-06-05 16:12 GMT+02:00 Martin Sladecek martin.slade...@oracle.com: Hi Rafal, you can wrap the control in a Group. That way, it's (actually Group's) layoutBounds will be the same as it's transformed bounds (boundsInParent). Alternatively you can use css styling, but I don't know much about how to do it properly, maybe Jonathan can help you there. -Martin On 06/05/2014 01:13 AM, Rafal Leibzig wrote: Hi, Sorry for disturbing you, but I have a question and no one answered me on other forums. My question is rather simple: http://stackoverflow.com/questions/23997115/how-to- scale-control-and-layout-it-properly-in-javafx Thanks in advance. You are the experts. :)
Re: monitor mouse events but not capture them
Hi Tom, have you tried .addEventFilter() method? It receives the Event before the controls underneath the canvas, in the capturing phase. If you don't consume the Event, it should pass down to the controls. For more on the topic, see http://docs.oracle.com/javafx/2/events/processing.htm or http://parleys.com/play/514892290364bc17fc56c39f -Martin On 06/09/2014 08:19 AM, Tom Eugelink wrote: Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: monitor mouse events but not capture them
Just looked at the code and it seems Canvas does pick on bounds independently of the pickOnBounds value. There's currently no logic for picking only when over an opaque pixel ( worth filing a JIRA issue maybe?). This makes Canvas to consume everything as it's always picked instead of some controls underneath. Unfortunately, I can't think of any solution that would work right now. If we'd support Node picking (https://javafx-jira.kenai.com/browse/RT-20184), it would be possible to redirect an unwanted event to a different event target on that mouse position. -Martin On 06/09/2014 08:44 AM, Tom Eugelink wrote: Ye. It does not work on the canvas pane, I suspect because of the pickOnBounds, but it does work on the stackpane. Plus, I can register to the stack pane without claiming the onMouseClick/Press hook. Many thanks! Tom On 2014-6-9 8:29, Martin Sladecek wrote: Hi Tom, have you tried .addEventFilter() method? It receives the Event before the controls underneath the canvas, in the capturing phase. If you don't consume the Event, it should pass down to the controls. For more on the topic, see http://docs.oracle.com/javafx/2/events/processing.htm or http://parleys.com/play/514892290364bc17fc56c39f -Martin On 06/09/2014 08:19 AM, Tom Eugelink wrote: Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: monitor mouse events but not capture them
OK, so to avoid further confusion, you have a PopupWindow with a Pane and you want to capture Events on the Pane and sent those events to the underlying controls (in a parent window) if those events are not relevant to that popup? Thanks, -Martin On 06/09/2014 10:07 AM, Tom Eugelink wrote: Hm, maybe I chose bad words; I'm not using Canvas, but just a Pane. Since the Pane is only used to draw the menu on when it need to appear, I'm calling it the canvas pane, as in what is painted on. On 2014-6-9 9:46, Martin Sladecek wrote: Just looked at the code and it seems Canvas does pick on bounds independently of the pickOnBounds value. There's currently no logic for picking only when over an opaque pixel ( worth filing a JIRA issue maybe?). This makes Canvas to consume everything as it's always picked instead of some controls underneath. Unfortunately, I can't think of any solution that would work right now. If we'd support Node picking (https://javafx-jira.kenai.com/browse/RT-20184), it would be possible to redirect an unwanted event to a different event target on that mouse position. -Martin On 06/09/2014 08:44 AM, Tom Eugelink wrote: Ye. It does not work on the canvas pane, I suspect because of the pickOnBounds, but it does work on the stackpane. Plus, I can register to the stack pane without claiming the onMouseClick/Press hook. Many thanks! Tom On 2014-6-9 8:29, Martin Sladecek wrote: Hi Tom, have you tried .addEventFilter() method? It receives the Event before the controls underneath the canvas, in the capturing phase. If you don't consume the Event, it should pass down to the controls. For more on the topic, see http://docs.oracle.com/javafx/2/events/processing.htm or http://parleys.com/play/514892290364bc17fc56c39f -Martin On 06/09/2014 08:19 AM, Tom Eugelink wrote: Hi all, Maybe someone has solved this already, so I thought I pop the question. Currently I'm working on CirclePopupMenu; a menu that is supposed to pop up on any place in a scene when a certain (usually the middle or right) mouse button is pressed. Right now CirclePopupMenu requires a stackpane to which it binds itself. CirclePopupMenu initially places an empty canvas Pane on the stack pane, and will use that to render and position the menu when it needs to appear. Also I need to monitor the mouse to detect if the menu should appear. In order to do that, I would like to use that canvas pane, but then any non relevant button clicks will not reach the underlying controls. In order to enable correct behavior I need to setPickOnBounds(false) on the pane, but then it does receive the mouse events anymore. Is there any way to monitor mouse events but still pass them through to the underlying controls? In Swing I did something similar and used a system level mouse event hook. Tom PS: I'm not certain if the stackpane approach I've used is the best way to do this. It does work expect the mouse button problem. But any suggestions are welcome.
Re: How to scale control properly?
Hi Rafal, you can wrap the control in a Group. That way, it's (actually Group's) layoutBounds will be the same as it's transformed bounds (boundsInParent). Alternatively you can use css styling, but I don't know much about how to do it properly, maybe Jonathan can help you there. -Martin On 06/05/2014 01:13 AM, Rafal Leibzig wrote: Hi, Sorry for disturbing you, but I have a question and no one answered me on other forums. My question is rather simple: http://stackoverflow.com/questions/23997115/how-to-scale-control-and-layout-it-properly-in-javafx Thanks in advance. You are the experts. :)
Re: FXMLLoader ?import? checking code conventions too much?
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it would
not be clear when there's e.g. a text property and text class if we
should set a property called text or create new text object and try to
assign it to the default property. The same problem with static setters.
Is hello.text.text a fully qualified name of text class in or text
static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c': cSomeClass.java
In the ?import ? parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
i n
Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: FXMLLoader ?import? checking code conventions too much?
Maybe some special tags can solve the problem, like
fx:property name=TEXTabc/fx:property
fx:new class=hello.text text=abc/
fx:static class=text property=TEXTabc/fx:static
They could be used in cases where the class name violates the
restrictions we have for property/object tags. FXML version and SB will
have to be update though, which means such fxml will not be compatible
with older versions. This is definitely something we should do only on
major release (9).
-Martin
On 5.6.2014 22:21, Stephen F Northover wrote:
Seems like we can't/shouldn't fix this. We can at least make sure it
is documented.
Steve
On 2014-06-05, 4:19 PM, Martin Sladecek wrote:
Currently, we use case to distinguish between newly created objects
(upper-case class name) and properties (lower-case). Otherwise, it
would not be clear when there's e.g. a text property and text class
if we should set a property called text or create new text object and
try to assign it to the default property. The same problem with
static setters.
Is hello.text.text a fully qualified name of text class in or
text static setter of a hello.text class?
I guess we could define some order in which we would try out this
options in the current context, but SB will have a problem since they
use static mode which can be used without having the classes on the cp.
-Martin
On 5.6.2014 20:57, Stephen F Northover wrote:
I see no reason why we should enforce this. Martin, any idea?
Steve
On 2014-06-05, 12:05 PM, Guillaume Anctil wrote:
Hi,
on a project I work on, the code convention does not follow the Java
standard and class names start with a lower case 'c':
cSomeClass.java
In the ?import ? parsing of the FXMLLoader, the loadType function
looks
like this:
int i = name.indexOf('.');
int n = name.length();
while (i != -1
i n
Character.isLowerCase(name.charAt(i + 1))) {
i = name.indexOf('.', i + 1);
}
if (i == -1 || i == n) {
throw new ClassNotFoundException();
}
String packageName = name.substring(0, i);
String className = name.substring(i + 1);
This causes a ClassNotFoundException on our custom controls because
of the
lowercase check.
I was wondering if a simple:
int i = name.lastIndexOf('.');
Instead of the lowercase check could be viable. The
ClassNotFoundException
would still be thrown later on, when trying to actually load the
class.
Is there a reason that I don't see why the convention _must_ be
upheld in
this case?
Thanks.
Re: Label baseline offset with a graphic
Hi Werner, this has changed in 8u20. See https://javafx-jira.kenai.com/browse/RT-36729 -Martin On 06/03/2014 02:11 PM, Werner Lehmann wrote: Hi, I am trying to align labels on their baseline in an hbox. This is surprisingly difficult if some of the labels have a graphic (on the left). Turns out that LabeledSkinBase.computeBaselineOffset() simply uses the max of the text baseline and the height of the graphic: h = Math.max(textBaselineOffset, g.prefHeight(-1)); So, if the label has no graphic its height is 17 with baseline 13. With a 16x16 graphic the height is still 17 but the baseline changes to 16. Which of course messes up the baseline alignment to other controls. Doesn't it make more sense to use the baseline of the actual text (possibly adjusted if the graphic is big)? Screenshot: http://postimg.org/image/kv12r24z9/ Werner
Re: Label prefHeight vs wrapText
Hi Werner,
the important min/pref/max height is the one with width parameter as
Label is horizontally biased. So while minHeight(width) == 17,
prefHeight(width) == 34.
But in your case, with ListView's prefHeight == 1000, you'll overflow by
over 400px. VBox does evenly subtract these overflow pixels from
children until it gets to their minimum. Which happens in case of the Label.
Vgrow is ignored when shrinking (see javadoc for setVgrow). Currently,
neither VBox nor GridPane allow you define policy for children when the
pane is below it's pref size and children need to be shrunk. Seems like
a good candidate for a Tweak in JIRA. ;-)
If you need to keep your Label at some height, currently you can only
raise it's minHeight, but I understand that in this case it may be
tricky as it depends on the width.
-Martin
On 28.5.2014 15:44, Werner Lehmann wrote:
Hi,
I am stumped. With a label and wrapText=true I am not getting wrapped
text when I think I should. Consider this scene (code at bottom):
VBox
- Label, long text, wrapText=true
- ListView, prefHeight=1000 (too big to fit)
This will not wrap the label text. The VBox gives all room to the
listview and keeps the label on a single line. VBox.vgrow does not
change this.
Without the prefHeight on the listview I am getting wrapped text.
Then, label height is 34 - while its min/pref/max height is all at 17
according to ScenicView.
Why is the label not reporting a pref height of 34?
Why is the vbox sizing the label beyond its max height?
Appreciate any insight because I don't see what's going on.
Rgds
Werner
public class WrapTest extends Application
{
public static void main(String[] args)
{
Application.launch(args);
}
@Override
public void start(Stage primaryStage) throws Exception
{
Label label1 = new Label(Strings.repeat(bla , 50));
label1.setWrapText(true);
ListViewString lv = new ListViewString();
lv.setPrefHeight(1000);
VBox vb = new VBox(label1, lv);
Scene scene = new Scene(vb, 800, 600);
primaryStage.setScene(scene);
primaryStage.show();
}
}
Re: Label prefHeight vs wrapText
On 28.5.2014 18:10, Werner Lehmann wrote: Martin, thanks for the explanation. Feels good to finally understand this ;-) And while I created a ticket as per your suggestion... [#RT-37309] VBox: vshrink layout hint similar to vgrow Thanks! ...it seems I can use this as a workaround: label1.minHeightProperty().bind(Bindings.createDoubleBinding( () - label1.prefHeight(vbox.getWidth()), vbox.widthProperty())); Maybe something similar could be made available per label boolean property. So basically the ability to ask a label to consider wrapping when calculating its minHeight... I can imagine that this might have made more sense as a default behavior: if people explicitly ask for wrapping text, they would probably accept a larger minHeight. Probably a property would be better since it doesn't change the behavior (and Labeled is all over the controls). It calls for a 3-state property (no wrapping, wrapping only when space available, wrapping), but it's too late for that unfortunately. Anyway, looks like we have another candidate for JIRA ;-) -Martin Werner On 28.05.2014 16:17, Martin Sladecek wrote: Hi Werner, the important min/pref/max height is the one with width parameter as Label is horizontally biased. So while minHeight(width) == 17, prefHeight(width) == 34. But in your case, with ListView's prefHeight == 1000, you'll overflow by over 400px. VBox does evenly subtract these overflow pixels from children until it gets to their minimum. Which happens in case of the Label. Vgrow is ignored when shrinking (see javadoc for setVgrow). Currently, neither VBox nor GridPane allow you define policy for children when the pane is below it's pref size and children need to be shrunk. Seems like a good candidate for a Tweak in JIRA. ;-) If you need to keep your Label at some height, currently you can only raise it's minHeight, but I understand that in this case it may be tricky as it depends on the width. -Martin
Re: add calculating methods to bind
That would be nice. Don't forget to add it to JIRA!
-Martin
On 23.5.2014 07:11, Tom Eugelink wrote:
I feel the standard binding should offer an easy hook option
heightProperty().multiply(3.4).calc( value - { snap(vallue); }
).add(5.0)
On 2014-5-21 22:00, Tomas Mikula wrote:
Just a side note, you could use
EasyBind.map(heightProperty(), value -
NodeUtil.snapXY(value.doubleValue() * 0.2));
instead of
snap(heightProperty().multiply(0.2))
and you don't need your custom DoubleBinding implementation. But note
that it returns BindingDouble, not DoubleBinding.
EasyBind is at http://www.fxmisc.org/easybind/
Tomas
On Wed, May 21, 2014 at 9:47 PM, Tomas Mikula
tomas.mik...@gmail.com wrote:
Yeah, and you could also eliminate Observable... dependencies from
snap's signature, since now you are not using them to invalidate your
binding.
On Wed, May 21, 2014 at 9:36 PM, Tom Eugelink t...@tbee.org wrote:
Found it! Slightly different DoubleBinding was required (copied it
from
negate).
private DoubleBinding snap(final ObservableNumberValue value,
final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(value);
}
@Override
public void dispose() {
super.unbind(value);
}
@Override
protected double computeValue() {
return NodeUtil.snapXY(value.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return FXCollections.singletonObservableList(value);
}
};
}
On 2014-5-21 21:34, Tomas Mikula wrote:
Hi Tom,
it seems to me that in your custom DoubleBinding implementation
`other` is not its dependency, thus it does not react to it's
invalidations.
Tomas
On Wed, May 21, 2014 at 9:25 PM, Tom Eugelink t...@tbee.org wrote:
I came up with this:
startXProperty().bind( *snap(*heightProperty().multiply(0.2)) )
And then:
private DoubleBinding snap(final ObservableNumberValue
other, final
Observable... dependencies) {
return new DoubleBinding() {
{
super.bind(dependencies);
}
@Override
public void dispose() {
super.unbind(dependencies);
}
@Override
protected double computeValue() {
return NodeUtil.snap(other.doubleValue());
}
@Override
public ObservableList? getDependencies() {
return new
ImmutableObservableListObservable(dependencies);
}
};
}
But that always returns 0... I feel this should have worked.
Tom
Re: Clarification on javafx.concurrent.Task cancellation behavior
Hi Weiqi,
this is definitely a bug, I filed
https://javafx-jira.kenai.com/browse/RT-37067 to track this.
Thanks,
-Martin
On 11.5.2014 20:22, weiqi...@gmail.com wrote:
Hi,
Looking at the javafx.concurrent.Task code, I see the following in the nested class
TaskCallableV’s call() method:
try {
final V result = task.call();
if (!task.isCancelled()) {
// If it was not cancelled, then we take the return
// value and set it as the result.
task.runLater(new Runnable() {
@Override public void run() {
// The result must be set first, so that when the
// SUCCEEDED flag is set, the value will be
available
// The alternative is not the case, because you
// can assume if the result is set, it has
// succeeded.
task.updateValue(result);
task.setState(State.SUCCEEDED);
}
});
return result;
} else {
// There may have been some intermediate result in the
// task set from the background thread, so I want to be
// sure to return the most recent intermediate value
return task.getValue();
}
} catch (final Throwable th) {
….
}
When this code is executed off the JavaFX Application Thread, which I take to
be the case almost all the time, the “task.getValue()” call will always throw
an exception as the getValue() method does a checkThread() first. Is this
intentional?
The practical implication is that a cancelled task, in addition to its state
being CANCELLED, also has an IllegalStateException with a message of “Task must
only be used from the FX Application Thread” recorded as an exception of the
task if the task chooses to exit the call() method normally when the task is
cancelled. And of course, if the task chooses to exit the call() method
abruptly by throwing its own RuntimeException, that runtime exception will be
recorded as the exception of the task instead of the ISE.
--
Weiqi Gao
Re: Why can Scene's only be constructed on the UI thread?
The patch tries to solve the issue by deferring the construction of Scene in PopupWindow, but the issues I ran into just show that it's not enough. In order to fix RT-17716, we need Scene construction outside of the thread. Looking at the Scene code, it seems that there are not that many places where app thread is necessary. The Scene's peer is created only when added to a Window (which is good), but there are still calls that need to be synchronized or transferred to the app thread. Like when a Node is removed from a Scene, it's peer is immediately disposed. And also snapshots require peers (i.e. Scene in a Window), but I guess we can live with that. I'm also not sure about accessibility, maybe the code would need some adjustments as well. -Martin On 04/28/2014 08:18 PM, Kevin Rushforth wrote: Some of this was looked at while trying to solve RT-17716 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch). I think it would be worth considering relaxing the restriction on constructing Scene and Window (maybe Stage, but I don't think there is a benefit for that one), but it seems that Martin ran into some issues with his specific patch. -- Kevin Richard Bair wrote: Hi, Actually I don’t know of any reason why Window and Scene cannot be created and initialized on any thread. Each of these has a peer, and the *peer* we can’t update except on the right thread (or with care, these are OS specific restrictions or issues). But I don’t see any reason why the Java side cannot be initialized on any background thread. And in fact, that was always my intent for exactly these reasons, having experienced all this pain in Swing before firsthand. Its just work that needs to be done, contributions welcome :-) Richard On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote: Hi Tom this is also true for Swing and the EDT. I had heard years ago jre 8 was going to address this via 2 drawing threads and modularity but jigsaw was delayed and not sure what happened to the 2 drawing thread idea. I really wish we could instantiate windows in memory and when needed draw them. The user experience and perception of java would be so much better for the client side. If someone on the java client side knows how to do this I would love to try it to verify it. Best Regards, Tony Anecito On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net wrote: At e(fx)clipse we have an FXML to Java translator who removes all the reflection overhead from FXML. It does not yet support all FXML features but we are steadily improving it and with test cases we are able to fix problems quite fast. Maybe this is an option for you? That would be very interesting to try, yes please! Where can I find it? My project is Java 8 based so that's no problem.
Re: com.sun.javafx.fxml.expression
I'm afraid the only available documentation is the document below. -Martin On 3.4.2014 20:59, Jeffrey Guenther wrote: Very interesting. Is there any other documentation about it's design available? Some of the things I'd be interested in knowing in more detail are the kind of expressions it supports and the goals for the path resolution mechanism? How does interact with native Java objects? From: Martin Sladecek martin.slade...@oracle.com To: openjfx-dev@openjdk.java.net Cc: Date: Thu, 03 Apr 2014 09:15:11 +0200 Subject: Re: com.sun.javafx.fxml.expression Yes, that's an expression parser for FXML expressions, see http://docs.oracle.com/javase/8/javafx/api/javafx/fxml/doc- files/introduction_to_fxml.html#expression_binding -Martin On 04/03/2014 12:57 AM, Jeffrey Guenther wrote: Hi, In the midst of an autocomplete in NetBeans I discovered com.sun.javafx.fxml.expression.Expression. I'm in the middle of implementing an expression parser for a project and happen to also have an Expression object. May I ask what this package is for? It's the first I've seen of it and it's quite interesting. Looks like there is a little expression parser built into FXML? Thanks, Jeff
Re: Dynamic position/size change and built-in layouts
Can you provide some small sample where this can be reproduce and preferably submit a bug to JIRA? Thanks, -Martin On 3.4.2014 23:57, Pedro Duque Vieira wrote: In the situation I described nothing happens after c1 changes height. But strangely if some other child changes, for instance c3 changing its height, than the children c3 and c2 will re-position correctly, taking into account the height of c1. So the change is being delayed, even if I call requestLayout().. It's being delayed for an undefined amount of time so it should have nothing to due with the pulse. On Thu, Apr 3, 2014 at 10:07 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Setting VBox preferred height to: USE_COMPUTED_SIZE, doesn't work. Regards, On Thu, Apr 3, 2014 at 6:14 PM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: What I'm saying isn't exactly that. What I'm saying is, for instance, if I change the height of the first child of the VBox than the other children below would re-position themselves. -VBox- - --- - - c1 - - - - - - - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- First child (c1) gets smaller. Result - c2 and c3 move up automatically (and the height of the VBox would also get smaller automatically): -VBox- - --- - - c1 - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- Thanks, On Thu, Apr 3, 2014 at 5:29 PM, Jasper Potts jasper.po...@oracle.comwrote: VBox preferred size will grow if one of its children's preferred sizes grows. It will be down the the parent node of the VBox to react to that and make the VBox bigger if there is space available. The change is not immediate it will happen one pulse later. Jasper On Apr 3, 2014, at 7:01 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi, Are built-in layouts prepared for dynamic changes of their children position and/or size? That is, for instance, if in a VBox I change the first child height the other subsequent children would re-adjust their position. My experiments with VBox tell me that this will result in bugs, i.e. it won't work. I think this is important for RIAs. Thanks, best regards, -- Pedro Duque Vieira -- Pedro Duque Vieira -- Pedro Duque Vieira
Re: com.sun.javafx.fxml.expression
Yes, that's an expression parser for FXML expressions, see http://docs.oracle.com/javase/8/javafx/api/javafx/fxml/doc-files/introduction_to_fxml.html#expression_binding -Martin On 04/03/2014 12:57 AM, Jeffrey Guenther wrote: Hi, In the midst of an autocomplete in NetBeans I discovered com.sun.javafx.fxml.expression.Expression. I'm in the middle of implementing an expression parser for a project and happen to also have an Expression object. May I ask what this package is for? It's the first I've seen of it and it's quite interesting. Looks like there is a little expression parser built into FXML? Thanks, Jeff
Re: Dynamic position/size change and built-in layouts
And are you changing the height of the child or it's preferred height? The height of a managed node is set by the VBox, so you shouldn't manipulate with it since if the VBox layout gets dirty, it will reset the heigh according to the preferred height. -Martin On 3.4.2014 19:14, Pedro Duque Vieira wrote: What I'm saying isn't exactly that. What I'm saying is, for instance, if I change the height of the first child of the VBox than the other children below would re-position themselves. -VBox- - --- - - c1 - - - - - - - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- First child (c1) gets smaller. Result - c2 and c3 move up automatically (and the height of the VBox would also get smaller automatically): -VBox- - --- - - c1 - - --- - - --- - - c2 - - --- - - --- - - c3 - - - - - --- Thanks, On Thu, Apr 3, 2014 at 5:29 PM, Jasper Potts jasper.po...@oracle.comwrote: VBox preferred size will grow if one of its children's preferred sizes grows. It will be down the the parent node of the VBox to react to that and make the VBox bigger if there is space available. The change is not immediate it will happen one pulse later. Jasper On Apr 3, 2014, at 7:01 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: Hi, Are built-in layouts prepared for dynamic changes of their children position and/or size? That is, for instance, if in a VBox I change the first child height the other subsequent children would re-adjust their position. My experiments with VBox tell me that this will result in bugs, i.e. it won't work. I think this is important for RIAs. Thanks, best regards, -- Pedro Duque Vieira
Re: Ability to decorate ChangeListener
Mario,
thanks for your suggestion, but I think your specific case will not
justify the change. First of all, as it was already said, equals should
be symmetric. Knowing the implementation, you could rely on the fact
that either the equals is called on the provided listener or on the
listeners already in the list. Might be that somebody else would need
the asymmetry to be implemented in the listener provided to
removeListener() method and the current situation suits him, so why do
the change for your case?
Anyway, relying on some implementation-specific behaviour is generally a
sign of bad code practice, so it should give you a hint that you should
find a different solution (like the one you discussed with Tomas
already). It might happen that the code would be changed / re-factored
in the future or some bug would be fixed there and behaviour will change
again, breaking your application in some future JFX version.
Regards,
-Martin
On 22.3.2014 15:47, Mario Ivankovits wrote:
The only thing which I ask for is to flip this „if in the *ExpressionHelper
classes:
So, JavaFX does not break anything and it is up to the app developer to take
the risk or not.
if (listener.equals(changeListeners[index])) {
If we flip this to
if (changeListeners[index].equals(listener))
Am 22.03.2014 um 15:42 schrieb Kevin Rushforth
kevin.rushfo...@oracle.commailto:kevin.rushfo...@oracle.com:
If you are talking about a change to the JavaFX API, we are not likely to
accept such a change if it breaks the contract of equals() or hashcode(). In
your own app it may not matter, but it is dangerous to assume it won't matter
to anyone. Martin owns the core libraries and can comment further.
-- Kevin
Mario Ivankovits wrote:
Hi Thomas!
Thanks for your input. Because I want to decorated listeners added by JavaFX
core I can not use the sub/unsub pattern.
Your second proposal is almost what I do right now. In removeListener I consult
a map where the decorated listeners and their undecorated one lives.
Regarding the symmetric doubts. Such listeners will always be removed by
passing in the undecorated object to removeListener.
They should act like a transparent proxy.
Even if this breaks the equals paradigm, in this special case I can perfectly
live with an equals/hashCode implementation like this below.
It won’t break your app; as long as both objects do not live in the same
HashSet/Map …. for sure - but why should they?
@Override
public boolean equals(Object obj)
{
return obj == delegate; // this == obj
}
@Override
public int hashCode()
{
return delegate.hashCode();
}
Regards,
Mario
Am 22.03.2014 um 14:22 schrieb Tomas Mikula
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com:
A simpler and more universal solution is to also override removeListener:
public void removeListener(ChangeListener? super T listener) {
super.removeListener(decorated(listener));
}
And the equals() method on decorated listeners only compares the
delegates (thus is symmetric).
Regards,
Tomas
On Sat, Mar 22, 2014 at 2:07 PM, Tomas Mikula
tomas.mik...@gmail.commailto:tomas.mik...@gmail.com wrote:
The suspicious thing about your solution is that your smart
implementation of equals() is not symmetric.
In case the observable value is visible only within your project, you
could do this:
interface Subscription {
void unsubscribe();
}
class MyObservableValueT implements ObservableValueT {
public Subscription subscribe(ChangeListener? extends T listener) {
ChangeListenerT decorated = decorate(listener);
addListener(decorated);
return () - removeListener(decorated);
}
}
and use subscribe()/unsubscribe() instead of addListener()/removeListener():
Subscription sub = observableValue.subscribe(listener);
// ...
sub.unsubscribe();
Of course this is not possible if you need to pass the observable
value to the outside world as ObservableValue.
Regards,
Tomas
On Sat, Mar 22, 2014 at 6:57 AM, Mario Ivankovits
ma...@datenwort.atmailto:ma...@datenwort.at wrote:
Hi!
In one of my ObservableValue implementations I do have the need to decorate
ChangeListener added to it.
Today this is somewhat complicated to implement, as I have to keep a map of the
original listener to the decorated one to being able to handle the removal
process of a listener. Because the outside World did not know that I decorated
the listener and the instance passed in to removeListener ist the undecorated
one.
We can make things easier with a small change in
ExpressionHelper.removeListener. When iterating through the listener list, the
listener passed in as argument to removeListener is asked if it is equal to the
one stored
if (listener.equals(changeListeners[index])) {
If we flip this to
if
Re: Ability to decorate ChangeListener
On 24.3.2014 15:24, Mario Ivankovits wrote: But, after this discussion I do not see why one ever used .equals() at all. Look, it does not fit my needs, I do not see any use-case where one would add an removeListener with asymmetric .equals() and thus it is better you use == I think. This clarifies that EXACTLY the added listener instance is required to remove any listener AND it gives no room to discussions like we had because the indention is perfectly clear - even to those reading JavaFX core code and bug fixing things in JavaFX. For me this would be fine and understandable - I will go the decorator-cache-map so I will be fine always. One example might be in bidirectional binding. There's a special listener that takes the 2 properties that are bound together and it's equals returns true if the other listener is of the same class and it's two properties (no matter in what order) are identical. This way, you can just write Bindings.unbindBidirectional() and the internal implementation does not need to remember the listener instance anywhere. The equals() is symmetric in this case, but == would not work here. -Martin
Review request: RT-36238, [Ensemble8] SwingInterop throws IllegalStateException: Not on FX application thread
Lisa, please review the following change in Ensemble8: https://javafx-jira.kenai.com/browse/RT-36238 http://cr.openjdk.java.net/~msladecek/rt-36238/webrev.00/ Thanks, -Martin
Re: Backwards compatibility broken: Why was Color made final
Here's the related JIRA issue: https://javafx-jira.kenai.com/browse/RT-31746 -Martin On 03/19/2014 09:46 AM, Randahl Fink Isaksen wrote: After upgrading to FX8, the framework I have been developing since the early access release of JavaFX three years ago is now broken. My framework has some really cool features for working with color, which relies on our own class PaletteColor which extends javafx.scene.paint.Color. Why would you, after three years, make the Color class final, thereby breaking backwards compatibility? I would really like to know the thoughts behind that decision. Yours Randahl
