from:"Benjamin Gudehus"

Re: measuring time to render in javafx

2017-06-02 Thread Benjamin Gudehus

Hi Selim,

there was a presentation a while back about PerformanceTracker and the
anatomy of pulses:

   - Oleg Mazurov: “Optimizing JavaFX Applications”
   - https://www.youtube.com/watch?v=dw8se4uA1qc

You can activate the pulse logging using Java start parameters.

If you want something more sophisticated like an render indicator in your
GUI you probably need to access private fields/methods in the classes
responsible for the pulse.

Here is a brief overview of the call hierarchy for
PerformanceTracker.pulse():

   - PerformanceTracker#pulse()
  - Scene#pulse()
  - Toolkit#runPulse()
  - Toolkit#firePulse()
  - QuantumToolkit#pulse()

 And for frameRenderered():

   - PerformanceTracker#frameRendered()
  - Scene.ScenePeerPaintListener#frameRendered()
  - GlassScene#frameRendered()
  - PaintCollector#done(RenderJob)
  - RenderJob#run()
  - QuantumToolkit#addRenderJob()
 - QuantumToolkit#renderToImage(ImageRenderingContext)
  - ViewScene#repaint()
  - PaintCollector#renderAll()
  - QuantumToolkit#pulse()

 And a rough list of start parameters:

   - -Dquantum.pulse=true
   - -Dquantum.debug=trre
   - -Dquantum.verbose=true
   - -Dprism.order=d3d
   - -Dprism.order=sw
   - -Djavafx.pulseLogger=true

(If we had something like the developer tools in modern browsers in JavaFX
10, this would be amazing)

--Benjamin

On Fri, Jun 2, 2017 at 10:18 AM, Selim Dincer  wrote:

> Hey,
>
> I am looking for a way to measure how long it takes for JavaFX to render
> something graphically. Say I change the text of a label, then this will
> schedule a new pulse. How can I now actually get feedback when the
> rendering is done?
> In swing I guess I could override the paint or paintComponent methods. In
> JavaFX I found a hacky way in which I supply a Canvas with my own
> implementation of NGCanvas and then override the impl_createPeer() method
> to return my implementation.
> However this is surely not the way to go and it will break in 9 :-)
>
> What would be the preferred way of doing this in JavaFX?
>
> --
> Viele Grüße
> *Selim Dincer*
>

Re: Need an official way to exclude parts of the SceneGraph from CSS-Processing

2017-01-24 Thread Benjamin Gudehus

>As Kevin notes, improving performance is a big push I want to get underway
for JDK 10.

I'd also love to see the PerformanceTracker API outside of com.sun in JDK
10.

>If anyone is interested in exploring performance-related topics in JavaFX

I'll ping you, when I've more time to deeply think and experiment with
improvements to the PerformanceTracker.

--Benjamin

On Tue, Jan 24, 2017 at 12:15 AM, Jonathan Giles 
wrote:

> There are two different topics here, both of which are near and dear to my
> heart (and also make me feel like I've been doing JavaFX for way too long!).
>
> The specific case of TabPane doing CSS / layout on the content of all tabs
> is something captured here:
>
> https://bugs.openjdk.java.net/browse/JDK-8092206
>
> It dates back to 2012 and I remember spending considerable amount of
> effort with my team working through this. As can be seen in some of the
> comments, there were attempts to improve performance (and they were really
> nice), but the outcome was to back it out as we could not change the
> default semantics of loading and doing all work on all tabs. The
> second-to-last comment was a proposal for some API that would specify the
> policy. I really would like to pick this back up for JDK 10, as JDK 9 is
> locked and loaded in this regard. I have retargeted this for JDK 10 just
> now.
>
> As Kevin notes, improving performance is a big push I want to get underway
> for JDK 10. The more general comment made in your email is - how can we get
> better performance out of our critical paths (CSS, layout, TableView, etc).
> That's something we will be actively exploring. There are a lot of ideas,
> some will yield results and some won't. I've been running into a few of
> those dead-ends myself recently as I do preliminary investigations.
>
> If anyone is interested in exploring performance-related topics in JavaFX,
> I've got plenty of areas to explore :-) Ping me off-list and we can discuss.
>
> Unfortunately, again, unless there is some critical oversight these
> discussions and investigations into performance and additional API are by
> default targeted to JDK 10 rather than JDK 9.
>
> -- Jonathan
>
>
> On 20/01/17 11:43 PM, Tom Schindl wrote:
>
>> Hi,
>>
>> One of the biggest problems when working with JavaFX is that if you
>> reparent a big portion of the SceneGraph is that a full CSS-Pass is
>> applied on all reparented SG-Nodes even if those nodes are currently not
>> visible (eg. because they are part of a TabPane).
>>
>> I general I think it is ok to also applyCSS changes on currently not
>> visible nodes (eg they still have an influence on layout-bounds) but
>> there are situations like the above mentioned example of TabPane that it
>> is unnecessary overhead to apply applyCSS changes on those parts of the
>> SG until they get visible.
>>
>> I would not mind if the CSS-Pass on JavaFX would be as performant as the
>> one from current browsers but unfortunately it isn't so I'd like to
>> discuss the possibility of a API to *temporarily* exclude portions of
>> the SG from CSS-Passes.
>>
>> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in
>> a subclass who changed to doProcessCSS who now is private so my hack
>> does not work anymore.
>>
>> To give you an impression on what performance gains we are talking about
>> just look at the video I recorded -
>> https://tomsondev.bestsolution.at/2016/11/25/improving-minma
>> x-performance-in-e4-on-javafx-applications/
>>
>> Tom
>>
>>
>

Re: Optimised, high-performance, multi-threaded rendering pipeline

2016-11-25 Thread Benjamin Gudehus

Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem
to really fit into what needs to be done to improve the performance.

Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering
or does this only apply to rasterization (i.e. Marlin)?

Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot,
along with parallelized DOM (scene graph) access, aggressive culling and
caching and batching.

--Benjamin

On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley  wrote:

> Hi,
>
> @Felix: Is there any Github project, demo video or trial to test HPR with
> JavaFX?
>
> Best regards,
> Tobi
>
>
>
>
> > Am 11.11.2016 um 12:08 schrieb Felix Bembrick  >:
> >
> > Thanks Laurent,
> >
> > That's another thing we discovered: using Java itself in the most
> performant way can help a lot.
> >
> > It can be tricky, but profiling can often highlight various patterns of
> object instantiation that show-up red flags and can lead you directly to
> regions of the code that can be refactored to be significantly more
> efficient.
> >
> > Also, the often overlooked GC log analysis can lead to similar
> discoveries and remedies.
> >
> > Blessings,
> >
> > Felix
> >
> >> On 11 Nov. 2016, at 21:55, Laurent Bourgès 
> wrote:
> >>
> >> Hi,
> >>
> >> To optimize Pisces that became the Marlin rasterizer, I carefully
> avoided any both array allocation (byte/int/float pools) and also reduced
> array copies or clean up ie only clear dirty parts.
> >>
> >> This approach is generic and could be applied in other critical places
> of the rendering pipelines.
> >>
> >> FYI here are my fosdem 2016 slides on the Marlin renderer:
> >> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf
> >>
> >> Of course I would be happy to share my experience and work with a tiger
> team on optimizing JavaFX graphics.
> >>
> >> However I would like getting sort of sponsoring for my potential
> contributions...
> >>
> >> Cheers,
> >> Laurent
> >>
> >> Le 11 nov. 2016 11:29, "Tobi"  a écrit :
> >>>
> >>> Hi,
> >>>
> >>> thanks Felix, Laurent and Chris for sharing your stuff with the
> community!
> >>>
> >>> I am happy to see starting a discussion about boosting up the JavaFX
> rendering performance. I can confirm that the performance of JavaFX scene
> graph is not there where it should be. So multithreading would be an
> excellent, but difficult approach.
> >>>
> >>> Felix, concerning your research of other toolkits: Do they all use
> multithreading or are there any toolkits which use single threading but are
> faster than JavaFX?
> >>>
> >>> So maybe there are other points than multithreading where we can boost
> the performance?
> >>>
> >>> 2) your HPR sounds great. Did you already try DemoFX (part 3)
> benchmark with your HPR?
> >>>
> >>>
> >>> Best regards,
> >>> Tobi
> >>>
> >>>
>  Am 10.11.2016 um 19:11 schrieb Felix Bembrick <
> felix.bembr...@gmail.com>:
> 
>  (Thanks to Kevin for lifting my "awaiting moderation" impasse).
> 
>  So, with all the recent discussions regarding the great contribution
> by
>  Laurent Bourgès of MarlinFX, it was suggested that a separate thread
> be
>  started to discuss parallelisation of the JavaFX rendering pipeline in
>  general.
> 
>  As has been correctly pointed-out, converting or modifying the
> existing
>  rendering pipeline into a fully multi-threaded and performant beast is
>  indeed quite a complex task.
> 
>  But, that's exactly what myself and my colleagues have been working
> on for
>  about 2 years.
> 
>  The result is what we call the Hyper Rendering Pipeline (HPR).
> 
>  Work on HPR started when we developed FXMark and were (bitterly)
>  disappointed with the performance of the JavaFX scene graph.  Many
> JavaFX
>  developers have blogged about the need to dramatically minimise the
> number
>  of nodes (especially on embedded devices) in order to achieve even
>  "acceptable" performance.  Often it is the case that most (if not all
>  rendering) is eventually done in a single Canvas node.
> 
>  Now, as well already know, the JavaFX Canvas does perform very well
> and the
>  recent awesome work (DemoFX) by Chris Newland, just for example,
> shows what
>  can be done with this one node.
> 
>  But, the majority of the animation plumbing in JavaFX is related to
> the
>  scene graph itself and is designed to make use of multiple nodes and
> node
>  types.  At the moment, the performance of this scene graph is the
> Achilles
>  Heel of JavaFX (or at least one of them).
> 
>  Enter HPR.
> 
>  I personally have worked with a number of hardware-accelerated
> toolkits
>  over the years and am astounded by just how sluggish the rendering
> pipeline
>  for JavaFX is. When I am animating just a couple of hundred nodes
> using

Re: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

2016-11-02 Thread Benjamin Gudehus

I wonder, if it is possible to test JavaFX applications without blocking
the main thread. User interactions could be completely simulated by using
Event.fireEvent(...) and we could enqueue assertions in the JavaFX
application thread, in which case the assertion library needs to support
asynchronous assertions.

On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs <snfu...@gmx.de> wrote:

