Sorry for the delay.
I tested a bit around, unfortunately this bug doesn't happen all the
time.
It looks like it can also happen when disconnecting just one screen.
I have filed a ticket: https://bugs.openjdk.java.net/browse/JDK-8283401
Also one time the JVM crashed, leaving a hs
art can also be done in your fork.
-- Marius
Gesendet: Montag, 21. Februar 2022 um 14:21 Uhr
Von: "Jeanette Winzenburg"
An: "Marius Hanl"
Cc: "openjfx-dev"
Betreff: Re: Aw: Sneak preview: cell edit api to support
commit-on-focusLost
hmm .. y
hmm .. yeah, will do .. once it's less sneak and less pre ;) Still fighting ..
Though not entirely certain how to work with the sandbox: technically,
that would be fork the sandbox, create a branch, merge my changes into
that branch and push?
And not sure how that would be simpler for oth
Can you may create a branch at the jfx sandbox repo?
https://github.com/openjdk/jfx-sandbox
Then I can more easily compare and check it out. (and monitor it :))
-- Marius
Gesendet: Freitag, 11. Februar 2022 um 18:03 Uhr
Von: "Jeanette Winzenburg"
An: "openjfx-dev"
Betr
Zitat von Marius Hanl :
I think I had the same issues some days ago. What helped was to delete all
the 'build' or 'target' or 'out' folders - so basically all the folders
with the compiled files.
thanks for the suggestion - didn't help, unfortunately
wondering what is "javafx.graphics@19-in
I think I had the same issues some days ago. What helped was to delete
all the 'build' or 'target' or 'out' folders - so basically all the
folders with the compiled files.
Gesendet: Dienstag, 18. Januar 2022 um 15:46 Uhr
Von: "Jeanette Winzenburg"
An: "openjfx-dev"
Betreff:
I like this idea.
Pretty sure some listener I wrote won't handle a permutation correctly.
I may have one question: Is there something that needs to be done in
case of an update (wasUpdated)?
-- Marius
Gesendet: Mittwoch, 20. Oktober 2021 um 21:07 Uhr
Von: "Michael Strau�"
By the time it is rendered, it will be transformed into the scaled
space. So the actual coordinate in screen space will be 13.
-- Kevin
On 10/1/2021 7:26 AM, Marius Hanl wrote:
Thanks for your answer.
Then one more question: How is a non-integer value rendered then?
Say we have snapped x value
Thanks for your answer.
Then one more question: How is a non-integer value rendered then?
Say we have snapped x value of 10.4 (scale 1.25). As we can just render
on a whole pixel, what will happen?
- Marius
Gesendet: Dienstag, 28. September 2021 um 01:57 Uhr
Von: "Kevin Rus
It would be very helpful if you could provide a minimum reproducable
example. So really just the code which is necessary for all of us to
reproduce it.
Am 29.09.21, 00:06 schrieb Alessandro Parisi
:
Can we have a look at this report please?
I'm having this issue more and
I want to see this as well.
Do we want to continue creating a draft for this?
Am 23.08.21, 01:48 schrieb Nir Lisker :
Getting this moving again as well.
> Another option could be to mirror the `Color` API in both `Border`
and
> `Background`, like in the following exam
Hi Ben,
Thank you. That does indeed reproduce the problem for me on the 100th
iteration. I've attached your test program to the bug report.
-- Kevin
On 2/13/2020 11:22 PM, Peter, Benjamin wrote:
Hello Kevin,
sure, will do :-).
BEGIN
import java.util.List;
import java.util.conc
Hello Kevin,
sure, will do :-).
BEGIN
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;
import javafx.application.Application;
import javafx.application.Platform;
import javafx.beans.property.SimpleStringProperty;
import javafx.beans.property.StringProperty;
im
Just add the OpenJDK to
Window->Preferences->Java->Installed JREs (you can make it the default)
See also:
https://stackoverflow.com/questions/15099530/how-to-change-default-jre-for-all-eclipse-workspaces[https://deref-web-02.de/mail/client/-nLC318xNiM/dereferrer/?redirectUrl=https%3A%2F%2Fstac
Kevin Rushforth"
An: "marcel Austenfeld"
Cc: openjfx-dev@openjdk.java.net
Betreff: Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then cal
Thanks.
-- Kevin
On 10/5/2018 12:10 AM, marcel Austenfeld wrote:
I created a bug report on https://bugs.java.com/
Bug ID is: 9057517
*Gesendet:* Donnerstag, 04. Oktober 2018 um 16:13 Uhr
*Von:* "Kevin Rushforth"
*An:* "marcel Austenfeld"
*Cc:* openjfx-dev@openjdk.java.n
Bug (now ID is: 8211754) can be found here:
https://bugs.java.com/view_bug.do?bug_id=8211754
Gesendet: Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von: "Kevin Rushforth"
An: "marcel Austenfeld"
Cc: openjfx-dev@openjdk.java.net
Betreff: Re: Aw: Re: "Toolkit alread
.home$/lib/javafx-swt.jar,
This worked for years and even now (with the exception of the classloader bug
analyzed by Kevin)
Gesendet: Freitag, 05. Oktober 2018 um 09:27 Uhr
Von: "Tom Schindl"
An: open
Betreff: Re: Aw: Re: Re: "Toolkit already initialized" error with Open
Gesendet:* Donnerstag, 04. Oktober 2018 um 16:44 Uhr
> *Von:* "Tom Schindl"
> *An:* openjfx-dev@openjdk.java.net
> *Betreff:* Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
> Hi,
>
> Just to make sure I understand. Do you say that other OSGi-
I created a bug report on https://bugs.java.com/
Bug ID is: 9057517
Gesendet: Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von: "Kevin Rushforth"
An: "marcel Austenfeld"
Cc: openjfx-dev@openjdk.java.net
Betreff: Re: Aw: Re: "Toolkit already initialized" error
Kevin Rushforth"
An: "marcel Austenfeld"
Cc: openjfx-dev@openjdk.java.net
Betreff: Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then cal
Hi,
Just to make sure I understand. Do you say that other OSGi-Bundles bring
with them their own FXCanvas?
I've been looking at the e(fx)clipse code [1] who deals with FXCanvas,
... but I can't think of a situation where we create multiple classloaders.
Tom
[1]
https://github.com/eclipse/efxcli
Hi,
FXCanvas should not be loaded multiple times. This sounds like a severe
bug in e(fx)clipse OSGi-Adapterhooks.
Tom
On 04.10.18 16:13, Kevin Rushforth wrote:
> I think I see what caused this. In FX 8 we called FXCanvas::initFx from
> the constructor of every FXCanvas. It then called an interna
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then called an internal startup
method, PlatformImpl::startup, that permits calling it when the Toolkit
is already initialized, turning it into a runLater if it is. As part of
the refac
Hello Kevin,
I still have problems with the error: "java.lang.IllegalStateException: Toolkit
already initialized".
However I found out that this error only occurs if I call SWT FXCanvas classes
located in different Eclipse plugins.
I can create multiple JavaFX canvas if they are located in
Good to know about the time frame. Yes, we are looking at backporting
GTK 3 support to JDK 8.
-- Kevin
On 7/12/2018 12:47 AM, Tom Schindl wrote:
Hi,
There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT
Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will
b
Hi,
There's a now a defined EOL for SWT-Gtk2 announced [1]. The last SWT
Release supporting Gtk2 is 2018-09! Starting with 2018-12 SWT there will
be no more Gtk2 support!
Tom
[1]https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15783.html
On 06.06.18 11:12, Tom Schindl wrote:
>
Hi,
Yes. FXCanvas from JavaFX8 won't work anymore once SWT-Gtk2 is gone.
The discussion on this currently happens at [platform-dev] mailing list
- see https://dev.eclipse.org/mhonarc/lists/platform-dev/ - There's no
timeframe mentionned yet by the SWT-Team but sooner or later that will
happen.
T
+1
I‘d too like to see some (coordinated) movement in the JavaFX area.
Greetings & have a nice weekend,
Thorsten
Von: John-Val Rose
Gesendet: Sonntag, 24. September 2017 12:43
An: Mark Fortner
Cc: Nir Lisker; openjfx-dev@openjdk.java.net Mailing
Betreff: Re: OpenJFX initiative
Hi Mark,
I didn'
Hello,
from our perspective as business application developers we would love to see:
1) CSS performance improvements
2) TableView and TreeTableView improvements - especially a cell spanning
feature would be most helpful to create better tree tables
Thanks,
Christoph
-Ursprüngliche Nachric
>> […] or even package scenebuilder as single jar and host it on maven central
>> in the future
that is an interesting idea, Benjamin: self-executable, versioned JARs on Maven
Central, incl. POM with build definitions.
Unfortunately, Maven is lacking a scope "DEV" as in "NPM --save-dev"
Hi Johan,
if you provided a hyperlink into the tagged OpenJdk source path repository for
both your builds “8.0.0.0” and “8.1.0.0”, I could help you analyzing the DIFF
as a community effort.
Sometimes it is just a partially defined XML “pretty print” instruction.
Hopefully it is not an internal
On 1/14/16 8:09 PM, Jim Graham wrote:
> How often are listeners added and removed? It might make more sense to
> make them copy-on-write instead...?
That is a good point. As far as I can see, every window adds a stage listener
when it is shown and removes it if it is closed. Every scene adds/rem
2 PM
To: Guru Hb
Cc: openjfx-dev@openjdk.java.net
Subject: AW: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low
Hello Guru,
I've tested it with 8u51 32bit, 8u60 32bit and 8u65 32bit using windows 7 64bit
where I can reproduce this every time against our test server.
Indeed it
Hello Guru,
I've tested it with 8u51 32bit, 8u60 32bit and 8u65 32bit using windows 7 64bit
where I can reproduce this every time against our test server.
Indeed it doesn't happen with 8u65 64bit and 8u66 64bit on windows 7 64bit.
I've not checked other 64bit JREs but can do so if wished.
Mac O
Okay, I think I slowly start to see how this will be working. But the logic
within the Behaviors won't go away or be moved, am I seeing this correct?
Maybe I should start with the viewpoint from which I'm looking at it.
The Behaviors contain logic at the moment, various functions that are used
by
> The intention is to move many JavaFX control skins into the appropriate
> public package, most probably javafx.scene.control.skin. There is no
> intention to also move the related behavior classes, since these will
> be handled separately as part of Project Two below.
>
> ...
>
> Project Two: Imp
Ah yep, that looks like it.
Cheers,
Rob
Thanks Martin, I'll try to reproduce it in a simple example and file a bug.
Cheers,
Rob
-Ursprüngliche Nachricht-
Von: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von
Martin Sladecek
Gesendet: Donnerstag, 28. August 2014 09:40
An: openjfx-dev@openjdk.java.net
Bet
Well suppose I have a Rectangle with a size of 100x100 and stroke-width of 1,
and I apply a scale transform to zoom in to 150%.
Then I would like to see a size of 150x150 pixels and still see a sharp border
stroke, let's say with a width of 2 pixels.
I'm not sure how I could apply a snapping tr
Hi Felipe,
I've added the results from the DirectWrite 'Hello World' sample to the image:
http://i.imgur.com/CGyckge.png
Is this supposed to be the benchmark for how black text should look? In my
opinion the text in Chrome / Firefox / Eclipse is a lot clearer and sharper
when viewed at 100%.
For a source jar/zip I added the following top-level task to my build.gradle
file:
task jfxrtSources(type: Zip) {
group = "Basic";
description = "Packs all sources for jfxrt.jar into a zip file";
archiveName = "build/javafx-src.zip";
includeEmptyDirs = false;
Hi August,
We've done a few tests with Autodesk's FBX converter. Unfortunately we've found
no conversion process where our sample model survives 100% intact.
Here are some examples (using Autodesk's FBX converter *and* viewer, and one of
the sample files provided with it, "Bird_Leg.fbx"):
FBX
48 matches
Mail list logo
