from:"Stephen F Northover"


I am only seeing the runnable fired once in FX 8u40.

Steve

Steps:

1) Run TestKeyCombination
2) Press Control+-

Here is the test code:

import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.input.KeyCharacterCombination;
import javafx.scene.input.KeyCode;
import javafx.scene.input.KeyCodeCombination;
import javafx.scene.input.KeyCombination;
import javafx.stage.Stage;

public class TestKeyCombination extends Application {
public static void main(String[] args) {
Application.launch(args);
}

@Override public void start(Stage stage) {
stage.setTitle(Test KeyCombination);
Scene scene = new Scene(new Group(), 600, 450);
Button button1 = new Button();
button1.setText(Click Me);
stage.setScene(scene);
stage.show();

KeyCombination cmdMinus = new KeyCodeCombination(KeyCode.MINUS, 
KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
KeyCharacterCombination(-, KeyCombination.CONTROL_DOWN);

Runnable runnable = () - System.out.println(HI);
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
}
}


On 2014-09-26, 1:01 PM, Scott Palmer wrote:

KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new Key*Character*Combination(-,
KeyCombination.CONTROL_DOWN);

Using the above like this:
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);

Will result in the runnable being fired twice from the same keypress.

I propose changing the accelerator processing logic so that only one
runnable gets called as the intention appears to be that a KeyCombination
can only have one runnable associated with it, but the logic in Map doesn't
see the above two KeyCombinations as the same key in the Map.

Note: With the second combination above I really wanted something that
worked for both MINUS and SUBTRACT simultaneously - since they both type
the same Character and only one accelerator can be set on a MenuItem.

Scott

Re: Accelerators - odd behavior


This is on Mac.  Will try Windows.

Steve

On 2014-09-26, 1:24 PM, Kevin Rushforth wrote:
Is this on a Mac or on Windows?  I just ran your test case and I get 
two runnables, which is what I would expect.


-- Kevin


Stephen F Northover wrote:

I am only seeing the runnable fired once in FX 8u40.

Steve

Steps:

1) Run TestKeyCombination
2) Press Control+-

Here is the test code:

import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.input.KeyCharacterCombination;
import javafx.scene.input.KeyCode;
import javafx.scene.input.KeyCodeCombination;
import javafx.scene.input.KeyCombination;
import javafx.stage.Stage;

public class TestKeyCombination extends Application {
public static void main(String[] args) {
Application.launch(args);
}

@Override public void start(Stage stage) {
stage.setTitle(Test KeyCombination);
Scene scene = new Scene(new Group(), 600, 450);
Button button1 = new Button();
button1.setText(Click Me);
stage.setScene(scene);
stage.show();

KeyCombination cmdMinus = new 
KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
KeyCharacterCombination(-, KeyCombination.CONTROL_DOWN);

Runnable runnable = () - System.out.println(HI);
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
}
}


On 2014-09-26, 1:01 PM, Scott Palmer wrote:

KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
Key*Character*Combination(-,

KeyCombination.CONTROL_DOWN);

Using the above like this:
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);

Will result in the runnable being fired twice from the same keypress.

I propose changing the accelerator processing logic so that only one
runnable gets called as the intention appears to be that a 
KeyCombination
can only have one runnable associated with it, but the logic in Map 
doesn't

see the above two KeyCombinations as the same key in the Map.

Note: With the second combination above I really wanted something that
worked for both MINUS and SUBTRACT simultaneously - since they both 
type

the same Character and only one accelerator can be set on a MenuItem.

Scott

Re: Accelerators - odd behavior

Two on Windows, one on Mac.  See 
https://javafx-jira.kenai.com/browse/RT-38830


Steve

On 2014-09-26, 1:25 PM, Stephen F Northover wrote:

This is on Mac.  Will try Windows.

Steve

On 2014-09-26, 1:24 PM, Kevin Rushforth wrote:
Is this on a Mac or on Windows?  I just ran your test case and I get 
two runnables, which is what I would expect.


-- Kevin


Stephen F Northover wrote:

I am only seeing the runnable fired once in FX 8u40.

Steve

Steps:

1) Run TestKeyCombination
2) Press Control+-

Here is the test code:

import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.input.KeyCharacterCombination;
import javafx.scene.input.KeyCode;
import javafx.scene.input.KeyCodeCombination;
import javafx.scene.input.KeyCombination;
import javafx.stage.Stage;

public class TestKeyCombination extends Application {
public static void main(String[] args) {
Application.launch(args);
}

@Override public void start(Stage stage) {
stage.setTitle(Test KeyCombination);
Scene scene = new Scene(new Group(), 600, 450);
Button button1 = new Button();
button1.setText(Click Me);
stage.setScene(scene);
stage.show();

KeyCombination cmdMinus = new 
KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
KeyCharacterCombination(-, KeyCombination.CONTROL_DOWN);

Runnable runnable = () - System.out.println(HI);
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
}
}


On 2014-09-26, 1:01 PM, Scott Palmer wrote:

KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
Key*Character*Combination(-,

KeyCombination.CONTROL_DOWN);

Using the above like this:
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);

Will result in the runnable being fired twice from the same keypress.

I propose changing the accelerator processing logic so that only one
runnable gets called as the intention appears to be that a 
KeyCombination
can only have one runnable associated with it, but the logic in Map 
doesn't

see the above two KeyCombinations as the same key in the Map.

Note: With the second combination above I really wanted something that
worked for both MINUS and SUBTRACT simultaneously - since they both 
type

the same Character and only one accelerator can be set on a MenuItem.

Scott

Re: Accelerators - odd behavior

Agree.  Suggest that we move the discussion to the JIRA to capture the 
background information for whoever will address the bug.


Steve

On 2014-09-26, 1:41 PM, Kevin Rushforth wrote:

It may or may not be a bug, but it will be good to investigate.

-- Kevin


Stephen F Northover wrote:
Two on Windows, one on Mac.  See 
https://javafx-jira.kenai.com/browse/RT-38830


Steve

On 2014-09-26, 1:25 PM, Stephen F Northover wrote:

This is on Mac.  Will try Windows.

Steve

On 2014-09-26, 1:24 PM, Kevin Rushforth wrote:
Is this on a Mac or on Windows?  I just ran your test case and I 
get two runnables, which is what I would expect.


-- Kevin


Stephen F Northover wrote:

I am only seeing the runnable fired once in FX 8u40.

Steve

Steps:

1) Run TestKeyCombination
2) Press Control+-

Here is the test code:

import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.input.KeyCharacterCombination;
import javafx.scene.input.KeyCode;
import javafx.scene.input.KeyCodeCombination;
import javafx.scene.input.KeyCombination;
import javafx.stage.Stage;

public class TestKeyCombination extends Application {
public static void main(String[] args) {
Application.launch(args);
}

@Override public void start(Stage stage) {
stage.setTitle(Test KeyCombination);
Scene scene = new Scene(new Group(), 600, 450);
Button button1 = new Button();
button1.setText(Click Me);
stage.setScene(scene);
stage.show();

KeyCombination cmdMinus = new 
KeyCodeCombination(KeyCode.MINUS, KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
KeyCharacterCombination(-, KeyCombination.CONTROL_DOWN);

Runnable runnable = () - System.out.println(HI);
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);
}
}


On 2014-09-26, 1:01 PM, Scott Palmer wrote:

KeyCombination cmdMinus = new Key*Code*Combination(KeyCode.MINUS,
KeyCombination.CONTROL_DOWN);
KeyCombination cmdMinusFromCharacter = new 
Key*Character*Combination(-,

KeyCombination.CONTROL_DOWN);

Using the above like this:
scene.getAccelerators().put(cmdMinus, runnable);
scene.getAccelerators().put(cmdMinusFromCharacter, runnable);

Will result in the runnable being fired twice from the same 
keypress.


I propose changing the accelerator processing logic so that only one
runnable gets called as the intention appears to be that a 
KeyCombination
can only have one runnable associated with it, but the logic in 
Map doesn't

see the above two KeyCombinations as the same key in the Map.

Note: With the second combination above I really wanted something 
that
worked for both MINUS and SUBTRACT simultaneously - since they 
both type
the same Character and only one accelerator can be set on a 
MenuItem.


Scott

Re: Time spinner in 8u40

2014-09-17 Thread Stephen F Northover


Hi Peter,

There are no plans to make the time spinner public for 8u40 as we are 
past FF (Feature Freeze).  Originally, the time spinner was intended to 
be part of the new spinner control but there were some issues with it 
involving tracking the caret.


It's all discussed in: https://javafx-jira.kenai.com/browse/RT-37968

Steve

On 2014-09-17, 6:22 AM, Peter Penzov wrote:

Hi All,
 I successfully tested Spinner control in 8u40.

final Spinner spinner = new Spinner();

 spinner.setValueFactory(new
SpinnerValueFactory.IntegerSpinnerValueFactory(0, 1));
 spinner.setEditable(true);

I noticed that there is a Java method for time spinner
LocalDateSpinnerValueFactory in SpinnerValueFactory. But the Java Method is
not public. Are there plans to release time spinner in 8u40?

BR,
Peter

Re: RichTextEditor in 8u40

2014-09-17 Thread Stephen F Northover


Hi Peter,

There was never an intent to have a RichTextEditor for 8u40.  The wiki 
is tracking milestones for committed work and the possibility of 
starting work on a RichTextEditor prototype.  At this point, given the 
bug backlog and other work that is targeted to 8u40, it's looking very 
unlikely that we will get to this.


Steve

On 2014-09-17, 8:11 AM, Peter Penzov wrote:

Hi All,
Looking at the 8u40 road map there are plans for RichTextEdito:

https://wiki.openjdk.java.net/display/OpenJFX/8u40

Is there any code example that I can test?

BR,
Peter

Re: OpenJFX Wiki and the Platforms location.

2014-09-12 Thread Stephen F Northover



On 2014-09-12, 10:54 AM, David Hill wrote:


https://wiki.openjdk.java.net/display/OpenJFX/Platforms

Just noticed that we have Main - Getting Started - Platform - 
bunch of neat stuff.
Feels odd that Platform is under Getting Started, as it has evolved to 
be a bunch of platform specific, and JavaFX feature general 
notes/documentation.


Does it make sense to move Platform to be under Main ?

Makes sense to me.  Platforms under Getting Started is likely there for 
historical reasons.


Steve

Re: Lighthouse

2014-09-12 Thread Stephen F Northover

Thanks for getting back to us Mike and letting us know about your 
successful use of JavaFX.  The team does work hard and appreciates the 
kind words.


Steve

On 2014-09-12, 2:42 PM, Mike Hearn wrote:

I've open sourced the JavaFX app I was working on for the past six months
or so. Lighthouse is a Bitcoin crowdfunding application that uses some of
the more novel features of the Bitcoin protocol to allow middleman free
fund raising.

There's a video of it in action here:

http://blog.vinumeris.com/2014/09/12/lighthouse-alpha-now-open-source/

and some screenshots here:

https://github.com/vinumeris/lighthouse

Additionally I've open sourced UpdateFX, which is an auto update engine
that provides some interesting features:

https://github.com/vinumeris/updatefx

It's kind of rough still but if anyone is looking for an alternative to the
existing update engines out there, take a look.

I just wanted to say thanks to the OpenJFX team for your help and support
this summer. I've very much enjoyed working both with you all and the
framework you've created. I believe JavaFX is a surprisingly good fit for
the Bitcoin community, because we suffer quite badly from the limitations
and problems of web apps. HTML5 + decentralisation don't mix very well. A
plain old desktop app works better, and JavaFX is a good way to build such
things.

thanks,
-mike

Re: Problem accessing jfx native libs under eclipse on windows

2014-09-12 Thread Stephen F Northover


Hi Richard,

Did you follow the instructions at this link: 
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE ?


You are picking up a set of shared libraries that do not match the java 
code you are running in the IDE.  You need to set java.library.path.  
It's on the wiki and I meant to update it to be something sensible.  My 
build puts the dll's in an artifacts directory:


-Djava.library.path=${workspace_loc:rt}/../artifacts/sdk/rt/bin

You will need to edit this expression to pick up the dll's from the 
standard build place (which I forget right now).


Steve

On 2014-09-12, 5:31 PM, Richard Steiger wrote:
I'm a newbie to JavaFX, and hoping to be able to contribute down the 
road once I learn much more about it.


To that end, I've been trying to get 8u-dev eclipse projects setup on 
a Win7 box so I can start stepping through the code.  The current 
show-stopper is getting UnsatisfiedLinkErrors when the system is 
trying to access dlls, such as glass.dll.


My rig:

 * jdk1.8.0_05
 * eclipse-SDK-N20140722-2000-win32-x86_64 (Mars stable build, has fix
   for StackOverflow bug in eclipse j8 compiler)
 * hg clone of 8u-dev as of 8/26

Setup:

 * ran the gradle build (successfully)
 * imported the eclipse projects in the repo, all cleanly compile (but
   had to fix cross-project links and manually locate and attach 3p libs)
 * removed javafx.* and related JavaFX sources from JAVA_HOME/src
 * moved jfxrt.jar to a cache directory

Failure situation:

 * attempting to launch jfx apps under eclipse debugger

The following console output is typical of what I'm running into (with 
-verbose:jni on the command line):


[Dynamic-linking native method java.lang.Object.registerNatives ... JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives ... JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives ... JNI]
[Registering JNI native method java.lang.Thread.start0]
[Registering JNI native method java.lang.Thread.stop0]
[Registering JNI native method java.lang.Thread.isAlive]
[Registering JNI native method java.lang.Thread.suspend0]
[Registering JNI native method java.lang.Thread.resume0]
[Registering JNI native method java.lang.Thread.setPriority0]
[Registering JNI native method java.lang.Thread.yield]
[Registering JNI native method java.lang.Thread.sleep]
[Registering JNI native method java.lang.Thread.currentThread]
[Registering JNI native method java.lang.Thread.countStackFrames]
[Registering JNI native method java.lang.Thread.interrupt0]
[Registering JNI native method java.lang.Thread.isInterrupted]
[Registering JNI native method java.lang.Thread.holdsLock]
[Registering JNI native method java.lang.Thread.getThreads]
[Registering JNI native method java.lang.Thread.dumpThreads]
[Registering JNI native method java.lang.Thread.setNativeName]
[Dynamic-linking native method 
java.security.AccessController.getStackAccessControlContext ... JNI]
[Dynamic-linking native method 
java.security.AccessController.getInheritedAccessControlContext ... JNI]

