Did someone mention my name ?
Implementing FX printing on top of 2D printing was always a pragmatic
way of delivering in FX 8.
Never something that was done because we wanted to for any reason.
A new native implementation will still cost the same amount of work that
we put off in JDK 8.
So
That's an interesting idea, although splitting it up to the degree you
listed below would be unwieldy at best and likely unworkable (due to
split package issues and interdependencies). It also would be wrong to
create any implementation modules unless they are 100% hidden from the
application
Hi,
Well I looked a bit closer now and the situation and you are right. I
think need to do that one by one.
I think getting rid of HostServices::showDocument is quite easy as the
code in Java-AWT is just 1 JNI-Method so copying that to OpenJFX should
be fairly easy.
Now on the printing
As noted in the thread you quoted below, removing the dependency on
java.desktop from javafx.base isn't a particularly hard problem, and is
tracked by JDK-8240844 [1]. And even though it will require a spec
change (meaning a CSR), it doesn't result in any loss of functionality,
since in order
I would also be surprised if printing and bean adapters are used much, but
what are the options? Rewrite the printing implementation.
On Tue, May 18, 2021 at 8:45 PM Tom Schindl
wrote:
> Uff - I'd like to revisit this topic. As I did some jlink stuff for our
> applications adding java.desktop
Uff - I'd like to revisit this topic. As I did some jlink stuff for our
applications adding java.desktop once more bugged me.
I guess the first thing to do is to file a JIRA-Ticket but it really
starts to bug me to include java.desktop although I don't plan to use
printing (and I guess > 90%
On 27.03.18 14:26, Kevin Rushforth wrote:
> Hi Tom,
>
> Yes, this is an unfortunate dependency. It is "only" an implementation
> dependency, meaning that nothing in the public API depends on
> java.desktop (which is why we don't "requires transient java.desktop"),
> so it should be possible to
Hi Tom,
Yes, this is an unfortunate dependency. It is "only" an implementation
dependency, meaning that nothing in the public API depends on
java.desktop (which is why we don't "requires transient java.desktop"),
so it should be possible to remove this dependency in the future. As
noted, it
Hi,
Anyone else has an opinion on that? Is require static the way to go?
Tom
On 21.03.18 23:23, Tom Schindl wrote:
> Hi,
>
> I always thought the JavaFX-Codebase should be able to run with just the
> java.base module but I was browsing the codebase a bit and was suprised
> (or rather shocked)
Hi,
I always thought the JavaFX-Codebase should be able to run with just the
java.base module but I was browsing the codebase a bit and was suprised
(or rather shocked) that even the base-module requires java.desktop.
If I get it correct this because of the java.beans (provided by the
adapters)
10 matches
Mail list logo