> Hi,
>
> in my experience blocking your working thread for the JavaFX application
> thread is almost always a sign of bad application design.
> You can easily deadlock your application. In our quite complex JavaFX
> Application, we could eliminate almost all of its uses.
>
> However, in one case it is still needed: In a thread we sequentially
> prepare several images in the background, create a snapshot and save them
> as jpegs.
> Here we use java.util.concurrent.CountDownLatch to simulate
> PlatformImpl.runAndWait.
>
> final WritableImage image = new WritableImage((int) targetWidth,
> (int) targetHeight);
> final CountDownLatch countDownLatch = new CountDownLatch(1);
> Platform.runLater(() -> {
>
>  /* render  and snapshot image */
>
>  countDownLatch.countDown();
>  });
>
> boolean released = countDownLatch.await(10, TimeUnit.SECONDS);
> if (!released) {
> Logger.getLogger(getClass()).error("Timeout reached, while
> waiting for snapshot");
> return null;
> }
>
> return image;
>
>
>
> What I would like to see implemented is a method, we call runNowOrLater.
>
> That is, if I'm on the JavaFX ApplicationThread execute the Runnable
> immediately, if not call Platform.runLater().
> With this method I have not to worry, if I'm on the JavaFX Application
> thread or not and I avoid flooding the event queue with calls to
> Platform.runLater, that could have been executed directly.
>
> So basically:
>
> public static void runNowOrLater(final Runnable runnable) {
> if (Platform.isFxApplicationThread()) {
> runnable.run();
> } else {
> Platform.runLater(runnable);
> }
> }
>
> -- Stefan
>
>
>
>
> Hi, Kevin. Thanks for the info!
>>
>> On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com>
>> wrote:
>>
>> No. This isn't something we will do for JDK 9, which is feature complete
>>> (with an exception process for critical requests, especially relating to
>>> Jigsaw). I note in this case that it isn't clear whether we want to do
>>> this
>>> one at all.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Benjamin Gudehus wrote:
>>>
>>> Hey!
>>>>
>>>> Are there plans to expose this API [1] in JavaFX 9?
>>>>
>>>> // NOTE: Add the following if we decide to expose it publicly
>>>> // public static void runAndWait(Runnable runnable) {
>>>> // PlatformImpl.runAndWait(runnable);
>>>> // }
>>>>
>>>> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/
>>>> 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/
>>>> application/Platform.java#l148
>>>>
>>>> --Benjamin
>>>>
>>>>
>>>>
>

Re: JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

2016-11-02 Thread Benjamin Gudehus

Hi, Kevin. Thanks for the info!

On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> No. This isn't something we will do for JDK 9, which is feature complete
> (with an exception process for critical requests, especially relating to
> Jigsaw). I note in this case that it isn't clear whether we want to do this
> one at all.
>
> -- Kevin
>
>
>
> Benjamin Gudehus wrote:
>
>> Hey!
>>
>> Are there plans to expose this API [1] in JavaFX 9?
>>
>> // NOTE: Add the following if we decide to expose it publicly
>> // public static void runAndWait(Runnable runnable) {
>> // PlatformImpl.runAndWait(runnable);
>> // }
>>
>> [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/
>> 6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/
>> application/Platform.java#l148
>>
>> --Benjamin
>>
>>
>

JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

2016-11-02 Thread Benjamin Gudehus

Hey!

Are there plans to expose this API [1] in JavaFX 9?

// NOTE: Add the following if we decide to expose it publicly
// public static void runAndWait(Runnable runnable) {
// PlatformImpl.runAndWait(runnable);
// }

[1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/
6edd0c3c01f4/modules/javafx.graphics/src/main/java/javafx/
application/Platform.java#l148

--Benjamin

Re: Removal of com.sun.javafx.robot

2016-05-12 Thread Benjamin Gudehus

**Update:** I've found a work-around and quickly tested it on our test
suite. Previously we needed `FXRobot::keyPress()`, `FXRobot::keyType()`,
and `FXRobot::keyRelease()`. Since Java 8 it is possible to use
`Event.fireEvent()` and create three `KeyEvent`s (PRESS, TYPE, RELEASE).

~~~java
Platform.runLater(() -> {
Event.fireEvent(scene.getFocusOwner(), keyEvent);
});
~~~

The amount of needed changes for this work-around is small. No revert is
needed.

Thanks,
Benjamin




On Fri, May 13, 2016 at 6:53 AM, Benjamin Gudehus <hasteb...@gmail.com>
wrote:

> Hey,
>
> yesterday a code change was made [1, 2] which removes FXRobot and the
> com.sun.javafx.robot package in JavaFX 9.
>
> >The com.sun.javafx.robot package contains obsolete, unused Prism
> functionality that was intended for testing automation. It was superseded
> long ago by glass Robot and should be removed as dead code.
>
> Unfortunately FXRobot allows a use-case which is not covered by the glass
> robot. In TestFX we use the FXRobot to fire keytyped events that allow to
> type arbitrary (Unicode) characters. This solves multiple issues related to
> non-english keyboards and special characters and simplifies simulation of
> keyboard input greatly. There is also a commercial JavaFX framework that
> uses FXRobot to solve this issue; I spoke with the developers a while ago.
>
> If possible, could this change be reverted?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8156809
> [2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/
>
> Regards,
> Benjamin
>
>

Removal of com.sun.javafx.robot

2016-05-12 Thread Benjamin Gudehus

Hey,

yesterday a code change was made [1, 2] which removes FXRobot and the
com.sun.javafx.robot package in JavaFX 9.

>The com.sun.javafx.robot package contains obsolete, unused Prism
functionality that was intended for testing automation. It was superseded
long ago by glass Robot and should be removed as dead code.

Unfortunately FXRobot allows a use-case which is not covered by the glass
robot. In TestFX we use the FXRobot to fire keytyped events that allow to
type arbitrary (Unicode) characters. This solves multiple issues related to
non-english keyboards and special characters and simplifies simulation of
keyboard input greatly. There is also a commercial JavaFX framework that
uses FXRobot to solve this issue; I spoke with the developers a while ago.

If possible, could this change be reverted?

[1] https://bugs.openjdk.java.net/browse/JDK-8156809
[2] http://cr.openjdk.java.net/~kcr/8156809/webrev.00/

Regards,
Benjamin

Re: Mac OSX and German Keyboard Layout (Y/Z)

2016-02-25 Thread Benjamin Gudehus

FWIW: `KeyEvent` in `keyTyped` should return a String with the right key,
i.e. "z" for German keyboard Z key.

--Benjamin


On Thu, Feb 25, 2016 at 11:31 PM, Tom Schindl 
wrote:

> Hi,
>
> Anyone any insights? Any Swing Savy dev around who knows how Swing
> manages to deliver the right key?
>
> Tom
>
> On 22.01.16 13:30, Tom Schindl wrote:
> > Hi,
> >
> > I just discovered that the KeyCode reported by JavaFX on OS-X with a
> > german keyboard layout (where eg z and y are interchanged) is wrong.
> >
> > If you press a Z you get as the KeyCode.Y and for Y you get KeyCode.Z -
> > this Y/Z problem. I don't think that I as a java-dev need to deal with
> > that and if you look at other toolkits (swing, swt) they handle this
> > transparently for me!
> >
> > I've attached you a javafx and swing application and you'll notice that
> > swing reports always the correct keycode (no matter if my keyboard
> > layout is english or german) and javafx is wrong on german keyboards.
> >
> >
> > FX:
> >> package application;
> >>
> >> import javafx.application.Application;
> >> import javafx.scene.Scene;
> >> import javafx.scene.control.TextField;
> >> import javafx.scene.layout.BorderPane;
> >> import javafx.stage.Stage;
> >>
> >>
> >> public class Main extends Application {
> >>  @Override
> >>  public void start(Stage primaryStage) {
> >>  try {
> >>  BorderPane root = new BorderPane();
> >>
> >>  TextField f = new TextField();
> >>  f.setOnKeyPressed( e -> {
> >>  System.err.println("KeyCode: " +
> e.getCode());
> >>  });
> >>
> >>  root.setCenter(f);
> >>
> >>  Scene scene = new Scene(root,400,400);
> >>  primaryStage.setScene(scene);
> >>  primaryStage.show();
> >>  } catch(Exception e) {
> >>  e.printStackTrace();
> >>  }
> >>  }
> >>
> >>  public static void main(String[] args) {
> >>  launch(args);
> >>  }
> >> }
> >
> > Swing:
> >> package application;
> >>
> >> import java.awt.event.KeyEvent;
> >> import java.awt.event.KeyListener;
> >>
> >> import javax.swing.JFrame;
> >> import javax.swing.JTextField;
> >>
> >> public class SampleSwing extends JFrame {
> >>  public SampleSwing() {
> >>  JTextField textField = new JTextField();
> >>  textField.addKeyListener(new KeyListener() {
> >>
> >>  @Override
> >>  public void keyTyped(KeyEvent e) {
> >>  // TODO Auto-generated method stub
> >>
> >>  }
> >>
> >>  @Override
> >>  public void keyReleased(KeyEvent e) {
> >>  // TODO Auto-generated method stub
> >>
> >>  }
> >>
> >>  @Override
> >>  public void keyPressed(KeyEvent e) {
> >>  System.err.println((char)e.getKeyCode());
> >>  }
> >>  });
> >>  getContentPane().add(textField);
> >>  }
> >>
> >>  public static void main(String[] args) {
> >>  new SampleSwing().setVisible(true);
> >>
> >>  }
> >> }
> >
> >
> >
> > Tom
> >
>
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Scenebuilder 8.1.0 removes Licensing / Copyright Terms and all other comments, worked with v8.0.0

2016-02-01 Thread Benjamin Gudehus

>Until this is fixed, I recommend to continue using Scenebuilder 8.0.0
It saved the comment back as is.

That's bad. Is it possible to host old archives on Bintray or even package
scenebuilder as single jar and host it on maven central in the future?
On Feb 1, 2016 10:23 AM, "Eder Dennis (ETAS/ESY3)" 
wrote:

> Hi FX'lers,
>
> I want to inform everyone that the latest Gluon Scenebuilder 8.1.0, as
> available here
> http://gluonhq.com/open-source/scene-builder/
> removes comments, in particular License Headers, e.g.
> 
> 
>
> This is a regression bug. Keeping comments was explicitly supported in
> earlier versions, as discussed here:
> https://community.oracle.com/message/11122448#11122448
>
> Until this is fixed, I recommend to continue using Scenebuilder 8.0.0
> It saved the comment back as is.
>
> Unfortunately that version does no longer seem to be available on
> http://gluonhq.com
>
> Best regards,
> Dennis
>
>

Re: Update on FX plans for JDK 9

2015-12-17 Thread Benjamin Gudehus

>For testing and so on, public APIs seem lower priority to me. A developer
can always override Jigsaw from the command line and use whatever internal
APIs are needed.

That's true, although is increases the initial hurdle of testing a bit.

>JDK-8145154: Provide public API support for PerformanceTracker
functionality

The ability to register custom Loggers would be nice; they currently behind
private fields.



On Thu, Dec 17, 2015 at 11:05 PM, Mike Hearn  wrote:

> >
> >   JDK-8091107: Add java.awt.Desktop support to javafx
> >   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX
> (FX
> > equivalent for JEP 272)
> >
>
> Exposing platform APIs is a big deal for anyone who wants to make an app
> that really benefits from being on the desktop. Doing things like handling
> files, registering URL handlers etc was a big PITA in my app. Definitely +1
> to supporting these cases better.
>
>
> >   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> > for non-applet Stage
> >
>
> It's unclear from this description or the bug what the benefit of doing
> that would be. Performance?
>
>
> >   JDK-8145154: Provide public API support for PerformanceTracker
> > functionality
> >   JDK-8090763: Public API for Glass's robot functionality
> >
>
> For testing and so on, public APIs seem lower priority to me. A developer
> can always override Jigsaw from the command line and use whatever internal
> APIs are needed. Breakage is less of a concern because it's under the
> control of the developer.
>
> The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
> slick auto update system. Shipping apps that can't update themselves in
> 2015 is unacceptable even for corporate deployments.
>

Public API for robot classes in JDK 9

2015-12-14 Thread Benjamin Gudehus

The missing public API for robots (`com.sun.glass.ui.Robot` and
`com.sun.javafx.robot.FXRobot`) is causing me sleepless nights. Here (
https://github.com/TestFX/Robot) is a small prototype for a possible API to
ignite some discussion. In case the proposed delay of JDK 9 (
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html)
takes place.

About the architecture:

In the prototype I decided to not touch classes in `com.sun.glass.ui` and
instead provide "wrapper" classes. This is a pattern which is also used for
other classes in the JavaFX codebase, to provide a public API for
functionality from e.g. `com.sun.prism` and `com.sun.javafx`. Additionally
`com.sun.glass.ui.Robot` has dependencies to other private classes in its
package and to native bindings to different operating systems and Monocle.

About the implementation:

- `javafx.application.ApplicationMixin::createGlassRobot()` returns a new
`javafx.application.util.GlassRobot`. The methods of `ApplicationMixin`
will of course find their places in `javafx.application.Application`
eventually.

- The `GlassRobot` is in the `javafx.util` package. It could also go into a
new `javafx.robot` package instead. `GlassRobot` uses classes from the
JavaFX API like `KeyCode`, `Point2D` and `MouseButton` instead of primitive
types which are used by `com.sun.glass.ui.Robot`.

(I've created a new mail thread in order to permalink to it and allow
others without JIRA writing access to participate in the discussion. A JIRA
ticket should be definately created via bugs.java.com -- if none already
exist; I'll check this. I also know the code needs to be patch files into
order to be merged into HG.)

--Benjamin

Re: Why there is no WebWorker like mechanism for JavaFX

2015-12-08 Thread Benjamin Gudehus

The JavaFX API offers Worker class for long running tasks.

If you want to execute JavaScript code without DOM and JavaFX you can use
the Nashorn JS Virtual machine, which is included in Java 8. I guess the
Nashorn documentation also has examples how it's used with the Java
scripting API.
On Dec 8, 2015 1:50 PM, "Rahman USTA"  wrote:

> I'm really enjoying developing apps in JavaFX, but I think there is a
> limitation point;
>
> When we think HTML5, there is WebWorker to run long-running tasks in
> another process. So, we know WebWorker has no DOM access, it is generally
> used computational needs.
>
> Ok, We can run long-running tasks in JavaFX with many threading services,
> but there is one exception;
>
> There are a lot of JavaScript libraries, and executing them in WebView
> needs JavaFX Application Thread. But, what if your JS code takes long time
> to execute ? Your UI will hang. Is it required to execute JS code in
> WebView if it is not accessing DOM API?
>
> Thanks.
>
> --
> Rahman USTA
> Istanbul JUG
> https://github.com/rahmanusta 
>

Re: [9] API review request: 8090585: Provide an official API to start the JavaFX platform

2015-11-22 Thread Benjamin Gudehus

Wow, this patch will simplify the architecture of JavaFX testing
libraries/frameworks.

>From my perspective it is important to have a method to start the FX
runtime and thread.

I guess one would just use `new Stage()` to create the primary Stage? Or do
we need to register the primary Stage somewhere?

This is a great.

As a sidenote: Another use-case for testing is to be able to call the
Application launch procedure multiple times (probably for different
Application classes) without starting the FX runtime. TestFX currently uses
custom code similar to the code in `LauncherImpl` to archive this.

--Benjamin



On Sun, Nov 22, 2015 at 9:26 PM, Ali Ebrahimi 
wrote:

> Hi,
> I know concerns here, but I think PlatformImpl.startup() and
> Platform.startup() should have same behavior from caller's POW.
> So I think if we can not have default behavior(duplicate calls) for public
> API so please change method name.
> My suggestions: Platform.safeStartup() or Platform.startPlatform or
> Platform.start
>
> On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles <
> jonathan.gi...@oracle.com>
> wrote:
>
> > I don't believe there is any inconsistency here. We are preserving the
> > existing semantics in PlatformImpl.startup to not prevent duplicate calls
> > by default, whilst we are reversing the semantics for the public API in
> > Platform, where we do prevent duplicate calls. The end result is that we
> > have one public API (Platform.startup) with one set of semantics (prevent
> > duplicate values).
> >
> > -- Jonathan
> >
> >
> > On 21/11/15 11:57 PM, Ali Ebrahimi wrote:
> >
> > Hi,
> > I think there is an inconsistency between :
> >
> > PlatformImpl.java
> >
> >  public static void startup(final Runnable r) {
> > +startup(r, false);  //* here default value false
> >
> > + }
> >
> > and
> >
> > Platform.java
> >
> > +public static void startup(Runnable runnable) {
> > +PlatformImpl.startup(runnable, true);  // here default
> value true
> >
> > +}
> >
> >
> >
> > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth <
> > kevin.rushfo...@oracle.com> wrote:
> >
> >> Jonathan and all,
> >>
> >> Please review the following new API proposal to add the ability to
> >> explicitly start the FX runtime.
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8090585
> >> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/
> >>
> >> -- Kevin
> >>
> >>
> >
> >
> > --
> >
> > Best Regards,
> > Ali Ebrahimi
> >
> >
> >
>
>
> --
>
> Best Regards,
> Ali Ebrahimi
>

Re: Fx questions

2015-10-29 Thread Benjamin Gudehus

Hi Brian!

> for unit testing on Linux servers, is monocle a good bet?

In case you simulate user input (mouse, keyboard, touch) you need to use
the Glass robot instead of AWT robot when using Monocle. I observed some
different behaviour and timing problems in my tests with Glass robot.

>when embedding html5 pages into fx apps, should we expect it to
render/behave similar to popular browsers like chrome?

AFAIK JavaFX just uses the Webkit rendering engine, so rendering should be
more or less exactly like Chrome (they use their fork Blink, but there are
not that much differences, yet). For JavaScript execution the Nashorn JS
engine is used.

>do you have a public roadmap for fx?

I guess there is some information on the OpenJFX project page.

>what is status of scenebuilder? Is it supported, and still worked on?

I saw some commits in the SceneBuilder repository in the last few days.
Binaries are provided by Gluon.

Regards,
Benjamin

On Thu, Oct 29, 2015 at 10:58 PM, Brian Harris 
wrote:

> Hi fx devs, a few questions.
>
> - for unit testing on Linux servers, is monocle a good bet? I got it
> working by adding monocle jar to ext classpath
>
> - when embedding html5 pages into fx apps, should we expect it to
> render/behave similar to popular browsers like chrome? I'm wondering if we
> can expect this to just work or if things may be a bit wonky.
>
> - do you have a public roadmap for fx?
>
> - what is your recommendation for lifecycle management, ie creating
> controllers with injected dependencies. I saw afterburner looked nice, we
> have spring working too.
>
> - what is status of scenebuilder? Is it supported, and still worked on?
>
> Thanks,
> Brian
>

Re: Usage of Toolkit firePulse

2015-10-06 Thread Benjamin Gudehus

Hi Ryan,

I've created an issue for that.
https://github.com/TestFX/TestFX/issues/231

Will try you example out.

--Benjamin

On Tue, Sep 29, 2015 at 2:58 AM, Ryan Jaeb <r...@jaeb.ca> wrote:

> Hi Benjamin,
>
> Yes, it's a NoNodesFoundException using TestFX 3.1.2.
>
> As far as I know, using firePulse() is the only way to guarantee all
> previous model changes are rendered in the scene.  I've created an example
> to show what I mean:
>
> https://gist.github.com/ryanjaeb/74685a002e2b402e7fac
>
> It's a small example, so I'll post it inline too:
>
> ...
> public class FirePulseApplication extends Application {
> @Override
> public void start(Stage primaryStage) throws Exception {
> printEnv();
>
> ListView listView = new ListView<>();
>
> Scene scene = new Scene(listView, 200, 400);
> primaryStage.setScene(scene);
> primaryStage.show();
>
> for (int i = 1; i < 6; i++) {
> listView.getItems().add("list-item-" + i);
> }
>
> System.out.println("Before firePulse():");
> printVisibleRowInfo(listView);
>
> Toolkit.getToolkit().firePulse();
>
> System.out.println("After firePulse():");
> printVisibleRowInfo(listView);
>
> Platform.exit();
> }
>
> private void printVisibleRowInfo(ListView listView) {
> // Item count according to the list model
> System.out.println("  Item count: " + listView.getItems().size());
>
> // Extract the VirtualFlow so it can be used to determine which
> // list items are rendered in the scene.
> ObservableList children = listView.getChildrenUnmodifiable();
> VirtualFlow flow = (VirtualFlow) children.get(0);
>
> IndexedCell firstCell = flow.getFirstVisibleCell();
> System.out.println("  First visible cell: " + firstCell);
>
> IndexedCell lastCell = flow.getLastVisibleCell();
> System.out.println("  Last visible cell: " + lastCell);
> }
>
> private void printEnv() {
> String osName = System.getProperty("os.name");
> String jvm = System.getProperty("java.version") +
> " (" + System.getProperty("java.vm.version") +
> " - " + System.getProperty("os.arch") + ")";
>
> System.out.println("OS: " + osName);
> System.out.println("JVM: " + jvm);
> System.out.println("");
> }
> }
> ...
>
> The output I get when running the example:
>
> ...
> OS: Windows 8.1
> JVM: 1.8.0_40 (25.40-b25 - amd64)
>
> Before firePulse():
>   Item count: 5
>   First visible cell: null
>   Last visible cell: null
> After firePulse():
>   Item count: 5
>   First visible cell: ListViewSkin$2@7820053f[styleClass=cell
> indexed-cell list-cell]'list-item-1'
>   Last visible cell: ListViewSkin$2@8be9262[styleClass=cell indexed-cell
> list-cell]'list-item-5'
> ...
>
> Until there's a pulse, the nodes that represent the list items don't
> exist, so the NoNodesFoundException is expected.
>
> Ryan
>
> On Sun, Sep 27, 2015 at 12:40 AM, Benjamin Gudehus <hasteb...@gmail.com>
> wrote:
>
>> Hi Ryan!
>>
>> >Otherwise the drag(...) command will throw an exception because it
>> can't find the node for "list-item-name" (it doesn't exist yet).
>>
>> Well, this is very interesting. This must be a NoNodesFoundException in
>> TestFX 3.
>>
>> >I don't actually needto call firePulse().  I just need a way to know the
>> scene is up to date with a re-validated model.  Is there a better way of
>> accomplishing that right now?
>>
>> TestFX should try to find the Node within the JavaFX Application Thread
>> using Platform.runLater(...). Maybe this is a better way than to call
>> firePulse(),
>>
>> --Benjamin
>>
>> On Thu, Sep 24, 2015 at 12:49 PM, Ryan Jaeb <r...@jaeb.ca> wrote:
>>
>>> I use firePulse() in GUI test code.  I'm using TestFX (v3) for testing.
>>> Is
>>> there a way to ensure model updates are reflected in the scene without
>>> using firePulse()?  Consider something like this:
>>>
>>> ...
>>> // TestFX starts us on the main thread.  Maybe I'm using it wrong?
>>>
>>> CountDownLatch latch = new CountDownLatch(1);
>>>
>>> Platform.runLater(() -> {
>>> // Add "list-item-name" to an empty list that's used as the model for
>>>

Re: RGB and LAB color spaces: Conversion and interpolation

2015-09-30 Thread Benjamin Gudehus

java.awt.color.ColorSpace (and ICC_ColorSpace) only provide an empty
implementation and constants for the conversion between color spaces, but
no specific implementation (at least for HSL, LAB, et cetera).

Conversion: Interestingly the implementations in the wild rarely reference
the source of the algorithms. So I searched through our university's
library and found different algorithms for HSV, HSL and HSI (Smith 1978,
Metrick 1979, Foley and van Dam 1982, Fishkin 1990, Travis 1991, Gonzalez
and Woods 1992).

Interpolation: JavaFX has LinearGradient. But it's rather complicated to
retrieve a color ramp from it; we need to fill a Rectangle with a
LinearGradient, make a snapshot and use PixelReader to extract the integer
color values, and the implemention uses some padding for the colors at
start and end. Then the implementation is in com.sun.prism.impl.paint so I
can't access it directly.

Seems I have to implement this library by myself.

On Fri, Sep 25, 2015 at 9:33 PM, Jim Graham <james.gra...@oracle.com> wrote:

> JavaFX has no color conversion libraries.  The classes in java.awt.color
> are the only alternative that ships standard with the JDK...
>
> ...jim
>
>
> On 9/25/15 7:42 AM, Benjamin Gudehus wrote:
>
>> Hey!
>>
>> I want to convert colors between different color spaces and interpolate
>> them within the specific color space (sRGB and its cylindrical
>> transformations HSL/HLS, HSV/HSB, and HSI. LAB and its cylindrical
>> transformations LCH, and HCL).
>>
>> javafx.scene.paint.Color only accepts (s)RGB and HSB and seems to support
>> interpolate() within RGB only. Should I use java.awt.color.ICC_ColorSpace
>> (which lacks support for HSI, LCH and HCL) or is there a more complete
>> library for Java or JavaFX?
>>
>> Regards,
>> Benjamin
>>
>>

Re: Usage of Toolkit firePulse

2015-09-27 Thread Benjamin Gudehus

Hi Ryan!

>Otherwise the drag(...) command will throw an exception because it
can't find the node for "list-item-name" (it doesn't exist yet).

Well, this is very interesting. This must be a NoNodesFoundException in
TestFX 3.

>I don't actually needto call firePulse().  I just need a way to know the
scene is up to date with a re-validated model.  Is there a better way of
accomplishing that right now?

TestFX should try to find the Node within the JavaFX Application Thread
using Platform.runLater(...). Maybe this is a better way than to call
firePulse(),

--Benjamin

On Thu, Sep 24, 2015 at 12:49 PM, Ryan Jaeb  wrote:

> I use firePulse() in GUI test code.  I'm using TestFX (v3) for testing.  Is
> there a way to ensure model updates are reflected in the scene without
> using firePulse()?  Consider something like this:
>
> ...
> // TestFX starts us on the main thread.  Maybe I'm using it wrong?
>
> CountDownLatch latch = new CountDownLatch(1);
>
> Platform.runLater(() -> {
> // Add "list-item-name" to an empty list that's used as the model for
> // a ListView.
> Toolkit.getToolkit().firePulse();
> latch.countDown();
> });
>
> try {
> latch.await(1, TimeUnit.SECONDS);
> }
> catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
>
> // TestFX runs this on the application thread.
> drag("list-item-name").to("trash");
>
> assertTrue(list.isEmpty);
> ...
>
> In a case like the above, firePulse() is used to ensure a node (ListCell)
> for "list-item-name" is added to the scene before continuing with the
> test.  Otherwise the drag(...) command will throw an exception because it
> can't find the node for "list-item-name" (it doesn't exist yet).
>
> I don't actually needto call firePulse().  I just need a way to know the
> scene is up to date with a re-validated model.  Is there a better way of
> accomplishing that right now?
>
> Ryan
>
>
> On Wed, Sep 23, 2015 at 5:49 PM, Jonathan Giles  >
> wrote:
>
> > Hi all,
> >
> > Today I am keen to get your help on understanding use of the
> > Toolkit.getToolkit().firePulse() private API. If you could spare a few
> > minutes to grep your source directory for any usage of 'firePulse', and
> > email me your findings, that would be really interesting.
> >
> > As a gentle motivational tool I'll conclude by saying that, surprisingly,
> > this private API is barely used inside the openjfx production code. If
> you
> > look at the openjfx unit tests, it is used massively. The question is -
> how
> > much is this being used by other community members. If the answer is 'not
> > much' or less, then this private API may not be made public in JDK 9.
> Your
> > feedback therefore is critical!
> >
> > Thanks,
> > -- Jonathan
> >
>

RGB and LAB color spaces: Conversion and interpolation

2015-09-25 Thread Benjamin Gudehus

Hey!

I want to convert colors between different color spaces and interpolate
them within the specific color space (sRGB and its cylindrical
transformations HSL/HLS, HSV/HSB, and HSI. LAB and its cylindrical
transformations LCH, and HCL).

javafx.scene.paint.Color only accepts (s)RGB and HSB and seems to support
interpolate() within RGB only. Should I use java.awt.color.ICC_ColorSpace
(which lacks support for HSI, LCH and HCL) or is there a more complete
library for Java or JavaFX?

Regards,
Benjamin

Re: Results of review of private JavaFX API for consideration to make public in JDK 9

2015-09-12 Thread Benjamin Gudehus

>And we will certainly need to use this for our own unit testing, too.
Details are tbd, but you will be able to use it for testing.

Anything new about the command line switch to access Robot? :)

--Benjamin

Re: Results of review of private JavaFX API for consideration to make public in JDK 9

2015-08-11 Thread Benjamin Gudehus

It would be good to discuss this via a JBS issue. Please file one and we
can discuss logistics further.

I have no project author status on JBS to create an issue. :/ I could sign
the Oracle Contributor Agreement, but I doubt I will able provide the two
required non-trivial patches anytime soon in order to become an author.
This was much easier with the previous OpenJFX issue system.



On Tue, Aug 11, 2015 at 12:36 AM, Jonathan Giles jonathan.gi...@oracle.com
wrote:


 On 7/08/2015 9:51 p.m., Benjamin Gudehus wrote:

 Hi Jonathan,

 thanks for the summary!

 pull up your sleeves and work with us to get the API into a shape where
 it is good enough to commit to as public API

 I'd like to help with the public API for profiling and performance
 tracking (mainly PulseLogger, maybe PerformanceTracker).


 It would be good to discuss this via a JBS issue. Please file one and we
 can discuss logistics further.


 These classes are com.sun.javafx.util.Utils,
 com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl.
 As most of these classes are just a collection of self-contained methods,
 it is quite likely that a number of these methods will find public API
 alternatives in a new class

 Sounds good. TestFX has a dependency to
 com.sun.javafx.application.ParametersImpl to provide the ability to test
 multiple different `Application`s. It currently depends on private fields
 and methods of internal classes.

 It is highly unlikely that ParemetersImpl will be made public API.


 Robot: A good API to make public, but not a small API, so the scope is
 possibly too great for JDK 9.

 The headless testing feature in TestFX has dependencies to
 com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the
 AWT robot, the normal testing mode needs no access to the internal APIs.

 The screenshot feature in headless testing depends on
 com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels.

 Additionally we also need access to com.sun.glass.ui.PlatformFactory in
 order to activate Monocle on desktop systems.


 These areas are outside my area of expertise, but my understanding is that
 it is extremely unlikely that any of the classes you mentioned will become
 public API in JDK 9.

 -- Jonathan

Re: Results of review of private JavaFX API for consideration to make public in JDK 9

2015-08-07 Thread Benjamin Gudehus

Hi Jonathan,

thanks for the summary!

pull up your sleeves and work with us to get the API into a shape where it
is good enough to commit to as public API

I'd like to help with the public API for profiling and performance tracking
(mainly PulseLogger, maybe PerformanceTracker).

These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil,
and com.sun.javafx.application.PlatformImpl. As most of these classes are
just a collection of self-contained methods, it is quite likely that a
number of these methods will find public API alternatives in a new class

Sounds good. TestFX has a dependency to
com.sun.javafx.application.ParametersImpl to provide the ability to test
multiple different `Application`s. It currently depends on private fields
and methods of internal classes.

Robot: A good API to make public, but not a small API, so the scope is
possibly too great for JDK 9.

The headless testing feature in TestFX has dependencies to
com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the
AWT robot, the normal testing mode needs no access to the internal APIs.

The screenshot feature in headless testing depends on
com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels.

Additionally we also need access to com.sun.glass.ui.PlatformFactory in
order to activate Monocle on desktop systems.

--Benjamin

On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles jonathan.gi...@oracle.com
wrote:

 Hi all. In April of this year a discussion began when news broke that with
 JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while
 back I posted a request to openjfx-dev for people to send me their JDeps
 output so that it could be analysed and used to inform our decisions around
 which API we should try to promote into public API. The response was very
 useful (and I should note: its too late now, please don't send me anymore
 JDeps files), and I believe we have the beginnings of a plan on how to move
 forward.

 Before I outline the plan, please note that this discussion would ideally
 _not_ devolve into a feature requests discussion. What we are wanting to
 talk about today is simply API that exists in the com.sun.* package
 namespace which we can conceivably bring out of this namespace for JDK 9.
 Developing new API is expressly out of scope (unless it is related to
 simplifying or wrapping the com.sun.* API).

 Another important point - UI control skins and a lot of very useful CSS
 API are being made public under JEP 253 [2]. A lot of the skin code has
 already been cleaned up, simplified, documented, etc, and will be merging
 into a repo very soon. I'll also post a separate post about JEP 253 soon.

 So, what does my JDeps analysis show (ignoring UI Controls and CSS usage,
 which has been largely resolved by JEP 253)? I can sum it up in the
 following categories:

 == 'Toolkit' API ==
 A lot of people use a small amount of API from Toolkit, such as the API
 for nested event loops, to fire a pulse, and to add / remove pulse
 listeners. Based on this analysis, the current thinking is to add API into
 the javafx.application.Platform class to enable the first two use cases
 above (nested event loops and pulse firing). The third use case needs more
 engineering effort, and is a far less common use case, so isn't being
 considered for JDK 9.

 == 'Traversal' API ==
 This API lives in com.sun.javafx.scene.traversal, and is quite useful when
 writing custom controls to ensure that keyboard traversal puts the focus in
 the right node at the right time. My ControlsFX open source project is a
 common (ab)user of this API, so I have a vested interest in making this
 public. Having said this, the API is actually in quite good shape, and it
 is possible with just a little JavaDoc work it could make the move into
 javafx.scene.traversal.

 == 'Collections Event' API ==
 There exists classes in com.sun.javafx.collections that are quite useful
 if you create your own custom ObservableList implementation and want to
 fire events at certain times. In my analysis there are only two projects
 using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent
 point is that this code is quite easy to reproduce, so, whilst I would like
 to see this API public, it doesn't seem to make sense for JavaFX 9.

 == 'Utils' API ==
 There exists three classes that are quite commonly used by people for the
 various utility methods contained within. These classes are
 com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and
 com.sun.javafx.application.PlatformImpl. As most of these classes are just
 a collection of self-contained methods, it is quite likely that a number of
 these methods will find public API alternatives in a new class (although
 there are no plans to move all the methods over!).

 == Miscellaneous API ==
 Finally, there are a few classes that popped up quite frequently. Here is
 the list, and my thoughts on what to do with them:

 1) com.sun.javafx.runtime.VersionInfo:

Re: slightly ot: java9 runtime images

2015-05-13 Thread Benjamin Gudehus

Hi Tom!

I would really like to be able to generate such a standalone exe.

With Danno's javafx-gradle Gradle plugin and with the java package API
(com.oracle.tools.packager.Bundler from Java 8) it is possible to generate
a standalone exe without installer (the bundler name is Windows
Application Image). That's the first thing I noticed, when I tested it.

Regards,
Benjamin

On Wed, May 13, 2015 at 11:43 AM, Tom Eugelink t...@tbee.org wrote:

 On 7-5-2015 15:52, Danno Ferrin wrote:

 It would be a major improvement (not only for JavaFX applications, but
 also standalone servers) if it would become possible to create a truly
 single distributable, without having to repack the jars. So either by
 automatic unpacking to a tmp and setting the classpath prior to stating
 java (cleaning up afterwards), or allowing jars-in-jars or
 jars-in-distributable.

  In 8u40 we added an option to install your application as service or
 daemon, so you can use the java packager to install your microsoervices.


 I've spent some time with the JavaFX packager (though the
 javafx-maven-plugin) and I am able to generate:
 - a distribution in the form of a lib directory and entry point jar
 - an exe  msi that are both installers

 What I am not able to generate is an exe that can simply be started. Right
 now my distribution consist of an all-in-one jar (jars-in-a-jar) that can
 simply be started. The JRE is also simply copied (when not present), so
 there is no need to install anything, just copy and start. I would really
 like to be able to generate such a standalone exe. Is this a limitation of
 the plugin or the packager? Since the plugin seems to be very close to the
 packager, I'm thinking the latter.

 Tom

Re: How to get raw pixel data into JavaFX

2015-04-29 Thread Benjamin Gudehus

Hi Philipp,

as far as I know PixelWriter, WritableImage and ImageView fits better for
handling raster images than Canvas.

TestFX uses PixelWriter.setArgb() to convert screenshots from Glass with
Monocle to PNG files:

https://github.com/TestFX/TestFX/blob/fd75122/subprojects/testfx-core/src/main/java/org/testfx/service/adapter/impl/GlassRobotAdapter.java#L230

--Benjamin

On Wed, Apr 29, 2015 at 4:21 PM, Philipp Dörfler phdoerf...@gmail.com
wrote:

 Hello list,

 I got some very low level pixel data residing in memory with a pixel
 format and want to get that into JavaFX. I am talking about raw bytes, BGR,
 24 bit per pixel etc..
 The library providing this pixel data is OpenCV and although it allows for
 encoding the data into a standard format like .bmp or .png which then
 can be read by JavaFX, I would like to avoid this extra conversion process
 because I got some real time constraints.

 As far as I understand this is what the PixelReader and PixelWriter
 interface is for. Is this correct? Where can I find additional information
 on how to use them besides the Javadoc? Would using the Canvas be easier?
 Can I somehow use the GraphicsContext of Canvas to do that?
 I'd be grateful for any pointers even when it's just check out the class
 XZY in the underlying prism code: link to bitbucket.

 Thanks and best regards!

 Philipp Dörfler

Re: Doubts on KeyCode

2015-03-30 Thread Benjamin Gudehus

Hi,

What I can not explain is why the keyboard + (ascii-code 43) maps to
] (ascii-code 93) from a native-keyevent to KeyCode happens in
Glass-Layer.