[Dynamic-linking native method java.lang.Class.registerNatives ... JNI]
[Registering JNI native method java.lang.Class.getName0]
[Registering JNI native method java.lang.Class.getSuperclass]
[Registering JNI native method java.lang.Class.getInterfaces0]
[Registering JNI native method java.lang.Class.getClassLoader0]
[Registering JNI native method java.lang.Class.isInterface]
[Registering JNI native method java.lang.Class.getSigners]
[Registering JNI native method java.lang.Class.setSigners]
[Registering JNI native method java.lang.Class.isArray]
[Registering JNI native method java.lang.Class.isPrimitive]
[Registering JNI native method java.lang.Class.getComponentType]
[Registering JNI native method java.lang.Class.getModifiers]
[Registering JNI native method java.lang.Class.getDeclaredFields0]
[Registering JNI native method java.lang.Class.getDeclaredMethods0]
[Registering JNI native method java.lang.Class.getDeclaredConstructors0]
[Registering JNI native method java.lang.Class.getProtectionDomain0]
[Registering JNI native method java.lang.Class.getDeclaredClasses0]
[Registering JNI native method java.lang.Class.getDeclaringClass0]
[Registering JNI native method java.lang.Class.getGenericSignature0]
[Registering JNI native method java.lang.Class.getRawAnnotations]
[Registering JNI native method java.lang.Class.getConstantPool]
[Registering JNI native method java.lang.Class.desiredAssertionStatus0]
[Registering JNI native method java.lang.Class.getEnclosingMethod0]
[Registering JNI

Re: [8u] Review request: RT-38290: [WebView] HTML canvas clip() functionality broken

2014-08-26 Thread Stephen F Northover


Hi Anton T,

The policy for OpenJFX is that code reviews happen in the associated JIRA:

https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews

Thanks for reviewing this code,

Steve

On 2014-08-26, 3:30 PM, Anton V. Tarasov wrote:

Hi Anton,

Does it make sense to add a boolean param to renderLayer() which would 
tell it if it should dispose the layer after rendering? In order to 
avoid the splitting.


Also, could you please clarify the following.

From your comments:

  72 // WCBufferedContext might be referenced from a client JS 
code and thus
  73 // couldn't be disposed right after rendering operations 
on it.


However, when it is disposed (will it?) it looks like it will 
re-render all the layers (WCGraphicsPrismContext.dispose). Is it an 
expected behavior?


Thanks,
Anton.


On 8/20/14 9:26 PM, anton nashatyrev wrote:

Hello,

could you please review the fix for 
https://javafx-jira.kenai.com/browse/RT-38290 ?


Thank you!
Anton.

Re: In(Sanity) Testing Mondays

2014-08-25 Thread Stephen F Northover


Hi Lisa,

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

I've updated the wiki to indicate the default action when a stopper is 
found as a result of (in)sanity.  The bottom line is that we will work 
to resolve the bug by 10PST, potentially reverting the change if it 
looks like we are not converging.


Steve

On 2014-08-22, 8:25 PM, Lisa Selle wrote:

Reminder, Monday is our weekly sanity testing.

You can find your (newly updated) testing assignment at:

https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 
1pm PDT.


Happy testing!

Lisa

Re: JavaFX 8 and TextFields

2014-08-18 Thread Stephen F Northover


This seems to be the bug: https://javafx-jira.kenai.com/browse/RT-36987

It's quite a mystery.  It's likely a shader problem but that's just a guess.

Steve

On 2014-08-18, 10:21 AM, Eric Le Ponner wrote:

Dirk, Anothony,

I’ve never observed this visual artifact on Mac OS 10.9 (.4)
no matter it’s SB 2.0 (i.e. b20) or latest SB (with latest FX8dev code).

Strange…

Could it be related to the graphics pipeline ?
What model of Mac are you using Dirk ?

Eric



Le 18 août 2014 à 15:34, Anthony Petrov anthony.pet...@oracle.com a écrit :


Hi Dirk,

This looks like a bug. Could you please verify if the latest 8u20 ea build 
works for you? You can download it at:

http://jdk8.java.net/download.html


If it still fails, please file a new bug at

https://javafx-jira.kenai.com/secure/CreateIssue!default.jspa

--
best regards,
Anthony

On 8/18/2014 5:28 PM, Dirk Dittert wrote:

Hi,

I'm wondering about the design of TextFields in JavaFX 8. Why are they
having a horizontal line through the input area? I find that this looks
rather peculiar...

I posted some screenshots here:
http://d.dittert.org/E4D7EB53-D198-47AC-9230-53E9A23F6767/

One is from SceneBuilder 2.0-b20 on OS X 10.9. The other one is from one of
my applications (running on 1.8.0_11) on OS X.

Thanks,
Dirk

Re: [8u40] Review Request: (RT-37418) CustomColorDialog cannot be skinned by adding stylesheet to scene.

2014-08-06 Thread Stephen F Northover

Might be better to get Jonathan to look at it as he is the owner of 
controls.  Anyhow, off to the JIRA ...


Steve

On 2014-08-06, 12:49 PM, David Grieve wrote:

Kevin, Steve,

Please review https://javafx-jira.kenai.com/browse/RT-37418. The 
changes are small and can be found in JIRA.

Re: [API REVIEW REQUEST] RT-19659 - [TabPane] Support for draggable tabs

2014-07-30 Thread Stephen F Northover


Thanks Tom,

We'll take a look at the patch in the JIRA: 
https://javafx-jira.kenai.com/browse/RT-19659


Steve

On 2014-07-30, 3:35 AM, Tom Schindl wrote:

Hi,

I'd like you to review the API proposed to make TabPane Tabs draggable.

The proposed public API only allows to put the TabPane in DnD mode:

public boolean isDndEnabled()
public void setDndEnabled(boolean dndEnabled)
public BooleanProperty dndEnabledProperty()

Tom

Re: error while building JFX 8udev for iOS (2)

2014-07-29 Thread Stephen F Northover


Belay that.  This works for me in 8u-dev:

gradle -PCOMPILE_TARGETS=ios -PUSE_LIPO=true -PIOS_VERSION=7.1

As far as I know, RoboVM does not support lambdas so the result will not 
run.


Steve

On 2014-07-29, 8:51 AM, Tobias Bley wrote:

@Oracle, can you help me?



Anfang der weitergeleiteten Nachricht:

Von: Tobias Bley t...@ultramixer.com
Betreff: error while building JFX 8udev for iOS
Datum: 15. Juli 2014 13:52:11 MESZ
An: openjfx-dev@openjdk.java.net Mailing openjfx-dev@openjdk.java.net

Hi folks,

when I try to build JFX for iOS using „gradle sdk…“ i’m getting the following 
errors - is it a known issue?

Best regards,
Tobi



:graphics:ccIosPrismES2Arm
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:67:34:
 warning: implicit declaration of function 'createContext' is invalid in C99 
[-Wimplicit-function-declaration]
 context = (jlong) (intptr_t) createContext((void *) (intptr_t) 
nativeShareCtxHandle,
  ^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:76:14:
 warning: implicit declaration of function 'makeCurrentContext' is invalid in 
C99 [-Wimplicit-function-declaration]
 result = makeCurrentContext((void *) (intptr_t) context);
  ^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:78:9:
 warning: implicit declaration of function 'printAndReleaseResources' is 
invalid in C99 [-Wimplicit-function-declaration]
 printAndReleaseResources(0, context,
 ^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:137:13:
 warning: implicit declaration of function 
'getProcAddress' is invalid in C99 [-Wimplicit-function-declaration]
 getProcAddress(glActiveTexture);
 ^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:239:5:
 warning: implicit declaration of function 'setSwapInterval' is invalid in C99 
[-Wimplicit-function-declaration]
 setSwapInterval((void *) jlong_to_ptr(ctxInfo-context), 0);
 ^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLContext.c:59:22:
 warning:unused variable 'pfInfo' [-Wunused-variable]
 PixelFormatInfo* pfInfo =  (PixelFormatInfo* )jlong_to_ptr(nativePFInfo);
  ^
6 warnings generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSGLDrawable.c:108:5:
 warning: implicit declaration of function 'flushBuffer' is invalid in C99 
[-Wimplicit-function-declaration]
 flushBuffer((void *) (intptr_t) ctxInfo-context);
 ^
1 warning generated.
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:13:
 warning: format specifies type 'unsigned int' but the argument has type 'void 
*' [-Wformat]
 shareContext, view, pixelFormat, viewNotReady);
 ^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:27:
 warning: format specifies type 'unsigned int' but the argument has type 'void 
*' [-Wformat]
 shareContext, view, pixelFormat, viewNotReady);
   ^~~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:70:
 warning: flag ' ' results in undefined behavior with 'n' conversion specifier 
[-Wformat]
 fprintf(stderr, IOSWindowSystemInterface : share %x view %x pf % notready 
%\n,
 ~^~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:42:33:
 warning: format specifies type 'int *' but the argument has type 'void *' 
[-Wformat]
 shareContext, view, pixelFormat, viewNotReady);
 ^~~
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:41:81:
 warning:invalid conversion specifier '
' [-Wformat-invalid-specifier]
 fprintf(stderr, IOSWindowSystemInterface : share %x view %x pf % notready 
%\n,

~^
/Applications/Developer/Java/open-jfx-graphics-8u-dev2/rt/modules/graphics/src/main/native-prism-es2/ios/IOSWindowSystemInterface.m:60:12:
 warning: incompatible integer to pointer conversion returning 'jlong' (aka 
'long long') from a function with result type 'void *'

Re: 8u20 broken in OS X Yosemite?

2014-07-28 Thread Stephen F Northover


Scott and everyone else,

Please report Yosemite bugs as soon as you find them.

Thanks,
Steve

On 2014-07-28, 12:01 PM, Kevin Rushforth wrote:
Good to hear. We are doing some testing with Yosemite, but it is 
somewhat limited testing at this point.


-- Kevin


Scott Palmer wrote:
Just to follow up.. things are not as dire as I initially thought.  
After a

reboot my application is working much better.


On Sun, Jul 27, 2014 at 12:59 PM, Scott Palmer swpal...@gmail.com 
wrote:


Is anyone testing on Yosemite?  I installed the Yosemite public beta 
and

am running with 8u20 b23 (also tested with 8u11, same results)

Without violating my Beta Agreement with Apple, lets just say that I
strongly suggest that someone at Oracle try it out and perhaps focus 
on:

-AudioClips
-MediaPlayer
-Animation performance

Scott

Milestone moved: M1 is now Aug 11, 2014

2014-07-28 Thread Stephen F Northover


Hi all,

This week (July 28) is the week before M1 milestone (Aug 4) so we should 
be ramping down (ie. extra +1 restrictions for committing code, 
more/better testing, etc.).  Since this is the first milestone for 8u40 
and there important API deadlines, I spoke with Kevin and we agreed to 
move M1 back a week to Aug 11 to give us a bit more time before the ramp 
down.


I have updated the wiki: https://wiki.openjdk.java.net/display/OpenJFX/8u40

Steve

Re: JavaFX tuning

2014-07-28 Thread Stephen F Northover


Hi Peter,

Right now it's not possible to turn off modules.  Memory can be consumed 
in all sorts of different places (Java object memory, graphics card 
memory, operating system memory, virtual machine memory).  Did you have 
a case where you were running out and hitting an issue?


Steve

On 2014-07-23, 10:26 AM, Peter Penzov wrote:

Hi,
 What are the options for JavaFX tuning? For example is it possible to
turn off some modules of the framework or some configuration for lowering
the memory consumption?

BR,
Peter

Re: Only 1 GUI thread dialogs (was Re: 2 JavaFX applets in the same JVM)

2014-07-08 Thread Stephen F Northover

What is the question?  How are modal dialogs done in FX?  A new event 
loop is stacked on top of the old, running in the same thread.


Steve

On 2014-07-08, 5:54 PM, Richard Bair wrote:

Hmmm… FX Experience is running for me. Is anybody else having this problem?

Richard

On Jul 8, 2014, at 2:51 PM, ngalarn...@abinitio.com wrote:


Hi Steve,

My understanding of Swing was that when in a modal dialog, which blocked
the EDT, a second EDT was fired up for the duration of the dialog to keep
the events flowing.

When you say, below, that only 1 GUI thread is supported (and that thread
is the native GUI thread), how are (will?) modal dialogs handled?


Thanks,

Neil

P.S. I've been trying to read Jonathan's article on dialogs on
fxexperience.com, but haven't been able to because I get redirected to
hosting.xmission.com



From:   Stephen F Northover steve.x.northo...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com,
ngalarn...@abinitio.com,
Cc: openjfx-dev@openjdk.java.net
Date:   07/08/2014 03:41 PM
Subject:Re: 2 JavaFX applets in the same JVM



This would imply that there was more than on distinguished GUI thread
per process.  JavaFX runs in the native GUI thread by design and more
than one GUI thread is not supported in JavaFX and on some platforms
(ie. Mac).

Steve

On 2014-07-08, 3:31 PM, Kevin Rushforth wrote:

Is running 2 JavaFX applets in the same JVM supported?

No, this is not supported. RT-29969 (and the non-public RT-32321) is
about running multiple applets from the same web page, each in their
own JVM. By design, JavaFX runs each applet in its own VM. It is very
unlikely that we would ever add the ability to run more than JavaFX
applet in the same VM.

-- Kevin


ngalarn...@abinitio.com wrote:

Hello,

What is the status of running 2 JavaFX applets in the same JVM
(separate_jvm = false)?
When we try to load 2 applets into the same JVM we get a runtime
error (I think it was class loader related).

When I searched in jira I found RT-29969 (the 2 applet test it refers
to may or may not be in the same JVM) which points to RT-32321 which
seems to be private (it gives me an error when I try to access it).

Is running 2 JavaFX applets in the same JVM supported?

If not, is that a bug or a feature?


Thanks,

Neil



NOTICE from Ab Initio: This email (including any attachments) may
contain information that is subject to confidentiality obligations or
is legally privileged, and sender does not waive confidentiality or
privilege. If received in error, please notify the sender, delete
this email, and make no further use, disclosure, or distribution.





NOTICE from Ab Initio: This email (including any attachments) may contain
information that is subject to confidentiality obligations or is legally
privileged, and sender does not waive confidentiality or privilege. If
received in error, please notify the sender, delete this email, and make
no further use, disclosure, or distribution.

Re: ComboBox: TestEditor to ListView binding

2014-07-07 Thread Stephen F Northover


Hi Kirill,

I looked at this again quickly and while there might be a combination of 
events and listeners that can make a combo box behave this way, you are 
better to create your own search box and manage the popup list.  The 
reason for this is that any code you are likely to write that 
manipulates the combo box will be sensitive to event ordering.


There is an example of a search field as part of EnsembleApp.  It is 
quite complicated and fancy and is mixed in with EnsembleApp code so you 
might have to work a bit to extract a simpler version of what you are 
looking for.


Hopefully Jasper is reading this right now and can whip up a hundred 
lines of code or so that do what you want.


Steve

On 2014-07-04, 5:48 PM, Kirill Kirichenko wrote:

I'm implementing a searchbox.
In the textfield of the combobox I'm typing a search string. 
textProperty of the editor has an onChange listener which forms a list 
of strings that contain the text as a substring. Then I set this list 
of strings as a content of the drop down list of the combobox.
The problem is when I start selecting items in the drop down list the 
editor field gets updated making new substring search and updating the 
list again.
I want to break this dependency. I don't want to update the text 
property when I select an item in the drop down list OR I want to 
distinguish in the textProperty listener what caused that event - real 
editing the field or setting the field trough binding from the list view.


I hope I could make myself clear.
K

On 05.07.2014 01:21, Stephen F Northover wrote:

Hi Kirill,

What exactly are you trying to do?  The following (crap) listens for the
value to change and then sets it back:

 ChangeListenerString l = new ChangeListenerString () {
 public void changed(ObservableValue observable, String
oldValue,
 String newValue) {
 System.out.println(attempt to set new value:  +
newValue);
 Platform.runLater(() - {
comboBox3.valueProperty().removeListener(this);
 System.out.println(restoring old value:  +
newValue);
 comboBox3.setValue(oldValue);
comboBox3.valueProperty().addListener(this);
 });
 };
 };
 comboBox3.valueProperty().addListener(l);

This is not good code because it adds and removes a listener to avoid
notification when the value is reset.  It uses runLater() in order to
stop the combo box from getting confused when the value is changed from
within a changed listener.

Steve


On 2014-07-04, 3:09 PM, Kirill Kirichenko wrote:

JavaFX ComboBox has binding between TextEdit field and the ListView
selection such that edit field gets updated when we change the
selected item in the drop down list.
Is there a way to break this binding - when we select an item in the
list the editor field remains untouched. Where should I look at ?


Thanks.
K

Re: REMINDER: no push Mondays are still in effect

2014-07-07 Thread Stephen F Northover

The link that describes this process is here: 
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing


Note that the link has moved.

Steve

On 2014-07-07, 11:04 AM, Kevin Rushforth wrote:
Please note that we should still be observing the no push Monday 
rule, meaning that no changes should be pushed (other than to fix a 
build or test failure, or IDE changes, etc) after 1am Pacific on 
Mondays. Ordinarily it doesn't really matter, but today we had to 
restart the Hudson build due to a failure, which picked up changes 
pushed after 1am.


There is no action needed for this week. We are early enough in the 
build cycle for both 8u40 (prior to the first promoted EA build) and 9 
that we will just pick up the changes that were pushed after 1am. 
Please remember to observe the quiet period in the future though.


Thank you.

-- Kevin

Re: ComboBox: TestEditor to ListView binding

2014-07-04 Thread Stephen F Northover


Hi Kirill,

What exactly are you trying to do?  The following (crap) listens for the 
value to change and then sets it back:


ChangeListenerString l = new ChangeListenerString () {
public void changed(ObservableValue observable, String 
oldValue,

String newValue) {
System.out.println(attempt to set new value:  + 
newValue);

Platform.runLater(() - {
comboBox3.valueProperty().removeListener(this);
System.out.println(restoring old value:  + newValue);
comboBox3.setValue(oldValue);
comboBox3.valueProperty().addListener(this);
});
};
};
comboBox3.valueProperty().addListener(l);

This is not good code because it adds and removes a listener to avoid 
notification when the value is reset.  It uses runLater() in order to 
stop the combo box from getting confused when the value is changed from 
within a changed listener.


Steve


On 2014-07-04, 3:09 PM, Kirill Kirichenko wrote:
JavaFX ComboBox has binding between TextEdit field and the ListView 
selection such that edit field gets updated when we change the 
selected item in the drop down list.
Is there a way to break this binding - when we select an item in the 
list the editor field remains untouched. Where should I look at ?



Thanks.
K

OpenJFX: API Review Process

2014-07-02 Thread Stephen F Northover


Hi all,

We've been working hard to document OpenJFX development over the past 
few months and strangely, the API Review Process was not described 
anywhere.  To fix this, I have updated the wiki:


https://wiki.openjdk.java.net/display/OpenJFX/API+Review

API is forever so it is very important that we are careful and 
consistent in our approach to updating the toolkit.


Steve

Re: Review Request: RT-37788

2014-07-02 Thread Stephen F Northover

I'm glad your not an objective C.  I suggest getting Felipe to look at 
this code too should we decide to go ahead with it.


Steve

On 2014-07-02, 5:15 PM, Danno Ferrin wrote:

Chris, Kevin, Steve,

Please review this fix for RT-37788.  Since I am not an objective C any 
comments are welcome.  Also, please consider if this is too much for an 8u20 
fix (the diff is against the current 8u40 codebase).

Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-37788

—Danno

Re: Review Request: RT-37788

2014-07-02 Thread Stephen F Northover

Personally, I wouldn't change any native code at this point unless it 
was fixing a crash.  The review is for 8u40, correct?


Steve

On 2014-07-02, 5:38 PM, Chris Bensen wrote:
I’m not sure about for 8u20. Seems fairly straight forward, and your 
Obj-C seems as good as any Obj-C. My only complaint at the moment is 
the following:

  358 if ([pathParts count]  2) {
  359 // for 3 or more steps, the domain is first.second.third and the keys are 
/first/second/third/, fourth/, fifth/... etc
  360 persistentDomain = [NSString stringWithFormat: @%@.%@.%@, 
[pathParts objectAtIndex: 0],
  361 [pathParts objectAtIndex: 1], [pathParts 
objectAtIndex: 2]];
  362
  363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
stringWithFormat:@/%@/%@/%@, [pathParts objectAtIndex: 0],
  364[pathParts 
objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
  365 [dictPath removeObjectAtIndex: 2];
  366 [dictPath removeObjectAtIndex: 1];
  367 } else {
  368 // for 1 or two steps, the domain is first.second.third and the keys are /, 
first/, second/
  369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
  370 [dictPath insertObject: @ atIndex:0];
  371 }

what if [pathParts count] is 0? I’d probably do a switch:

switch ([pathParts count]) {
  case 0:
 //error
 return/break;
  case 1:
  case 2:
  368 // for 1 or two steps, the domain is first.second.third and the keys are /, 
first/, second/
  369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
  370 [dictPath insertObject: @ atIndex:0];
  default:
  359 // for 3 or more steps, the domain is first.second.third and the keys are 
/first/second/third/, fourth/, fifth/... etc
  360 persistentDomain = [NSString stringWithFormat: @%@.%@.%@, 
[pathParts objectAtIndex: 0],
  361 [pathParts objectAtIndex: 1], [pathParts 
objectAtIndex: 2]];
  362
  363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString 
stringWithFormat:@/%@/%@/%@, [pathParts objectAtIndex: 0],
  364[pathParts 
objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
  365 [dictPath removeObjectAtIndex: 2];
  366 [dictPath removeObjectAtIndex: 1];

}


Make sense? Clear as mud?

Chris


On Jul 2, 2014, at 2:15 PM, Danno Ferrin danno.fer...@oracle.com 
mailto:danno.fer...@oracle.com wrote:



Chris, Kevin, Steve,

Please review this fix for RT-37788.  Since I am not an objective C 
any comments are welcome.  Also, please consider if this is too much 
for an 8u20 fix (the diff is against the current 8u40 codebase).


Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/ 
http://cr.openjdk.java.net/%7Eshemnon/RT-37788/webrev.00/

JIRA: https://javafx-jira.kenai.com/browse/RT-37788

—Danno

Re: hg: openjfx/8u-dev/rt: Take public off StyleablePropertyFactory pending further review of RT-36501: Reduce CssMetaData boilerplate code

2014-06-27 Thread Stephen F Northover


Hi Tom,

The code got away too soon.  Please add your comment to the JIRA so that 
we can take it into account.


Thanks,
Steve

On 2014-06-27, 6:06 AM, Tom Schindl wrote:

The class is showing com.sun.istack.internal.NotNull in it's API! Is
this really a good idea?

Tom

On 26.06.14 21:48, david.gri...@oracle.com wrote:

Changeset: 8d41ccb6bcdb
Author:David Grievedavid.gri...@oracle.com
Date:  2014-06-26 15:47 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8d41ccb6bcdb

Take public off StyleablePropertyFactory pending further review of RT-36501: 
Reduce CssMetaData boilerplate code

! modules/graphics/src/main/java/javafx/css/StyleablePropertyFactory.java

Re: hg: openjfx/8u-dev/rt: Take public off StyleablePropertyFactory pending further review of RT-36501: Reduce CssMetaData boilerplate code

2014-06-27 Thread Stephen F Northover


It was a typo.  I added your comment.

Steve

On 2014-06-27, 9:43 AM, Tom Schindl wrote:

What is the correct JIRA? RT-36501 is a completely different entry.

Tom

On 27.06.14 15:39, Stephen F Northover wrote:

Hi Tom,

The code got away too soon.  Please add your comment to the JIRA so that
we can take it into account.

Thanks,
Steve

On 2014-06-27, 6:06 AM, Tom Schindl wrote:

The class is showing com.sun.istack.internal.NotNull in it's API! Is
this really a good idea?

Tom

On 26.06.14 21:48, david.gri...@oracle.com wrote:

Changeset: 8d41ccb6bcdb
Author:David Grievedavid.gri...@oracle.com
Date:  2014-06-26 15:47 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8d41ccb6bcdb

Take public off StyleablePropertyFactory pending further review of
RT-36501: Reduce CssMetaData boilerplate code

!
modules/graphics/src/main/java/javafx/css/StyleablePropertyFactory.java

Re: hg: openjfx/8u-dev/rt: Take public off StyleablePropertyFactory pending further review of RT-36501: Reduce CssMetaData boilerplate code

2014-06-27 Thread Stephen F Northover


https://javafx-jira.kenai.com/browse/RT-36510

On 2014-06-27, 9:43 AM, Tom Schindl wrote:

What is the correct JIRA? RT-36501 is a completely different entry.

Tom

On 27.06.14 15:39, Stephen F Northover wrote:

Hi Tom,

The code got away too soon.  Please add your comment to the JIRA so that
we can take it into account.

Thanks,
Steve

On 2014-06-27, 6:06 AM, Tom Schindl wrote:

The class is showing com.sun.istack.internal.NotNull in it's API! Is
this really a good idea?

Tom

On 26.06.14 21:48, david.gri...@oracle.com wrote:

Changeset: 8d41ccb6bcdb
Author:David Grievedavid.gri...@oracle.com
Date:  2014-06-26 15:47 -0400
URL:   http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8d41ccb6bcdb

Take public off StyleablePropertyFactory pending further review of
RT-36501: Reduce CssMetaData boilerplate code

!
modules/graphics/src/main/java/javafx/css/StyleablePropertyFactory.java

Re: Testing accessibility / sample apps

2014-06-25 Thread Stephen F Northover

 Studio 10.0/VC/BIN/amd64/cl.exe (in
directory
D:\jann\sandbox\java\openjfx\modules\fxpackager): CreateProcess
error=2, Das System kann die angegebene Datei nicht finden
...
Caused by: java.io.IOException: CreateProcess error=2, Das System
kann
die angegebene Datei nicht finden (file not found)

Actually cl.exe is located at: C:\Program Files (x86)\Microsoft
Visual
Studio 10.0\VC\bin - but it looks for ...bin/amd64/cl.exe

I've also tried to run the build from the cygwin terminal and as
well
from the visual studio command prompt where i could call cl.exe
directly .. Always the same result.

Is there a parameter to specify where theVS compiler and stuff is
located? btw. i checked that the %VS100COMNTools% variable is set
properly.

What else could i check? Thanks in advance :)

Jann




2014-06-20 23:30 GMT+02:00, Kevin Rushforth
kevin.rushfo...@oracle.com:

* What went wrong:
Execution failed for task ':fxpackager:buildJavaPackager'.

Could not call NativeCompileTask.compile() on task
':fxpackager:buildJavaPackager'
When I've seen this in the past it's been related to the 
compiler

install. Do you have VS 2010 SP1 or something else?

-- Kevin



Jann Schneider wrote:

Hi,

Well on windows it's always a bit more difficult i guess :-)
After setting up my build environment as described on the 
wiki i

first
tried
$ gradle tasks
This works as expected! When running
$ gradle sdk
or just gradle without any target i get the following error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':fxpackager:buildJavaPackager'.


Could not call NativeCompileTask.compile() on task
':fxpackager:buildJavaPackager'

Is this a known issue and do you know what's going wrong 
here?

Should i post more info or debug output, too?

Thanks
Jann



2014-06-20 21:58 GMT+02:00, Stephen F Northover
steve.x.northo...@oracle.com:


Being non-Unix, Windows is always a pain.

Steve

On 2014-06-20, 3:42 PM, Kevin Rushforth wrote:


I hope you have similar success with the Windows build.

-- Kevin


Jann Schneider wrote:


Hi all,

The build instructions for linux where very good! I was 
able to

build
the project without any problems.

Regards Jann

2014-06-20 19:27 GMT+02:00, Kevin Rushforth
kevin.rushfo...@oracle.com:


To be clear, you will still use the 8u-dev repo at the
existing
URL:

http://hg.openjdk.java.net/openjfx/8u-dev/rt

It's just that after Monday the repo will become the 
place

where
8u40
work is done.

Regarding the build, it is a bit painful to set up for
Windows,
but
not
too bad as long as you don't need to build WebKit. We 
would be
interested in hearing whether the instructions on the 
Wiki are

sufficient for you to get the build working.

-- Kevin


Stephen F Northover wrote:


Ok, let us know how you get on with building FX.

NOTE: The accessibility code is not there in 8u20 so 
you will

just
be
ensuring that you can build on Windows (there is nothing
there
to
test).  The accessibility code will be going back into
8u40 on
Monday
or Tuesday so you'll need to get that release at that time
and
build
it instead when it becomes available.  It's good to 
debug the

build
process though because it can be painful building from
source.

Steve

On 2014-06-20, 12:43 PM, Jann Schneider wrote:


Hi all,

@Steven: thx for the links. I'll try to build the openjfx
project
on
the windows 7 notebook and test the sample apps with NVDA
then.
Today i tried the latest ea of jdk1.8.0_20 and sample 
apps

with
nvda
14.2. Unfortunately i was not able to read anything
except the
window
title.
I've just installed the jdk, changed my JAVA_HOME and
tried to
run
e.g. the ensemble.jar
$ java -jar ensemble.jar -Djavafx.accessible.force=true

Well i'll try it again by means of building javafx from
source
and
post my results back to the list.

Regards Jann!


2014-06-20 14:46 GMT+02:00, Stephen F Northover
steve.x.northo...@oracle.com:


Hello Jann!

As soon as the 8u40 repos open, the Accessibility 
code will

be
put back
along with the recent fixes for JAWS.  Since OpenJFX
(and the
JDK) does
not have nightly builds, unless you want to wait for 
an EA

build
of
8u40
or 9, you will need to get OpenJFX and build it.  
This is

really
the
best way to work with the team anyway because you can 
get

fixes
as they
are made.  EA builds take a while to come out and there
is no
substitute
for running on the latest code base.

Unfortunately due to Microsoft, building OpenJFX is a 
bit

harder
on
Windows.  However, it is doable and the build 
instructions

should
be
complete.  If they are not (and if you hit any 
problems),

please
post
back to this list.

Here are the build instructions:

https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX 




Many committers use an IDE (you don't have to) and
OpenJFX is
supports
the three major IDE vendors:

https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE 



Looking forward to working with you,
Steve

On 2014-06-19, 7:10 PM, Felipe Heidrich wrote:


Hi Jann

Re: New alias for hg commit notifications?

2014-06-24 Thread Stephen F Northover

I don't see a down side to this other than people will have to subscribe 
to the new list get the notifications that they were seeing before (or 
could / should / can we see the new list?)


Steve

On 2014-06-24, 9:34 AM, Kevin Rushforth wrote:
It has been suggested that we create a new alias for Mercurial (hg) 
commit notifications -- perhaps openjfx-chan...@openjdk.java.net -- 
rather than sending all of them to the discussion alias. This will 
facilitate e-mail filtering
as well as allow people to opt in or out of getting these 
notifications separately from being on the discussion alias.


What do others think?

-- Kevin

Re: Exposing native surface or opengl handle

2014-06-23 Thread Stephen F Northover


I'm sorry this thread scrolled away into the bitbucket in the sky.

Last JavaOne, we wrote a prototype that showed native integration on OS 
X.  We parented a native sheet dialog in an FX stage and providing an 
OpenGL node.  The code was a prototype that worked only on OS X.  The 
Open GL node allowed drawing JOGL and LWJGL to draw on a texture that 
was created by FX.  This mean that the OpenGL node could take part in FX 
animations and effects.


I will attach the prototype code to 
https://javafx-jira.kenai.com/browse/RT-36215.  I need to find it and 
make sure that it still compiles and works.  This week is M5 RDP2 and 
today is likely to be a write off for a number of reasons.


https://wiki.openjdk.java.net/display/OpenJFX/8u20

Please ping me in the JIRA if the code doesn't show up sometime this 
week.  The prototype is the basis of one possible implementation and 
needs some work.  There are other possible implementations and this is 
not the final word on the issue.


Steve

On 2014-06-23, 10:03 AM, Robert Krüger wrote:

Sorry, my last reply did not go to the list. That was unintended.

Oracle-Team, please someone comment on this, at least on what should
be done regarding a Jira Issue (or several ones?) to track any
progress on this and collect ideas  requirements.

Best regards,

Robert

On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger krue...@lesspain.de wrote:

Thanks for the hint. I think this is similar to what a colleague of
mine did a while ago as a proof of concept using other com.sun.api
that then went away. As long as we're bundling the JRE with our
product and we're desperate enough to get it working, we might do
something like this but it's of course just a last resort. Lets hope
someone from Oracle says something.



On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer swpal...@gmail.com wrote:

That’s basically it. It isn’t perfect, but its so simple I don’t see why it 
can’t be done quickly.  We are already talking about using native code to 
render.

That said, com.sun.glass.ui.Window contains the field we want:

 // Native object handle (HWND, or NSWindow*, etc.)
 long ptr;

You could be evil and hack it now with reflection, but it relies on internal 
implementation details.

In my application I already create a native window for video preview… though 
not as a child of the FX window.  The problem is that there isn’t a 
straight-forward, reliable, supported way to get the window handle to use for 
the parent (JavaFX) window.  There are ways to hack it, but they aren’t pretty.


Scott

On Jun 13, 2014, at 7:55 AM, Robert Krüger krue...@lesspain.de wrote:


Just for my understanding: Your approach would be to get the native
window handle for the hosting JFX stage, then leave an open space in
the layout for e.g. the player canvas that will be implemented
natively and then create a native child window that just reacts to
move and resize events of its native parent?

On Fri, Jun 13, 2014 at 1:48 PM, Scott Palmer swpal...@gmail.com wrote:

This is critical, but I don't think we need to focus on a specific technology 
like Direct3D or OpenGL. As a first step all we need is a mechanism to get a 
native reference to the Window. Just like we can with JAWT.  I'm guessing that 
JavaFX doesn't use heavyweight child windows so we could add a new child window 
that we manage with our own code and it would appear on top of the JavaFX 
content.

Scott


On Jun 13, 2014, at 3:08 AM, Felix Bembrick felix.bembr...@gmail.com wrote:

I absolutely agree that such a feature is critical for the success and
longevity of JavaFX.  I am *really* hoping for some heavily beefed-up 3D
support in a JFX 8.* release or JFX 9.

I need my graphics toolkit (currently JavaFX) to be able to handle
everything from simple UIs with basic controls to complex 3D
visualisations, just like the underlying graphics API is capable of (i.e.
OpenGL or Direct3D).  I strongly suspect though that focusing on OpenGL
exclusively is the only viable way to go from a cost perspective which
would mean JavaFX supporting OpenGL on Windows.



On 13 June 2014 16:57, Robert Krüger krue...@lesspain.de wrote:

Hi,

it has been discussed a number of time in the passed but let me
quickly summarize:

A number of people have requested a feature that provides the ability
to have native code draw into a surface provided by a JavaFX
application as fast as technically possible, i.e. with no indirection
or copying because use cases for this were mostly cases where
performance was critical, e.g. HD/UHD video players, real-time
visualization etc. where losing even e few percent would make a
software written in JavaFX unable to compete with native products
(e.g. in the video area nobody will use a video player that is not
able to play the content smoothly that VLC player or Quicktime can on
the same machine). Some people already have libraries of native code
that they have built over the years and would like to reuse. I would
even go so far to say that

Re: Testing accessibility / sample apps


Hello Jann!

As soon as the 8u40 repos open, the Accessibility code will be put back 
along with the recent fixes for JAWS.  Since OpenJFX (and the JDK) does 
not have nightly builds, unless you want to wait for an EA build of 8u40 
or 9, you will need to get OpenJFX and build it.  This is really the 
best way to work with the team anyway because you can get fixes as they 
are made.  EA builds take a while to come out and there is no substitute 
for running on the latest code base.


Unfortunately due to Microsoft, building OpenJFX is a bit harder on 
Windows.  However, it is doable and the build instructions should be 
complete.  If they are not (and if you hit any problems), please post 
back to this list.


Here are the build instructions:

https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Many committers use an IDE (you don't have to) and OpenJFX is supports 
the three major IDE vendors:


https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE

Looking forward to working with you,
Steve

On 2014-06-19, 7:10 PM, Felipe Heidrich wrote:

Hi Jann,

Unfortunately Linux support is not in the plan for 8u40.

Windows 7 is supported and we have recently fixed JAWS support (see 
https://javafx-jira.kenai.com/browse/RT-37530 and 
https://javafx-jira.kenai.com/browse/RT-37609).
Unfortunately due to the 8u20 to 8u40 transition the code has not being 
released yet, but soon.

The majority of our testing was done using Narrator. That said, I also tested 
NVDA lastest version on Windows 8 and I didn’t see any major problems.
On the Mac we tested with VoiceOver.

Regards,
Felipe


On Jun 19, 2014, at 2:24 PM, Jann Schneider jann.schnei...@googlemail.com 
wrote:


Hello all,

As a blind java developer i'm interessted in testing the accessibility of 
JavaFX and maybe help to find some issues.

I've just set up my build environment on my ubuntu 14.04 laptop and checked out 
the project files as described in the wiki. I could also set it up on a windows 
7 with Jaws 15 and NVDa (don't know what the current version is) for 
comparison..

No i am wondering if there are some examples i could try?

Regards Jann

Re: Dialogs in JavaFX

This essentially matches my current thinking, however, I would have 
DialogBox as an abstract superclass of Alert.  Further, I would not have 
many different types of show() methods.


Want to take the discussion further in the JIRA?  That way, is will 
track everyone's thinking on the various issues.  The downside is that 
JIRA does not provide threaded conversations and it can be hard to follow.


Steve

On 2014-06-20, 9:41 AM, Jeff Martin wrote:

That is a great post. I think the big problem with dialogs in Swing was the 
permutations problem. There were four basic types of dialogs (Message, Confirm, 
Option, Input) with six different parameters (Title, Message, Icon, Content, 
MessageType, Options) - so JOptionPane ended up with a sea of static methods 
that were confusing to navigate.

I don't think you could go wrong with a simple DialogBox class like this (I 
love simple):

// Constructor
public DialogBox(String aTitle);

// Options
public String getTitle();
public void setTitle(String aTitle);
public String getMessage();
public void setMessage(String aMessage);
public MessageType getMessageType();
public void setMessageType(MessageType aMessageType);
public Node getContent();
public void setContent(Node aNode);
public Node getGraphic();
public void setGraphic(Node aNode);
public String[] getOptions();
public void setOptions(String ... theOptions);

// Convenience methods to set Message + MessageType
public void setErrorMessage(String aMessage);
public void setWarningMessage(String aMessage);
public void setQuestionMessage(String aMessage);

// Show methods
public void showMessageDialog(T aComp);
public boolean showConfirmDialog(T aComp);
public int showOptionDialog(T aComp, String aDefault);
public String showInputDialog(T aComp, String aDefault);

// Programatic dismissal
public void confirm();
public void cancel();

Then most common invocations would look something like this:

// Get user confirmation
DialogBox dbox = new DialogBox(Sanity Check);
dbox.setWarningMessage(Are you sure you want to do this? It could kill 
you.);
if(!dbox.showConfirmationDialog(focusedNode)) return;

Using instance methods instead of static methods gives opportunity to subclass 
and override various methods. And notice the Content attribute - for the 
standard case when no Content is provided, it is built programmatically based 
on the parameters (essentially just the message and either an Option combo, an 
input textfield or nothing).

I've been using this in my JavaFX app for a while and it is working great and 
makes porting from Swing easy. I even built it on a convenient FormBuilder 
class that makes building a simple stack of form controls easy, and can also be 
used for advanced DialogBoxes.

Jeff Martin
214.513.1636


On Jun 20, 2014, at 7:05 AM, Stephen F Northover steve.x.northo...@oracle.com 
wrote:


Great post Jonathan.  The summary is that whatever direction we take, we'll 
have a plan for the future.  So if we run out of time and provide only a very 
scaled back API, we'll have prototyped how it can evolve to handle more complex 
cases.

Steve

On 2014-06-20, 12:37 AM, Jonathan Giles wrote:

Hi all,

Dialogs are something everyone wants, and also something most people seem to 
have an opinion on! JavaFX 8u40 will have dialogs, but what form they take 
(API-wise) is not yet defined. I've posted a relatively long discussion on this 
over at FX Experience [1] and your feedback is highly welcome. As I note in the 
blog post, the Jira issue for this feature is RT-12643. If you have any 
thoughts, please do post them there (rather than spam the many good people 
subscribed to openjfx-dev).

[1] http://fxexperience.com/2014/06/bringing-dialogs-to-javafx/

Thanks!

Re: Testing accessibility / sample apps


Ok, let us know how you get on with building FX.

NOTE: The accessibility code is not there in 8u20 so you will just be 
ensuring that you can build on Windows (there is nothing there to 
test).  The accessibility code will be going back into 8u40 on Monday or 
Tuesday so you'll need to get that release at that time and build it 
instead when it becomes available.  It's good to debug the build process 
though because it can be painful building from source.


Steve

On 2014-06-20, 12:43 PM, Jann Schneider wrote:

Hi all,

@Steven: thx for the links. I'll try to build the openjfx project on
the windows 7 notebook and test the sample apps with NVDA then.
Today i tried the latest ea of jdk1.8.0_20 and sample apps with nvda
14.2. Unfortunately i was not able to read anything except the window
title.
I've just installed the jdk, changed my JAVA_HOME and tried to run
e.g. the ensemble.jar
$ java -jar ensemble.jar -Djavafx.accessible.force=true

Well i'll try it again by means of building javafx from source and
post my results back to the list.

Regards Jann!


2014-06-20 14:46 GMT+02:00, Stephen F Northover steve.x.northo...@oracle.com:

Hello Jann!

As soon as the 8u40 repos open, the Accessibility code will be put back
along with the recent fixes for JAWS.  Since OpenJFX (and the JDK) does
not have nightly builds, unless you want to wait for an EA build of 8u40
or 9, you will need to get OpenJFX and build it.  This is really the
best way to work with the team anyway because you can get fixes as they
are made.  EA builds take a while to come out and there is no substitute
for running on the latest code base.

Unfortunately due to Microsoft, building OpenJFX is a bit harder on
Windows.  However, it is doable and the build instructions should be
complete.  If they are not (and if you hit any problems), please post
back to this list.

Here are the build instructions:

  https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Many committers use an IDE (you don't have to) and OpenJFX is supports
the three major IDE vendors:

  https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE

Looking forward to working with you,
Steve

On 2014-06-19, 7:10 PM, Felipe Heidrich wrote:

Hi Jann,

Unfortunately Linux support is not in the plan for 8u40.

Windows 7 is supported and we have recently fixed JAWS support (see
https://javafx-jira.kenai.com/browse/RT-37530 and
https://javafx-jira.kenai.com/browse/RT-37609).
Unfortunately due to the 8u20 to 8u40 transition the code has not being
released yet, but soon.

The majority of our testing was done using Narrator. That said, I also
tested NVDA lastest version on Windows 8 and I didn’t see any major
problems.
On the Mac we tested with VoiceOver.

Regards,
Felipe


On Jun 19, 2014, at 2:24 PM, Jann Schneider
jann.schnei...@googlemail.com wrote:


Hello all,

As a blind java developer i'm interessted in testing the accessibility of
JavaFX and maybe help to find some issues.

I've just set up my build environment on my ubuntu 14.04 laptop and
checked out the project files as described in the wiki. I could also set
it up on a windows 7 with Jaws 15 and NVDa (don't know what the current
version is) for comparison..

No i am wondering if there are some examples i could try?

Regards Jann

Re: Testing accessibility / sample apps


Being non-Unix, Windows is always a pain.

Steve

On 2014-06-20, 3:42 PM, Kevin Rushforth wrote:

I hope you have similar success with the Windows build.

-- Kevin


Jann Schneider wrote:

Hi all,

The build instructions for linux where very good! I was able to build
the project without any problems.

Regards Jann

2014-06-20 19:27 GMT+02:00, Kevin Rushforth 
kevin.rushfo...@oracle.com:

To be clear, you will still use the 8u-dev repo at the existing URL:

http://hg.openjdk.java.net/openjfx/8u-dev/rt

It's just that after Monday the repo will become the place where 8u40
work is done.

Regarding the build, it is a bit painful to set up for Windows, but not
too bad as long as you don't need to build WebKit. We would be
interested in hearing whether the instructions on the Wiki are
sufficient for you to get the build working.

-- Kevin


Stephen F Northover wrote:

Ok, let us know how you get on with building FX.

NOTE: The accessibility code is not there in 8u20 so you will just be
ensuring that you can build on Windows (there is nothing there to
test).  The accessibility code will be going back into 8u40 on Monday
or Tuesday so you'll need to get that release at that time and build
it instead when it becomes available.  It's good to debug the build
process though because it can be painful building from source.

Steve

On 2014-06-20, 12:43 PM, Jann Schneider wrote:

Hi all,

@Steven: thx for the links. I'll try to build the openjfx project on
the windows 7 notebook and test the sample apps with NVDA then.
Today i tried the latest ea of jdk1.8.0_20 and sample apps with nvda
14.2. Unfortunately i was not able to read anything except the window
title.
I've just installed the jdk, changed my JAVA_HOME and tried to run
e.g. the ensemble.jar
$ java -jar ensemble.jar -Djavafx.accessible.force=true

Well i'll try it again by means of building javafx from source and
post my results back to the list.

Regards Jann!


2014-06-20 14:46 GMT+02:00, Stephen F Northover
steve.x.northo...@oracle.com:

Hello Jann!

As soon as the 8u40 repos open, the Accessibility code will be 
put back
along with the recent fixes for JAWS.  Since OpenJFX (and the 
JDK) does

not have nightly builds, unless you want to wait for an EA build of
8u40
or 9, you will need to get OpenJFX and build it.  This is really the
best way to work with the team anyway because you can get fixes 
as they

are made.  EA builds take a while to come out and there is no
substitute
for running on the latest code base.

Unfortunately due to Microsoft, building OpenJFX is a bit harder on
Windows.  However, it is doable and the build instructions should be
complete.  If they are not (and if you hit any problems), please 
post

back to this list.

Here are the build instructions:

https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Many committers use an IDE (you don't have to) and OpenJFX is 
supports

the three major IDE vendors:

https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE

Looking forward to working with you,
Steve

On 2014-06-19, 7:10 PM, Felipe Heidrich wrote:

Hi Jann,

Unfortunately Linux support is not in the plan for 8u40.

Windows 7 is supported and we have recently fixed JAWS support (see
https://javafx-jira.kenai.com/browse/RT-37530 and
https://javafx-jira.kenai.com/browse/RT-37609).
Unfortunately due to the 8u20 to 8u40 transition the code has not
being
released yet, but soon.

The majority of our testing was done using Narrator. That said, 
I also

tested NVDA lastest version on Windows 8 and I didn’t see any major
problems.
On the Mac we tested with VoiceOver.

Regards,
Felipe


On Jun 19, 2014, at 2:24 PM, Jann Schneider
jann.schnei...@googlemail.com wrote:


Hello all,

As a blind java developer i'm interessted in testing the
accessibility of
JavaFX and maybe help to find some issues.

I've just set up my build environment on my ubuntu 14.04 laptop 
and

checked out the project files as described in the wiki. I could
also set
it up on a windows 7 with Jaws 15 and NVDa (don't know what the
current
version is) for comparison..

No i am wondering if there are some examples i could try?

Regards Jann

Re: Testing accessibility / sample apps

You'll need to run under a Cygwin shell or paths will be wrong. Fingers 
crossed ...


Steve

On 2014-06-20, 5:12 PM, Jann Schneider wrote:

Hi,

Well on windows it's always a bit more difficult i guess :-)
After setting up my build environment as described on the wiki i first tried
$ gradle tasks
This works as expected! When running
$ gradle sdk
or just gradle without any target i get the following error:

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':fxpackager:buildJavaPackager'.

Could not call NativeCompileTask.compile() on task 
':fxpackager:buildJavaPackager'

Is this a known issue and do you know what's going wrong here?
Should i post more info or debug output, too?

Thanks
Jann



2014-06-20 21:58 GMT+02:00, Stephen F Northover steve.x.northo...@oracle.com:

Being non-Unix, Windows is always a pain.

Steve

On 2014-06-20, 3:42 PM, Kevin Rushforth wrote:

I hope you have similar success with the Windows build.

-- Kevin


Jann Schneider wrote:

Hi all,

The build instructions for linux where very good! I was able to build
the project without any problems.

Regards Jann

2014-06-20 19:27 GMT+02:00, Kevin Rushforth
kevin.rushfo...@oracle.com:

To be clear, you will still use the 8u-dev repo at the existing URL:

http://hg.openjdk.java.net/openjfx/8u-dev/rt

It's just that after Monday the repo will become the place where 8u40
work is done.

Regarding the build, it is a bit painful to set up for Windows, but not
too bad as long as you don't need to build WebKit. We would be
interested in hearing whether the instructions on the Wiki are
sufficient for you to get the build working.

-- Kevin


Stephen F Northover wrote:

Ok, let us know how you get on with building FX.

NOTE: The accessibility code is not there in 8u20 so you will just be
ensuring that you can build on Windows (there is nothing there to
test).  The accessibility code will be going back into 8u40 on Monday
or Tuesday so you'll need to get that release at that time and build
it instead when it becomes available.  It's good to debug the build
process though because it can be painful building from source.

Steve

On 2014-06-20, 12:43 PM, Jann Schneider wrote:

Hi all,

@Steven: thx for the links. I'll try to build the openjfx project on
the windows 7 notebook and test the sample apps with NVDA then.
Today i tried the latest ea of jdk1.8.0_20 and sample apps with nvda
14.2. Unfortunately i was not able to read anything except the window
title.
I've just installed the jdk, changed my JAVA_HOME and tried to run
e.g. the ensemble.jar
$ java -jar ensemble.jar -Djavafx.accessible.force=true

Well i'll try it again by means of building javafx from source and
post my results back to the list.

Regards Jann!


2014-06-20 14:46 GMT+02:00, Stephen F Northover
steve.x.northo...@oracle.com:

Hello Jann!

As soon as the 8u40 repos open, the Accessibility code will be
put back
along with the recent fixes for JAWS.  Since OpenJFX (and the
JDK) does
not have nightly builds, unless you want to wait for an EA build of
8u40
or 9, you will need to get OpenJFX and build it.  This is really the
best way to work with the team anyway because you can get fixes
as they
are made.  EA builds take a while to come out and there is no
substitute
for running on the latest code base.

Unfortunately due to Microsoft, building OpenJFX is a bit harder on
Windows.  However, it is doable and the build instructions should be
complete.  If they are not (and if you hit any problems), please
post
back to this list.

Here are the build instructions:

https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX

Many committers use an IDE (you don't have to) and OpenJFX is
supports
the three major IDE vendors:

https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE

Looking forward to working with you,
Steve

On 2014-06-19, 7:10 PM, Felipe Heidrich wrote:

Hi Jann,

Unfortunately Linux support is not in the plan for 8u40.

Windows 7 is supported and we have recently fixed JAWS support (see
https://javafx-jira.kenai.com/browse/RT-37530 and
https://javafx-jira.kenai.com/browse/RT-37609).
Unfortunately due to the 8u20 to 8u40 transition the code has not
being
released yet, but soon.

The majority of our testing was done using Narrator. That said,
I also
tested NVDA lastest version on Windows 8 and I didn’t see any major
problems.
On the Mac we tested with VoiceOver.

Regards,
Felipe


On Jun 19, 2014, at 2:24 PM, Jann Schneider
jann.schnei...@googlemail.com wrote:


Hello all,

As a blind java developer i'm interessted in testing the
accessibility of
JavaFX and maybe help to find some issues.

I've just set up my build environment on my ubuntu 14.04 laptop
and
checked out the project files as described in the wiki. I could
also set
it up on a windows 7 with Jaws 15 and NVDa (don't know what the
current
version is) for comparison..

No i am wondering if there are some examples i could try?

Regards Jann

Re: Is JavaFX keyboard event handling too rigid?

2014-06-13 Thread Stephen F Northover

You should be able to use event filtering to get in the way of any event 
before it is delivered to the control.  If you provide some sample code 
for what you are trying to do, we can take a look at it and suggest a 
possible solution.


Steve

On 2014-06-13, 10:39 AM, Tomas Mikula wrote:

Hi Randahl,

I think the general advice is to avoid subclassing controls if
possible. You can create your custom control that embeds a text field
and filter events on your custom control so they never reach the
embedded text field.

Tomas

On Fri, Jun 13, 2014 at 10:11 AM, Randahl Fink Isaksen
rand...@rockit.dk wrote:

I have noticed that quite many developers are having trouble avoiding 
triggering of focus navigation occurring when a user presses the UP and DOWN 
arrow keys. From a number of different forum posts I have seen how people are 
jumping through hoops to avoid this.

I myself have the challenge, that I need to use the UP and DOWN keys for 
changing the selected autocompletion in a text field, and it seems that no 
matter how greedily I try to consume or filter out these KeyEvents, JavaFX 
still insists on moving the focus from one field to the next.

This got me thinking: Why is JavaFX keyboard event handling so rigid? If you 
implement a control which listens for keyboard events on itself and does some 
cool stuff, that is fine. But once you implement a subclass that wishes to 
replace some of that behaviour you are in trouble, because once the 
EventHandlers are registered, there is no public API to replace them.

Is this a conscious design decision? Is it something that I should file a 
feature request on, or have I overlooked a part of the API which could be used 
here?

Randahl

Re: VisibleBounds

2014-06-11 Thread Stephen F Northover


This seems like a good enhancement request.  Please enter a JIRA for it.

Steve

On 2014-06-11, 10:17 AM, Jeff Martin wrote:

Below is my poor man's getVisibleBounds. I'm using this so that my custom text 
pane only needs to add child nodes for lines of text that are visible - similar 
to how ListView and friends only add cell nodes for visible items. I hope I'm 
on the right track - I was surprised that my web search for getVisibleBounds() 
came up so empty. If nobody points out my idiocy, I'm going to put this in a 
blog.

jeff

/**
  * Returns the visible bounds for a node based on ancestor clips (or null if 
no clipping found).
  */
public static Bounds getVisibleBounds(Node aNode)
{
 // Get parent visible bounds (if set, convert to local)
 Bounds bounds = aNode.getParent()!=null? 
getVisibleBounds(aNode.getParent()) : null;
 if(bounds!=null) { if(!bounds.isEmpty()) bounds = 
aNode.parentToLocal(bounds); else return bounds; }
 
 // If node has clip, get clip local bounds (intersected with parent visible bounds if present)

 if(aNode.getClip()!=null) { Node clip = aNode.getClip(); Bounds cb = 
clip.getBoundsInLocal();
 bounds = bounds!=null? getIntersectingBounds(cb, bounds) : cb; }
 
 // Return node visible bounds

 return bounds;
}

/**
  * Returns the intersection bounds of two bounds.
  */
public static Bounds getIntersectingBounds(Bounds b1, Bounds b2)
{
 if(!b1.intersects(b2)) return new BoundingBox(0,0,-1,-1);
 double minx = Math.max(b1.getMinX(), b2.getMinX());
 double miny = Math.max(b1.getMinY(), b2.getMinY());
 double maxx = Math.min(b1.getMaxX(), b2.getMaxX());
 double maxy = Math.min(b1.getMaxY(), b2.getMaxY());
 return new BoundingBox(minx, miny, maxx-minx, maxy-miny);
}


On Jun 10, 2014, at 6:59 PM, Jeff Martin j...@reportmill.com wrote:


What is the JFX equivalent of JComponent.getVisibleRect() - and is there a way 
to get a notification when it changes?

jeff

[8u20] Review request: [FXCanvas, JFXPanel] NPE in Browser while pressing back/forward buttons from mouse

2014-06-09 Thread Stephen F Northover


Hi Antony, Felipe,

Please review: https://javafx-jira.kenai.com/browse/RT-37436

Steve

Re: FXMLLoader ?import? checking code conventions too much?

2014-06-05 Thread Stephen F Northover

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: FXMLLoader ?import? checking code conventions too much?

2014-06-05 Thread Stephen F Northover


Guillaume, if you feel strongly about this, please file a JIRA. Thanks!

Steve

On 2014-06-05, 4:29 PM, Martin Sladecek wrote:

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: [API REVIEW REQUEST] RT-5747: Spinner control

2014-06-04 Thread Stephen F Northover

Thanks Jonathan!  Although the JIRA is long winded, at least it captures 
all the thinking in one place.


Steve

On 2014-06-03, 6:07 PM, Jonathan Giles wrote:

Hi all,

A Spinner control is in the planning stages for JavaFX 8u40, and so 
when my 8u20 backlog has got down (or near to) zero recently, I've 
been prototyping one possible implementation of the Spinner. I'm now 
at the stage where I would appreciate more eyes on the API, so I have 
published the JavaDoc as a zip file attachment to the jira issue [1] - 
see spinner-javadoc.zip. Additionally, a relatively recent 
implementation is also available - download spinner.zip - but note 
that the visuals, whilst passable, are not in their final form in any 
way!


I'm aware that RT-5747 has become relatively long winded, but I would 
like to draw attention to my most recent comment [2], where I'm 
specifically pointing out areas that need more discussion. As always I 
have an opinion on these issues, but I'm keen to hear yours.


Also, for those of you that look at the API, you may be interested to 
note the stepping away from using a List for the backing model. I have 
some more early discussion on this decision at [3], but you probably 
want to read through the rest of the comments to fully understand! 
Suffice to say, nothing is set in stone - this is still in the 
prototype stage (although rather far along).


If people could post their thoughts to the Jira issue, rather than as 
a response to this email, that would be appreciated.


[1] https://javafx-jira.kenai.com/browse/RT-5747
[2] 
https://javafx-jira.kenai.com/browse/RT-5747?focusedCommentId=411207#comment-411207
[3] 
https://javafx-jira.kenai.com/browse/RT-5747?focusedCommentId=409920#comment-409920


Thanks,
-- Jonathan

Re: Resizing stage creates delays in platform.runLater pool?

2014-06-02 Thread Stephen F Northover

I suggest you add yourself to the bug.  At this time, we are not sure 
what is causing it.  It could be graphics or event queue related as 
there is evidence that changing either solves the problem.


Steve

On 2014-06-02, 10:51 AM, Guillaume Anctil wrote:

Yes. -Dprism.order=sw does fix the issue. Looking at that bug's sample code
and how to reproduce, it looks very similar.

Thank you. I'll run it in software mode for now and see how bad it affects
performance. I can always apply a hacky workaround of stopping animations
when I detect a resize and restarting them once the resize is done.

So I guess this is on your radar, and it is being looked into?


On Mon, Jun 2, 2014 at 10:43 AM, Anthony Petrov anthony.pet...@oracle.com
wrote:


You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796

Please try running with -Dprism.order=sw and see if this changes anything.

--
best regards,
Anthony


On 6/2/2014 6:20 PM, Guillaume Anctil wrote:


Hi,

I have encountered severe lag in my application when resizing the stage
while an animation is running.

I've made this very simple example code to reproduce the issue:
https://github.com/Drakkoon/LWJGL-FX/blob/master/src/
JavaFXResizeTest.java

This is only a tread that acquires a semaphore, prints the
System.nanotime() delta and releases the semaphore. There's a button on
the
stage that can clicked on to start a fade animation and stop it.

Resizing the stage while it is animating will create huge deltas in the
thread. Stopping the animation brings everything back to normal.
Restarting
the animation once resized and stopped does not create the huge deltas
until you resize again.

Does anyone know what is at play here, what underlying system creates the
lag and how to avoid this?

Thanks.

Re: Resizing stage creates delays in platform.runLater pool?

2014-06-02 Thread Stephen F Northover

Does running with the software pipeline fix the problem as suggested in 
https://javafx-jira.kenai.com/browse/RT-36796 ?


Steve

On 2014-06-02, 11:10 AM, Werner Lehmann wrote:
We also experienced laggy animation with a stage slide out/down 
animation. The animation would change stage size and it appeared to 
have only 2 or 3 frames. Workaround was to use a different animation 
style: keep stage size but move it 20 px down while changing opacity 
from low to full, both animated. Maybe this is an option for you, too.


Werner

On 02.06.2014 16:20, Guillaume Anctil wrote:
Does anyone know what is at play here, what underlying system creates 
the

lag and how to avoid this?

Re: Gradle Scripts

2014-05-27 Thread Stephen F Northover

BUILD_NATIVES was never implemented so I deleted mention of it from the
wiki. I have also updated the Mac section to include
MACOSX_MIN_VERSION. I could have swore this information was there but
apparently not.

Steve

On 2014-05-27, 12:22 PM, Scott Palmer wrote:

My build woes continued a bit...
I tweaked build.gradle such that the buildnum.min was 5.
Then the build failed trying to build :fxpackager:compileLauncher

Coud not call NativeCompileTask.compile() on task ':fxpackager:compileLauncher'

I belive this is native code? The wiki says that native code doesnt'
normally build unless you use -PBUILD_NATIVES=true
I imagine this is true for the FX runtime DLLs and was just overlooked
for the launcher.

The root cause seems to be that I am missing the OS X 10.7 SDK:

clang: warning: no such sysroot directory:
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'

But I do have later versions for 10.8 and 10.9.

Tweaking buildSrc/mac.gradle so MACOSX_MIN_VERSION is 10.8 allowed me
to finally complete a successful build! - I think I haven't tested
anything yet.. but at least gradle stopped complaining.

Cheers,

Scott

On Tue, May 27, 2014 at 11:56 AM, Scott Palmer swpal...@gmail.com wrote:

I know the wiki says only Gradle 1.8 is guaranteed to work so I have to ask:
Why not use the Gradle Wrapper to force use of 1.8?
http://www.gradle.org/docs/current/userguide/gradle_wrapper.html

Well, I tried tweaking the build scripts to use it myself, running on
OS X and found that the scripts appear to be badly broken anyway and
they can't even be parsed with later Gradle versions so you can't even
run the wrapper task:

The error is:

Could not find method 'defineProperty() for arguments
[MACOSX_MIN_VERSION, 10.7] on root project .

Sure enough the defineProperty method is being called from a different
.gradle file than the one in which it is defined, so it is out of
scope. I corrected this locally by changing it to a closure and
assigning it to project.ext.defineProperty. Then I added:

task wrapper(type: Wrapper) {
gradleVersion = 1.8'
}

and was able to get the gradlew script created by running:

gradle wrapper

So then I tried to build with Gradle 1.8 by running:

./gradlew

Then I hit :verifyJava complaining that the build number (13) was too
low ( 115)... but I'm building the 8u5 code with the 8u5 release...
that seems like a combination that should work.

I think everyone (myself included) would be more inclined to help with
patches if it wasn't such a pain to build. I appreciate that prior to
the use of Gradle this was likely much worse. Gradle is a great build
system and should be able to make this an even simpler process.

On Windows for what I assume are historical reasons, Cygwin is
expected. I'm only trying to build the Java side of things.. not the
native DLLs and I don't see Cygwin doing anything of value in the
build scripts for that case. It's mangling paths that don't need to
be mangle for example.

I think the build scripts could be cleaned up to provide a much
smoother build experience for those outside of Oracle.

No doubt you guys simply don't have the cycles to burn on fixing build
scripts that are currently working for you.. but I suspect it will pay
off in the long run. The current version of Gradle, 1.12, is the last
1.x Gradle release before the 2.x versions appear. It may make sense
to achieve compatibility with it. Gradle 2.x is expected to break
things, but once things are working with 1.12, then you can work on
getting rid of the warnings and you will be in a much better position.

Cheers,

Scott

Planning for M5: June 23, 2014 [RDP2]

2014-05-23 Thread Stephen F Northover


Hi all,

The next milestone M5, June 23, 2014 [RDP2], is an important one. 
Essentially, we are shipping FX for 8u20 after this.  There is a week 
before the final FX ZBB date which is July 1, 2014, but we should not be 
touching any code during this week.  After July 1 ZBB, we are stopping 
all development on FX 8u20 and starting on 8u40.


Here is the plan for M5:

May 26-30: Fix P123, fix or move P45 to 8u40
June 2-5: Fix P123, zero P45 targeted to 8u20
June 9-13: Fix P123, defer bugs that won't make it
June 16-20: Code freeze, ramp down rules, fix doc bugs

During the week June 16-20, the usual milestone rules will be in effect 
and we are likely to be quite ruthless about any code changes.  We will 
likely only accept fixes for P12 critical bugs / regressions.


Thanks to everyone for their hard work,

Steve and Kevin

Re: Layout regression

2014-05-23 Thread Stephen F Northover

Application code only runs on the app thread.  Setting the uncaught 
exception handler should work for you.


Steve

On 2014-05-23 8:33 AM, ngalarn...@abinitio.com wrote:

How can we be notified of exceptions like these programmatically?

When my code is on the call stack, I can catch the exception
programmatically.

In this stack trace, only JavaFX code is there, but I still want to know
that something bad happened.

For the case of the JavaFX Application Thread, I guess I could do a
Platform.runLater  in that code call

 Thread.currentThread().setUncaughtExceptionHandler(myHandler)  //
ugh! Do I need to save away the previous one  chain to it?

Is that the best way for this thread?

What about JavaFX's other threads? Does application code ever run on those
threads?

How can I know that something went wrong on those threads? Even if my code
never runs there, I still want an automated way to know if something went
wrong.


Thanks,

Neil




From:   Scott Palmer swpal...@gmail.com
To: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net,
Date:   05/22/2014 03:56 PM
Subject:Re: Layout regression
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net



This appears to be a bug introduced in JavaFX 8
I have filed https://javafx-jira.kenai.com/browse/RT-37252 and will
work on a test case.

Scott

On Thu, May 22, 2014 at 3:45 PM, Scott Palmer swpal...@gmail.com wrote:

I'm investigating an issue with my application where things are
working fine running with JavaFX 2.2 on 7u55, but I have a particular
case where 8u5 is throwing the following exception during layout:

Exception in thread JavaFX Application Thread

java.lang.NullPointerException

at javafx.scene.layout.GridPane.computeMinHeights(GridPane.java:1450)
at javafx.scene.layout.GridPane.computeMinHeight(GridPane.java:1224)
at javafx.scene.Parent.minHeight(Parent.java:946)
at javafx.scene.layout.Region.minHeight(Region.java:1404)
at

javafx.scene.layout.Region.computeChildMinAreaHeight(Region.java:1700)

at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1981)
at javafx.scene.layout.Region.computeMaxMinAreaHeight(Region.java:1854)
at javafx.scene.layout.StackPane.computeMinHeight(StackPane.java:293)
at javafx.scene.Parent.minHeight(Parent.java:946)
at javafx.scene.layout.Region.minHeight(Region.java:1404)
at

javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765)

at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1982)
at javafx.scene.layout.Region.computeMaxPrefAreaHeight(Region.java:1884)
at javafx.scene.layout.StackPane.computePrefHeight(StackPane.java:310)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at

com.sun.javafx.scene.control.skin.TitledPaneSkin.computePrefHeight(TitledPaneSkin.java:249)

at javafx.scene.control.Control.computePrefHeight(Control.java:543)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at

javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765)

at javafx.scene.layout.GridPane.computePrefHeights(GridPane.java:1407)
at javafx.scene.layout.GridPane.computePrefHeight(GridPane.java:1242)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at

com.sun.javafx.scene.control.skin.ScrollPaneSkin.computeScrollNodeSize(ScrollPaneSkin.java:916)

at

com.sun.javafx.scene.control.skin.ScrollPaneSkin.layoutChildren(ScrollPaneSkin.java:791)

at javafx.scene.control.Control.layoutChildren(Control.java:574)
at javafx.scene.Parent.layout(Parent.java:1076)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Scene.doLayoutPass(Scene.java:576)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2386)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:321)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:319)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:319)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:348)
at

com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:479)

at

com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460)

at

com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327)

