hg: openjfx/8/controls/rt: revert computePrefW/H of TabPaneSkin to return W/H based on content instead of a constant.
Changeset: a2978f7aae56 Author:psomashe Date: 2013-06-04 23:14 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/a2978f7aae56 revert computePrefW/H of TabPaneSkin to return W/H based on content instead of a constant. ! javafx-ui-controls/src/com/sun/javafx/scene/control/skin/TabPaneSkin.java
Usecase for needsLayout property?
I'm having a bit of a chicken-egg problem with regards to some
dynamically sized components I'm displaying in my application.
Description:
I have a group with a title that wraps some content and displays a title
above it -- the entire group, including the title must be hidden and
unmanaged when the content it is wrapping is empty, here it is in code:
protected Pane createTitledBlock(final String title, final Node content,
final BooleanExpression visibleCondition) {
return new VBox() {{
setFillWidth(true);
getChildren().add(new Label(title) {{
getStyleClass().add(header);
}});
getChildren().add(content);
if(visibleCondition != null) {
managedProperty().bind(visibleCondition);
visibleProperty().bind(visibleCondition);
}
}};
}
Problem:
When the content becomes available and visibleCondition gets toggled to
true, the content part of the titled group is not yet laid out. This
causes the title to be visible without any content briefly until a
layout pass occurs.
Timeline:
- Group with title is hidden/unmanaged
- The content gets updated and visibleCondition is set to true
- Group with title becomes visible/managed
- Briefly an empty group with title is displayed
- Layout occurs, group with title gets resized
Now, I'm thinking of playing with the needsLayout property and delaying
the making visible/managed of the titled group until needsLayout is
false... however, I have a feeling that won't work as an
unmanaged/hidden group is probably not gonna participate in the layout,
resulting in needsLayout never becoming false again as it is not
visible/managed yet...
Any ideas how I could resolve this, and have the group with title only
visible and managed when it is properly laid out?
Also, has any progress in general been made with regards to
hidden/unmanaged controls and determining their expected size when
they're made visible/managed?
--John
Re: Usecase for needsLayout property?
Hi John,
the problem you described is most likely caused by something else as the
layout pass occurs BEFORE the actual rendering.
Also, you bind managed and visible of the entire VBox, not just the
title. So it's strange that you see Label correctly laid-out, but not
the content.
Can you make some sample and attach it to a JIRA issue, so I can have a
look what's actually happening there?
Thanks,
-Martin
On 06/05/2013 11:29 AM, John Hendrikx wrote:
I'm having a bit of a chicken-egg problem with regards to some
dynamically sized components I'm displaying in my application.
Description:
I have a group with a title that wraps some content and displays a
title above it -- the entire group, including the title must be hidden
and unmanaged when the content it is wrapping is empty, here it is in
code:
protected Pane createTitledBlock(final String title, final Node
content, final BooleanExpression visibleCondition) {
return new VBox() {{
setFillWidth(true);
getChildren().add(new Label(title) {{
getStyleClass().add(header);
}});
getChildren().add(content);
if(visibleCondition != null) {
managedProperty().bind(visibleCondition);
visibleProperty().bind(visibleCondition);
}
}};
}
Problem:
When the content becomes available and visibleCondition gets toggled
to true, the content part of the titled group is not yet laid out.
This causes the title to be visible without any content briefly until
a layout pass occurs.
Timeline:
- Group with title is hidden/unmanaged
- The content gets updated and visibleCondition is set to true
- Group with title becomes visible/managed
- Briefly an empty group with title is displayed
- Layout occurs, group with title gets resized
Now, I'm thinking of playing with the needsLayout property and
delaying the making visible/managed of the titled group until
needsLayout is false... however, I have a feeling that won't work as
an unmanaged/hidden group is probably not gonna participate in the
layout, resulting in needsLayout never becoming false again as it is
not visible/managed yet...
Any ideas how I could resolve this, and have the group with title only
visible and managed when it is properly laid out?
Also, has any progress in general been made with regards to
hidden/unmanaged controls and determining their expected size when
they're made visible/managed?
--John
[API review] RT-30668: ClipboardContent has buggy API
Hello, ClipboardContent API contradicts itself and the documentation doesn't match the behavior. Issue 1: Every putSomething method documentation says: * Setting this value to null effectively clears it from the clipboard. * @throws NullPointerException if null reference is passed We need to choose one of the two described behaviors. Currently the code throws NPE. For some complicated content creation logic the clearing may be useful, so I propose to let the passed null reference clear the value. Issue 2: Every putSomething method documentation says: * @return True if the something was successfully placed on the clipboard. And in other places it refers to this clipboard. But this is not clipboard, it is the ClipboardContent which is later set to the Clipboard - and this operation returns the successful boolean. So we definitely should rephrase the documentation. In the putter, if we say * @return True if the something was successfully placed on the clipboard content. then it needs to always return true (putting a reference to a map doesn't fail) which is not the case right now (right now the behavior is senseless, it returns true if the same thing is put there for the second time). As the always true is not really useful, and because of backward compatibility we can hardly change the return value to map's usual previous value, we can consider at least redefining the boolean to something like returns true if a previously added value was replaced. What do you think? I'd probably go with the always true, which not useful but at least quite intuitive. I would document it to return always true to spare users pointless checks. Thanks, Pavel
hg: openjfx/8/graphics/rt: 5 new changesets
Changeset: 4d270a8b1c08 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-05 11:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4d270a8b1c08 [JAVADOC] RT-30848 Missing documentation of Region.layoutInArea + since tag to Parent#requestParentLayout ! javafx-ui-common/src/javafx/scene/Parent.java ! javafx-ui-common/src/javafx/scene/layout/Region.java Changeset: 1960366c3157 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-05 11:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1960366c3157 Automated merge with file:///home/martin/work/jfx-80-sync/rt Changeset: d8cc9c99d9f4 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-05 11:08 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d8cc9c99d9f4 Automated merge with file:///home/martin/work/jfx-80-sync/rt Changeset: 8bebc4d79bfe Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-05 13:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/8bebc4d79bfe RT-30831 Unsorted mode in the SortedList ! javafx-beans/src/javafx/collections/transformation/SortedList.java ! javafx-beans/test/javafx/collections/SortedListTest.java Changeset: 82df4606a165 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-06-05 13:43 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/82df4606a165 merge
Re: Preloaders
Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
hg: openjfx/8/graphics/rt: 3 new changesets
Changeset: 411a75a54143 Author:Martin Soch martin.s...@oracle.com Date: 2013-06-05 15:10 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/411a75a54143 SW pipeline: fix for performance regression in image rendering (RT-30710) ! prism-sw-native/src/JPiscesRenderer.c ! prism-sw-native/src/PiscesBlit.c Changeset: bb8e96b8b2b3 Author:Martin Soch martin.s...@oracle.com Date: 2013-06-05 15:14 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/bb8e96b8b2b3 SW pipeline: removing default comments from SWArgbPreTexture class ! prism-sw/src/com/sun/prism/sw/SWArgbPreTexture.java Changeset: 54446b832921 Author:Martin Soch martin.s...@oracle.com Date: 2013-06-05 15:16 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/54446b832921 merge
JAVAFX Android
Hello: I would like to create applications on Android. Someone know when will be possible? How I can begin with android? Thanks a lot!!! Javier
Re: Preloaders
I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
hg: openjfx/8/graphics/rt: RT-30916 Winlauncher.cpp failing to compile with Gradle
Changeset: 18e84f5dbf41 Author:kcr Date: 2013-06-05 09:53 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/18e84f5dbf41 RT-30916 Winlauncher.cpp failing to compile with Gradle Contributed-by: Mark Howe Reviewed-by: ngthomas, kcr ! deploy/packager/native/windows/WinLauncher.cpp
hg: openjfx/8/graphics/rt: [COSMETIC CHANGE ONLY] workaround for Eclipse compiler
Changeset: 786c1575aac2 Author:snorthov Date: 2013-06-05 13:19 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/786c1575aac2 [COSMETIC CHANGE ONLY] workaround for Eclipse compiler ! javafx-beans/src/javafx/collections/transformation/SortedList.java
hg: openjfx/8/graphics/rt: RT-30862: Animated text leaves cheese on the scene
Changeset: c549e432383d Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-06-05 11:39 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c549e432383d RT-30862: Animated text leaves cheese on the scene ! prism-common/src/com/sun/prism/impl/GlyphCache.java
Re: Usecase for needsLayout property?
Thanks Martin,
I've done my best to quickly extract the code from my application...
however, I cannot reproduce the issue there in a direct fashion --
however, I did discover an issue which may be the reason I see a partial
group, I filed that as RT-30952 (TilePane doesn't appear until after
Stage resized a bit).
Basically, my main application is much more active, and will do a lot
of background stuff, which may trigger more layouts -- that's why there
I may only see the partial group for a moment (flickering when I scroll
through the big list) before it gets displayed completely. In this test
application, I see it much more directly where the group that I want to
see is simply not complete until more action is taken.
I also filed another issue, RT-30951 because the resizing of a Stage is
very jittery (the controls keep moving a bit from their correct
positions when in the process of resizing a Stage)... seems like some
font-metrics or other calculation is not producing repeatable results
resulting in a slightly different layout every time...
--John
On 5/06/2013 13:04, Martin Sladecek wrote:
Hi John,
the problem you described is most likely caused by something else as
the layout pass occurs BEFORE the actual rendering.
Also, you bind managed and visible of the entire VBox, not just the
title. So it's strange that you see Label correctly laid-out, but not
the content.
Can you make some sample and attach it to a JIRA issue, so I can have
a look what's actually happening there?
Thanks,
-Martin
On 06/05/2013 11:29 AM, John Hendrikx wrote:
I'm having a bit of a chicken-egg problem with regards to some
dynamically sized components I'm displaying in my application.
Description:
I have a group with a title that wraps some content and displays a
title above it -- the entire group, including the title must be
hidden and unmanaged when the content it is wrapping is empty, here
it is in code:
protected Pane createTitledBlock(final String title, final Node
content, final BooleanExpression visibleCondition) {
return new VBox() {{
setFillWidth(true);
getChildren().add(new Label(title) {{
getStyleClass().add(header);
}});
getChildren().add(content);
if(visibleCondition != null) {
managedProperty().bind(visibleCondition);
visibleProperty().bind(visibleCondition);
}
}};
}
Problem:
When the content becomes available and visibleCondition gets toggled
to true, the content part of the titled group is not yet laid out.
This causes the title to be visible without any content briefly until
a layout pass occurs.
Timeline:
- Group with title is hidden/unmanaged
- The content gets updated and visibleCondition is set to true
- Group with title becomes visible/managed
- Briefly an empty group with title is displayed
- Layout occurs, group with title gets resized
Now, I'm thinking of playing with the needsLayout property and
delaying the making visible/managed of the titled group until
needsLayout is false... however, I have a feeling that won't work as
an unmanaged/hidden group is probably not gonna participate in the
layout, resulting in needsLayout never becoming false again as it is
not visible/managed yet...
Any ideas how I could resolve this, and have the group with title
only visible and managed when it is properly laid out?
Also, has any progress in general been made with regards to
hidden/unmanaged controls and determining their expected size when
they're made visible/managed?
--John
hg: openjfx/8/graphics/rt: 3 new changesets
Changeset: dc90699e1820 Author:snorthov Date: 2013-06-05 14:55 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dc90699e1820 [COSMETIC CHANGE ONLY] workaround for Eclipse compiler ! apps/experiments/3DViewer/src/main/java/com/javafx/experiments/jfx3dviewer/TimelineController.java Changeset: a8528aa93120 Author:Alexander Kouznetsov Date: 2013-06-05 11:12 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a8528aa93120 Fix for RT-30891 Interpolators don't implement equals. Reviewed-by: Martin ! javafx-anim/src/com/sun/scenario/animation/NumberTangentInterpolator.java ! javafx-anim/src/com/sun/scenario/animation/SplineInterpolator.java ! javafx-anim/src/javafx/animation/Interpolator.java ! javafx-anim/test/unit/com/sun/scenario/animation/NumberTangentInterpolatorTest.java + javafx-anim/test/unit/com/sun/scenario/animation/SplineInterpolatorTest.java Changeset: 63bf3c13723a Author:Alexander Kouznetsov Date: 2013-06-05 12:19 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/63bf3c13723a Automated merge with ssh://jfxsrc.sfbay.sun.com//javafx/8.0/scrum/graphics/jfx/rt/
ObservableValue Stacktrace
Hi List,
I'm getting some log messages sometimes (see at the end) about
properties being null (whereas I didn't get them before in JavaFX 2.2).
Is this intended as an informative message to the developer, something I
should report, or just debug code for the JavaFX team?
In this case, the binding is null, and that's fine -- it will be
populated later, but the binding is already in place -- I thought JavaFX
was designed to allow nulls in a chain of bindings and
fall back to reasonable defaults for things like Strings, numbers etc?
Am I doing something wrong?
Code:
{
private final ObjectPropertyMedia data = new SimpleObjectProperty();
public ObjectPropertyMedia dataProperty() { return data; }
protected final ObjectBindingObservableListCasting castings =
Bindings.select(dataProperty(), castings);
}
Log:
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
WARNING: Exception while evaluating select-binding [castings]
Jun 05, 2013 9:15:55 PM
com.sun.javafx.binding.SelectBinding$SelectBindingHelper getObservableValue
WARNING: Property 'castings' in ObjectProperty [bound, value: null] is null
java.lang.NullPointerException
at
com.sun.javafx.binding.SelectBinding$SelectBindingHelper.getObservableValue(SelectBinding.java:481)
at
com.sun.javafx.binding.SelectBinding$AsObject.computeValue(SelectBinding.java:92)
at javafx.beans.binding.ObjectBinding.get(ObjectBinding.java:152)
at
javafx.beans.binding.ObjectExpression.getValue(ObjectExpression.java:49)
at
com.sun.javafx.binding.ExpressionHelper.addListener(ExpressionHelper.java:53)
at
javafx.beans.binding.ObjectBinding.addListener(ObjectBinding.java:71)
at
javafx.beans.property.ObjectPropertyBase.bind(ObjectPropertyBase.java:170)
at
hs.mediasystem.TitledBlockSample.createCastingsRow(TitledBlockSample.java:114)
at hs.mediasystem.TitledBlockSample.start(TitledBlockSample.java:78)
at com.sun.javafx.application.LauncherImpl$5.run(LauncherImpl.java:810)
at com.sun.javafx.application.PlatformImpl$6.run(PlatformImpl.java:260)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:226)
at
com.sun.javafx.application.PlatformImpl$5$1.run(PlatformImpl.java:223)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl$5.run(PlatformImpl.java:223)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at
com.sun.glass.ui.win.WinApplication.access$300(WinApplication.java:39)
at com.sun.glass.ui.win.WinApplication$3$1.run(WinApplication.java:101)
at java.lang.Thread.run(Thread.java:724)
Regards,
--John
hg: openjfx/8/graphics/rt: RT-13813: Full screen overlay warning needs to be MT safe
Changeset: 4f4bc0128afe Author:snorthov Date: 2013-06-05 16:28 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4f4bc0128afe RT-13813: Full screen overlay warning needs to be MT safe ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassStage.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/OverlayWarning.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java
JDK 8 dependency
Hi guys, To help the JDK 7 back port effort, I wanted to bring up a JIRA issue which will have some impact on that back port to both let you know the issue and see what you think about it. Basically, until we fix this issue, the JDK cannot remove some code that they are planning to remove in 8. I think this is a place where the back port will need to have some patch to basically undo what I'm about to do :-) https://javafx-jira.kenai.com/browse/RT-29523 We can carry on the discussion in this bug. Richard
hg: openjfx/8/graphics/rt: RT-30954: Open Source javafx-accessible
Changeset: 1725cd8784b0 Author:rbair Date: 2013-06-05 14:35 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1725cd8784b0 RT-30954: Open Source javafx-accessible ! generator.gradle ! glass/build-closed.xml + javafx-accessible/build-closed.xml + javafx-accessible/build.xml + javafx-accessible/nbproject/project.xml + javafx-accessible/project.properties + javafx-accessible/src/com/sun/javafx/accessible/providers/Accessible.java + javafx-accessible/src/com/sun/javafx/accessible/providers/AccessibleProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/AccessibleStageProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/ExpandCollapseProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/GridItemProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/GridProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/InvokeProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/RangeValueProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/SelectionItemProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/SelectionProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/ToggleProvider.java + javafx-accessible/src/com/sun/javafx/accessible/providers/ValueProvider.java + javafx-accessible/src/com/sun/javafx/accessible/utils/ControlTypeIds.java + javafx-accessible/src/com/sun/javafx/accessible/utils/EventIds.java + javafx-accessible/src/com/sun/javafx/accessible/utils/ExpandCollapseState.java + javafx-accessible/src/com/sun/javafx/accessible/utils/NavigateDirection.java + javafx-accessible/src/com/sun/javafx/accessible/utils/OrientationType.java + javafx-accessible/src/com/sun/javafx/accessible/utils/PatternIds.java + javafx-accessible/src/com/sun/javafx/accessible/utils/PropertyIds.java + javafx-accessible/src/com/sun/javafx/accessible/utils/ProviderOptions.java + javafx-accessible/src/com/sun/javafx/accessible/utils/Rect.java + javafx-accessible/src/com/sun/javafx/accessible/utils/ToggleState.java ! javafx-ui-common/build-closed.xml ! javafx-ui-common/project.properties ! javafx-ui-controls/build-closed.xml ! javafx-ui-quantum/build-closed.xml ! javafx-ui-quantum/project.properties ! test-stub-toolkit/build-closed.xml ! test-stub-toolkit/project.properties
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: fc584651b922 Author:snorthov Date: 2013-06-05 18:29 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/fc584651b922 Backed out of changeset 3837:4f4bc0128afe ! javafx-ui-common/src/com/sun/javafx/tk/Toolkit.java ! javafx-ui-common/src/javafx/scene/Scene.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/AbstractPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/GlassStage.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/OverlayWarning.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/QuantumToolkit.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/WindowStage.java Changeset: 9d3e54202b29 Author:snorthov Date: 2013-06-05 18:30 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/9d3e54202b29 Merge with fc584651b922c9a366c874dba602382c5b78daef
hg: openjfx/8/graphics/rt: fix .classpath
Changeset: d9e00fa40ee1 Author:snorthov Date: 2013-06-05 18:58 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/d9e00fa40ee1 fix .classpath ! .classpath
Re: [API review] RT-30668: ClipboardContent has buggy API
Issue 1: Every putSomething method documentation says: * Setting this value to null effectively clears it from the clipboard. * @throws NullPointerException if null reference is passed We need to choose one of the two described behaviors. Currently the code throws NPE. For some complicated content creation logic the clearing may be useful, so I propose to let the passed null reference clear the value. Sounds fine (I prefer not having the exception for sure). Issue 2: Every putSomething method documentation says: * @return True if the something was successfully placed on the clipboard. And in other places it refers to this clipboard. But this is not clipboard, it is the ClipboardContent which is later set to the Clipboard - and this operation returns the successful boolean. So we definitely should rephrase the documentation. In the putter, if we say * @return True if the something was successfully placed on the clipboard content. then it needs to always return true (putting a reference to a map doesn't fail) which is not the case right now (right now the behavior is senseless, it returns true if the same thing is put there for the second time). As the always true is not really useful, and because of backward compatibility we can hardly change the return value to map's usual previous value, we can consider at least redefining the boolean to something like returns true if a previously added value was replaced. What do you think? I'd probably go with the always true, which not useful but at least quite intuitive. I would document it to return always true to spare users pointless checks. I agree. Thanks Richard
hg: openjfx/8/graphics/rt: Fix to RT-30340: Functional regression in Charts.Scatter benchmark on embedded since h995 of graphics scrum
Changeset: e7050b44101a Author:Chien Yang chien.y...@orcale.com Date: 2013-06-06 09:32 +0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/e7050b44101a Fix to RT-30340: Functional regression in Charts.Scatter benchmark on embedded since h995 of graphics scrum Reviewed by Kevin ! prism-common/src/com/sun/prism/impl/BaseGraphics.java
hg: openjfx/2u/master/rt: Added tag 2.2.40-b28 for changeset fac50f983ffa
Changeset: 6b5ccbc93d06 Author:hudson Date: 2013-06-05 13:23 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/master/rt/rev/6b5ccbc93d06 Added tag 2.2.40-b28 for changeset fac50f983ffa ! .hgtags
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 7ac411e54de3 Author:Richard Bair richard.b...@oracle.com Date: 2013-06-05 19:08 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7ac411e54de3 RT-30499: Rename groovy/com/sun/javafx/build package to something without build in the name Summary: renamed package to gradle. - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/CCTask.groovy - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/CompileHLSLTask.groovy - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/CompileResourceTask.groovy - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/JavaHeaderTask.groovy - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/LinkTask.groovy - gradleBuildSrc/src/main/groovy/com/sun/javafx/build/NativeCompileTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/CCTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/CompileHLSLTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/CompileResourceTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/JavaHeaderTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/LinkTask.groovy + gradleBuildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy Changeset: 0049b4190d1b Author:Chien Yang chien.y...@orcale.com Date: 2013-06-06 10:13 +0800 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/0049b4190d1b Fix to RT-30594: Evaluate the restriction set on Mesh's indexBuffer (see RT-30448) Reviewed by Kevin ! javafx-ui-common/src/javafx/scene/shape/TriangleMesh.java ! prism-common/src/com/sun/prism/impl/BaseMesh.java ! prism-d3d-native/src/D3DContext.cc ! prism-d3d-native/src/D3DMesh.cc ! prism-d3d-native/src/D3DMesh.h ! prism-d3d/src/com/sun/prism/d3d/D3DContext.java ! prism-d3d/src/com/sun/prism/d3d/D3DMesh.java ! prism-es2-native/src/GLContext.c ! prism-es2-native/src/PrismES2Defs.h ! prism-es2/src/com/sun/prism/es2/ES2Context.java ! prism-es2/src/com/sun/prism/es2/ES2Mesh.java ! prism-es2/src/com/sun/prism/es2/GLContext.java
Re: Preloaders
Great news - happy to provide more input and feedback into the new tools/APIs when you get to that. I'd guess that Danno's probably got some good input for that side of it too - would be great to keep the conversations open and on this mailing list. For my money, I'd vote for only show stopper bugs getting fixed on the existing packager code base, and you focus on getting it all cleaned up and working nice and a better pattern for contributions in place. That could allow us to contribute more and stop you churning endlessly on a backlog of bugs. Cheers, Dan On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe mark.h...@oracle.com wrote: I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
Re: Preloaders
For me the biggest add would be for some form of runtime configuration of the packager, as well as the bundler params. this would allow outside contributors to cerate an APK bundler or an iOS bundler of many forms without having to adjust the core code, and allowing them to be brought in at runtime (the runtime of the build). This also extends to the bundle params having an open-ended property set of some sort, so things that matter to random packaging formats don't leak into other bundle params. My dream would be to be able to create an APK or other such bundle just by flipping a param in the packager call form an otherwise desktop app. On Wed, Jun 5, 2013 at 8:33 PM, Daniel Zwolenski zon...@gmail.com wrote: Great news - happy to provide more input and feedback into the new tools/APIs when you get to that. I'd guess that Danno's probably got some good input for that side of it too - would be great to keep the conversations open and on this mailing list. For my money, I'd vote for only show stopper bugs getting fixed on the existing packager code base, and you focus on getting it all cleaned up and working nice and a better pattern for contributions in place. That could allow us to contribute more and stop you churning endlessly on a backlog of bugs. Cheers, Dan On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe mark.h...@oracle.com wrote: I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be set. I don't use them but people using the maven plugin want them. It looks like you can set a preloader for both jars and for bundles (web, native). When building the bundles however they include the jar in them. So we end up with both the bundle, and the jar within the bundle, getting the preloader set. Does anyone know what will or should happen in this case? Does one preloader take precedence and the other is ignored, or are both used at different times and I should allow the user to set a different jar preloader to the bundle one, or is this setup invalid and I should actually not pass the preloader setting to one or the other in this case? Not using Preloaders myself and with the packaging tool code being a complete mess, it would be good to know the expectations here so I can properly support the users wanting this. Cheers Dan
Re: Preloaders
To sum up my previous major suggestions for a better world: - everything should be easily configurable via runtime params passed to packager code: input paths, output paths, paths to native tools, resources, includes, file names, etc. Everything! - web deploy code should be separate module from native, and jar separate again. Each native module (win, Linux, Mac) should be separate and I should be able to invoke any and all of them how and when I want, not just one generateDeployment method as the only entry point. - java code of packager should be one library for all platforms so we have one jar for all, not a separate one for each OS. Native bits are referenced from this one jar as needed. - native should not have dumb stuff from web as a requirement if not used. Signing, special jfx meta-inf in jars, checking registry for jdk, etc, etc. Native is actually very simple and really should be able to work with a stock standard jar and not need a special jfx built one. Web should be quarrantined so that native isn't sullied by it. - no magic config in the core libraries (higher wrappers can try and add it on top). Eg It shouldn't look for wix and use it just because it's installed. I should be able to specify I want wix or inno and tools should fail if they are not there. That's just looking at improvements to what's already there. As far as my picks for new features, these would be my top: - app store support (desktop at this stage) - auto updating support for native bundles - cross platform builds on the one machine (ie build for Mac from a windows machine, etc). Also build a 32bit distro on a 64bit jdk, etc. - compact jre's for smaller distro sizes. Just a little wish list :) Cheers, Dan On 06/06/2013, at 1:15 PM, Danno Ferrin danno.fer...@shemnon.com wrote: For me the biggest add would be for some form of runtime configuration of the packager, as well as the bundler params. this would allow outside contributors to cerate an APK bundler or an iOS bundler of many forms without having to adjust the core code, and allowing them to be brought in at runtime (the runtime of the build). This also extends to the bundle params having an open-ended property set of some sort, so things that matter to random packaging formats don't leak into other bundle params. My dream would be to be able to create an APK or other such bundle just by flipping a param in the packager call form an otherwise desktop app. On Wed, Jun 5, 2013 at 8:33 PM, Daniel Zwolenski zon...@gmail.com wrote: Great news - happy to provide more input and feedback into the new tools/APIs when you get to that. I'd guess that Danno's probably got some good input for that side of it too - would be great to keep the conversations open and on this mailing list. For my money, I'd vote for only show stopper bugs getting fixed on the existing packager code base, and you focus on getting it all cleaned up and working nice and a better pattern for contributions in place. That could allow us to contribute more and stop you churning endlessly on a backlog of bugs. Cheers, Dan On Thu, Jun 6, 2013 at 1:21 AM, Mark Howe mark.h...@oracle.com wrote: I actually spent at least half my time on the packager the last two weeks - woo hoo :). Still have other priorities but am finding time for the packager. Working on a few critical packager bugs right now. Then later this week going to finally get Danno's patches in. There are a lot of packager bugs in the backlog. Once some of that backlog is cleared up I am going to do some refactoring, really want to make the code simpler, cleaner and more obvious - and subsequently easier to contribute to. Cheers On Jun 5, 2013, at 5:14 AM, Daniel Zwolenski zon...@gmail.com wrote: Thanks Mark. If the user sets a preloader in the plugin I'm going to pass that same class to the jar and to the native bundle. I guess people will complain to me if that doesn't work and I'll point them your way. Are they ever going to let you do some packager stuff? I gave up waiting for the revolution and rebuilt the maven plugin to be less crap than it was but its the underlying packaging tools that need the rewrite if JFX is ever going to have a decent deployment option. On 05/06/2013, at 3:58 AM, Mark Howe mark.h...@oracle.com wrote: It should be the one within the bundle otherwise deploying an app bundle won't work. If you find otherwise please create an issue. Cheers Mark On May 29, 2013, at 6:51 AM, Scott Palmer swpal...@gmail.com wrote: I think native bundles should use the preloader contained within. I use the Preloader to implement a splash screen since my app takes a long time to start up, even though all the jars are already downloaded. On Wed, May 29, 2013 at 8:40 AM, Daniel Zwolenski zon...@gmail.com wrote: The jfx packaging tools allow pre-loaders to be
