On Thu, 20 Oct 2022 11:31:43 GMT, Ambarish Rapte wrote:
> Updating last modified year in copyright header of the files that were
> modified during year 2022.
Marked as reviewed by kcr (Lead).
-
PR: https://git.openjdk.org/jfx/pull/923
It doesn't look to me like a big problem, regardless of the size of the
project. You just include the modules you want depending on what your
application needs and which platforms it targets. In Gradle, it's just 2
lines of code.
There is also the JavaFX plugin that might help with this, but it's
Thanks Nir for the links to the other discussions. I got the thing to run with
the simple approach of including all artifacts. Probably did miss some before
but it's late in the night here :)
One thing that still bugs me is that I have to do dependency resolution
manually if I want to include
There was a discussion on this some years ago, it started here:
https://mail.openjdk.org/pipermail/openjfx-dev/2018-April/021762.html (and
continued in
https://mail.openjdk.org/pipermail/openjfx-dev/2018-May/021774.html).
There might have been another discussion after that, I don't remember.
Interesting. I will repeat my test more carefully. Maybe I am just doing
something incredible stupid. But Andy has a good point: why include the java
classes at all in the platform-specific jars - shouldn't they just contain the
native libraries if all the java code is indeed the same?
Good point - are we packaging platform-specific javafx parts incorrectly?
-andy
From: openjfx-dev on behalf of John Hendrikx
Date: Thursday, 2022/10/20 at 13:03
To: openjfx-dev@openjdk.org
Subject: Re: Platform independent deployment
Correct me if I'm wrong, but all the classes in the
Correct me if I'm wrong, but all the classes in the artifacts for win,
linux and mac are actually exactly the same -- this is Java code after
all, why would all Java classes for a platform be platform specific? It
doesn't matter which one is packaged. The platform specific stuff lives
in the
> - added Skin.install()
> - javadoc changes for Skinnable.setSkin(Skin)
Andy Goryachev has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains 26 additional
Hi Andy,
This is actually a good suggestion. There are compatibility issues with
existing installations (end users could change the commandline/arguments). I
will have to check.
- Thomas
Mit freundlichen Grüßen,
Thomas Reinhardt
Am 20.10.2022 19:12 schrieb Andy Goryachev :
clean backport of 8277785: ListView scrollTo jumps to wrong location when
CellHeight is…changed
Reviewed-by: kcr, fkirmaier, aghaisas
-
Commit messages:
- 8277785: ListView scrollTo jumps to wrong location when CellHeight is changed
Changes:
clean backport of 8284665: First selected item of a TreeItem multiple selection
gets removed if new items are constantly added to the TreeTableView
Reviewed-by: aghaisas
-
Commit messages:
- 8284665: First selected item of a TreeItem multiple selection gets removed
if new items
On Thu, 20 Oct 2022 17:04:31 GMT, Thiago Milczarek Sayao
wrote:
>> This cleans size and positioning code, reducing special cases, code
>> complexity and size.
>>
>> Changes:
>>
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
>> sizes. It does not assume any
Thomas:
if your installer can change the command line it uses to launch java, you could
modify the classpath to point to a subdirectory or a set of platform-specific
jars. do you think this might work?
-andy
From: openjfx-dev on behalf of Thomas Reinhardt
Date: Thursday, 2022/10/20 at
clean backport of 8291625: DialogPane without header nor headerText nor graphic
node adds padding to the left of the content pane
Reviewed-by: aghaisas
-
Commit messages:
- 8291625: DialogPane without header nor headerText nor graphic node adds
padding to the left of the content
I use this in a gradle project I have and it works for me. All the
OS-specific modules are packaged and I can run the app on all 3 desktop
platforms.
It seems that you are doing something more special. Maybe someone else has
insights.
On Thu, Oct 20, 2022 at 8:03 PM Thomas Reinhardt
wrote:
>
>
> This cleans size and positioning code, reducing special cases, code
> complexity and size.
>
> Changes:
>
> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different
> sizes. It does not assume any size because it varies - it does cache because
> it's unlikely to vary on
Hi Nir,
Does not work (I testet it) and it can not work (see below).
Also, this is exactly what my naive test was (I did not use maven to
copy the artifacts, but the result obviously is the same).
It can not work as the implementation classes have the same name and
thus the jre can not
On Thu, 20 Oct 2022 14:37:04 GMT, Johan Vos wrote:
> The root problem is actually broader than stated in the JBS issue. This PR
> now translates screencoordinates from absolute coordinates into coordinates
> that take the platformScale into account.
> The whole process is complicated by the
Hi Thomas,
Did you try to just specify the platform-specific dependencies in the POM?
org.openjfx
javafx-graphics
19
win
org.openjfx
javafx-graphics
19
linux
org.openjfx
javafx-graphics
On Thu, 20 Oct 2022 11:31:43 GMT, Ambarish Rapte wrote:
> Updating last modified year in copyright header of the files that were
> modified during year 2022.
Marked as reviewed by angorya (Author).
-
PR: https://git.openjdk.org/jfx/pull/923
The root problem is actually broader than stated in the JBS issue. This PR now
translates screencoordinates from absolute coordinates into coordinates that
take the platformScale into account.
The whole process is complicated by the fact that throughout our code, we use
e.g. `x` and `y`
Updating last modified year in copyright header of the files that were modified
during year 2022.
-
Commit messages:
- copyright header year update
Changes: https://git.openjdk.org/jfx/pull/923/files
Webrev: https://webrevs.openjdk.org/?repo=jfx=923=00
Issue:
On Wed, 19 Oct 2022 14:55:40 GMT, Johan Vos wrote:
> Update JavaFX 17 release version to 17.0.6
> Fix for JDK-8295660
This pull request has now been integrated.
Changeset: 32fd4dec
Author:Johan Vos
URL:
https://git.openjdk.org/jfx17u/commit/32fd4dec86dc8862fd1b4ba03d75a34dbf4d7494
On Wed, 19 Oct 2022 15:02:42 GMT, Johan Vos wrote:
> update javaFX release version to 11.0.18
> Fix for JDK-8295659
This pull request has now been integrated.
Changeset: 8e1d7fe0
Author:Johan Vos
URL:
https://git.openjdk.org/jfx11u/commit/8e1d7fe0f96999db95deb82c4575131338b2bfd4
Hi!
Apologizes if this is not the proper list to ask my question.
For context: we are using the WebView of JavaFX in our legacy swing
based frontend application. For now that is the only component we are
using but we might migrate completely at a later point in time.
I have an issue with
On Mon, 17 Oct 2022 14:02:52 GMT, Lukasz Kostyra wrote:
> This change removes runFinalization calls in ImagePool::pruneCache method.
>
> Finalizers are deprecated in JDK 18 and will be removed soon.
This pull request has now been integrated.
Changeset: 91e1a278
Author:Lukasz Kostyra
26 matches
Mail list logo