at

com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)

at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at

Re: [8u] Review request: (RT-37168) Mention if a property is configurable via CSS in the javadocs.

2014-05-22 Thread Stephen F Northover


Hi David,

I didn't see a problem with this.  Is there a downside to adding 
arbitrary tags to JavaDoc?


Steve

On 2014-05-22 3:23 PM, David Grieve wrote:

Steve, Kevin,

I'm looking for your ok on a change to rt/build.gradle that will allow 
me to add @css tags in javadoc. The diff is in the bug. This isn't the 
fix for the bug, but if you don't want to allow the tag option, then I 
need to approach this bug in a different way.


https://javafx-jira.kenai.com/browse/RT-37168

Re: Layout regression

2014-05-22 Thread Stephen F Northover

Thanks Scott.  It maybe that if you can't isolate a case, you can build 
FX from source (easy on Mac or Linux) and add some prints and debugging 
code.  See you in the JIRA!


Steve

On 2014-05-22 3:55 PM, Scott Palmer wrote:

This appears to be a bug introduced in JavaFX 8
I have filed https://javafx-jira.kenai.com/browse/RT-37252 and will
work on a test case.

Scott

On Thu, May 22, 2014 at 3:45 PM, Scott Palmer swpal...@gmail.com wrote:

I'm investigating an issue with my application where things are
working fine running with JavaFX 2.2 on 7u55, but I have a particular
case where 8u5 is throwing the following exception during layout:

Exception in thread JavaFX Application Thread java.lang.NullPointerException
at javafx.scene.layout.GridPane.computeMinHeights(GridPane.java:1450)
at javafx.scene.layout.GridPane.computeMinHeight(GridPane.java:1224)
at javafx.scene.Parent.minHeight(Parent.java:946)
at javafx.scene.layout.Region.minHeight(Region.java:1404)
at javafx.scene.layout.Region.computeChildMinAreaHeight(Region.java:1700)
at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1981)
at javafx.scene.layout.Region.computeMaxMinAreaHeight(Region.java:1854)
at javafx.scene.layout.StackPane.computeMinHeight(StackPane.java:293)
at javafx.scene.Parent.minHeight(Parent.java:946)
at javafx.scene.layout.Region.minHeight(Region.java:1404)
at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765)
at javafx.scene.layout.Region.getMaxAreaHeight(Region.java:1982)
at javafx.scene.layout.Region.computeMaxPrefAreaHeight(Region.java:1884)
at javafx.scene.layout.StackPane.computePrefHeight(StackPane.java:310)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at 
com.sun.javafx.scene.control.skin.TitledPaneSkin.computePrefHeight(TitledPaneSkin.java:249)
at javafx.scene.control.Control.computePrefHeight(Control.java:543)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at javafx.scene.layout.Region.computeChildPrefAreaHeight(Region.java:1765)
at javafx.scene.layout.GridPane.computePrefHeights(GridPane.java:1407)
at javafx.scene.layout.GridPane.computePrefHeight(GridPane.java:1242)
at javafx.scene.Parent.prefHeight(Parent.java:918)
at javafx.scene.layout.Region.prefHeight(Region.java:1438)
at 
com.sun.javafx.scene.control.skin.ScrollPaneSkin.computeScrollNodeSize(ScrollPaneSkin.java:916)
at 
com.sun.javafx.scene.control.skin.ScrollPaneSkin.layoutChildren(ScrollPaneSkin.java:791)
at javafx.scene.control.Control.layoutChildren(Control.java:574)
at javafx.scene.Parent.layout(Parent.java:1076)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Parent.layout(Parent.java:1082)
at javafx.scene.Scene.doLayoutPass(Scene.java:576)
at javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2386)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:321)
at com.sun.javafx.tk.Toolkit$3.run(Toolkit.java:319)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:319)
at com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:348)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:479)
at com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:460)
at com.sun.javafx.tk.quantum.QuantumToolkit$13.run(QuantumToolkit.java:327)
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$4$1.run(WinApplication.java:112)
at java.lang.Thread.run(Thread.java:745)