Hmm, the + key on a german keyboard layout [1] is actually ] on the us
keyboard layout [2].

But when I type + on my german keyboard with german layout activated on
Windows it outputs + as unicode string and PLUS for the KeyCode. With
this code:

textField.setOnKeyPressed((event) - {
System.out.println(event.getText());
System.out.println(event.getCode());
});

[1]
http://upload.wikimedia.org/wikipedia/commons/thumb/3/36/KB_Germany.svg/800px-KB_Germany.svg.png
[2]
http://upload.wikimedia.org/wikipedia/commons/thumb/5/51/KB_United_States-NoAltGr.svg/800px-KB_United_States-NoAltGr.svg.png

On Mon, Mar 30, 2015 at 1:19 PM, Scott Palmer swpal...@gmail.com wrote:

 If I recall correctly there is one keycode named PLUS and another named
 ADD. One of them refers to the numeric keypad.

 Scott

  On Mar 30, 2015, at 6:58 AM, Tom Schindl tom.schi...@bestsolution.at
 wrote:
 
  hi,
 
  suppose you have the following code:
 
  package application;
 
  import javafx.application.Application;
  import javafx.scene.Scene;
  import javafx.scene.control.TextField;
  import javafx.scene.layout.BorderPane;
  import javafx.stage.Stage;
 
  public class Main extends Application {
 @Override
 public void start(Stage primaryStage) {
 try {
 BorderPane root = new BorderPane();
 Scene scene = new Scene(root, 400, 400);
 
 TextField f = new TextField();
 f.setOnKeyReleased( e - {
 System.err.println(e.getCode());
 });
 root.setCenter(f);
 
 primaryStage.setScene(scene);
 primaryStage.show();
 } catch (Exception e) {
 e.printStackTrace();
 }
 }
 
 public static void main(String[] args) {
 launch(args);
 }
  }
 
  For default ASCII-Chars like a, b, c, ... I get the correct KeyCode but
  e.g. for +, -, ... the information is totally bogus. Please note I get
  the correct keyCode when pressing the NumPad char but e.g. CLOSE_BRACKET
  when pressing + on my keyboard.
 
  If I'm not completely mistaken the KeyCode defintion for the current +
  is the one for the keypad + and the one for the ordinary + is missing?
 
  This means that the definition:
 
  PLUS(0x0209, Plus)
 
  has to be
 
  PLUS(0x0209, Plus, KeyCodeClass.KEYPAD)
 
  What I can not explain is why the keyboard + (ascii-code 43) maps to
  ] (ascii-code 93) from a native-keyevent to KeyCode happens in
  Glass-Layer.
 
  Tom
 
  --
  Thomas Schindl, CTO
  BestSolution.at EDV Systemhaus GmbH
  Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
  http://www.bestsolution.at/
  Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Unit testing recommendations for JavaFX

