> this is Java code after all, why would all Java classes for a
platform be platform specific?
There absolutely CAN be such things as platform-specific Java classes in
code that ports to a platform.
OpenJDK is littered with subdirectories named "windows" and "linux" etc.
And it takes great car
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 a
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.
Thoma
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?
-T
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 artifac
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 co
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 :
Thomas:
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: https://git.openjdk.org/jfx17u/pull/86/
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 ar
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 si
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 10:
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 p
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 t
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 dis
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 fa
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` without
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&pr=923&range=00
Issue: https://bu
23 matches
Mail list logo