As you can see, it's all JavaFX code on the stack, so this is a little
tricky to debug.  As such I'm not sure yet if this is a JavaFX bug
introduced with 8.0 or an application bug that was masked in JavaFX
2.2 and is now showing up in JavaFX 8.

This happens when the managed/visible state of children changes.. but
I think it only for the case when all the children become unmanaged.

Once it happens JavaFX is crippled and pretty much all layout is
broken.  Popups (menus) still work and I can exit the application, but
all layout in the main window seems to not happen anymore.  Manual
positioning of nodes still works though.

I'll try to isolate a reproducible test case and file a bug report of course.

Scott

Re: Should TreeItem have a Text property?

2014-05-21 Thread Stephen F Northover


This sounds reasonable to me.  Please enter a JIRA for it.

Steve

On 2014-05-21 2:52 PM, Jeff Martin wrote:

I'm working with TreeView today and it seems like it would be convenient if 
TreeItem had a Text property in addition to it's Graphic property. This would 
seem to solve the most common need for a custom TreeCell factory.

Since most trees basically show a tree of labels, it would seem to make as much 
sense as the Graphic property.

It might have been sufficient if the default rendering used TreeItem.toString() 
instead of TreeItem.getValue().toString(), although this would miss the free 
updating you could get by resetting a TreeItem.Text property dynamically.

jeff

Re: Embedding JavaFX in SWT on Linux (Gtk3)


Hi Tom,

https://javafx-jira.kenai.com/browse/RT-35264

There is no plan to move to gtk3 at this point.  If we move to gtk3, FX 
will no longer be compatible with AWT/Swing which uses GTK2.  The 
monocle port uses only X11 and this could be investigated, however, 
things like Drag and Drop are unlikely to work.


I'll add all this information including Webkit use of GTK to RT-35264.

Steve

On 2014-05-14 8:54 AM, Tom Schindl wrote:

Hi,

Starting with Eclipse Luna (released in end of June) the default mode of
SWT on Linux is to make use of Gtk3.

As far as I understand the situation Glass on Linux is linked against
Gtk2 so JavaFX components that need glass (=fairly everything beside
javafx-properties) will fail to load - in fact i got reports that the
JVM crashes.

IIRC i read that monocole has a port that directly uses X11 would it be
a work-around to run with this port when running in swt-embedding?

Am I right that the webkit binaries are also linked against gtk2 or do I
remember this wrong?

Tom

CFV: New OpenJFX Committer: Eric Le Ponner


I hereby nominate Eric Le Ponner to be an OpenJFX Committer.

Eric Le Ponner is a significant contributor of the JavaFX Scene Builder 
2.0 product, and is the architect of the SB Kit API as well as the 
designated owner of the Content Panel.  Eric has been working on SB for 
more than 3 years, and during last year has been responsible for 
approximately 1620 commits to the internal SB 2.0 repository that we are 
converting to Open Source.


Eric is part of the team that has collectively done the Scene Builder 
2.0 product, which is a complete re-implementation of the code base, 
over a period of roughly 12 months. The new code base is more than 
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX 
repository, and will be maintained out of that repository after the 
conversion.



Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

CFV: New OpenJFX Committer: Jerome Cambon


I hereby nominate Jerome Cambon to be an OpenJFX Committer.

Jerome Cambon is a significant contributor of the JavaFX Scene Builder 
2.0 product, and is the designated owner of the Inspector Panel as well 
as the CSS Panel. Jerome has been working on SB for more than 3 years, 
and during last year has been responsible for approximately 500 commits 
to the SB 2.0 repository that we are converting to Open Source.


Jerome is part of the team that has collectively done the Scene Builder 
2.0 product, which is a complete re-implementation of the code base, 
over a period of roughly 12 months. The new code base is more than 
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX 
repository, and will be maintained out of that repository after the 
conversion.



Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

CFV: New OpenJFX Committer: Mo Chicharro


I hereby nominate Mo Chicharro to be an OpenJFX Committer.

Mo Chicharro is a significant contributor of the JavaFX Scene Builder 
2.0 product, and, as the visual and interaction designer, he is the 
designated owner of all FXML and CSS content. Mo has been working on SB 
since its inception 4 years ago, and during last year has been 
responsible for approximately 160 commits to the SB 2.0 repository that 
we are converting to Open Source.


Mo is part of the team that has collectively done the Scene Builder 2.0 
product, which is a complete re-implementation of the code base, over a 
period of roughly 12 months. The new code base is more than 70,000 lines 
of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX 
repository, and will be maintained out of that repository after the 
conversion.


Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

CFV: New OpenJFX Committer: Sandra Lions-Piron


I hereby nominate Sandra Lions-Piron to be an OpenJFX Committer.

Sandra Lions-Piron is a significant contributor of the JavaFX Scene 
Builder 2.0 product, and is the designated owner of the Hierarchy Panel 
as well as all menu commands. Sandra has been working on SB since its 
inception 4 years ago, and during last year has been responsible for 
approximately 750 commits to the SB 2.0 repository that we are 
converting to Open Source.


Sandra is part of the team that has collectively done the Scene Builder 
2.0 product, which is a complete re-implementation of the code base, 
over a period of roughly 12 months. The new code base is more than 
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX 
repository, and will be maintained out of that repository after the 
conversion.



Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

CFV: New OpenJFX Committer: Yves Joan


I hereby nominate Yves Joan to be an OpenJFX Committer.

Yves Joan is a significant contributor of the JavaFX Scene Builder 2.0 
product, and is the designated owner of the Library Panel, Document 
Panel and product packaging. Yves has been working on SB since its 
inception 4 years ago, and during last year has been responsible for 
approximately 960 commits to the SB 2.0 repository that we are 
converting to Open Source.


Yves is part of the team that has collectively done the Scene Builder 
2.0 product, which is a complete re-implementation of the code base, 
over a period of roughly 12 months. The new code base is more than 
70,000 lines of code, spread over approximately 4000 commits.
Scene Builder 2.0 is in the process of being converted to the OpenJFX 
repository, and will be maintained out of that repository after the 
conversion.



Votes are due by May 29, 2014.

