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 release - the parallel fo
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 26, 2018 at 5:54 PM,
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 downloa
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 -
modules/javafx.base/src/main/java/com/su
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 PlatformLogg
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
>
>
> Michael Ennen wrote:
>
>> Sounds l
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 -
http://cr.openjdk.jav
>
> > (including property files and native code), he uses his build tools (e.g.
> > maven/gradle) to manage the download/install//update of those
> > libaries/frameworks.
> > If you rely on Spring, Apache Commons, slf4j,... you don't download those
> > SDK's but you point to the group-name-version
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 Node.s
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 JBS:
>
> 1. In PRs a
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. Addres
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:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.lwjgl%2
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
modules/javafx.gr
+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 contain
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 depende
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 i
+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 brainer?
>
>
> On 26
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 vers
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
"in
19 matches
Mail list logo