2015-03-30 Thread Benjamin Gudehus

There are also Automaton, which is similar to TestFX and supports Swing as
well, and MavinFX, which is especially useful to assert Properties.

TestFX allows simple and clean testing without much boiler-plate code. When
we took JavaFX into consideration for a migration of our geographical
information system to Swing to first thing we looked for was a testing
framework. With a background with the FEST-Swing testing framework TestFX
convinced us, because even testing new dialogs looked a lot easier than
with FEST.

I can't say much about Squish. It seems that it follows an approach with a
recorder for user interactions which I guess won't allow creation of
test-cases before the actual production code is written.

--Benjamin




On Sat, Mar 28, 2015 at 8:45 PM, Tom Eugelink t...@tbee.org wrote:

 JFXtras uses TestFX (3), very pleasant, highly recommended.



 On 28-3-2015 09:13, Adam Granger wrote:

 Following migration to JavaFX I've been looking into a unit testing...
 Possible solutions

   - home brew - just code up a few basic methods like find a node with
 given selector within given timeout, then build tests using those using
 JUnit / Mockito. Also used @Rule approach from
 http://stackoverflow.com/a/18988752/898289 for simple tests which didn't
 require any asynchronous behaviour. I was previously using this approach
 until discovered TestFX

   -  Jemmy - seems well documented. Last release 4 years ago - no updates
 since JavaFX 2.2? Is this because its so good, or does anyone know
 whether it has been scrapped? Any plans to update for JavaFX 8?
 https://jemmy.java.net/

   - TestFX - just started dabbling with this - seems a lot better
 maintained that Jemmy, however the new release 4 is still alpha and
 documentation is a little sparse - https://github.com/TestFX/TestFX

   - Squish by FrogLogic - commercial product, but only seems suitable for
 integration level testing. -
 http://doc.froglogic.com/squish/5.1/tutorial-getting-started-java_fx.html

 I'm interested in any recommendations this group might have or experiences
 of solutions I've mentioned...  What solution do OpenJFX / other large FX
 developments use for unit testing?

 Many thanks,

 Adam.