Only current OpenJFX Committers [1] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [2]. Nomination to a project 
Committer is described in [3].


[1] http://openjdk.java.net/census#openjfx

[2] http://openjdk.java.net/bylaws#lazy-consensus

[3] http://openjdk.java.net/projects#project-committer

Re: gradle

2014-05-08 Thread Stephen F Northover

This is great news.  I would go with what you have (the unjaring) for 
now of course.


Are there any changes you are waiting on in OpenJFX?

Steve

On 2014-05-08 12:31 PM, Johan Vos wrote:

Hi,

We're getting closer to building the JavaFX Android runtime in OpenJFX.
I'm trying to automate all steps in the gradle build files, but my
knowledge is still very limited.
My current bottleneck: I would like to apply retrolambda to all class files
once they are compiled (per module). In my JavaFX Android application, this
is easily done by following the instructions for the retrolambda-gradle
plugin at https://github.com/evant/gradle-retrolambda. I just add apply
plugin: 'retrolambda' and automatically all my class files are converted
from Java 8 to Java 7, with lambda's being replaced.
For some reason, this doesn't work out of the box on the OpenJFX build --
maybe because it's a multiproject, or maybe because the jfxrt.jar is not
created with the jar command?

I currently do the following: unjar the jfxrt.jar after everything is
built, apply retrolambda on the class files, and repackage everything.
Clearly, this is a much dirtier than applying the retrolambda step after
compilation of the class files in each module.

Is there someone with sufficient gradle knowledge who can help here?

I've watched a number of gradle tutorials, and while I'm more pleased with
gradle than with maven, the only thing that disturbs me is that
gradle-professionals claim that gradle is extremely easy. Build tools are
NEVER easy for developers :) Some are just a bit easier than others.

Thanks,

- Johan

Re: (In)Sanity testing

2014-05-06 Thread Stephen F Northover


Please request in the JIRA or ping on Skype.

Steve

On 2014-05-06 9:46 AM, Kevin Rushforth wrote:

Unit test changes do not need an extra +1. From the Wiki:

   Changes that do not affect the bits that we ship do not require 
approval. ...


-- Kevin


David Grieve wrote:

Unit test only changes, too?

On 5/5/14, 11:07 AM, Stephen F Northover wrote:

Hi all,

Note also that this is M4 Milestone week which means no post-commit 
reviews and extra +1 controls required to release code.  The main 
point is that one of Kevin, Daniel, Jasper, Lisa or David H must be 
aware what code is going in and why.


Steve

On 2014-05-02 8:45 PM, Lisa Selle wrote:

Reminder to check out the matrix at

https://wiki.openjdk.java.net/display/OpenJFX/8u20

 for your insanity testing assignment for this week (assignments 
have changed for this week).  Testing should take 1 hour or less. 
If your assignment takes longer, stop after an hour and continue 
where you left off the following week.


Also, please review the weekly code freeze and push rules

Happy testing!

Lisa

Re: (In)Sanity testing

2014-05-05 Thread Stephen F Northover


Hi all,

Note also that this is M4 Milestone week which means no post-commit 
reviews and extra +1 controls required to release code.  The main point 
is that one of Kevin, Daniel, Jasper, Lisa or David H must be aware what 
code is going in and why.


Steve

On 2014-05-02 8:45 PM, Lisa Selle wrote:

Reminder to check out the matrix at

https://wiki.openjdk.java.net/display/OpenJFX/8u20

 for your insanity testing assignment for this week (assignments have 
changed for this week).  Testing should take 1 hour or less. If your 
assignment takes longer, stop after an hour and continue where you 
left off the following week.


Also, please review the weekly code freeze and push rules

Happy testing!

Lisa

Testing, Testing, 123 - Accessibility for JavaFX

2014-05-05 Thread Stephen F Northover


Hi all,

We have made good progress recently on Accessibility for JavaFX and have 
working implementation for Windows 8 (UIA) and OS X 10.9.  All of the 
built-in controls have been enabled.  You can find information about the 
work and how to enable the support here:


https://wiki.openjdk.java.net/display/OpenJFX/Accessibility+Exploration 
(this link is background information on the work)
https://wiki.openjdk.java.net/display/OpenJFX/Getting+Started+A11y (this 
link is for developers but describes some flags)


We have tested informally under VoiceOver and Narrator but nothing else 
(ie. for example, we have no run proprietary AT's such as JAWS).


We're looking for folks to help test the code and enter bug reports.  
The work is not targeted for 8u20 and will be removed before we ship 
because it is not ready for that release.  However, it is ready to be 
tested right now and will be spending the next couple of weeks seeing 
where we are.


https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report

Remember to set -Djavafx.accessible=true when testing.  Currently only 
Windows 8 and Mac OSX 10.9 are allowed to enable accessibility.  We hope 
to support Windows 7 and Mac OSX 10.8 as well, however these are 
disabled.  Using -Djavafx.accessible.force=true will force accessibility 
on these systems.


You can help!  Especially valuable is input from folks who use screen 
readers as part of their normal day.  Try one of the standard examples 
such as Modena or Ensemble and see how far you get.  There are problems 
for sure, but many things work.


Thanks,
Steve

Re: Setup IDE for development instructions

2014-04-24 Thread Stephen F Northover



On 2014-04-24 4:29 PM, Tom Schindl wrote:

Hi,

I try to follow the guide at
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my
Eclipse workspace but the description how to preconfigure the JDK is a
ambiguous.

The ambiguous information is the cd PATH TO JFX which could me (I
take my OS-X install as the reference)


This is the path where you checked out OpenJFX.  It is important that 
you get jfxrt.jar out of the ext directory.  I believe it is no longer 
necessary to move it to a standard place.  This is a hold over from when 
parts of JFX were not open source and you could not build everything.  
In that case, you needed a binary stub.  Of course, it doesn't hurt for 
everyone to move jfxrt.jar to a well known standard place in case you 
need it again.

* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext
* cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/

BTW for Eclipse there's no an easier way to get Java8 support you can
grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php


Fixed.


Tom

Re: Setup IDE for development instructions

2014-04-24 Thread Stephen F Northover


Did you build once outside the IDE?  Type gradle in the rt directory.

Steve

On 2014-04-24 5:28 PM, Tom Schindl wrote:

More stuff that does not work.

If you import the projects you have build-path errors because source
folders are missing in:
* base:
   - src/main/resources
   - src/test/resources
* builders
   - src/main/resources
   - src/test/resources
* designTime
   - src/main/resources
* fxml
   - src/main/resources
* media
   - src/test/java
   - src/test/resources
* swing
   - src/main/resources
   - src/test/java
   - src/test/resources
* swt
   - src/main/resources
   - src/test/java
   - src/test/resources
* web
   - src/main/native/WebKitBuild/Release/WebCore/generated/java

Libraries are not found in buildSrc:

It looks like you are using relative-paths but at least my eclipse does
not like that but e.g. wants to detect them as
rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar

* graphics to compile without errors needs swt-debug.jar in the library
path.

* swt to compile without errors needs swt-debug.jar in the library path

* scenebuilder needs to reference all projects but not rt-project

Tom


On 24.04.14 22:29, Tom Schindl wrote:

Hi,

I try to follow the guide at
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to setup my
Eclipse workspace but the description how to preconfigure the JDK is a
ambiguous.

The ambiguous information is the cd PATH TO JFX which could me (I
take my OS-X install as the reference)
* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext
* cd /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/

BTW for Eclipse there's no an easier way to get Java8 support you can
grab a prebuilt distro from http://www.eclipse.org/downloads/index-java8.php

Tom

Re: Setup IDE for development instructions

2014-04-24 Thread Stephen F Northover

H . I can't look at this now but will look at it tomorrow. I am 
running:


Eclipse SDK

Version: 4.3.2
Build id: M20140221-1700

I will get the latest and greatest from the Eclipse download page and 
follow the steps.


Eclipse has this funky optional classpath syntax.  Is this burning us?

  classpathentry kind=src exported=true path=src/test/java
  attributes
  attribute name=optional value=true/
/attributes
  /classpathentry

Anyhow, tomorrow!

Steve

On 2014-04-24 5:51 PM, Kevin Rushforth wrote:
The default task in build.gradle is sdk so gradle and gradle sdk 
are equivalent.


-- Kevin


Tom Schindl wrote:

Hi,

I once built with gradle sdk maybe that was wrong?

Tom

On 24.04.14 23:37, Stephen F Northover wrote:

Did you build once outside the IDE? Type gradle in the rt directory.

Steve

On 2014-04-24 5:28 PM, Tom Schindl wrote:

More stuff that does not work.

If you import the projects you have build-path errors because source
folders are missing in:
* base:
   - src/main/resources
   - src/test/resources
* builders
   - src/main/resources
   - src/test/resources
* designTime
   - src/main/resources
* fxml
   - src/main/resources
* media
   - src/test/java
   - src/test/resources
* swing
   - src/main/resources
   - src/test/java
   - src/test/resources
* swt
   - src/main/resources
   - src/test/java
   - src/test/resources
* web
   - src/main/native/WebKitBuild/Release/WebCore/generated/java

Libraries are not found in buildSrc:

It looks like you are using relative-paths but at least my eclipse 
does

not like that but e.g. wants to detect them as
rt/build/libs/ant-1.8.2.jar and not ../build/libs/ant-1.8.2.jar

* graphics to compile without errors needs swt-debug.jar in the 
library

path.

* swt to compile without errors needs swt-debug.jar in the library 
path


* scenebuilder needs to reference all projects but not rt-project

Tom


On 24.04.14 22:29, Tom Schindl wrote:

Hi,

I try to follow the guide at
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE to 
setup my
Eclipse workspace but the description how to preconfigure the JDK 
is a

ambiguous.

The ambiguous information is the cd PATH TO JFX which could me (I
take my OS-X install as the reference)
* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/jre/lib/ext 



* cd
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk_nofx/Contents/Home/

BTW for Eclipse there's no an easier way to get Java8 support you can
grab a prebuilt distro from
http://www.eclipse.org/downloads/index-java8.php

Tom

Re: Should Canvas have been Image subclass instead of Node?

2014-04-23 Thread Stephen F Northover

I think a graphics context on a writable image would make more sense.  
In any case, Canvas is a Node and will remain one forever.


Steve

On 2014-04-22 6:15 PM, Jeff Martin wrote:

I have a case where I need to draw to a canvas and reuse it in multiple nodes. 
My non-optimal work-around is to take a snapshot and use that, but it makes me 
wonder if Canvas should have been an Image subclass or if WritableImage should 
get it's own getGraphicsContext() method.

jeff

[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples

2014-04-16 Thread Stephen F Northover


Hi Jim,

Please review the lambdification of the buildSrc component (JSL 
portion).  Strangely, there is only one file that is affected.


Jira: https://javafx-jira.kenai.com/browse/RT-35197
Webrev: See patch in the JIRA

Steve

[8u20] [SWT, Mac, Retina] FXCanvas draws badly when Scene is changed

2014-04-16 Thread Stephen F Northover


Hi Anton,

Please review the fix for FXCanvas drawing badly (shrinking) when a new 
scene is set on retina.


Jira: https://javafx-jira.kenai.com/browse/RT-35250
Webrev: See patch in the JIRA

Steve

Re: [RT-33954] static block...causes IllegalStateException - re-open?

2014-04-08 Thread Stephen F Northover

The two ways of launching are equivalent however, at one point, we did 
not run main() even when main() was available and this caused problems 
on the desktop.  Lots of code was written that expected main() to run 
and this code was broken.  We will be supporting both ways of launching 
an FX application for the foreseeable future, however, the IDE's still 
need to understand that FX applications that only contain start() are 
launchable.


Steve

On 2014-04-08 8:34 AM, ngalarn...@abinitio.com wrote:

Hi Richard,

You raised this IntelliJ issue here:
http://youtrack.jetbrains.com/issue/IDEA-101939

It is marked as a feature request.

Are you guys saying that the 2 ways of launching are not equivalent?

What is the difference?

Maybe that issue should be upgraded to a BUG if the old launching method
is now wrong, not merely old fashioned.


Neil




From:   Richard Bair richard.b...@oracle.com
To: Kevin Rushforth kevin.rushfo...@oracle.com
Cc: openjfx-dev@openjdk.java.net, Sandipan Razzaque m...@sandipan.net
Date:   04/07/2014 09:43 PM
Subject:Re: [RT-33954] static block...causes IllegalStateException
- re-open?
Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net



Yes, this is one of the few things that I just hate about IDEA.

On Apr 7, 2014, at 6:00 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:


I can't speak to other IntelliJ issues, but the root cause of this

particular one is the same thing that Debbie ran into last week --
IntelliJ doesn't launch programs using the standard Java launcher. For
whatever reason, it uses its own launcher. This might be worth raising
with JetBrains.

-- Kevin


Jonathan Giles wrote:

Kevin,

Yes, that is the program I used, and yes, I get the 'Toolkit not

initialized' exception. I am running IntelliJ, so that is the reason. I
switched over to Eclipse and the code run as expected.

I am slightly bothered by the occasional failures that seem to be

IntelliJ-specific. I have a gut feeling that it doesn't always run all
tests (or that it runs them slightly differently to get different results
than when run on the command line). Does anyone know why this is?

I'm actually most at home in Eclipse, so perhaps I should switch to

that as my primary IDE for OpenJFX development.

-- Jonathan

On 8/04/2014 11:29 a.m., Kevin Rushforth wrote:

Just to make sure we are running the same program, the one I ran to

verify that RT-33954 is fixed was the simple test program in the comments
of that bug. Here it is (with the imports omitted for brevity).

public class Example extends Application {
   public static void main(String[] args) {
   //this is called from a static block in

javafx.scene.control.Control

   PlatformImpl.setDefaultPlatformUserAgentStylesheet();

   Application.launch(args);
   }

   @Override
   public void start(final Stage primaryStage) throws Exception {
   }
}

The above program runs fine for me with no exception.

Jonathan: are you seeing something different? Or perhaps running a

different example?

NOTE: if you run this from IntelliJ it will not work. I verified that

with Debbie last week (on a different issue), which may be why you are
seeing a problem. Running it from command line, from NB, or from Eclipse
works.

-- Kevin


Jonathan Giles wrote:

Firstly, I agree - this does seem to still be reproducible despite

Kevin's comment that it should have been resolved in JavaFX 8.0 due to
RT-28754 https://javafx-jira.kenai.com/browse/RT-28754, so that is
troubling. I'll leave Kevin to comment on that.

Secondly, RT-33954 was closed as a duplicate of RT-28754 

https://javafx-jira.kenai.com/browse/RT-28754, so it would be better to
leave RT-33954 closed and move discussion (including what you recently
posted) into RT-28754 https://javafx-jira.kenai.com/browse/RT-28754. The
discussion can start in there and most probably a new bug will need to be
opened (as RT-28754 https://javafx-jira.kenai.com/browse/RT-28754 did
result in a code change that at one point appears to have fixed the
problem, so we're possibly dealing with a regression).

Thirdly, whether this is a suitable bug for someone learning the

ropes is debatable. I'll leave Kevin to offer his thoughts, but perhaps
you can propose a patch that resolves this issue for you in your test
scenarios. Also, a good starting point is to develop a simple test
application that helps to demonstrate this issue (preferably the test case
is a single class with no dependencies), and which you can then share in
the jira issue via copy/paste into a comment.

Fourthly, to be a contributor in the OpenJDK requires you to follow a

process to get the paperwork in order. It is wise to get that started as
soon as possible, as it can sometimes take a while. Here's a link to the
process: http://openjdk.java.net/contribute/ The main thing is the OCA.

Finally, welcome! :-)

-- Jonathan

On 6/04/2014 1:06 p.m., Sandipan Razzaque wrote:

Hi JavaFX devs!

I was wondering how people

Re: JavaFX 2 + with LWJGL ( OpenGL )

2014-04-07 Thread Stephen F Northover

This solution is cool, but it draws to an image, sucks out the bits and 
then converts that to an FX image.  This is a good approach because it 
uses API and does not rely on any internals of FX. Hopefully it is fast 
enough for you.


Steve

On 2014-04-06 12:41 PM, Exo Verse wrote:

Yea the OpenGL comes with your graphics drivers for your video card. So
your correct that it doesn't ship with JavaFX. What I have been going on
about is trying to find a way to use JavaFX with LWJGL. In case you are
unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for
the OpenGL API. It's an alternative to JOGL.

On another note, as I did a search, Thanks to Tom showing me that link I
examined that code and I found something of interest in the JOGL code
interface..  well it lead me to a google search, and viola..  LWJGL with
JavaFX. :)

LINK :
https://github.com/Spasi/LWJGL-FX

So just wanted to post the link here and say thanks for all of your help. :)

Cheers,
Torak


On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.atwrote:


JavaFX does not ship OpenGL binaries on windows you have to build it your
own.

Please note:
a) if there are people who manage to write a prism pipeline on jogl why
should you not be able to do the same with lwjgl?
b) the talk i mentionned from felipe and steve show how to get access to
the native OpenGL context and there from you can use any API you like can't
remember which one they used

Tom

Von meinem iPhone gesendet


Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com:

Thanks, but as I mentioned in my original post, I don't like JOGL. It
doesn't work with my setup. I use LWJGL because its only about the OpenGL
and not other libraries, and its an easy API wrapper to use. There are

many

many reason I hate JOGL.. but this thread is not about hating on JOGL,

its

about finding a way to use LWJGL with JavaFX2+.

Also, Win32 API calls can use both DirectX and OpenGL APIs. And it

doesn't

matter what Windows OS you're using. I have tested this out from Windows

XP

all the way to Windows 7 - 32/64 Bit with no problem.

Cheers
Torak


On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl 

tom.schi...@bestsolution.atwrote:

There is a talk from Felipe and Steve at J1 last year how to embed

OpenGL

into FX using *internal* API!

Search for it on parleys - this does not help you on Win32 which uses
directx instead of javafx. BTW there are people doing a JOGL pipeline
https://bitbucket.org/dejayberlin/joglfxpipeline/src!

Tom
Von meinem iPhone gesendet


Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com:

Yea its a shame that using JavaFX as an option along with OpenGL wasn't
even thought of to begin with. I don't understand why they limit you

like

they do. Them trying to recreate the wheel and make their own version

of

a

3D interface is just plain stupid if it can't run low level. I can see

2D

games and applications with a LOT of usage for JavaFX and its 2D

graphics

API. But True 3D needs low level other wise its a waste of time.

Well, thanks for the replies. Guess I'll have to stick with using other
sources for my GUI. It's just that I like JavaFX version of its GUI

because

