Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

Seems a reasonable addition to me, too. -- Kevin Michael Ennen wrote: Sounds like a reasonable idea to me. On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker wrote: I'm thinking about the addition of a public method for mouse click, which is mouse press and then mouse

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

Sounds like a reasonable idea to me. On Mon, Mar 26, 2018 at 1:00 PM, Nir Lisker wrote: > I'm thinking about the addition of a public method for mouse click, which > is mouse press and then mouse release - the parallel for key typed. Is it > worth? > > - Nir > > On Mon, Mar

Re: modules versus SDK's

Ultimately, I think you are right that a standalone JavaFX needs to be discoverable and usable via a dependency manager like gradle or maven. From the discussion, it seems most others agree. I note that this doesn't preclude also making a zip bundle available for developers who want to

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

This looks fine to me now. -- Kevin Ajit Ghaisas wrote: Thanks all for the review. I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ The changes are - 1. Addressed the (c) year inaccuracies in files -

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

It doesn't seem harmful to keep the current implementation. This seems better to leave for the follow-on JBS issue (JDK-8200236) unless there something I am missing. -- Kevin mandy chung wrote: You don't need the loggers map and getLogger method can simply return return new

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

I'm thinking about the addition of a public method for mouse click, which is mouse press and then mouse release - the parallel for key typed. Is it worth? - Nir On Mon, Mar 26, 2018 at 5:54 PM, Kevin Rushforth wrote: > Seems good to me, too. > > -- Kevin > > >

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

You don't need the loggers map and getLogger method can simply return return new PlatformLogger(System.getLogger(name)); Other than this, looks fine. Mandy On 3/26/18 4:36 AM, Ajit Ghaisas wrote: Thanks all for the review. I have addressed the review comments in -

Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

Seems good to me, too. -- Kevin Michael Ennen wrote: Sounds like a good idea to me to only have `getScreenCapture` methods that have a WritableImage parameter which can be `null` which means a new WritableImage will be created otherwise the given one is re-used, as in Scene.snapshot and

Re: OpenJFX GitHub mirror

Hi Nir, About 4. (jfx-dev): you're right, I just removed that repository. That was just some testing before we did the real thing. As for the other points: I agree - Johan On Mon, Mar 26, 2018 at 12:03 PM Nir Lisker wrote: > Hi All, > > A few comments about the mirror and

Re: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

Hi Ajit, Looks good to me. I obviously didn't review the build changes. best regards, -- daniel On 26/03/2018 12:36, Ajit Ghaisas wrote: Thanks all for the review. I have addressed the review comments in -http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ The changes are - 1.

Re: modules versus SDK's

On 2018-03-26T11:28:44 + Mario Ivankovits wrote: > +1 on providing JavaFX as „simple“ dependency. > > Question is how to deal with the native libraries. Provide an artifact per > platform? Take a look at how LWJGL handles it:

RE: [11] Review request : JDK-8195799 : Use System logger instead of platform logger in javafx modules

Thanks all for the review. I have addressed the review comments in - http://cr.openjdk.java.net/~aghaisas/fx/8195799/webrev.1/ The changes are - 1. Addressed the (c) year inaccuracies in files - modules/javafx.base/src/main/java/com/sun/javafx/collections/SetListenerHelper.java

Re: modules versus SDK's

+1 on providing JavaFX as „simple“ dependency. Question is how to deal with the native libraries. Provide an artifact per platform? compile: 'javafx:javax.graphics-osx:11.0.0' compile: 'javafx:javax.graphics-win:11.0.0' compile: 'javafx:javax.graphics-pi:11.0.0‘ These bundles might just

Re: modules versus SDK's

Hi Johan, hi all, in my opinion SDKs are tolerable for providing the fundamental layers of infrastructure. But other dependencies should be lightweight and use the default channels for providing dependencies. There should be no difference between consuming JavaFX and let's say CommonsIO as

OpenJFX GitHub mirror

Hi All, A few comments about the mirror and JBS: 1. In PRs and issues on GitHub, I strongly suggest that the link to JBS be included in the top comment. If the JBS issue was created after a discussion, edit it in. 2. In JBS, I suggest to link to the GitHub mirror via More > Link > Web Link and

Re: modules versus SDK's

+1 for getting it the "normal" way.. Sven Tom Eugelink schrieb am Mo., 26. März 2018, 10:59: > I totally assumed that, when JavaFX is separated out, it will distributed > as an artifact on Maven central (or similar) so it can be included like a > dependency. Feels like a no

Re: modules versus SDK's

I totally assumed that, when JavaFX is separated out, it will distributed as an artifact on Maven central (or similar) so it can be included like a dependency. Feels like a no brainer? On 26-3-2018 10:50, Johan Vos wrote: Hi, I want to start a discussion on distributing JavaFX as an SDK

modules versus SDK's

Hi, I want to start a discussion on distributing JavaFX as an SDK versus distributing its modules via the traditional build and distribution mechanisms. Personally, I think relying on an SDK is too much a barrier. It requires users to manually download software from the exact right place, and