Re: The trouble with Skins

2015-03-22 Thread Benjamin Gudehus

Hi John,

if your app has something like pages this could work. You could use a
StackPane and put the first page (for example a list view) into it. When a
state change occurs (for example a list item is clicked and we move over to
a detail view) we could put this second page over the first page in the
StackPane. If a jump to previous page action is fired then the element on
top of the StackPane is pop()'ed and we see the ListView with the previous
scroll offset.

--Benjamin

On Sun, Mar 22, 2015 at 1:53 PM, John Hendrikx hj...@xs4all.nl wrote:

 On 22/03/2015 09:59, Tom Eugelink wrote:

 On 22-3-2015 00:12, John Hendrikx wrote:


 What I do need however is a way to restore the control to the exact same
 state it was in before (the same amount of pixels scrolled, the same item
 at the top, the same item at the bottom).


 That is an interesting use case. Can you describe it a bit more?

 Tom

  My app works more like a browser, so when I go back, I expect the same
 screen layout again (even though I have to reconstruct the screen again).
 With a ListView, this cannot be done as the #scrollTo method only shows an
 item.  It doesn't remember however if that item was somewhere in the
 middle, top or bottom.  It's just convenient if it was in the same spot, as
 the user might expect it there.  Just like I expect my browser to go back
 to the same spot helps me a bit (eg: I clicked the link at the bottom of
 the screen somewhere, and there was something else interesting to the left
 of it -- that fails if it is now somewhere else).

 --John

Re: OpenJFX mirror at BitBucket?

2015-03-18 Thread Benjamin Gudehus

Maybe a crazy idea: If we have a main repository and a Bitbucket
mirror, we could add a hook on every commit to the main repository
that replicates the commits to the mirror.

If someone opens a pull request a reviewer (with commit rights to the
main repository) can review the pull and comment with r+ (review
positive), then a bot will check if the pull is mergeable to the main
repository and runs the complete tests suite. If the pull is not
mergeable the bot will try to automatically merge changes to the
default branch from the main repository into the PRs branch. If the
merge or tests fail the bot will add a comment to the PR.

Mozilla Rust's bot bors is an example for a bot that works in a
similar way in practice. With ~50 merged commits last week [1]. There
is a recent article (yesterday) that writes about bors successor
[2]. Unfortunately bors is written with Git in mind. There is also a
viewable queue for the pull request auto-merge bot at [3].

[1] https://github.com/bors
[2] 
http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastructure/
[3] http://buildbot.rust-lang.org/bors/bors.html


On 3/18/15, Benjamin Gudehus hasteb...@gmail.com wrote:
 Ah I see, that's reasonable.

 Using patch files sounds like the change sets will be really
 scattered. I first thought about an official Bitbucket mirror that
 acts as a gate and only accepts small pull requests where every author
 identified by his/her email address has accepted the OCA/CLA. There
 also is a synchronization between the main repository and the mirror,
 where the default branch is merged between both. I don't know if this
 is feasible, sounds like a lot of coordination work, e.g. the people
 from Node.js and its fork io.js have some problems with coordination
 between both repositories.





 On 3/18/15, dalibor topic dalibor.to...@oracle.com wrote:
 On 18.03.2015 06:50, Benjamin Gudehus wrote:
  then you have to spend weeks sorting out who contributed to the files
 in the pull request

 Is it common to have multiple authors for a single pull request?

 It's fairly easy to create scenarios with multiple authors:

 A forks away, patches, B forks from A, patches again and submits some
 sort of 'pull request' to the mailing list incorporating both change
 sets.

 cheers,
 dalibor topic
 --
 http://www.oracle.com Dalibor Topic | Principal Product Manager
 Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961
 tel:+491737185961

 ORACLE Deutschland B.V.  Co. KG | Kühnehöfe 5 | 22761 Hamburg

 ORACLE Deutschland B.V.  Co. KG
 Hauptverwaltung: Riesstr. 25, D-80992 München
 Registergericht: Amtsgericht München, HRA 95603
 Geschäftsführer: Jürgen Kunz

 Komplementärin: ORACLE Deutschland Verwaltung B.V.
 Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
 Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

 http://www.oracle.com/commitment Oracle is committed to developing
 practices and products that help protect the environment

Re: OpenJFX mirror at BitBucket?

2015-03-18 Thread Benjamin Gudehus

Ah I see, that's reasonable.

Using patch files sounds like the change sets will be really
scattered. I first thought about an official Bitbucket mirror that
acts as a gate and only accepts small pull requests where every author
identified by his/her email address has accepted the OCA/CLA. There
also is a synchronization between the main repository and the mirror,
where the default branch is merged between both. I don't know if this
is feasible, sounds like a lot of coordination work, e.g. the people
from Node.js and its fork io.js have some problems with coordination
between both repositories.





On 3/18/15, dalibor topic dalibor.to...@oracle.com wrote:
 On 18.03.2015 06:50, Benjamin Gudehus wrote:
  then you have to spend weeks sorting out who contributed to the files
 in the pull request

 Is it common to have multiple authors for a single pull request?

 It's fairly easy to create scenarios with multiple authors:

 A forks away, patches, B forks from A, patches again and submits some
 sort of 'pull request' to the mailing list incorporating both change sets.

 cheers,
 dalibor topic
 --
 http://www.oracle.com Dalibor Topic | Principal Product Manager
 Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961
 tel:+491737185961

 ORACLE Deutschland B.V.  Co. KG | Kühnehöfe 5 | 22761 Hamburg

 ORACLE Deutschland B.V.  Co. KG
 Hauptverwaltung: Riesstr. 25, D-80992 München
 Registergericht: Amtsgericht München, HRA 95603
 Geschäftsführer: Jürgen Kunz

 Komplementärin: ORACLE Deutschland Verwaltung B.V.
 Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
 Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

 http://www.oracle.com/commitment Oracle is committed to developing
 practices and products that help protect the environment

Re: OpenJFX mirror at BitBucket?

2015-03-17 Thread Benjamin Gudehus

then you have to spend weeks sorting out who contributed to the files in
the pull request

Is it common to have multiple authors for a single pull request?

how to contact them, if they are covered under the OCA

Google [1] (googlebot), Mozilla [2] (rust-highfive robot) and Microsoft [3]
(msftclas bot) solve this issue, by using automatic bots that welcome the
contributors and keep an list of already signed CLAs.

[1] https://github.com/Polymer/polymer/pull/1247#issuecomment-76956855
[2] https://github.com/rust-lang/rust/pull/23466#issuecomment-82750848
[3] https://github.com/Microsoft/TypeScript/pull/2376

Regards,
Benjamin