it is so simple to use. But not worth it if you can't use it for the

reason

that we the people need it for. Like in my case, game dev.

Cheers.
Torak


On Sun, Apr 6, 2014 at 10:48 AM, Philipp Dörfler phdoerf...@gmail.com
wrote:


It is not possible to combine JavaFX and OpenGL as it is right now.

This

was discussed on this mailing list some time before as a _possible_

future

addition, but I'd be very surprised if Oracle actually chose to

implement

this.

Starting with JavaFX 8 there is indeed some kind of 3D support but

the

3D API allows only for the most basic operations. It is still

completely

scene graph based and you have to live with all restrictions that

JavaFX

imposes on you. Not wanting to say that the 3D API is completely

useless,

but I'm afraid that even WPF is more flexible when it comes to 3D than
JavaFX is. For example: As far as I know you can not even change the
shading model from GL_SMOOTH to GL_FLAT. You could work around that by
setting the normals yourself though (Same for WPF). Also render

quality

is

bad when you render an instance of Text in 3D and scale it down for
example. At least it was when I tried that last time (few months ago).

Again, not to say that one can't work with JavaFX's 3D API, but it's

not

raw OpenGL either. As far as I know the JavaFX team wants to be able

to

let

the user use his own OpenGL context and let JavaFX render on top of

that or

add the possibility to ask JavaFX for the underlying context and mess

with

that but this is not even officially planned or included on any

roadmap

(AFAIK) so we can only keep our fingers crossed for that to happen.

Like

you I would absolutely LOVE to use JavaFX as a GUI on top of my OpenGL
games.

Cheers
Philipp Dörfler


Am 06.04.2014 um 16:31 schrieb Exo Verse

Re: JavaFX 2 + with LWJGL ( OpenGL )

2014-04-07 Thread Stephen F Northover


The lwjglfx solution.

Steve

On 2014-04-07 12:45 PM, Exo Verse wrote:

@ Steve
Which approach are you referring too ? The lwjglfx solution or this
transparency background solution ?

The lwjglfx I am assuming here since its drawing out to an image and back
in again. But if your speaking about my transparency issue I solved, I
didn't realize it was sending out to an image and back again. Could you
please elaborate as to which solution your speaking about ?

Torak


On Mon, Apr 7, 2014 at 12:33 PM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:


This solution is cool, but it draws to an image, sucks out the bits and
then converts that to an FX image.  This is a good approach because it uses
API and does not rely on any internals of FX. Hopefully it is fast enough
for you.

Steve


On 2014-04-06 12:41 PM, Exo Verse wrote:


Yea the OpenGL comes with your graphics drivers for your video card. So
your correct that it doesn't ship with JavaFX. What I have been going on
about is trying to find a way to use JavaFX with LWJGL. In case you are
unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for
the OpenGL API. It's an alternative to JOGL.

On another note, as I did a search, Thanks to Tom showing me that link I
examined that code and I found something of interest in the JOGL code
interface..  well it lead me to a google search, and viola..  LWJGL with
JavaFX. :)

LINK :
https://github.com/Spasi/LWJGL-FX

So just wanted to post the link here and say thanks for all of your help.
:)

Cheers,
Torak


On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.at

wrote:

  JavaFX does not ship OpenGL binaries on windows you have to build it your

own.

Please note:
a) if there are people who manage to write a prism pipeline on jogl why
should you not be able to do the same with lwjgl?
b) the talk i mentionned from felipe and steve show how to get access to
the native OpenGL context and there from you can use any API you like
can't
remember which one they used

Tom

Von meinem iPhone gesendet

  Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com:

Thanks, but as I mentioned in my original post, I don't like JOGL. It
doesn't work with my setup. I use LWJGL because its only about the
OpenGL
and not other libraries, and its an easy API wrapper to use. There are


many


many reason I hate JOGL.. but this thread is not about hating on JOGL,


its


about finding a way to use LWJGL with JavaFX2+.

Also, Win32 API calls can use both DirectX and OpenGL APIs. And it


doesn't


matter what Windows OS you're using. I have tested this out from Windows


XP


all the way to Windows 7 - 32/64 Bit with no problem.

Cheers
Torak


On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl 


tom.schi...@bestsolution.atwrote:


There is a talk from Felipe and Steve at J1 last year how to embed
OpenGL
into FX using *internal* API!

Search for it on parleys - this does not help you on Win32 which uses
directx instead of javafx. BTW there are people doing a JOGL pipeline
https://bitbucket.org/dejayberlin/joglfxpipeline/src!

Tom
Von meinem iPhone gesendet

  Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com:

Yea its a shame that using JavaFX as an option along with OpenGL
wasn't
even thought of to begin with. I don't understand why they limit you


like

they do. Them trying to recreate the wheel and make their own version

of

a

3D interface is just plain stupid if it can't run low level. I can see


2D

games and applications with a LOT of usage for JavaFX and its 2D

graphics

API. But True 3D needs low level other wise its a waste of time.

Well, thanks for the replies. Guess I'll have to stick with using
other
sources for my GUI. It's just that I like JavaFX version of its GUI


because


it is so simple to use. But not worth it if you can't use it for the


reason


that we the people need it for. Like in my case, game dev.

Cheers.
Torak


On Sun, Apr 6, 2014 at 10:48 AM, Philipp Dörfler 
phdoerf...@gmail.com
wrote:

  It is not possible to combine JavaFX and OpenGL as it is right now.
This

was discussed on this mailing list some time before as a _possible_

future
addition, but I'd be very surprised if Oracle actually chose to
implement
this.

Starting with JavaFX 8 there is indeed some kind of 3D support but


the

3D API allows only for the most basic operations. It is still

completely

scene graph based and you have to live with all restrictions that

JavaFX

imposes on you. Not wanting to say that the 3D API is completely

useless,
but I'm afraid that even WPF is more flexible when it comes to 3D than

JavaFX is. For example: As far as I know you can not even change the
shading model from GL_SMOOTH to GL_FLAT. You could work around that
by
setting the normals yourself though (Same for WPF). Also render


quality

is

bad when you render an instance of Text in 3D and scale it down for

example. At least it was when I tried that last time (few months
ago).

Again, not to say

[8u20] Review request: RT-35197: Use Lambda in FX runtime and samples

2014-04-04 Thread Stephen F Northover


Hi Kevin,

Please review the lambdification of the graphics component. You are 
welcome to apply the patch, but there are numerous changes and they are 
all automatic. If you or any of the team have outstanding changes, 
please coordinate with me in the JIRA and I will re-lambdify after you 
have released your changes.


Jira: https://javafx-jira.kenai.com/browse/RT-35197
Webrev: See patch is in the JIRA

Steve

Re: Expected frame rates for a full-screen blur

2014-04-04 Thread Stephen F Northover


Hi Mike,

I'm sorry that I've been unable to get to this until now.  I can 
recreate the problem you are seeing on my Mac by running 
ColorfulCirclesApp.  Please enter a JIRA for the problem.  Thanks. Also 
try this:


Try this:

PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
Timeline timeline = new Timeline(
  new KeyFrame(Duration.seconds(1), t - {
 System.out.println(::FPS =  + tracker.getAverageFPS());
  }));
timeline.setCycleCount(Timeline.INDEFINITE);
timeline.play();

Steve

On 2014-04-04 4:33 PM, Mike Hearn wrote:

OK, now I'm really puzzled - I watched the JavaFX performance talk from
2011 and learned about PeformanceTracker. It's too bad that's not public
API, but it works. I used it like so:

PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
 tracker.setOnRenderedFrameTask(new Runnable() {
 long lastTimestamp = System.currentTimeMillis();

 @Override
 public void run() {
 final long now = System.currentTimeMillis();
 long delta = now - lastTimestamp;
 if (delta  1000)
 System.out.println(Frame took  + delta + msec);
 lastTimestamp = now;
 }
 });

The 1000 thing is just to avoid printing a nonsense timestamp when the UI
hasn't been touched for a while.

The deltas I see are consistently between 10-20msec which would be between
50 and 60fps, i.e. the vsync of the screen. But the wacky thing is, this
doesn't change when I increase the size of the window, even though the
animation is noticeably more choppy. It still says there's a 10-20msec gap
between frames even though my eyes tell me otherwise. Even when I shrink
the window size right down and get super smooth animation, the above code
prints the same kind of deltas.

This makes me think that whatever is going on, the regular JavaFX drawing
thread isn't the issue. It seems to be churning through the scene at the
same totally acceptable rate no matter what. So I'm thinking the issue must
be something to do with how fast the GPU drains the command queue or
something.

BTW I tried doing -Dprism.order=j2d to see what would happen, and the GUI
hangs before rendering anything. I'll file a bug on that later.


On Thu, Apr 3, 2014 at 11:54 AM, Mike Hearn m...@plan99.net wrote:


How does the OS tank?
All the OS animations hit the same frame rate as the app itself does. For
instance, opening Mission Control is normally smooth, but when a maximized
JFX app is animating, it's not.

It feels like the GPU is being overworked but as I'm not a GPU expert at
all, I'm not sure where to begin - I am not even sure how to find out the
frame rate so I know when tweaks are improving things! Is there a way to
get this data from the system?

Re: Building OpenJFX on Mac OS X 10.9.2 / XCode 5.1 / XCode 4.3.3

2014-04-04 Thread Stephen F Northover


Put this in your gradle.properties file:

MACOSX_SDK_PATH = 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk


We need to document this on the wiki.  Will do that Monday.  Gotta go now.

Steve

On 2014-04-04 5:31 PM, Philipp Dörfler wrote:

Hi,

just out of curiousity I wanted to build OpenJFX, but although I followed the 
instructions at
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
I can’t get it to work.

gradle 1.8 fails when building :fxpackage:compileLauncher as follows:

:fxpackager:compileLauncher
clang: warning: no such sysroot directory: 
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
/Users/phi/Documents/workspace/OpenJFX8-rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26:9:
 fatal error: 'Cocoa/Cocoa.h' file not found
#import Cocoa/Cocoa.h
 ^
1 error generated.
:fxpackager:compileLauncher FAILED

I do not have a 10.7 SDK on my 10.9 Mac, but I do have a 10.8 and 10.9:

$ ls 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
MacOSX10.8.sdk MacOSX10.9.sdk

According to „the internet™“ I would have to find an old version of Xcode 
(apparently 4.3.3) because that’s the only way to find an old SDK.
As I’m sure that you guys have valid reasons to stick to 10.7 I think it would 
not hurt to mention this on the wiki page mentioned above stating that one 
needs XCode not newer than 4.3.3 and that old XCode versions can be downloaded 
on the Apple Developer website.
I would add it myself but as I’m not a contributor I don’t have the required 
permissions, so all I can do is to ask here for inclusion of that.

Thanks! May that be the only obstacle in building JFX8.

Re: Why is com.sun.glass.ui.swt part of graphics-module

2014-04-02 Thread Stephen F Northover


Hi Tom,

This is an experimental SWT implementation of Glass that is used for 
debugging, benchmarking etc. purposes.  It's unlikely that we will ever 
ship it as part of FX.  You are right that it can't be part of jfxrt.jar 
and should it ever become more than that, it would need to be in a 
separate jar, perhaps part of swtfx.jar.


Steve

On 2014-04-02 3:43 AM, Tom Schindl wrote:

Hi Steve  others,

Why is com.sun.glass.ui.swt part of the graphics module? Should it go
into the swt one?

I think it should be shipped with swtfx.jar not else we get back to
classloader hell because the extension classloader tries to load classes
from swt which it naturally can not find.

Tom

Re: macosx fullscreen and window manager

2014-03-31 Thread Stephen F Northover

It doesn't hurt to enter a JIRA for this.  Even if we don't get to it 
ourselves, any sort of solution that you might come up with (even Mac 
only) can be tracked there.


Steve

On 2014-03-31 11:03 AM, Jasper Potts wrote:

Hot corners and screen saver could just be turned off in system preferences. 
Then the cursor set to empty. If you need dynamic then you might be able to use 
something like JNA or JNIWrapper to make native call need to disable those 
things.

Jasper


On Mar 29, 2014, at 2:08 AM, Erik Colson e...@ecocode.net wrote:

Hi,

Is it possible to use JavaFX for developping a fullscreen macosx
application that skips the window manager ? I have currently an app that
does fullscreen but :
- the 'hot corners' still work, letting the user switch to another app
- the screensaver is still working
- the mouse pointer is still shown

The app is ment to become something like a Slideshow. Therefor those 3
points need to be solved.

This is what I have for now:

Screen screen = Screen.getPrimary();
primaryStage.initStyle(StageStyle.UNDECORATED);
primaryStage.setResizable(false);
primaryStage.setIconified(false);
primaryStage.setFullScreenExitHint();
primaryStage.setFullScreen(true);
primaryStage.setScene(scene);
primaryStage.toFront(); // not really needed I think
primaryStage.centerOnScreen();
primaryStage.show();

thanks !
--
erik colson

Re: Adding GStreamer plugins

2014-03-26 Thread Stephen F Northover


https://javafx-jira.kenai.com/browse/RT-18009

This JIRA is covering adding support for more media formats.  Since we 
are just talking about MKV, please open a separate JIRA to cover this 
work and attach the patch there.  We can link to the new JIRA from RT-18009.


Steve

On 2014-03-25 7:47 PM, Jonathan Giles wrote:
Typically in this case you would email the patch to the assigned 
developer, but it appears RT-18009 is unassigned at present. I think 
that is the first hurdle that needs to be resolved, but if you email 
me your patch I will attach it to the jira issue so that it is at 
least available for others.


Thanks!

-- Jonathan

On 26/03/2014 12:39 p.m., Michael Berry wrote:

Hi all,

Turns out it was a stupid mistake on my part causing the last few 
linking
errors, I hadn't added one of the C files I needed to the makefile 
(well I
had, but I'd then reverted it again without realising!) Thanks to all 
for

the prods and advice.

Once I'd done that, the build went through without a hitch - and then it
was just a case of making the relevant additions to the native code to
register the MKV type and create a pipeline from it using the plugin. 
This
wasn't hard to work out at all; I've since tried several test files 
in MKV
format (with AAC audio) all of which play in MediaPlayer without a 
hitch!


I mainly wanted to do this as a personal exercise, though I'd imagine 
this

is a useful piece of functionality for many others also - so should I
submit a patch of the changes, or is this unlikely to be accepted? 
(Again,
sorry for the perhaps obvious question, I'm rather new to this.) I've 
had a
look at the code review process and it seems to suggest adding a 
patch to

the relevant JIRA issue for those who don't have commit access (in this
case 18009), but I don't seem to have permission to do that either?

Thanks,

Michael


On 25 March 2014 17:01, Stephen F Northover 
steve.x.northo...@oracle.comwrote:



On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:


Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:


I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external 
symbol

errors for functions it uses in glib - not entirely sure why at the
moment,
as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer 
version, and

I
can't quite work out the logic behind why things have been changed 
the

way
they have - so even after the compilation issue is resolved I'm 
now less

confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could 
shed any

light on any of this, it would be hugely appreciated.

We did some changes in existing GStreamer code because it had 
errors and
because we needed to expand some functionality. The changes are not 
very

extensive.

  However, putting the current problems aside for a bit, the snags 
I hit up

until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional 
points
for the wiki? These may be obvious to the majority reading here, 
but as
someone completely new to building JFX they had me stumped for a 
while!


I can give you some directions. There is no wiki. I'd appreciate if 
you

created one.

- It turns out that the Gstreamer stuff doesn't compile at all by

default,
which is why I wasn't seeing any changes on the native level. To 
ensure

GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and 
uncomment the
#COMPILE_MEDIA = true line. (A similar scenario would appear to 
exist

for
any webkit alterations as per the line above.)


You don't need to comment/uncomment anything. Just add
-PCOMPILE_MEDIA=true to the gradle command line. You can however 
change the

properties file too.

- As well as the requirements listed, I needed the Windows SDK (
http://www.microsoft.com/en-gb/download/details.aspx?id=8279) 
installed

for
GStreamer to compile successfully under Windows (7) - without it 
cygpath

just threw a rather confusing error.


You need windows 7.1a SDK and speaking precisely you need only samples
from it because samples have BaseClasses at 
Samples/multimedia/directshow/baseclasses.

BaseClasses are used for Oracle direchshowwrapper plugin.

- The developer workflow page (

https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow)
refers
to  -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs
instead?


What are you gonna use it for ?


I updated the page and got rid of the BINARY_STUB reference that is no
longer needed.


  I'm happy to make the above changes myself but unsure of if / 
where you

can
sign up for an account, so I'm just throwing them here for now - if
anyone
could point me to the right place then that'd be great!


Steve. Can you give an advice

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread Stephen F Northover


Hi David,

Sorry to be getting to this so late.  An uninitialized pixel is normally 
considered to be black.  If you throw an exception, clients will need to 
either catch the exception or perform the same test that you are 
performing before they call the API.  Since this is not pubic API, no 
client will be affected so even if we make the change to throw the 
exception and then decide not to do this later, we can change it.


What is happening now?  Who is being affected by this bug?  Is it easy 
to change the implementations to return black?  This seems better to me 
than throwing the exception.


As I say, if we throw the exception, then we will only break ourselves, 
not clients of FX API.  Have we ensured that the exception will not 
break SQE tests.


Again, sorry to be getting to this so late and apologies if all of this 
has been discussed in another thread that I missed,

Steve

On 2014-03-25 2:46 PM, David Hill wrote:

On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

Having heard a little feedback, here is my proposal in the form of a 
review request :-)



My recommendation would be modify the JavaDoc contract to specify 
that the x,y and x+width, y+height must be within the screen bounds, 
with an IllegalArgumentException if out of bounds. This would be 
checked in Robot, prior to calling the native impls.


This code is internal API, so I expect the real impact would be on 
SQE.
I really like the idea of adding a bounds restriction - so that the 
requested bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge 
case of out of bound pixels, with the least likely impact.


This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given 
that most of us would avoid asking for a screen capture with undefined 
pixels. I do expect that we will encounter a few exceptions to this 
when tests are run on smaller displays (like embedded).


I also added bounds checking to Robot.getPixelColor() for consistency, 
and because Embedded passes this call through to common code for 
screen capture.


I did a grep through the JavaFX code base, and don't see any JavaFX 
use cases. I expect any golden image test code could be affected.


I separated out this internal API changes from my embedded changes so 
we have a clear and easy thing to review.


Jira: https://javafx-jira.kenai.com/browse/RT-36382

Patch: is inline in the Jira, but also here:

diff -r bb72bd2fa889 
modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue 
Mar 25 14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue 
Mar 25 14:41:37 2014 -0400