On Wed, Mar 18, 2015 at 6:31 AM, dalibor topic dalibor.to...@oracle.com
wrote:

 On 18.03.2015 01:03, Tomas Mikula wrote:

 Legal issues could be resolved by requiring a signed OCA before each
 pull request is merged.


 Or we could simply require changes to come in the way we do now and avoid
 having to deal with another set of side issues altogether.

 A development model where individual contributors work on their own
 individual changes, and then submit them separately is much easier to deal
 with for reviewers than one where some random things happen on bitbucket,
 someone after a while sends in a random pull request and then you have to
 spend weeks sorting out who contributed to the files in the pull request,
 how to contact them, if they are covered under the OCA, etc.

 cheers,
 dalibor topic
 --
 http://www.oracle.com Dalibor Topic | Principal Product Manager
 Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961
 tel:+491737185961

 ORACLE Deutschland B.V.  Co. KG | Kühnehöfe 5 | 22761 Hamburg

 ORACLE Deutschland B.V.  Co. KG
 Hauptverwaltung: Riesstr. 25, D-80992 München
 Registergericht: Amtsgericht München, HRA 95603
 Geschäftsführer: Jürgen Kunz

 Komplementärin: ORACLE Deutschland Verwaltung B.V.
 Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
 Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

 http://www.oracle.com/commitment Oracle is committed to developing
 practices and products that help protect the environment

Re: 8u40 is released / SB

2015-03-05 Thread Benjamin Gudehus

Hi Tom! As a programmer I use SB for prototyping. I think the problem is,
that designers really need a visual UI and CSS editor.

Upcoming web-standards like Web Components and frameworks like Google
Polymer really shine, when it comes to connection between programmers and
designers.

--Benjamin

On Thu, Mar 5, 2015 at 9:19 AM, Tom Eugelink t...@tbee.org wrote:

 My two cents would be that maintaining a UI builder is an awful lot of
 work, while I expect that a lot of programmers won't be using SB because it
 always has limitations. Either with complex layouts or custom controls.
 Real programmers probably use FXML directly or even just code it in Java.
 So the return on investment probably is fairly low and thus the resources
 can be much better spent on the core. IMHO.


 On 5-3-2015 02:34, Mike Hearn wrote:

 I agree that SB is probably something that can be well maintained by the
 community at this point, especially with commercial backing from Gluon

Re: 8u40 is released

2015-03-05 Thread Benjamin Gudehus


 Looks like Gluon is the Trolltech equivalent I just wished
 for - that was fast :-)


I had a similar thought. Honestly this reminds me a bit more to JGoodies
and the tools around it, but with a lot more. Looks good. Hope that Gluon
takes the mobile ports for JavaFX and SceneBuilder to the next level and
allow open-source contributions. Also noticed the support for Material
design on Android.


 If you let me know when you have a public repository, I'll take a look at
 contributing an integration of UpdateFX and CrashFX.


Why don't I know about these projects? They look very useful! :D Maybe I'm
on the wrong communication channels.


 I'm also interested in making it more keyboardable, in particular shortcuts
 for wrapping/unwrapping would be useful and ability to insert controls
 based on an auto complete of the name.


A keyboard shortcuts editor would be nice. I wish I could toggle the left
and right panes with ALT-1 and ALT-2. A IntelliJ-esque action palette to
insert controls would be very nice.

--Benjamin

Re: QML vs. FXML

2015-03-05 Thread Benjamin Gudehus

Now, having said that, HTML seems to be pretty popular…

Some folks found even HTML too cumbersome to write and edit, and built
transpilers [1], [2], [3], [4]. They look a bit like QML.

[1] http://jade-lang.com/
[2] http://emblemjs.com/
[3] http://haml.info/
[4] http://slim-lang.com/

--Benjamin

Re: Event when CSS is applied

2015-02-17 Thread Benjamin Gudehus

Basically I would like to be informed when the styling of a node has been 
applied or changed.

There are isNeedsLayout() and needsLayoutProperty() and they might
give Node-based information whether the the layout and thus the
styling was applied. I guess this might be true, since doCSSPass() is
called before doLayoutPass() in the JavaFX thread, but could be wrong
on this regard.

As another (more fuzzy) option you could place a custom Logger into
PulseLogger and handle calls to the newPhase() method. The problem is,
that it only gives Scene-based information, i.e. you don't see which
Node was processed, so it might be unreliable information. I use a
custom PulseLogger for performance tests.

--Benjamin


On 2/17/15, Tom Eugelink t...@tbee.org wrote:
 I have a skin (of a control) that centers a Text node. This Text node can be
 styled via CSS, so this styling is a factor when centering. because larger
 font means wider text.

 The centering works perfectly, the only problem is figuring out when to
 center the node. At the moment I'm centering the node on every
 layoutChildren call of the skin, but this is way to often, because after
 applying the CSS chances are very low that the node will need to be
 repositioned.

 Basically I would like to be informed when the styling of a node has been
 applied or changed. Is there some place that can provide this information?


 Tom

Re: Rotate and Rotate transformation

2015-02-15 Thread Benjamin Gudehus

Hi Tom,

this seems to be the case.

Node's rotate property only accepts x and y coordinates, but not
pivotX and pivotY for the rotation center. Interestingly
RotateTransition uses the rotate property (in
Transition#interpolate()) instead of a Rotate transformation.

If you want to specify pivot coordinates, you have to use the Rotate
transformation (or the Scale transformation). I transform Rotate and
Scale transformation with Timeline; it also provides a stop() method
which I needed for a geographical information system.

--Benjamin


On 2/15/15, Tom Eugelink t...@tbee.org wrote:
 Just to check that I'm seeing this right:
 - The rotate property of a node can only rotate around the node's center.
 - The RotateTransition simply manipulates a node's rotate property.

 So as soon as you have to rotate around any other point except the center,
 these two classes cannot be used.

 The alternative is:
 - Use a Rotate transformation, which allows specifying the rotation center.
 - Animate that using a Timeline, because that is the easiest way to animatie
 a transformation.

 Tom

Re: Monocle in 8u25

2014-11-30 Thread Benjamin Gudehus

A snapshot build (testfx-core-4.0.0-20141130.085021-5.jar) with headless
support (using Monocle for JDK 8u20 and above) is available at [1].

If you run headless mode for TestFX in a desktop environment, add Monocle
as an external jar [2] into your classpath and use the properties:
-Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw

If you've managed to run TestFX in an embedded environment please use:
-Dtestfx.robot=glass -Dglass.platform=Monocle -Dmonocle.platform=Headless
-Dprism.order=sw

It will be also included in the first beta build of TestFX 4
(TestFX-4.0.0-beta.1) coming soon.

[1] https://github.com/TestFX/TestFX/releases
[2] https://github.com/TestFX/Monocle/releases

Regards,
Benjamin

On Thu, Nov 27, 2014 at 11:34 AM, Benjamin Gudehus hasteb...@gmail.com
wrote:

Well, unit tests for the glass robot are finished and the integration
tests pass now. This PR will be pulled into master very soon. :)

https://github.com/TestFX/TestFX/pull/159#commits-pushed-11b9b64

Headless mode in TestFX will be behind the properties:
-Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw

I decided to keep the AWT robot as default, for compability and
because the Node.startDragAndDrop() issue is not resolved.

@Neil:
Does that explain what you have seen?
I'm not quite sure. Thanks for the hint. I'll need to investigate this
futher.

On 11/17/14, ngalarn...@abinitio.com ngalarn...@abinitio.com wrote:
Hi Benjamin,

Your progress sounds very good!

In your email below, you said: Also I thought that events with
Platform.runLater() will be processed first-in-first-out, but it seems
that this is not the case.

Kevin, on an email on Nov. 5th to this list, said that the only exception
to Platform.runLater() Runnables being processed in order was in the case
of a showAndWait() being done. That blocks the current thread, which
stops
the current Runnable from completing while a new thread takes the next
event/Runnable from the queue. In that case later Runnables would be
processed before the earlier one completes.

Does that explain what you have seen?

Neil

From: Benjamin Gudehus hasteb...@gmail.com
To: ngalarn...@abinitio.com,
Cc: Tom Eugelink t...@tbee.org, openjfx-dev@openjdk.java.net
openjfx-dev@openjdk.java.net
Date: 11/15/2014 10:50 AM
Subject:Re: Monocle in 8u25

Small update:

Regarding (2) requires interactions to be run withing the JavaFX
thread:
Nearly all integration tests for TestFX pass now. However the
interactions
freeze when using Glass robot, Node.startDragAndDrop() and
ClipboardContent.putString() together. I guess the timing with
Platform.runLater() needs some work.

Regarding (3) retrieve screenshot images in headless mode: I forgot to
use -Dprism.order=sw. Screenshots work in headless mode.

--Benjamin

On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus hasteb...@gmail.com
wrote:
You can find the PR for headless support in TestFX here:
https://github.com/TestFX/TestFX/pull/159

There are some issues with the Glass robot. We need this robot in order
to
simulate user interactions in headless mode.

One problem is, that the Glass robot (1) requires an JavaFX application
to
be set up. TestFX initializes the robots first and then launches the
Application. I worked-around this problem, by initializing the Glass
robot
just before the first user interaction is made.

Another problem is, that the Glass robot (2) requires interactions to be
run within the JavaFX thread. From the integration tests I've wrote it
looks that we need to wait for the events in the JavaFX thread to
complete
for certain interactions, e.g. we need to wait after mouseMove() in order
to do mouseClick(). With the AWT robot we only needed to wait for the
events triggered by interactions to complete (let's call them
post-interaction events). Now it seems that we also need to wait for the
interactions itself to complete, which then will also trigger the
post-interaction events. I'll need to visualize different interaction
events, post-interaction events and the event waiting, and decide when we
need to use the semaphore solution we currently use to wait for
post-interaction events. Also I thought that events with
Platform.runLater() will be processed first-in-first-out, but it seems
that this is not the case.

https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117
).

Regards,
Benjamin

NOTICE from Ab Initio: This email (including any attachments) may contain
information that is subject

Re: Monocle in 8u25

2014-11-27 Thread Benjamin Gudehus

Well, unit tests for the glass robot are finished and the integration
tests pass now. This PR will be pulled into master very soon. :)

https://github.com/TestFX/TestFX/pull/159#commits-pushed-11b9b64

Headless mode in TestFX will be behind the properties:
-Dtestfx.robot=glass -Dtestfx.headless=true -Dprism.order=sw

I decided to keep the AWT robot as default, for compability and
because the Node.startDragAndDrop() issue is not resolved.

@Neil:
Does that explain what you have seen?
I'm not quite sure. Thanks for the hint. I'll need to investigate this futher.

On 11/17/14, ngalarn...@abinitio.com ngalarn...@abinitio.com wrote:
Hi Benjamin,

Your progress sounds very good!

In your email below, you said: Also I thought that events with
Platform.runLater() will be processed first-in-first-out, but it seems
that this is not the case.

Kevin, on an email on Nov. 5th to this list, said that the only exception
to Platform.runLater() Runnables being processed in order was in the case
of a showAndWait() being done. That blocks the current thread, which stops
the current Runnable from completing while a new thread takes the next
event/Runnable from the queue. In that case later Runnables would be
processed before the earlier one completes.

Does that explain what you have seen?

Neil

Small update:

Regarding (2) requires interactions to be run withing the JavaFX thread:
Nearly all integration tests for TestFX pass now. However the interactions
freeze when using Glass robot, Node.startDragAndDrop() and
ClipboardContent.putString() together. I guess the timing with
Platform.runLater() needs some work.

Regarding (3) retrieve screenshot images in headless mode: I forgot to
use -Dprism.order=sw. Screenshots work in headless mode.

--Benjamin

On Sat, Nov 15, 2014 at 1:48 AM, Benjamin Gudehus hasteb...@gmail.com
wrote:
You can find the PR for headless support in TestFX here:
https://github.com/TestFX/TestFX/pull/159

There are some issues with the Glass robot. We need this robot in order to
simulate user interactions in headless mode.

One problem is, that the Glass robot (1) requires an JavaFX application to
be set up. TestFX initializes the robots first and then launches the
Application. I worked-around this problem, by initializing the Glass robot
just before the first user interaction is made.

Another problem is, that the Glass robot (2) requires interactions to be
run within the JavaFX thread. From the integration tests I've wrote it
looks that we need to wait for the events in the JavaFX thread to complete
for certain interactions, e.g. we need to wait after mouseMove() in order
to do mouseClick(). With the AWT robot we only needed to wait for the
events triggered by interactions to complete (let's call them
post-interaction events). Now it seems that we also need to wait for the
interactions itself to complete, which then will also trigger the
post-interaction events. I'll need to visualize different interaction
events, post-interaction events and the event waiting, and decide when we
need to use the semaphore solution we currently use to wait for
post-interaction events. Also I thought that events with
Platform.runLater() will be processed first-in-first-out, but it seems
that this is not the case.

Yet, another problem is, that I did not manage to (3) retrieve screenshot
images in headless mode with the Glass robot. Although it works in normal
mode. Maybe the JavaFX event robot can retrieve the screenshots.
Interestingly the HeadlessScreen updates it's framebuffer (
https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117
).

Regards,
Benjamin

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: Public way to monitor JavaFX Windows

2014-11-25 Thread Benjamin Gudehus

Hi!

TestFX uses `javafx.stage.Window.impl_getWindows()` to search nodes
for user input simulation and state verification. I haven't spotted a
public way to retrieve or even monitor windows or stages. Also:
Searching for nodes within all windows simplifies tests for open popup
window drastically in comparision to e.g. the FEST-Swing test
framework.

--Benjamin


On 11/25/14, Matthieu BROUILLARD matth...@brouillard.fr wrote:
 Hi all,

 I'd like to know if there is a public way to monitor all root window
 JavaFX objects (Window, Stage, PopupWindow).

 All what I have found until now is private impl

- com.sun.javafx.stage.StageHelper.getStages(), observable but relevant
only for Stages
- javafx.stage.Window.impl_getWindows(), used inside ScenicView but not
listenable

 If there is not a public API, I'll create a JIRA for this.

 Matthieu

Re: Monocle in 8u25

2014-11-14 Thread Benjamin Gudehus

You can find the PR for headless support in TestFX here:
https://github.com/TestFX/TestFX/pull/159

There are some issues with the Glass robot. We need this robot in order to
simulate user interactions in headless mode.

One problem is, that the Glass robot *(1) requires an JavaFX application*
to be set up. TestFX initializes the robots first and then launches the
Application. I worked-around this problem, by initializing the Glass robot
just before the first user interaction is made.

Another problem is, that the Glass robot *(2) requires interactions to be
run within the JavaFX thread*. From the integration tests I've wrote it
looks that we need to wait for the events in the JavaFX thread to complete
for certain interactions, e.g. we need to wait after mouseMove() in order
to do mouseClick(). With the AWT robot we only needed to wait for the
events triggered by interactions to complete (let's call them
post-interaction events). Now it seems that we also need to wait for the
interactions itself to complete, which then will also trigger the
post-interaction events. I'll need to visualize different interaction
events, post-interaction events and the event waiting, and decide when we
need to use the semaphore solution we currently use to wait for
post-interaction events. Also I thought that events with
Platform.runLater() will be processed first-in-first-out, but it seems that
this is not the case.

Yet, another problem is, that I did not manage to *(3) retrieve screenshot
images in headless mode* with the Glass robot. Although it works in normal
mode. Maybe the JavaFX event robot can retrieve the screenshots.
Interestingly the HeadlessScreen updates it's framebuffer (
https://github.com/TestFX/Monocle/blob/0ab3986f4c/src/main/java/com/sun/glass/ui/monocle/headless/HeadlessScreen.java#L117
).

Regards,
Benjamin

On Fri, Nov 14, 2014 at 8:04 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:

Should we roll out a openjfx-monocle-1.8.0_40-SNAPSHOT?

I'll prepare a branch for this.

Applied your patch and made some changes (introduced gradle.properties and
removed redundant if-condition):

https://github.com/TestFX/Monocle/pull/2/files

--Benjamin

Re: Monocle in 8u25

2014-11-13 Thread Benjamin Gudehus

Hi Neil!

The TestFX library is still moving the Windows mouse!
TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls
the OS's cursor.
We need to replace it with Glass' robot. I already tested it and it works
fine.
PR will be ready soon. This PR will also replace the Awt screenshot
mechanism with the one
from the Glass robot. I hoped that this will also take screenshots wenn
running in headless mode.
But unfortunately the screenshots were empty. I saw in Monocle's source
code, that it writes
color values into an internal byte stream, so it actually should work.

Also very nice to see, that people are using bleeding edge version of
TestFX. :)
TestFX will also have better Spock/Groovy support in the future.

--Benjamin


On Thu, Nov 13, 2014 at 9:38 PM, ngalarn...@abinitio.com wrote:

 Hi Benjamin,

 We are using Spock for testing, and have modified the setupStage() method
 to support optional headless testing with Monocle,
 which is working well on Windows (the code is in groovy):

  void setupStage(Closurejavafx.scene.Node rootNodeFactory)
   {
 if (fx == null  isHeadless)
 {
   // Cribbed from:
 https://gist.github.com/hastebrot/cbca1128dd791966e3a6
   PlatformFactory.instance = new MonoclePlatformFactory()
   NativePlatformFactory.platform = new HeadlessPlatform()
 }
 fx = new GuiTest()
 fx.rootNodeFactory = rootNodeFactory
 fx.setupGuiTest()
   }

 It works nicely until fx.clickOn is called. The TestFX library is still
 moving the Windows mouse!

 Any thoughts?


 Thanks,

 Neil




 From:Benjamin Gudehus hasteb...@gmail.com
 To:Tom Eugelink t...@tbee.org,
 Cc:openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net
 Date:11/12/2014 03:10 AM
 Subject:Re: Monocle in 8u25
 Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
 --



 That would be nice, Tom.

 Example usage:

 Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
 external jars, we need to change

 public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
 }

 to

 public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
 }

 and start the Application with -Djavafx.monocle.headless=true.

 ToolkitApplicationLauncher.jar:
 https://gist.github.com/hastebrot/cbca1128dd791966e3a6


 On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org wrote:

   I can roll it out under the same name (openjfx-monocle-1.8.0_20) within
  the org.jfxtras group. Just say so.
 
  Tom
 
 
  On 12-11-2014 08:30, Benjamin Gudehus wrote:
 
 Hi all!
 
   Files and instructions are available at
 https://github.com/TestFX/Monocle
  .
 
   Releases with jars: https://github.com/TestFX/Monocle/releases
 
   License (taken from OpenJFX respository):
  https://github.com/TestFX/Monocle/blob/master/LICENSE
 
   Would be nice to have this available from Maven.
 
   --Benjamin
 
  On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org wrote:
 
  This is extremely good news. I have no problem to drag that library
  along in the JFXtras project (project name seems to be a good match for
  this usage ;-) and release it to maven - if that is allowed by the
 JavaFX
  license.
 
  Tom
 
 
 
  On 5-11-2014 16:57, Benjamin Gudehus wrote:
 
  Hi Sean,
 
  I've put the Monocle sources directly in my code directories for
  testing purposes. Putting it into a separate Jar is possible and I
  thought that pre-compiled jars could be provided via Maven.
 
  I didn't do a complete OpenJFX build, because I was only interested in
  the Headless component of Monocle, i.e. I didn't needed the
  platform-dependent dynamic libraries.
 
  Rough instructions were given in a previous mail. There were some
  request to provide the pre-compoile jars so I will additionally set up
  a public repository with detailed instructions when I'm back home.
 
  --Benjamin
 
  On 11/5/14, Sean True sean.t...@gmail.com wrote:
 
  Did you build the glass/ui/monocle sources into a separate jar, or did
  you
  do a complete OpenJFX build?
 
  If you did a separate build, a recipe would be extremely helpful.
 
  -- Sean
 
  On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com
 
  wrote:
 
   I managed to run Monocle/Headless on Windows with 8u25. This will
 allow
  users to run headless tests.
 
  All what is needed is to copy all files from
 com/sun/glass/ui/monocle
  of
  javafx-src.zip and add the
  cursor resource files from
  modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
  related hg tag in the OpenJFX repository [1].
 
  Before Application#launch() is called we need to manually set the
 Glass
  and
  Monocle platforms:
 
  accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance,
   new com.sun.glass.ui.monocle.MonoclePlatformFactory());
 
 accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class

Re: Monocle in 8u25

2014-11-13 Thread Benjamin Gudehus

@Tom Thanks for the patch. Will apply it soon.
Is there something like a package maintainer field for Maven? I think
developer is a bit too pompous; I didn't touch the code.

On Thu, Nov 13, 2014 at 10:01 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:

 Hi Neil!

 The TestFX library is still moving the Windows mouse!
 TestFX is using Awt's robot. This robot ignores Glass/Monocle and controls
 the OS's cursor.
 We need to replace it with Glass' robot. I already tested it and it works
 fine.
 PR will be ready soon. This PR will also replace the Awt screenshot
 mechanism with the one
 from the Glass robot. I hoped that this will also take screenshots wenn
 running in headless mode.
 But unfortunately the screenshots were empty. I saw in Monocle's source
 code, that it writes
 color values into an internal byte stream, so it actually should work.

 Also very nice to see, that people are using bleeding edge version of
 TestFX. :)
 TestFX will also have better Spock/Groovy support in the future.

 --Benjamin


 On Thu, Nov 13, 2014 at 9:38 PM, ngalarn...@abinitio.com wrote:

 Hi Benjamin,

 We are using Spock for testing, and have modified the setupStage() method
 to support optional headless testing with Monocle,
 which is working well on Windows (the code is in groovy):

  void setupStage(Closurejavafx.scene.Node rootNodeFactory)
   {
 if (fx == null  isHeadless)
 {
   // Cribbed from:
 https://gist.github.com/hastebrot/cbca1128dd791966e3a6
   PlatformFactory.instance = new MonoclePlatformFactory()
   NativePlatformFactory.platform = new HeadlessPlatform()
 }
 fx = new GuiTest()
 fx.rootNodeFactory = rootNodeFactory
 fx.setupGuiTest()
   }

 It works nicely until fx.clickOn is called. The TestFX library is still
 moving the Windows mouse!

 Any thoughts?


 Thanks,

 Neil




 From:Benjamin Gudehus hasteb...@gmail.com
 To:Tom Eugelink t...@tbee.org,
 Cc:openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net
 Date:11/12/2014 03:10 AM
 Subject:Re: Monocle in 8u25
 Sent by:openjfx-dev openjfx-dev-boun...@openjdk.java.net
 --



 That would be nice, Tom.

 Example usage:

 Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
 external jars, we need to change

 public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
 }

 to

 public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
 }

 and start the Application with -Djavafx.monocle.headless=true.

 ToolkitApplicationLauncher.jar:
 https://gist.github.com/hastebrot/cbca1128dd791966e3a6


 On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org wrote:

   I can roll it out under the same name (openjfx-monocle-1.8.0_20) within
  the org.jfxtras group. Just say so.
 
  Tom
 
 
  On 12-11-2014 08:30, Benjamin Gudehus wrote:
 
 Hi all!
 
   Files and instructions are available at
 https://github.com/TestFX/Monocle
  .
 
   Releases with jars: https://github.com/TestFX/Monocle/releases
 
   License (taken from OpenJFX respository):
  https://github.com/TestFX/Monocle/blob/master/LICENSE
 
   Would be nice to have this available from Maven.
 
   --Benjamin
 
  On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org wrote:
 
  This is extremely good news. I have no problem to drag that library
  along in the JFXtras project (project name seems to be a good match for
  this usage ;-) and release it to maven - if that is allowed by the
 JavaFX
  license.
 
  Tom
 
 
 
  On 5-11-2014 16:57, Benjamin Gudehus wrote:
 
  Hi Sean,
 
  I've put the Monocle sources directly in my code directories for
  testing purposes. Putting it into a separate Jar is possible and I
  thought that pre-compiled jars could be provided via Maven.
 
  I didn't do a complete OpenJFX build, because I was only interested in
  the Headless component of Monocle, i.e. I didn't needed the
  platform-dependent dynamic libraries.
 
  Rough instructions were given in a previous mail. There were some
  request to provide the pre-compoile jars so I will additionally set up
  a public repository with detailed instructions when I'm back home.
 
  --Benjamin
 
  On 11/5/14, Sean True sean.t...@gmail.com wrote:
 
  Did you build the glass/ui/monocle sources into a separate jar, or
 did
  you
  do a complete OpenJFX build?
 
  If you did a separate build, a recipe would be extremely helpful.
 
  -- Sean
 
  On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus 
 hasteb...@gmail.com
  wrote:
 
   I managed to run Monocle/Headless on Windows with 8u25. This will
 allow
  users to run headless tests.
 
  All what is needed is to copy all files from
 com/sun/glass/ui/monocle
  of
  javafx-src.zip and add the
  cursor resource files from
  modules/graphics/src/main/resources/com/sun/glass/ui/monocle of
 the
  related hg tag in the OpenJFX repository [1].
 
  Before Application#launch() is called we