@@ -144,9 +144,20 @@
 protected abstract int _getPixelColor(int x, int y);
 /**
  * Returns pixel color at specified screen coordinates in IntARGB 
format.

+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
  */
 public int getPixelColor(int x, int y) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x = s.getWidth() || y  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getPixelColor(x, y);
 }

@@ -162,13 +173,27 @@
  * will result in a Pixels object with dimensions (20x20). 
Calling code
  * should use the returned objects's getWidth() and getHeight() 
methods

  * to determine the image size.
- *
+ *
  * If (@code isHiDPI) is {@code false}, the returned Pixels 
object is of
  * the requested size. Note that in this case the image may be 
scaled in
  * order to fit to the requested dimensions if running on a HiDPI 
display.

+ *
+ * If the requested capture bounds is not contained by the actual 
Screen

+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
+ * @param width The of width the requested capture (must be =1 
and fit on the screen)
+ * @param height The of width the requested capture (must be =1 
and fit on the screen)

+ * @param isHiDPI return HiDPI if available
  */
 public Pixels getScreenCapture(int x, int y, int width, int 
height, boolean isHiDPI) {

 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x + width  s.getWidth() || y + height  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getScreenCapture(x, y, width,

Re: Adding GStreamer plugins

2014-03-25 Thread Stephen F Northover



On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:

Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:

I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external 
symbol
errors for functions it uses in glib - not entirely sure why at the 
moment,

as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer version, 
and I
can't quite work out the logic behind why things have been changed 
the way

they have - so even after the compilation issue is resolved I'm now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could shed any
light on any of this, it would be hugely appreciated.
We did some changes in existing GStreamer code because it had errors 
and because we needed to expand some functionality. The changes are 
not very extensive.


However, putting the current problems aside for a bit, the snags I 
hit up

until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional points
for the wiki? These may be obvious to the majority reading here, but as
someone completely new to building JFX they had me stumped for a while!
I can give you some directions. There is no wiki. I'd appreciate if 
you created one.


  - It turns out that the Gstreamer stuff doesn't compile at all by 
default,

which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and uncomment the
#COMPILE_MEDIA = true line. (A similar scenario would appear to 
exist for

any webkit alterations as per the line above.)
You don't need to comment/uncomment anything. Just add 
-PCOMPILE_MEDIA=true to the gradle command line. You can however 
change the properties file too.



  - As well as the requirements listed, I needed the Windows SDK (
http://www.microsoft.com/en-gb/download/details.aspx?id=8279) 
installed for

GStreamer to compile successfully under Windows (7) - without it cygpath
just threw a rather confusing error.
You need windows 7.1a SDK and speaking precisely you need only samples 
from it because samples have BaseClasses at 
Samples/multimedia/directshow/baseclasses. BaseClasses are used for 
Oracle direchshowwrapper plugin.



  - The developer workflow page (
https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) 
refers
to  -Djavafx.ext.dirs - I think this should be -Djava.ext.dirs 
instead?

What are you gonna use it for ?
I updated the page and got rid of the BINARY_STUB reference that is no 
longer needed.


I'm happy to make the above changes myself but unsure of if / where 
you can
sign up for an account, so I'm just throwing them here for now - if 
anyone

could point me to the right place then that'd be great!

Steve. Can you give an advice ?
If you are looking to contribute (when you get to a good place), the 
process is well known and is followed by the everyone.


https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews


If I do ever manage to get this working (ha-ha) I'd also like to 
throw up a

wiki page just detailing how to grab a gstreamer plugin and make the
necessary changes to it to compile it into openjfx as a stop gap to then
perhaps working on one or both of the above JIRA issues and seeing 
where I

get - does this sound reasonable?


Only committers can edit the wiki right now.  It is possible to become 
an Author and write to the wiki, but I would be happy to publish your 
recipe when you are happy with it.



It does.



On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote:
However, I'm not sure if I'm going about including the matroska 
plugin

in

the right way - I've currently done the following:

- Downloaded the latest version of the plugins from here (
http://gstreamer.freedesktop.org/src/gst-plugins-good/), then 
added the

matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the

modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/ 


folder (I'm unsure of this - should I add it to both these folders?).
Well you see. If you download the latest matroska plugin it 
potentially can have dependencies on the latest GStreamer platform. We 
don't have/use the latest gstreamer. The version we use is 0.10.35. 
And the latest available is 1.x. They are incompatible in some methods.



- Added all the C files from the first folder mentioned above to the
plugins.vcxproj file

- Added the relevant files and directory to Makefile.gstplugins

- Called the additional relevant plugin_init() function in
gstplugins-lite.c
There is one more thing you need to do here for Windows only apart 
from running gradle with -PCOMPILE_MEDIA=true. Windows build system 
has files that export symbols
1)

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread Stephen F Northover

Apple has a long history of burning developers like this. It's the
price of running on their platform.

Steve

On 2014-03-25 3:30 PM, Phil Race wrote:
I see .. so AVFoundation was already there since 10.7, its AVKit
that's new in 10.9

but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation
about 18 months ago

based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as
a big, urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:
Therein lies The Problem, and why we had to go with QTKit when we
supported 10.6... Every two releases they seem to deprecate
half-baked APIs in favor of some new half-baked API. At least as of
10.8 that seems to have stabilized somewhat, as we transition more
and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it
wasn't available on 10.6. It's supposed to work correctly (never had
time to confirm) on 10.8 but that still leaves 10.7 out in the cold.
So we'll likely have to stick with QTKit for older releases and move
to AVFoundation in 10.8 and later. Ideally, the QTKit component would
be separate so it could be removed allowing MAS apps to still support
A/V playback. I think the QTKit component can be dropped completely
in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it
doesn't look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets
10.8 if its

unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the
installed base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:
Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:
Thanks for the verification. No matter what state Quicktime is in
it is no longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I
could be wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven
david.deha...@oracle.com wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the
obsolete Quicktime. When some submits to the Apple Store a JavaFX
app it gets rejected based on JavaFX having the obsolete API. I
found out how to fix it from someone else running into the same
issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Is Quicktime API calls inside JavaFX?

2014-03-25 Thread Stephen F Northover

As I said, Apple does this. It took cocoa (a nice API) years until it
had the functionality of carbon (an awful API). Believe me, I have
experienced the trail of dead API and the pointless developer rewrites.

Steve

On 2014-03-25 4:02 PM, David DeHaven wrote:

Yes, this is true, but QuickTime (despite it's horrible component architecture)
was stable and actually useful for a very long time, then they dropped it and
replaced it with what amounts to absolutely nothing useful. Only in 10.8 did
they start putting useful bits back in, it's still a long ways to go to catch
up to the utility of QuickTime.

-DrD-

Apple has a long history of burning developers like this. It's the price of
running on their platform.

Steve

On 2014-03-25 3:30 PM, Phil Race wrote:

I see .. so AVFoundation was already there since 10.7, its AVKit that's new in
10.9
but AV Foundation is what FX would use.
It looks like Apple starting encouraging migration to AV Foundation about 18
months ago
based on the date of this document :-
https://developer.apple.com/library/mac/technotes/tn2300/_index.html
I suppose we need to learn read the apple seeds and interpret that as a big,
urgent, hint.

-phil.

On 3/25/2014 12:09 PM, David DeHaven wrote:

Therein lies The Problem, and why we had to go with QTKit when we supported
10.6... Every two releases they seem to deprecate half-baked APIs in favor of
some new half-baked API. At least as of 10.8 that seems to have stabilized
somewhat, as we transition more and more to an iOS clone.

We had issues with AVFoundation not working the way we needed and it wasn't
available on 10.6. It's supposed to work correctly (never had time to confirm)
on 10.8 but that still leaves 10.7 out in the cold. So we'll likely have to
stick with QTKit for older releases and move to AVFoundation in 10.8 and later.
Ideally, the QTKit component would be separate so it could be removed allowing
MAS apps to still support A/V playback. I think the QTKit component can be
dropped completely in FX 9 but it needs to be there in FX 8.

AVKit is a high level component that sits on top of AVFoundation, it doesn't
look useful for our purposes at first glance.

-DrD-

I presume that Apple now want you to use AVKit which is new in 10.9.
However I don't understand how you can develop an app that targets 10.8 if its
unable to use QTKit since that's all there is on 10.8 or earlier.

Does the AppStore really disallow targeting something like half the installed
base ??

-phil.

On 3/25/2014 9:19 AM, Stephen F Northover wrote:

Here is the JIRA that is tracking this:
https://javafx-jira.kenai.com/browse/RT-34893

Steve

On 2014-03-25 11:46 AM, Tony Anecito wrote:

Thanks for the verification. No matter what state Quicktime is in it is no
longer accepted by the Apple Store.
I am guessing these new rules will soon apply to everything but I could be
wrong.

Regards,
-Tony

On Tuesday, March 25, 2014 9:27 AM, David DeHaven david.deha...@oracle.com
wrote:

Hi All,
Apparently the JavaFX includes some libraries that use the obsolete Quicktime.
When some submits to the Apple Store a JavaFX app it gets rejected based on
JavaFX having the obsolete API. I found out how to fix it from someone else
running into the same issue.

http://stackoverflow.com/questions/21008617/java-error-when-submitting-app-to-mac-store-deprecated-api-usage

It uses the now deprecated QTKit to play media.

-DrD-

Re: Ability to decorate ChangeListener

2014-03-24 Thread Stephen F Northover

I'm pretty sure this discussion has solidified around not flipping the 
equals() but this is a good example of something that we wouldn't 
change.  If you write code that relies on this, it will break in the 
future when new code is added in FX that does not follow the pattern.


Steve

On 2014-03-22 10:47 AM, 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 (changeListeners[index].equals(listener)) {

a listener decoration can be smart enough to not only check against itself, but 
also against its delegate.

What do you think?

I could prepare a patch for the *ExpressionHelper classes.


Best regards,
Mario

Re: Using JavaFX deploy and having signing issues...

2014-03-24 Thread Stephen F Northover


Yes and we'll put them on the OpenJFX wiki.

Steve

On 2014-03-24 6:39 PM, Mark Fortner wrote:

Tony and/or Danno,
Would you mind documenting the steps that you had to go through to make a
Mac application that was submittable to the Apple Store?  I'm sure everyone
who's struggling to create applications would appreciate the information.

Cheers,

Mark



On Mon, Mar 24, 2014 at 3:30 PM, Tony Anecito adanec...@yahoo.com wrote:


Ok I was able to codesign and submit. The JavaFX deploy task is not
creating a info.plist when the jdk is added to the bundle for the jdk.

After submission there were some issues related to signing and it now
requires a entitlements file for some things in the jre.

Regards,
-Tony



On Monday, March 24, 2014 12:01 PM, Tony Anecito adanec...@yahoo.com
wrote:

So you have tried codesign with Mavericks OS X? I am getting invalid
bundle when the jdk is bundled as required by the Apple Store. You have to
codesign the jdk plugin seprately.
Yes you can create a pkg or dmg image but I am looking for the correct way
get the jdk codesigned else the app codesign fails also.

Do you have a working example of codesign the jdk in the bundle?

Thanks,
-Tony




On Monday, March 24, 2014 11:48 AM, Danno Ferrin danno.fer...@oracle.com
wrote:

You can still deploy apps to the app store using JavaFX.  You just cannot
use the media library at the moment.  You can do it also via non app store
distribution and sign it via gatekeeper as well and keep the media
libraries in.  And it shouldn't matter what version of Mac OSX you use to
build it.

Tony Anecito adanec...@yahoo.com wrote:


Thanks Richard,

I know some more now. It seems with Mavericks 10.9 codesign and the bundle
format that JavaFX deploy creates is no longer valid. There are starting to
appear to be more references to this issue on the internet.
So JavaFX apps can no longer be created and work on the Mac at least as
far as the Apple Store is concerned.

I may have to downgrade my Mac OS X to 10.8 to create Apple Store
distributable JavaFX apps for the Mac.

-Tony



On Monday, March 24, 2014 10:57 AM, Richard Bair richard.b...@oracle.com
wrote:


One last hurdle, you need to remove the media library for JavaFX

(lib/libjfxmedia.dylib) from your bundled JDK.  It uses QuickTime and that
is being disowned by apple.  This may be fixed in a later 8u update, but
not in 8.0.0_b132.

Oh good grief, Apple! So what should we be using instead? This means I
cannot make use of fx media in any app submitted to the app store?

Richard

Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'

Was this gradle 1.8 or a problem with an EA version of JDK8?  In any 
case, update both.  If you can't, doing a clean every time should work 
but that's not the long term answer.


Steve

On 2014-03-21 5:49 AM, Kevin Rushforth wrote:
Are you using gradle 1.8? This looks like a bug we used to have with 
prior versions of gradle.


-- Kevin


Leonid Popov wrote:
Hi, I updated my workspace recently, tried to build it and have got 
the following exception. Any suggestions?


 FAILURE: Build failed with an exception.

 * What went wrong:
 Execution failed for task ':web:compileGeneratedWin'.
  java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

 * Exception is:
 org.gradle.api.tasks.TaskExecutionException: Execution failed for 
task ':web:compileGeneratedWin'.

Re: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin'

We fail on gradle 1.11.  I have filed this bug: 
https://javafx-jira.kenai.com/browse/RT-36330


I suggest that if we can't fix the bug quickly, we print out a message 
that we require gradle 1.8 and exit.  We should let people override this 
choice in the properties file.


Steve

On 2014-03-21 7:47 AM, Kevin Rushforth wrote:
This was a gradle 1.4 bug that is fixed in 1.8: 
http://issues.gradle.org/browse/GRADLE-2831


Leonid just happened to be running an older gradle.

-- Kevin


Stephen F Northover wrote:
Was this gradle 1.8 or a problem with an EA version of JDK8?  In any 
case, update both.  If you can't, doing a clean every time should 
work but that's not the long term answer.


Steve

On 2014-03-21 5:49 AM, Kevin Rushforth wrote:
Are you using gradle 1.8? This looks like a bug we used to have with 
prior versions of gradle.


-- Kevin


Leonid Popov wrote:
Hi, I updated my workspace recently, tried to build it and have got 
the following exception. Any suggestions?


 FAILURE: Build failed with an exception.

 * What went wrong:
 Execution failed for task ':web:compileGeneratedWin'.
  java.lang.ClassFormatError: Invalid Constant Pool entry Type 18

 * Exception is:
 org.gradle.api.tasks.TaskExecutionException: Execution failed for 
task ':web:compileGeneratedWin'.

Re: PropertyBase vs SimpleProperty

This looks good.  I wonder if we should make this (massive) change 
before we lambda graphics and controls?  Probably doesn't matter. We'll 
need a JIRA and someone assigned to it in order to track the work.


Steve

On 2014-03-21 12:53 PM, Tom Schindl wrote:

Hi Richard,

Coming back to this old thread and now that we are using lamdas all over
I guess we could take one more look into that.

I've prototyped an initial version by introducing a new internal type
named InvalidatedSimpleObjectProperty (not the best name ever!) - see
code pasted below.

And now one can write code like this:


 public final ObjectPropertyRectangle2D viewportProperty() {
 if (viewport == null) {
 viewport = new InvalidatedSimpleObjectProperty(this, viewport, 
(o) - {
invalidateWidthHeight();
 impl_markDirty(DirtyBits.NODE_VIEWPORT);
 impl_geomChanged();
 } );
 }
 return viewport;
 }

instead of


 public final ObjectPropertyRectangle2D viewportProperty() {
 if (viewport == null) {
 viewport = new ObjectPropertyBaseRectangle2D() {

 @Override
 protected void invalidated() {
 invalidateWidthHeight();
 impl_markDirty(DirtyBits.NODE_VIEWPORT);
 impl_geomChanged();
 }

 @Override
 public Object getBean() {
 return ImageView.this;
 }

 @Override
 public String getName() {
 return viewport;
 }
 };
 }
 return viewport;
 }

Which allows us to get rid of most of the ObjectPropertyBase sublcasses.

Tom



package com.sun.javafx.property;

import java.util.function.Consumer;

import javafx.beans.property.SimpleObjectProperty;

public final class InvalidatedSimpleObjectPropertyT extends 
SimpleObjectPropertyT {
private final ConsumerInvalidatedSimpleObjectPropertyT 
invalidationConsumer;

 /**
  * The constructor of {@code ObjectProperty}
  *
  * @param initialValue
  *the initial value of the wrapped value
  * @param invalidationConsumer
  *   the consumer to be called when the bean is 
invalidated
  */
 public InvalidatedSimpleObjectProperty(T initialValue, final 
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
 super(initialValue);
 if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
 }
 this.invalidationConsumer = invalidationConsumer;
 }

 /**
  * The constructor of {@code ObjectProperty}
  *
  * @param bean
  *the bean of this {@code ObjectProperty}
  * @param name
  *the name of this {@code ObjectProperty}
  * @param invalidationConsumer
  *   the consumer to be called when the bean is 
invalidated
  */
 public InvalidatedSimpleObjectProperty(Object bean, String name, final 
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
super(bean, name);
if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
}
this.invalidationConsumer = invalidationConsumer;
 }

 /**
  * The constructor of {@code ObjectProperty}
  *
  * @param bean
  *the bean of this {@code ObjectProperty}
  * @param name
  *the name of this {@code ObjectProperty}
  * @param initialValue
  *the initial value of the wrapped value
  * @param invalidationConsumer
  *   the consumer to be called when the bean is 
invalidated
  */
 public InvalidatedSimpleObjectProperty(Object bean, String name, T initialValue, final 
ConsumerInvalidatedSimpleObjectPropertyT invalidationConsumer) {
 super(bean,name,initialValue);
 if( invalidationConsumer == null ) {
throw new IllegalArgumentException(Consumer can not be null);
 }
 this.invalidationConsumer = invalidationConsumer;
 }
 
 @Override

 protected void invalidated() {
invalidationConsumer.accept(this);
 }
}


On 22.01.13 10:30, Richard Bair wrote:

Is the Java8 plan still there if not should the current Simple*Property
subclasses who overload invalidated be changed to PropertyBase?

It is unlikely that we'll be able to do anything major here in Java 8 just 
because we don't really have Lambda yet that we can play with, and changing 
over every property is a big job. Unless we knew it would be a major win. I 
would say, if you encounter a Simple* property that has been subclassed, then 
we should fix it up as we go to be a PropertyBase* guy instead.

Re: Gradle 1.11 (and 1.8) will now fail fast with a clear error [was: TaskExecutionException: Execution failed for task ':web:compileGeneratedWin']