Re: Monocle in 8u25

2014-11-12 Thread Benjamin Gudehus

That would be nice, Tom.

Example usage:

Since com.sun.glass.ui.PlatformFactory can't find Monocle classes from the
external jars, we need to change

public static void main(String[] appArgs) {
Application.launch(appClass, appArgs);
}

to

public static void main(String[] appArgs) {
new ToolkitApplicationLauncher().launch(appClass, appArgs);
}

and start the Application with -Djavafx.monocle.headless=true.

ToolkitApplicationLauncher.jar:
https://gist.github.com/hastebrot/cbca1128dd791966e3a6


On Wed, Nov 12, 2014 at 8:48 AM, Tom Eugelink t...@tbee.org wrote:

  I can roll it out under the same name (openjfx-monocle-1.8.0_20) within
 the org.jfxtras group. Just say so.

 Tom





 On 12-11-2014 08:30, Benjamin Gudehus wrote:

Hi all!

  Files and instructions are available at https://github.com/TestFX/Monocle
 .

  Releases with jars: https://github.com/TestFX/Monocle/releases

  License (taken from OpenJFX respository):
 https://github.com/TestFX/Monocle/blob/master/LICENSE

  Would be nice to have this available from Maven.

  --Benjamin

 On Wed, Nov 5, 2014 at 8:20 PM, Tom Eugelink t...@tbee.org wrote:

 This is extremely good news. I have no problem to drag that library
 along in the JFXtras project (project name seems to be a good match for
 this usage ;-) and release it to maven - if that is allowed by the JavaFX
 license.

 Tom



 On 5-11-2014 16:57, Benjamin Gudehus wrote:

 Hi Sean,

 I've put the Monocle sources directly in my code directories for
 testing purposes. Putting it into a separate Jar is possible and I
 thought that pre-compiled jars could be provided via Maven.

 I didn't do a complete OpenJFX build, because I was only interested in
 the Headless component of Monocle, i.e. I didn't needed the
 platform-dependent dynamic libraries.

 Rough instructions were given in a previous mail. There were some
 request to provide the pre-compoile jars so I will additionally set up
 a public repository with detailed instructions when I'm back home.

 --Benjamin

 On 11/5/14, Sean True sean.t...@gmail.com wrote:

 Did you build the glass/ui/monocle sources into a separate jar, or did
 you
 do a complete OpenJFX build?

 If you did a separate build, a recipe would be extremely helpful.

 -- Sean

 On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com
 wrote:

  I managed to run Monocle/Headless on Windows with 8u25. This will allow
 users to run headless tests.

 All what is needed is to copy all files from com/sun/glass/ui/monocle
 of
 javafx-src.zip and add the
 cursor resource files from
 modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
 related hg tag in the OpenJFX repository [1].

 Before Application#launch() is called we need to manually set the Glass
 and
 Monocle platforms:

 accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance,
  new com.sun.glass.ui.monocle.MonoclePlatformFactory());
 accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class,
 platform,
  new com.sun.glass.ui.monocle.headless.HeadlessPlatform());

 The directory structure in 8u40 is a bit different, but there could be
 added version checks. Checking
 for the JVM vars glass.platform and monocle.platform might be also
 added to this code.

 [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags


 On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com
 wrote:

  Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory
 won't
 retrieve externally defined PlatformFactorys. So I will try to set the
 PlatformFactory.instance field manually, before the
 Application/Tookit/FX-Thread is launched.

 On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com
 
 wrote:

  Thank you. That makes it clearer. :)

 Is it possible to supply the headless part of Monocle in an external
 Jar
 for desktop platforms?

 As far as I know the only possibility to run TestFX tests with
 Hudson/Jenkins is in headless mode.
 TestFX's tests itself can only run with the X virtual framebuffer on
 Linux test clients for the Travis CI so far.

 So far the only advice I could give TestFX users who like to run

  headless

  tests is to use 1.8.0_20-ea-b05.

Re: Monocle in 8u25

2014-11-05 Thread Benjamin Gudehus

Hi Sean,

I've put the Monocle sources directly in my code directories for
testing purposes. Putting it into a separate Jar is possible and I
thought that pre-compiled jars could be provided via Maven.

I didn't do a complete OpenJFX build, because I was only interested in
the Headless component of Monocle, i.e. I didn't needed the
platform-dependent dynamic libraries.

Rough instructions were given in a previous mail. There were some
request to provide the pre-compoile jars so I will additionally set up
a public repository with detailed instructions when I'm back home.

--Benjamin

On 11/5/14, Sean True sean.t...@gmail.com wrote:
 Did you build the glass/ui/monocle sources into a separate jar, or did you
 do a complete OpenJFX build?

 If you did a separate build, a recipe would be extremely helpful.

 -- Sean

 On Tue, Nov 4, 2014 at 6:17 PM, Benjamin Gudehus hasteb...@gmail.com
 wrote:

 I managed to run Monocle/Headless on Windows with 8u25. This will allow
 users to run headless tests.

 All what is needed is to copy all files from com/sun/glass/ui/monocle
 of
 javafx-src.zip and add the
 cursor resource files from
 modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
 related hg tag in the OpenJFX repository [1].

 Before Application#launch() is called we need to manually set the Glass
 and
 Monocle platforms:

 accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance,
 new com.sun.glass.ui.monocle.MonoclePlatformFactory());
 accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class,
 platform,
 new com.sun.glass.ui.monocle.headless.HeadlessPlatform());

 The directory structure in 8u40 is a bit different, but there could be
 added version checks. Checking
 for the JVM vars glass.platform and monocle.platform might be also
 added to this code.

 [1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags


 On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com
 wrote:

  Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory
  won't
  retrieve externally defined PlatformFactorys. So I will try to set the
  PlatformFactory.instance field manually, before the
  Application/Tookit/FX-Thread is launched.
 
  On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com
  wrote:
 
  Thank you. That makes it clearer. :)
 
  Is it possible to supply the headless part of Monocle in an external
  Jar
  for desktop platforms?
 
  As far as I know the only possibility to run TestFX tests with
  Hudson/Jenkins is in headless mode.
  TestFX's tests itself can only run with the X virtual framebuffer on
  Linux test clients for the Travis CI so far.
 
  So far the only advice I could give TestFX users who like to run
 headless
  tests is to use 1.8.0_20-ea-b05.

Re: Monocle in 8u25

2014-11-04 Thread Benjamin Gudehus

I see. Didn't know that. Thanks for the quick response.

Users from the TestFX project are interested in headless testing (e.g. on
Windows with Jenkins). There was a blog post [1] a while back, which
explained how to use TestFX and Java 8 to run headless tests. I've never
tried this myself, but recently added adapters for GlassRobot and the
JavaFX event robot to TestFX in order to allow headless testing.

[1]
http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/

On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:

 Monocle is not included in any 8u release on desktop platforms (Windows,
 Linux, Mac).

 -- Kevin



 Benjamin Gudehus wrote:

 Hi!

 I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing
 from
 `jfxrt.jar` at
 least in the Windows and Linux builds of Java 8u25, although it is
 included
 in 8u20.

 Is there any specific reason why Monocle is not included? Is there a way
 to
 use Monocle
 in 8u25?

 Regards
 Benjamin

 (Crosspost from: https://community.oracle.com/message/12680634#12680634)

Re: Monocle in 8u25

2014-11-04 Thread Benjamin Gudehus

I ran a simple click test with

-Dglass.platform=Monocle -Dmonocle.platform=Headless -Dprism.order=sw

and the GlassRobot on Windows 7 with Java 8u20 and can confirm that the
tests ran headless and clicked on an invisible table row. I also could
browse the Monocle source code within IntelliJ IDEA.

However on Java 8u25 the same test will fail with

java.lang.ClassNotFoundException:
com.sun.glass.ui.monocle.MonoclePlatformFactory
Failed to load Glass factory class



C:\Program Files\Java\jdk1.8.0_20\binjava -version
java version 1.8.0_20-ea
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)

Regards,
Benjamin

On Tue, Nov 4, 2014 at 6:51 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:

 I see. Didn't know that. Thanks for the quick response.

 Users from the TestFX project are interested in headless testing (e.g. on
 Windows with Jenkins). There was a blog post [1] a while back, which
 explained how to use TestFX and Java 8 to run headless tests. I've never
 tried this myself, but recently added adapters for GlassRobot and the
 JavaFX event robot to TestFX in order to allow headless testing.

 [1]
 http://ustesis.wordpress.com/2014/04/23/headless-ui-testing-with-testfx-and-javafx-8/

 On Tue, Nov 4, 2014 at 6:43 PM, Kevin Rushforth 
 kevin.rushfo...@oracle.com wrote:

 Monocle is not included in any 8u release on desktop platforms (Windows,
 Linux, Mac).

 -- Kevin



 Benjamin Gudehus wrote:

 Hi!

 I noticed `com.sun.glass.ui.monocle.MonoclePlatformFactory` is missing
 from
 `jfxrt.jar` at
 least in the Windows and Linux builds of Java 8u25, although it is
 included
 in 8u20.

 Is there any specific reason why Monocle is not included? Is there a way
 to
 use Monocle
 in 8u25?

 Regards
 Benjamin

 (Crosspost from: https://community.oracle.com/message/12680634#12680634)

Re: Monocle in 8u25

2014-11-04 Thread Benjamin Gudehus

I managed to run Monocle/Headless on Windows with 8u25. This will allow
users to run headless tests.

All what is needed is to copy all files from com/sun/glass/ui/monocle of
javafx-src.zip and add the
cursor resource files from
modules/graphics/src/main/resources/com/sun/glass/ui/monocle of the
related hg tag in the OpenJFX repository [1].

Before Application#launch() is called we need to manually set the Glass and
Monocle platforms:

accessStaticField(com.sun.glass.ui.PlatformFactory.class, instance,
new com.sun.glass.ui.monocle.MonoclePlatformFactory());
accessStaticField(com.sun.glass.ui.monocle.NativePlatformFactory.class,
platform,
new com.sun.glass.ui.monocle.headless.HeadlessPlatform());

The directory structure in 8u40 is a bit different, but there could be
added version checks. Checking
for the JVM vars glass.platform and monocle.platform might be also
added to this code.

[1] http://hg.openjdk.java.net/openjfx/8u-dev/rt/tags


On Tue, Nov 4, 2014 at 8:42 PM, Benjamin Gudehus hasteb...@gmail.com
wrote:

 Hmm. Seems that Class.forName() in com.sun.glass.ui.PlatformFactory won't
 retrieve externally defined PlatformFactorys. So I will try to set the
 PlatformFactory.instance field manually, before the
 Application/Tookit/FX-Thread is launched.

 On Tue, Nov 4, 2014 at 7:36 PM, Benjamin Gudehus hasteb...@gmail.com
 wrote:

 Thank you. That makes it clearer. :)

 Is it possible to supply the headless part of Monocle in an external Jar
 for desktop platforms?

 As far as I know the only possibility to run TestFX tests with
 Hudson/Jenkins is in headless mode.
 TestFX's tests itself can only run with the X virtual framebuffer on
 Linux test clients for the Travis CI so far.

 So far the only advice I could give TestFX users who like to run headless
 tests is to use 1.8.0_20-ea-b05.

46 matches

Mail list logo