Re: JDK-8091393: Observable collections for ObservableMap views
Hi,
Well the binary compat IMHO is not a problem. If your subtype overwrites
the return type of a method the compiler will inserts a bridge method:
Take this example
package bla;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
public class Test {
public interface IB {
public Collection get();
}
public interface I extends IB {
public List get();
}
public class C implements I {
public ArrayList get() {
return new ArrayList();
}
}
}
if you look at C with javap you'll notice
Compiled from "Test.java"
public class bla.Test$C implements bla.Test$I {
final bla.Test this$0;
public bla.Test$C(bla.Test);
public java.util.ArrayList get();
public java.util.Collection get();
public java.util.List get();
}
The problem is more that if someone directly implemented ObservableMap
him/her self that it won't compile anymore. So it is a source
incompatible change.
Tom
Am 30.05.22 um 08:58 schrieb John Hendrikx:
It's not binary compatible, as changing the return type results in a new
method that compiled code won't be able to find.
See also "change result type (including void)" here:
https://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interfaces_-_API_methods
--John
On 30/05/2022 03:22, Nir Lisker wrote:
Hi,
Picking up an old issue, JDK-8091393 [1], I went ahead and looked at the
work needed to implement it.
keySet() and entrySet() can both be made to return ObservableSet rather
easily. values() will probably require an ObservableCollection type.
Before discussing these details, my question is: is it backwards
compatible
to require that these methods now return a more refined type? I think
that
it will break implementations of ObservableMap out in the wild if it
overrides these methods in Map. What is the assessment here?
https://bugs.openjdk.java.net/browse/JDK-8091393
Re: RFR: 8274771: Map, FlatMap and OrElse fluent bindings for ObservableValue [v11]
On Fri, 18 Mar 2022 10:32:36 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>> This was based on https://github.com/openjdk/jfx/pull/434 but with a smaller
>> API footprint. Compared to the PoC this is lacking public API for
>> subscriptions, and does not include `orElseGet` or the `conditionOn`
>> conditional mapping.
>>
>> **Flexible Mappings**
>> Map the contents of a property any way you like with `map`, or map nested
>> properties with `flatMap`.
>>
>> **Lazy**
>> The bindings created are lazy, which means they are always _invalid_ when
>> not themselves observed. This allows for easier garbage collection (once the
>> last observer is removed, a chain of bindings will stop observing their
>> parents) and less listener management when dealing with nested properties.
>> Furthermore, this allows inclusion of such bindings in classes such as
>> `Node` without listeners being created when the binding itself is not used
>> (this would allow for the inclusion of a `treeShowingProperty` in `Node`
>> without creating excessive listeners, see this fix I did in an earlier PR:
>> https://github.com/openjdk/jfx/pull/185)
>>
>> **Null Safe**
>> The `map` and `flatMap` methods are skipped, similar to `java.util.Optional`
>> when the value they would be mapping is `null`. This makes mapping nested
>> properties with `flatMap` trivial as the `null` case does not need to be
>> taken into account in a chain like this:
>> `node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty)`.
>> Instead a default can be provided with `orElse`.
>>
>> Some examples:
>>
>> void mapProperty() {
>> // Standard JavaFX:
>> label.textProperty().bind(Bindings.createStringBinding(() ->
>> text.getValueSafe().toUpperCase(), text));
>>
>> // Fluent: much more compact, no need to handle null
>> label.textProperty().bind(text.map(String::toUpperCase));
>> }
>>
>> void calculateCharactersLeft() {
>> // Standard JavaFX:
>>
>> label.textProperty().bind(text.length().negate().add(100).asString().concat("
>> characters left"));
>>
>> // Fluent: slightly more compact and more clear (no negate needed)
>> label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() +
>> " characters left"));
>> }
>>
>> void mapNestedValue() {
>> // Standard JavaFX:
>> label.textProperty().bind(Bindings.createStringBinding(
>> () -> employee.get() == null ? ""
>> : employee.get().getCompany() == null ? ""
>> : employee.get().getCompany().getName(),
>> employee
>> ));
>>
>> // Fluent: no need to handle nulls everywhere
>> label.textProperty().bind(
>> employee.map(Employee::getCompany)
>> .map(Company::getName)
>> .orElse("")
>> );
>> }
>>
>> void mapNestedProperty() {
>> // Standard JavaFX:
>> label.textProperty().bind(
>> Bindings.when(Bindings.selectBoolean(label.sceneProperty(),
>> "window", "showing"))
>> .then("Visible")
>> .otherwise("Not Visible")
>> );
>>
>> // Fluent: type safe
>> label.textProperty().bind(label.sceneProperty()
>> .flatMap(Scene::windowProperty)
>> .flatMap(Window::showingProperty)
>> .orElse(false)
>> .map(showing -> showing ? "Visible" : "Not Visible")
>> );
>> }
>>
>> Note that this is based on ideas in ReactFX and my own experiments in
>> https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion
>> that this is much better directly integrated into JavaFX, and I'm hoping
>> this proof of concept will be able to move such an effort forward.
>
> John Hendrikx has updated the pull request incrementally with five additional
> commits since the last revision:
>
> - Reword flat map docs a bit and fixed a link
> - Add missing javadoc tags
> - Clean up docs in Subscription
> - Fix code blocks
> - Add line feed at last line where it was missing
modules/javafx.base/src/main/java/com/sun/javafx/binding/Subscription.java line
57:
> 55: * Cancels this subscription.
> 56: */
> 57: void unsubscribe();
to me `unsubscribe` feels not natural, I'm not unsubscribing a `Subscription`
but I'm eg disposing it, hence to me `dispose` would feel better but I'm not a
native speaker.
Another pattern I see often is that I store a subscription in a field and
recreate it under certain conditions:
private Subscription mySubscription;
void refresh() {
if( this.mySubscription != null ) {
this.mySubscription.dispos();
}
this.mySubscription =
}
if Subscription would provide
```java
static void dispose(Subscription subscription) {
if( su
Re: Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale
ok answering my own question it is quite simple using setFitWidth/setFitHeight already today. ImageView renderingView renderingView.setFitWidth(width / scaleFactor); renderingView.setFitHeight(height / scaleFactor); I already tested that before sending out this mail but unfortunately it did not work because I had a reflection effect on the parent node and it took the whole day to track down that I run a bug with the Reflection-Effect I documented at [1]. Tom [1] https://bugs.openjdk.java.net/browse/JDK-8278170 Am 02.12.21 um 11:35 schrieb Tom Schindl: Hi, I'm try to get a HiDPI-Image produced by an external application into JavaFX using WritableImage. In the end the situation is comparable to what you get today when loading an image from an URL (eg sam...@2.png) where JavaFX sets the appropriate image pixelScale on "com.sun.prism.Image". If I'm not completely mistaken I would need an new API on PixelBuffer to containing the pixelScale who is used QuantumImage to create an appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 because I fed in a HiDPI-Image already. Before filing an ehancement I wanted to bring this up here because maybe I'm missing something obvious or maybe my proposal makes totally no sense. Tom
Proposal for Enhancement to PixelBuffer/WritableImage to support pixelScale
Hi, I'm try to get a HiDPI-Image produced by an external application into JavaFX using WritableImage. In the end the situation is comparable to what you get today when loading an image from an URL (eg sam...@2.png) where JavaFX sets the appropriate image pixelScale on "com.sun.prism.Image". If I'm not completely mistaken I would need an new API on PixelBuffer to containing the pixelScale who is used QuantumImage to create an appropriate "com.sun.prism.Image" who has eg the pixelScale = 2.0 because I fed in a HiDPI-Image already. Before filing an ehancement I wanted to bring this up here because maybe I'm missing something obvious or maybe my proposal makes totally no sense. Tom
Re: RFR: 8197991: Selecting many items in a TableView is very slow
On Thu, 18 Nov 2021 00:55:18 GMT, Nir Lisker wrote: >> This work improves the performance of `MultipleSelectionModel` over large >> data sets by caching some values and avoiding unnecessary calls to >> `SelectedIndicesList#size`. It further improves the performance by reducing >> the number of iterations required to find the index of an element in the >> BitSet. >> >> The work is based on [an abandoned >> patch](https://github.com/openjdk/jfx/pull/127) submitted by @yososs >> >> There are currently 2 manual tests for this fix. > > modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ReadOnlyUnbackedObservableList.java > line 119: > >> 117: Object obj = get(i); >> 118: if (o.equals(obj)) return i; >> 119: } > > An alternative is > > return IntStream.range(0, size()) > .filter(i -> o.equals(get(i))) > .findFirst() > .orElse(-1); > > I don't know if it helps. the for-loop is certainly faster and would allocate less memory - i find the `for(int i = 0, max = size())`-style a bit odd - PR: https://git.openjdk.java.net/jfx/pull/673
Re: Bidirectional binding enhancement
Hi, We had something very similar in Eclipse-Databinding so I think something like that makes a lot of sense but I wonder how you want to implement this FOCUS, ACTION. Another thing we had was a delayed-Observable where the sync only happened if there hasn't been a change with a user specified timeout which fairly nice to implement undo/redo like stuff eg in TextAreas. As you don't have access to Node in javafx.base I'm not sure how you want to implement the trigger stuff. Just in case in Eclipse-Databinding world we had stuff like this in a module (in this case OSGi-Bundle) who has access to both the core-API and the ui-API. Tom Am 10.11.21 um 06:45 schrieb Michael Strauß: JavaFX developers routinely use programming patterns like MVC, MVP, or MVVM to separate views from their associated business logic. Bindings can be used to connect the values of UI controls (like Label or TextField) to properties on a business logic class. A typical (simplified) scenario may look like this: var valueField = new TextField(); valueField.textProperty().bindBidirectional(businessLogic.valueProperty()); The business logic class may perform data validation or other actions on the value that was entered in the TextField. However, in many cases, it is neither necessary nor desirable for the binding to update the business-layer property on every single change (i.e. every single character that was typed by a user). For example, if a business rule verifies that the data entered by a user is formatted in a specific way, it's usually not a great experience to yield a validation error before the user has finished typing. Instead, it's often better to wait until the user has significantly interacted with a UI control before running business logic. For this reason, I propose to add a new type of binding to the javafx.beans.binding.Bindings class: void bindBidirectional(Property target, Property source, UpdateSourceTrigger trigger) UpdateSourceTrigger is an enumeration that allows developers to specify the condition on which changes of the target property will update the source property. Its values are: DEFAULT: Updates the source property on every change (this is the default behavior of bidirectional bindings). FOCUS: Updates the source property when the UI control loses input focus. ACTION: Updates the source property when the UI control loses input focus or when it receives an ActionEvent (in the case of TextField, this corresponds to the ENTER key). Note that this setting only applies to changes of the target property. When the source property is changed instead, the target property is always immediately updated. Any feedback on this proposal is appreciated. -- Tom Schindl - CTO BestSolution.at EDV Systemhaus GmbH Salurner Straße 15, A-6020 Innsbruck Phone: ++43 (0)512 935834 http://www.BestSolution.at - http://efxclipse.org
Re: RFR: 8273969: Memory Leak on the Lambda provided to Platform.startup
On Sun, 19 Sep 2021 15:58:24 GMT, Florian Kirmaier wrote: > For the strange reason, why i haven't used a lambda for the test, I've > created another ticket: https://bugs.openjdk.java.net/browse/JDK-8273970 I dpn't think this is a bug - none capturing lambdas are instantiated once and you reuse that instance for all time - the JLS allows this https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.27.4 - PR: https://git.openjdk.java.net/jfx/pull/626
Re: Enhancements for JavaFX 18
I have not looked at the code yet but why does this have to be part of OpenJFX and can not be implemented as an external library? Tom Am 05.08.21 um 00:25 schrieb John Hendrikx: Perhaps: Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434 It was received well I think, and there was some interest from Nir Lisker to work on a proposal. --John On 30/07/2021 14:56, Kevin Rushforth wrote: Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. Specifically, I'd like to see the following proceed: * Transparent backgrounds in WebView JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 PR: https://github.com/openjdk/jfx/pull/563 * Add DirectionalLight JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 PR: https://github.com/openjdk/jfx/pull/548 * CSS pseudoclasses :focus-visible and :focus-within https://bugs.openjdk.java.net/browse/JDK-8268225 PR: https://github.com/openjdk/jfx/pull/475 * Improve property system to facilitate correct usage (minus the binary incompatible API change) JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 PR: https://github.com/openjdk/jfx/pull/590 (Draft) And maybe the following: * Add CSS themes as a first-class concept (need a consensus on how to proceed) * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) There are probably others I'm forgetting. Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. -- Kevin -- Tom Schindl - CTO BestSolution.at EDV Systemhaus GmbH Salurner Straße 15, A-6020 Innsbruck Phone: ++43 (0)512 935834 http://www.BestSolution.at - http://efxclipse.org
Improving/Enhancing Accessibility Support on Windows
Hi, I'd like to inform you that we (BestSolution.at) are currently partnering with another company (dvhaus.de) to allow JavaFX applications leverage the complete Window UI Automation API for OpenJFX applications *running on Windows*. The main target of our work is to provide best accessibility support for the Canvas-Node, which is used by our partner company to implement a comprehensive text editor. I don't want to go too deep into the topic, but we explicitly decided: a) not to implement the support into the current cross-platform accessibility API b) provide 100% UI Automation support (ruling out a cross-platform API for now) Of course we know that we are relying on internals and undocumented APIs to intercept the OpenJFX Accessibility API calls and take over control if requested. Long story short - the sources are available at https://github.com/BestSolution-at/openfx-uia Tom Schindl BestSolution.at EDV Systemhaus GmbH
Re: Java FX dark theme
Hi, As the picture did not made it through i can only guess that we talk about the window trim who is controlled by the OS and so JavaFX has no control how it is drawn. So the „solution“ is to use a StageStyle.UNDECORATED and draw a trim with min/max/close yourself, implement window resizer,... I‘ve put the word solution in quotes because once you do that you loose many native festures like snapping to other windows or desktop edges. I gave a talk last year where i talk a bit about this stuff - https://m.youtube.com/watch?v=NusKg2ZWnrg the stuff you are interested in starts around minute 9:20 Tom Von meinem iPhone gesendet > Am 24.07.2021 um 18:14 schrieb Davide Perini : > > Hi all, > I am using some CSS rules to create a "dark theme". > > Is it possible to change the color of the window? > > > > As you can see in this picture I have a dark theme but the window border is > white. can I change that color? > > Thank you. > Davide
Re: Moving src.zip out of the lib directory of the JavaFX SDK
well I can push a new release in a few days if I know your final decision? You proposed option 1 and to me that sounds fine to me. Tom Am 24.06.21 um 20:22 schrieb Kevin Rushforth: Since it seems that this change will cause Eclipse to not find the sources without changes on their part (see Tom's message), and might not be as important any more for Netbeans users, it's less clear to me that we should make this change. Netbeans users who download and use the JavaFX SDK can already use the documented workaround of adding the individual jar files rather than the entire lib directory to the module path. Anyone feel strongly that we should still do this? -- Kevin On 6/24/2021 2:37 AM, Ty Young wrote: Netbeans no longer defaults to creating Ant based projects unlike years ago & there has been, IIRC, some talk on further retiring support for it and Maven works just fine provided that you use the JavaFX Maven plugin*. Still maybe worth fixing since support isn't completely removed and there may be cases where one might want to download and use a JavaFX SDK dist. * the situation with IDE JavaFX support is complicated due to a project created outside Netbeans not set up with hacks Netbeans needs for green run button but there is an in-IDE option to do javafx:run and intellij needs a custom run action created to do javafx:run AFAIK, but I digress. On 6/14/2021 1:15 PM, Kevin Rushforth wrote: We deliver a set of modular jars in the lib directory of the standalone JavaFX SDK. We also deliver src.zip for use by IDEs into that same directory. If you add the lib directory to your application's module path in your IDE, it will try to load src.zip as if it were a jar file, and will fail. This is a pain point for developers using the SDK. This problem has been raised on the mailing list a couple of times, and I think it's time to fix it. This issue is tracked in JBS by JDK-8258499 [1]. I propose to move the src.zip file from the lib directory to the top directory of the SDK. Alternatively, we could create a new directory for src.zip (either a sibling of lib or sub-directory under lib). However, I think it would be easier to find in the top dir of the SDK, and I don't see the need for a new directory just to hold src.zip. Before I create the PR and the associated CSR, I'd like to hear developer's opinions on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8258499
Re: Moving src.zip out of the lib directory of the JavaFX SDK
well I guess eclipse users won't see the sources anymore if they are moved, as we expect the src.zip next to the jar file [1] if I read my code appropriately. I filed [2] to adapt our code Tom [1] https://github.com/eclipse-efx/efxclipse-eclipse/blob/master/bundles/tooling/org.eclipse.fx.ide.jdt.core/src/org/eclipse/fx/ide/jdt/core/internal/BuildPathSupport.java#L80 [2] https://github.com/eclipse-efx/efxclipse-eclipse/issues/85 Am 23.06.21 um 15:50 schrieb Kevin Rushforth: Are there any IDE users who are currently having problems as a result of this? If not, I'll retarget this for a future release. -- Kevin On 6/14/2021 1:15 PM, Kevin Rushforth wrote: We deliver a set of modular jars in the lib directory of the standalone JavaFX SDK. We also deliver src.zip for use by IDEs into that same directory. If you add the lib directory to your application's module path in your IDE, it will try to load src.zip as if it were a jar file, and will fail. This is a pain point for developers using the SDK. This problem has been raised on the mailing list a couple of times, and I think it's time to fix it. This issue is tracked in JBS by JDK-8258499 [1]. I propose to move the src.zip file from the lib directory to the top directory of the SDK. Alternatively, we could create a new directory for src.zip (either a sibling of lib or sub-directory under lib). However, I think it would be easier to find in the top dir of the SDK, and I don't see the need for a new directory just to hold src.zip. Before I create the PR and the associated CSR, I'd like to hear developer's opinions on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8258499
Re: Support :focus-visible CSS pseudoclass
Hi, As an application developer I highly appreciate this built-in CSS support. We had to roll our own version for focus-visible and focus-within when implementing our custom controls and L&F but we would leverage this built-in support to remove complexity from our codebase. Beside Microsofts new L&F many Web-UI-Toolkits use this focus-visible-feature (and emulate it while not all browsers support it). How we use focus-visible: I think focus-visible has a fairly narrow scope so we use it to show input focus differently depending on the way an element got focused (mainly mouse-activation vs rest) How we use focus-within: We use focus-within to visiually indicate the area the focus is currently in by changing by lifting or coloring that area. Tom Am 08.06.21 um 01:08 schrieb Kevin Rushforth: I'd be interested in hearing from application developers as to whether and how they would use such a feature. As with all non-trivial features, we don't want to do it if only one or two developers are asking for it. This seems a reasonably new CSS feature; Firefox just added support in FF 85 released earlier this year and Safari still doesn't. That suggests it might be a bit early to adopt this for JavaFX. Also, one thing that isn't clear is whether there would be any user visible change using the standard themes. I presume that the answer is "no", meaning that unless your stylesheets do anything with focus-visible, it will not affect the look and feel of the app. That should be stated explicitly I also presume that there would be no application visible changes when using the standard themes, other than the presence of the two new read-only boolean properties? -- Kevin On 6/7/2021 3:46 PM, Michael Strauß wrote: I have expanded the scope of the proposal to include the :focus-within pseudo-class, which completes the set of focus-related pseudo-classes. The updated text of the proposal can be found in the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8268225 I'm looking forward to comments.
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]
On Mon, 24 May 2021 15:25:22 GMT, Martin Fox wrote: >> Martin Fox has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fixed whitespace error. > > Is there some reason you would prefer a Swing-style implementation over the > approach I submitted in this PR? The Swing code breaks down if an accelerator > calls for the Option modifier alone or in addition to Command. I'm still > investigating work-arounds. > > (Long story short, Command alters the character we receive in a good way, > providing a low-ASCII character even on non-ASCII layouts like Cyrillic. > Option alters the character in a bad way, often producing an arbitrary > symbol. Prior to macOS 10.15 we can't toss one modifier without tossing the > other short of using UCKeyTranslate.) @beldenfox I did not say that the swing version is the way to go and in the end its @kevinrushforth call what route should be taken - I just wanted to show what my initial change would have been without saying it is better than what you are proposing which sounds like is more complete than what swing provides today. - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]
On Thu, 25 Mar 2021 17:41:40 GMT, Martin Fox
wrote:
>> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as
>> expected by more accurately mapping from a Mac key code to a Java key code
>> based on the user’s active keyboard layout (the existing code assumes a US
>> QWERTY layout). The new code first identifies a set of Mac keys which can
>> produce different characters based on the user’s keyboard layout. A Mac key
>> code outside that area is processed exactly as before. For a key inside the
>> layout-sensitive area the code calls UCKeyTranslate to translate the key to
>> an unshifted ASCII character based on the active keyboard and uses that to
>> determine the Java key code.
>>
>> When performing the reverse mapping for the Robot the code first uses the
>> old QWERTY mapping to find a candidate key. If it lies in the
>> layout-sensitive area the code then scans the entire area calling
>> UCKeyTranslate until it finds a match. If the key lies outside the
>> layout-sensitive area it’s processed exactly as before.
>>
>> There are multiple duplicates of these bugs logged against Mac applications
>> built with JavaFX.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents
>> with alternative keyboard layouts
>> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z
>> accelerator is not working with French keyboard
>> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't
>> take into account azerty keyboard layout
>> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard
>> Layout (Y/Z)
>
> Martin Fox has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fixed whitespace error.
For reference this was the code I had around from my first iteration working on
that problem
diff --git a/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m
b/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m
index 38a828a41e..8657519f13 100644
--- a/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m
+++ b/modules/javafx.graphics/src/main/native-glass/mac/GlassKey.m
@@ -247,6 +247,24 @@ jint GetJavaKeyCodeFor(unsigned short keyCode)
jint GetJavaKeyCode(NSEvent *event)
{
+ NSString *chars = [event charactersIgnoringModifiers];
+
+ if ([chars length] > 0) {
+ NSInteger offset;
+
+ unichar ch = [chars characterAtIndex:0];
+ if ([[NSCharacterSet letterCharacterSet] characterIsMember:ch])
{
+ NSLog(@"Letter char");
+ unichar lower;
+ lower = tolower(ch);
+ offset = lower - 'a';
+ if (offset >= 0 && offset <= 25) {
+ NSLog(@"Hello Char it is");
+ return com_sun_glass_events_KeyEvent_VK_A +
offset;
+ }
+ }
+ }
+
return GetJavaKeyCodeFor([event keyCode]);
}
-
PR: https://git.openjdk.java.net/jfx/pull/425
Re: [External] : Re: Dependencies on java.desktop
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 story which is the real problem a fairly radical approach would be to split up javafx.graphics into multiple modules and make javafx.graphics a META-Module who provides the backward compat using "requires transitive". We would end up with: * javafx.graphics * javafx.graphics.base * javafx.graphics.print * javafx.graphics.prism.base * javafx.graphics.prism.j2d * javafx.graphics.prism.es2 * javafx.graphics.prism.d3d * javafx.graphics.glass.base * javafx.graphics.glass.win32 * javafx.graphics.glass.mac * ... I know that sounds radical but from a pure architectual point of view this would be better than optional features in javafx.graphics and would not require us to reimplement printing to get rid of java.desktop. Out of curiosity I tried that locally and it just works ;-) Tom Am 18.05.21 um 23:40 schrieb Kevin Rushforth: 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 to usefully do anything with the JavaBeanX classes requires java.desktop anyway. Removing the dependency on java.desktop from javafx.graphics is a larger issue because of printing. There is also an implementation dependency on the Desktop class to implement HostServices::showDocument that would need to be redone. And of course it depends on the above (eliminating the dependency from javafx.base) being done first. For printing we would need to do one of two things: 1. Eliminate the implementation dependency on the Java2D printing code. This is a large effort, but would preserve existing functionality. 2. Make the JavaFX Printing function "optional" (i.e., make it a "ConditionalFeature"), such that if java.desktop is not present, printing doesn't work (all of the printing APIs would throw an UnsupportedOperationException if java.desktop is not available). An application that wants to do printing would need to include java.desktop. Option 1 would be my preferred approach, but as mentioned above it's a lot of work. Option 2 would need a spec change, and I'm not convinced we want to do it. If there are enough other developers who would want this, we could open it up for discussion for some future version (not JavaFX 17). Phil might have some thoughts on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8240844 On 5/18/2021 10:45 AM, Tom Schindl wrote: 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% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: 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 is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: 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) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
.classpath files for Eclipse
Hi Nir/Jeannette, As you are both using Eclipse for development I'd like to get your take on the following things. Dealing with OS specific The graphics module has to have different source folders depending on the OS you are developing on: * Windows: build/hlsl/Decora and build/hslPrism * Linux/OS-X: build/gensrc/jsl-decora build/gensrc/jsl-prism So when importing the projects Eclipse does not even build anything until you fix the .classpath file - I'd like to propose to mark those Source-Folders optional. Swing-Project - There the .classpath has a none existing "src/test/java" I wonder where that source is and if not there anymore remove the offending entry from .classpath-File BuildSrc What's the purpose of that project? The classpath is incorrect and does it have to be a Java-Project? Tom
Re: Dependencies on 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% of the JavaFX don't use the printing API either but produce PDFs or whatever) and Java-Beans. Tom Am 27.03.18 um 14:26 schrieb Kevin Rushforth: 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 is only there because Java Beans is part of the java.desktop module. In the interim, your suggestion of "requires static java.base" could be the way to go. It would need a spec change to the JavaFX beans adapter classes documenting that they would throw an UnsupportedOperationException if java.desktop was not present at runtime, along with a recommendation that applications needing that functionality should add "requires java.desktop" to their own module-info.java. Note that this would only help non-graphical JavaFX applications that use javafx.base for its collections, properties, and bindings, since javafx.graphics requires java.desktop in a way that currently cannot easily be made optional (not without reimplementing printing support anyway). -- Kevin Tom Schindl wrote: 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) that even the base-module requires java.desktop. If I get it correct this because of the java.beans (provided by the adapters) stuff is found in there. Why hasn't the requires there not defined as: requires static java.desktop; Tom
Re: Support :focus-visible CSS pseudoclass
Ok did not know that so then yes following the CSS-Spec naming make sense. Tom Am 28.04.21 um 17:24 schrieb Michael Strauß: It's certainly true that all JavaFX themes show a focus indicator for all controls, but that's not universally so. For example, Microsoft's Fluent theme doesn't show any focus indicators on mouse-based interaction except for text controls. In the end, the official CSS spec has named this pseudoclass :focus-visible, and I think JavaFX should almost always try to follow the CSS spec in this regard. Am Mi., 28. Apr. 2021 um 16:52 Uhr schrieb Tom Schindl : Hi, As someone who had to implement this manually in our current project I would welcome if it would have been possible to use a pseudo-state to get a CSS only solution. What I don't know if the name of the pseudo-State is correct :focus-visible does not sound right to me because controls still show that they are focused but less obvious. In the end in our application we turned it around and called the pseudo-state ":mouse-focused" in contrast do (keyboard-focused, programmatically focused, accessibility focused). Tom Am 28.04.21 um 16:39 schrieb Michael Strauß: Circling back to this proposal: does anyone want to comment on it?
Re: Support :focus-visible CSS pseudoclass
Hi, As someone who had to implement this manually in our current project I would welcome if it would have been possible to use a pseudo-state to get a CSS only solution. What I don't know if the name of the pseudo-State is correct :focus-visible does not sound right to me because controls still show that they are focused but less obvious. In the end in our application we turned it around and called the pseudo-state ":mouse-focused" in contrast do (keyboard-focused, programmatically focused, accessibility focused). Tom Am 28.04.21 um 16:39 schrieb Michael Strauß: Circling back to this proposal: does anyone want to comment on it?
Re: javafx-swt not deployed on maven central
Hi, So I deployed the Artifact in the meanwhile to our companies public maven repo [1] as I didn't want to pollute maven-central with javafx-swt in a different namespace. Tom [1] https://maven.bestsolution.at/releases/at/bestsolution/openjfx/javafx-swt/ Am 07.04.21 um 10:53 schrieb Tom Schindl: Hi, I'm not sure where to report this but it looks like the javafx-swt.jar is not deployed on maven central. Is there a reason? Tom
javafx-swt not deployed on maven central
Hi, I'm not sure where to report this but it looks like the javafx-swt.jar is not deployed on maven central. Is there a reason? Tom
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Mon, 15 Mar 2021 21:40:55 GMT, Martin Fox wrote: >> https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 > > On the French keyboard the digits are shifted but I assumed we would still > want those keys to map to KeyCode.0-9 as they do on Windows. My solution was > to hard-code those key positions to be digits but this interferes with Dvorak > layouts. I'm tweaking the implementation to fix this. The new approach will > be to query both the shifted and unshifted characters on a key and favor > digits and letters over everything else (and something over nothing). > > (I've been writing Mac code to enumerate all the OS keyboard layouts and > generate lists showing which Java key codes will change from the historic > implementation. It also does some sanity checking.) Maybe this is a very dumb idea but why are we not using the char to map back to the keycode? At least for everything in the ASCII-Range this would be ok not? We'd only have to check for special keys (like NUM-Keys, F-Keys, ...) first. So once we checked and the text is of length 1 we could do the mapping from the char. - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 21:12:41 GMT, Martin Fox wrote: >> I see that the Windows pre-submit test build failed. It's clearly not >> related to anything in this PR, so it can be ignored. >> >> I'll review this PR later (hopefully next week some time), but I have a >> couple general comments: >> >> 1. Would it be possible to provide an automated test? Maybe not since it is >> sensitive to the keyboard layout. >> 2. For the related bugs, we can either close them as duplicates of this bug >> or use the `/solves` command to list them here. Generally, we would do the >> former in the case it really is a single fix, as this seems to be. That's >> what I'll do once this bug is integrated unless there is a good reason not >> to. Normally we would use the earliest of the bugs, but in this case, I >> don't think it matters, so I have no problem with your using the one you >> chose. >> >> @tomsontom Since you were the one who filed >> [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's >> currently assigned to you, do you want to be the second reviewer on this? > > @kevinrushforth I have a manual app that can perform a simple test to verify > that when a robot sends KeyCode.A through KeyCode.Z the system receives the > characters 'a' to 'z'. On the Mac this sanity test was failing on German and > French keyboards prior to these changes. The test is part of a key logger app > I created. > > I chose this bug because it has a straight-forward test attached and some > recent comment activity. > > @tomsontom Could you point me to the relevant code in Swing? I'm looking at > the code but am getting lost in the layers. https://github.com/openjdk/jdk/blob/8760688d213865eaf1bd675056eb809cdae67048/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m#L462 - PR: https://git.openjdk.java.net/jfx/pull/425
Re: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z)
On Fri, 12 Mar 2021 18:57:45 GMT, Kevin Rushforth wrote: >> This PR adds code to ensure that KeyCodeCombinations match KeyEvents as >> expected by more accurately mapping from a Mac key code to a Java key code >> based on the user’s active keyboard layout (the existing code assumes a US >> QWERTY layout). The new code first identifies a set of Mac keys which can >> produce different characters based on the user’s keyboard layout. A Mac key >> code outside that area is processed exactly as before. For a key inside the >> layout-sensitive area the code calls UCKeyTranslate to translate the key to >> an unshifted ASCII character based on the active keyboard and uses that to >> determine the Java key code. >> >> When performing the reverse mapping for the Robot the code first uses the >> old QWERTY mapping to find a candidate key. If it lies in the >> layout-sensitive area the code then scans the entire area calling >> UCKeyTranslate until it finds a match. If the key lies outside the >> layout-sensitive area it’s processed exactly as before. >> >> There are multiple duplicates of these bugs logged against Mac applications >> built with JavaFX. >> >> https://bugs.openjdk.java.net/browse/JDK-8090257 Mac: Inconsistent KeyEvents >> with alternative keyboard layouts >> https://bugs.openjdk.java.net/browse/JDK-8088120 [Accelerator, Mac] CMD + Z >> accelerator is not working with French keyboard >> https://bugs.openjdk.java.net/browse/JDK-8087915 Mac: accelerator doesn't >> take into account azerty keyboard layout >> https://bugs.openjdk.java.net/browse/JDK-8150709 Mac OSX and German Keyboard >> Layout (Y/Z) > > I see that the Windows pre-submit test build failed. It's clearly not related > to anything in this PR, so it can be ignored. > > I'll review this PR later (hopefully next week some time), but I have a > couple general comments: > > 1. Would it be possible to provide an automated test? Maybe not since it is > sensitive to the keyboard layout. > 2. For the related bugs, we can either close them as duplicates of this bug > or use the `/solves` command to list them here. Generally, we would do the > former in the case it really is a single fix, as this seems to be. That's > what I'll do once this bug is integrated unless there is a good reason not > to. Normally we would use the earliest of the bugs, but in this case, I don't > think it matters, so I have no problem with your using the one you chose. > > @tomsontom Since you were the one who filed > [JDK-8150709](https://bugs.openjdk.java.net/browse/JDK-8150709), and it's > currently assigned to you, do you want to be the second reviewer on this? Sure I started looking into this last week and found the place this translation is done in swing (there it is done differently but only works for keys a-z but not for other chars like #,...) - PR: https://git.openjdk.java.net/jfx/pull/425
Re: Layering JavaFX onto an external rendering context
Hi, If I got you right you now changed your idea to render JavaFX into an PixelBuffer and integrate that into a scene renderer with Vulkan, ... . This exactly how the integration into SWT and Swing is done, the internal API for that is found in "com.sun.javafx.embed". Before we implemented DriftFX we integrated a JavaFX-Scene into our application exactly this way. For that purpose we hacked FXCanvas and published the changed code at our customers github account [1]. You see there at [2] how one fills the buffer from an offscreen scene. My gut feeling is that getting a "com.sun.javafx.embed"-API is much more likely than an DriftFX-Like-API but that just my personal opinion. Anyways our/my focus still is DriftFX and I/we are quite confident that what we have today in DriftFX is a good API where we today support JavaFX-8 to JavaFX-15 (I haven't tested 16 but I have not seen any changes going into it that would require us to change our code) Tom [1] https://github.com/eclipsesource/FXCanvas/blob/master/FXCanvas/src/javafx/embed/swt/FXCanvas.java [2] https://github.com/eclipsesource/FXCanvas/blob/master/FXCanvas/src/javafx/embed/swt/FXCanvas.java#L631 Am 07.03.21 um 16:35 schrieb Mark Raynsford: On 2021-03-07T12:22:11 + Neil C Smith wrote: Hi, A few comments from my perspective here, mainly coming from frustration at the number of times I've had to tell clients or users that JavaFX isn't a viable option for them .. On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote: there is a combinatorial explosion of possibilities with regards to which rendering API the _user_ might be using, and which rendering API JavaFX might be using (if any!). I agree that's a difficult one, but also surely not an insurmountable one?! There are precedents around Java APIs that provide querying and access to optional support on a platform by platform basis... I think it's insurmountable due to the complexity of the semantics of the thing (the GPU) that's being abstracted over. The basic primitive that would be required is "transfer this image to this other image". You'd need to expose that operation in way that would work for every possible pair of rendering APIs, including getting all of the synchronization right that lower level APIs like Vulkan and DX12 require. The complexity of handling that would need to be pushed onto each person trying to use the API. JavaFX would effectively need to know when it was safe to use an image that was being transferred in, without actually being able to know where the image was coming from or who to talk to about it. The only methods it _could_ use would involve CPU-side fences, which would then have performance implications. To clarify a bit: Let's say we lived in an ideal world and JavaFX had a Vulkan backend, and contained code that was willing to cooperate with the user's Vulkan-based rendering code. The user could tell JavaFX "here's the image to use for this node, but don't use it until this semaphore becomes available". This is generally highly efficient as a semaphore (in Vulkan terms) is a GPU-side primitive that just controls parallelism across different queue instances on the GPU, with no CPU-side interaction at all. We have no way to get to that ideal world whilst JavaFX and the user's code have no common API over which to communicate. Everything would have to go via CPU-based abstractions. Traditional stateful APIs like OpenGL make it far too easy for external code to screw up the rendering context anyway, so exposing JavaFX's own context would be a bad idea. I remain of the view that this shouldn't really be that concerning?! It's a bug in the library if it does so. It's definitely concerning. Have you worked with OpenGL much? If you're *lucky* you'll get a crash, because at least then you'll see the exact location where the mistake occured. What you'll typically get instead is corrupted rendering, a black screen, or just bad performance as the driver desperately tries to make sense of what you asked it to do, usually in completely unrelated parts of the rendering process. It's the prime reason I jumped ship to Vulkan the second it came out. :) JavaFX _does_ have a software renderer. What if we could have JavaFX work with entirely software rendering into an offscreen BufferedImage? Why BufferedImage? What about a reuse / extension / parallel of PixelBuffer? Yes indeed. I said BufferedImage just because I assumed that would be more familiar. I'd not personally care where the output went as long as I could get the raw bytes out of it in order to upload to the GPU.
Re: Eclipse problem: not compiling module projects
I setup everything from scratch a few weeks ago and all worked fine: * I first run the gradle build * then imported everything into Eclipse Tom Am 02.03.21 um 14:37 schrieb Jeanette Winzenburg: Just a quick question to Eclipse users (who do compile with Eclipse, not with gradle) Problem: updated my Eclipse to the december release yesterday, now it doesn't compile (neither automatically, nor forcing a clean build) anything as soon as the module projects are included, neither the modules nor dependent projects - nothing else changed (hopefully ;). All fine when adding the compiled module-jars. Questions: - anybody else seeing it? - any ideas where to look? -- Jeanette
Re: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice
On Fri, 29 Jan 2021 12:25:53 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/com/sun/prism/Image.java line 654:
>>
>>> 652: }
>>> 653: if (pixelScale != 1.0f) {
>>> 654: pixelaccessor = new ScaledAccessor<>(pixelaccessor,
>>> pixelScale);
>>
>> is that really correct? I think you should not overwrite/save the scaled
>> pixelAccessor in the instance variable - if I read that correct with this
>> change the following happens: if I call getPixelAccessor() 3 times I get a
>> ScaledAccessor wrapping a ScaleAccessor wrapping a ScaledAccessor, wrapping
>> one of ByteAccess, ByteRgbAccess, IntAccess
>
> No, that’s what used to happen before this fix.
>
> The fix moves the wrapping of the pixelAccessor with a ScaledPixelAxcessor
> inside the null check so it’s now only done once.
ah I missed that the lines moved up inside the first if-check
-
PR: https://git.openjdk.java.net/jfx/pull/389
Re: RFR: 8258986: getColor throws IOOBE when PixelReader reads the same pixel twice
On Fri, 29 Jan 2021 00:05:57 GMT, Kevin Rushforth wrote:
> As indicated in the JBS bug, using a `PixelReader` to read a scaled image in
> HiDPI mode, for example an `@2x` image, to read more than one pixel will read
> data from the wrong location in the image, usually leading to an IOOBE.
>
> The bug is in the `getPixelAccessor` method of Prism Image. The method
> correctly creates a new `Accessor` if one hasn't already been created, but
> then it unconditionally wraps the current `Accessor` in a
> `ScaledPixelAccessor` if the scale is > 1. So the second time this method is
> called, it created another `ScaledPixelAccessor` that wraps the first
> `ScaledPixelAccessor`, meaning that the indexes into the pixel array are
> multiplied by 4. This continues for each new call to this method.
>
> The fix is to only wrap an `Accessor` in a `ScaledPixelAccessor` the first
> time, when it is created.
>
> I added a test, which is run for both scaled and unscaled images, to ensure
> that we get the right value when reading a pixel, and that reading it a
> second time returns the same result. Without the fix, the new test will fail
> with IOOBE when the scale factor is two. Related to this, I initially
> commented out the wrapping in a `ScaledPixelAccessor` entirely, just to see
> what would happen, and none of the existing tests caught it. The new test
> will catch this.
modules/javafx.graphics/src/main/java/com/sun/prism/Image.java line 654:
> 652: }
> 653: if (pixelScale != 1.0f) {
> 654: pixelaccessor = new ScaledAccessor<>(pixelaccessor,
> pixelScale);
is that really correct? I think you should not overwrite save the scaled
pixelAccessor in the instance variable - if I read that correct with this
change the following happens: if I call getPixelAccessor() 3 times I get a
ScaledAccessor wrapping a ScaleAccessor wrapping a ScaledAccessor, wrapping one
of ByteAccess, ByteRgbAccess, IntAccess
-
PR: https://git.openjdk.java.net/jfx/pull/389
Re: Integrated: 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina
Hi Kevin, I today saw this tweet by Alex Blewitt [1] in my twitter feed and a possible fix without the de/reactivation. So I thought I would bring it up here as well. Tom [1] https://twitter.com/alblue/status/1350877893979746305 Am 07.12.20 um 16:58 schrieb Bruce Johnson: On Dec 7, 2020, at 10:33 AM, Kevin Rushforth wrote: On Wed, 2 Dec 2020 20:00:55 GMT, Kevin Rushforth wrote: This is a proposed fix for the bug where the Apple system menubar is initially non-responsive on macOS 10.15 and later after a JavaFX application has started up. The end user can workaround this by switching to some other application and then back to the JavaFX app, but there is no known workaround that the application developer can use. JavaFX is using a non-standard approach to creating the system menus, and seems likely that some change in macOS 10.15 means that this no longer works the same as in previous versions of macOS. We have had problems with application startup on macOS in the past that affected the system menubar: see [JDK-8123430](https://bugs.openjdk.java.net/browse/JDK-8123430) and [JDK-8093743](https://bugs.openjdk.java.net/browse/JDK-8093743). The solution is to deactivate and then reactivate the application after the app has initially been made active, but before any window is initialized and before the system menu is populated. I pushed this as two commits: one with the fix and one with some temporary verbose debug print statements. I will remove the print statements prior to the formal review, but wanted to leave them in for now in case someone wanted to test them, and ran into an issue (the debug print statements could help isolate any problems). I have tested this on macOS 10.14, 10.15, and 11 (Big Sur). It will need additional testing. The only drawback I see with this approach is that there can be a very brief flash when launching the JavaFX app from a terminal window as the FX application activates, deactivates, and reactivates. This pull request has now been integrated. Changeset: e7dbdfcb Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/e7dbdfcb Stats: 109 lines in 4 files changed: 94 ins; 0 del; 15 mod 8233678: [macos 10.15] System menu bar does not work initially on macOS Catalina Reviewed-by: jvos, aghaisas - PR: https://git.openjdk.java.net/jfx/pull/361 It would be useful, at least to me, to see a brief comment in this email thread about why this approach (which results in the application flashing) is necessary. Why does JavaFX require this approach, or is there an alternative, but more complex approach that could ultimately be used in later releases. I’d just like to be able to look back in the email thread when I (or the users of my software) see the flash to understand why it's there. Bruce
Re: Can't load fxml on Macos
Well, you don't give a enough information (no stacktrace, no context, ...). If you have reproducable code please share it (with the current information provided I highly doubt this is an issue in Java/JavaFX). Tom Am 20.10.20 um 12:28 schrieb Davide Perini: Hi all, this code works well on both Windows and Linux running Java 15 on JavaFX 15. FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + Constants.FXML)); return fxmlLoader.load(); It doesn't work on Macos returning a nullpointer exception. Any idea? Why Macos is always the black sheep? Thanks Davide
Re: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4]
On Wed, 7 Oct 2020 09:38:40 GMT, Jeanette Winzenburg wrote: >> The error occurs as specified in getSelectedItems(). It seems to be correct >> to write the following >> >> `listView.getItems().removeAll(new HashSet<>(selectedItems)) >> ` >> >> (or ArrayList) >> >> It could be interpreted that the intention was to mitigate the side effects >> associated with the getSelectedItems() >> specification. >> The use of BitSet should be avoided when the list is large, as it is not a >> sparse implementation and therefore wastes a >> lot of memory. For example, when removing the last item in the list. >> `BitSet bs = new BitSet(c.size()); >> ` >> The previous change was an incorrect initialization size for BitSet. > >> >> >> The error occurs as specified in getSelectedItems(). > > no, both spec and implementation (at least as far as its relation to this > issue) is correct. > >> It seems to be correct to write the following >> >> `listView.getItems().removeAll(new HashSet<>(selectedItems)) ` >> >> (or ArrayList) >> > > asking client code to adopt to changes in the framework is not an option > >> It could be interpreted that the intention was to mitigate the side effects >> associated with the getSelectedItems() >> specification. > > no side-effects, nothing mitigated, : it's a deliberate, full-fledged support > of source lists that change on removing > items from the target list >> The use of BitSet should be avoided when the list is large, as it is not a >> sparse implementation and therefore wastes a >> lot of memory. For example, when removing the last item in the list. >> `BitSet bs = new BitSet(c.size()); ` >> The previous change was an incorrect initialization size for BitSet. > > feel free to suggest another (working without requiring changes to client > code) two-pass approach in remove/retainAll. did anyone look into Java-Collection-Frameworks (ArrayList and friends or Eclipse-Collections) how they handle this situation effeciently? - PR: https://git.openjdk.java.net/jfx/pull/305
Re: Unable to import OpenJFX Build into Eclipse
Hi, Do we really use the Eclipse-Gradle-Tooling now? I think the reasons we checked in all .product/.classpath files is that this did not work in the past. At least my Eclipse install I use for OpenJFX-Development does not have the gradle-tooling installed and things work there just fine. Tom Am 16.08.20 um 21:49 schrieb Nir Lisker: Hi Andrew, I did the same setup only with Ubuntu 18, which shouldn't matter, and I don't remember having this issue. I can try redoing it next time I boot the Ubuntu partition. What looks odd is that the error references the build directory. What happens if you clean the project first? - Nir On Sat, Aug 15, 2020 at 1:55 PM Andrew Waters wrote: Hi All, I'm trying to diagnose a bug in OpenJFX that I've been struggling with on and off for almost a year(!) and I decided to build OpenJFX from source and use Eclipse to help. I've built a brand new Ubuntu 20.04.1-Desktop system with OpenJDK 14.0.1 and the latest stable OpenJFX 14. I've run the Gradle build and run the tests and all looks 100%. When importing the root directory (home/jdkdev/dev/jfx) into Eclipse using the gradle import tool (using the wrapper option as recommended) I get this build path error: Cannot nest 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main/javafx.base' inside library 'home/jdkdev/dev/jfx/modules/javafx.base/build/classes/java/main' It seems to be trying to set up a looped import to itself somehow. I've tried to edit the build path in eclipse but the fields appear to be all non-editable. Has anyone any idea as to what the problem is and how to fix it? Has anyone recently done a successful import with these latest levels? As this is the base module none of the other modules compile of course so they too may have other problems once the base module is fixed. I tried the "existing projects" import too but that just appears to have even more problems. Thanks, Andrew Waters UK.
Re: [Integrated] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
On Fri, 10 Apr 2020 10:26:06 GMT, Tom Schindl wrote: > Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 This pull request has now been integrated. Changeset: 435671ee Author: Tom Schindl Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/435671ee Stats: 74 lines in 2 files changed: 0 ins; 68 del; 6 mod 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/170
Re: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
On Tue, 28 Apr 2020 22:36:47 GMT, Kevin Rushforth wrote: >> Tom Schindl has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. >> >> Fix whitespace errors > > Looks good to me. I verified that the new test fails without your fix and > passes with your fix. > > In case anyone else is looking at this and wants to run the test, it isn't > enabled by default, so you need to run it > like this: > gradle -PUNSTABLE_TEST=true -PFULL_TEST=true -PUSE_ROBOT=true \ > :systemTests:test --tests test.robot.com.sun.glass.ui.monocle.RobotTest @kevinrushforth is there anything left todo or did you simply forget to merge it? - PR: https://git.openjdk.java.net/jfx/pull/170
Re: Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light
Hi Phil, I haven't looked too deep into that but to the "only" problem I see is how the internal lookup tree is structured in "PrismFontFactory". And yes you are right the OS/2-Table (there's even a comment in PrismFontFile mentionning usWeightClass) contains the necessary information, some mac-fonts use the header-segment so there one has to distinction but those font would be simply classified as BOLD(700). I'll put that on my opensource working queue, to look a bit deeper into that and get back with a more in depth report (and probably questions). The current in ability to use FontWeight is a real problem compared to WebUIs, and although there is a work around not using FontWeight in CSS it is very cumbersome. Tom Am 23.04.20 um 03:02 schrieb Philip Race: I was mulling over why if it is so easy we didn't do it and I suspect (haven't checked, and so long ago I can't remember off hand) that this code needed to run on top of the old Java 2D pipeline (wrongly called the Swing pipeline). And 2D did not and does not provide this functionality either. -phil. On 4/22/20, 3:40 PM, Philip Race wrote: Sadly no one is working on it. It probably is not that hard to do, the weight should be in the OS/2 table -phil On 4/22/20, 3:26 PM, Tom Schindl wrote: Hi Kevin / Phil, I'd like to start working on JDK-8090423 but before I start investing time I wanted to make sure nobody is working on that and if you have any input, ideas already how to address that problem help me not wasting time. Tom
Working on - JDK-8090423 - [Font] Support Font Weights other than Bold and Regular, like Light
Hi Kevin / Phil, I'd like to start working on JDK-8090423 but before I start investing time I wanted to make sure nobody is working on that and if you have any input, ideas already how to address that problem help me not wasting time. Tom
Re: White box / window flicker upon launch
yes I do but I think this is by nature:
a) you use CSS so only after the first CSS-Pass the color could be set
appropriately, this CSS pass could happen after the Native-Window is
shown
=> you can mitigate that a bit using
root.setBackground(new Background(new BackgroundFill(Color.ORANGE,
CornerRadii.EMPTY, Insets.EMPTY)));
b) if the above gives you short flash (IMHO shorter than with CSS) and
you can see that by setting eg RED or GREEN as the Scene-Fill so then
it gets more prominent
So the flash is gone if you put the same color to Scene.setFill() as
your root-Pane but now something slightly unexpected happens. The trim
is colored slighly in your scene-color ;-)
Tom
Am 22.04.20 um 19:46 schrieb Dirk Lemmermann:
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
public class BugDemo extends Application {
public void start(Stage stage) {
VBox root = new VBox();
root.setStyle("-fx-background-color: orange;");
Scene scene = new Scene(root, 1000, 800);
stage.setScene(scene);
stage.show();
}
public static void main(String[] args) {
launch(args);
}
}
Re: [Rev 03] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
> Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors - Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/64a802ca..8fe96a90 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.03 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.02-03 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170
Re: [Rev 02] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
> Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with two additional commits since the last revision: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Fix whitespace errors - Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/2ca1c88a..64a802ca Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.02 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170
Re: [Rev 01] RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
> Extract keystate and add to the existing modifier mask, to support eg > multi-select > > https://bugs.openjdk.java.net/browse/JDK-8202296 Tom Schindl has updated the pull request incrementally with one additional commit since the last revision: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Added Test for keyboard modifiers - Changes: - all: https://git.openjdk.java.net/jfx/pull/170/files - new: https://git.openjdk.java.net/jfx/pull/170/files/79fe0fd7..2ca1c88a Webrevs: - full: https://webrevs.openjdk.java.net/jfx/170/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/170/webrev.00-01 Stats: 54 lines in 1 file changed: 54 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170
RFR: 8202296: Monocle MouseInput doesn't send keyboard modifiers in events.
Extract keystate and add to the existing modifier mask, to support eg multi-select https://bugs.openjdk.java.net/browse/JDK-8202296 - Commit messages: - 8202296: Monocle MouseInput doesn't send keyboard modifiers in events. Changes: https://git.openjdk.java.net/jfx/pull/170/files Webrev: https://webrevs.openjdk.java.net/jfx/170/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202296 Stats: 20 lines in 1 file changed: 14 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/170.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/170/head:pull/170 PR: https://git.openjdk.java.net/jfx/pull/170
Re: RFR: 8240692: Cleanup of the javafx property objects
On Fri, 6 Mar 2020 23:35:56 GMT, Nir Lisker wrote: >> I note that this also changes the wrapper property objects from anonymous >> subclasses of XPropertyBase to SimpleXProperty. This is more than >> just a readability cleanup. It's probably fine for this case, but that's why >> I want a second reviewer. > >> I note that this also changes the wrapper property objects from anonymous >> subclasses of XPropertyBase to SimpleXProperty. This is more than >> just a readability cleanup. It's probably fine for this case, but that's why >> I want a second reviewer. > > Isn't SimpleXProperty exactly made for XPropertyBase with the > built-in overrides for the bean and the name? When is this substitution not > fine? I can somehow remember asking Richard Bair why JavaFX internally does not use Simple* but creates the anonymous subclasses and he said it's memory reason - Simple* uses more memory because of the additional fields - PR: https://git.openjdk.java.net/jfx/pull/141
Re: RFR: 8240692: Cleanup of the javafx property objects
On Sat, 7 Mar 2020 00:22:59 GMT, Nir Lisker wrote: >> I can somehow remember asking Richard Bair why JavaFX internally does not >> use Simple* but creates the anonymous subclasses and he said it's memory >> reason - Simple* uses more memory because of the additional fields > > That doesn't seem right. The additional fields are captured in the > anonymous class anyway (same as in lambdas). > > On Sat, Mar 7, 2020 at 1:53 AM Tom Schindl wrote: > >> I can somehow remember asking Richard Bair why JavaFX internally does not >> use Simple* but creates the anonymous subclasses and he said it's memory >> reason - Simple* uses more memory because of the additional fields >> >> — >> You are receiving this because you were assigned. >> Reply to this email directly, view it on GitHub >> <https://github.com/openjdk/jfx/pull/141?email_source=notifications&email_token=AI5QOM5SILAYZUP3TZVCIW3RGGEHTA5CNFSM4LDJHCF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEODG4OY#issuecomment-596012603>, >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/AI5QOM2UNAZKYJUMYJSER7TRGGEHTANCNFSM4LDJHCFQ> >> . >> the subclass saves the owner field who is a static null, not? - PR: https://git.openjdk.java.net/jfx/pull/141
Re: [jfx14] [Rev 01] RFR: 8228867: Fix mistakes in FX API docs
IIRC I had filed a bugzilla a while ago at Eclipse on a javadoc Problem like
that
Tom
Von meinem iPhone gesendet
> Am 18.02.2020 um 20:09 schrieb Nir Lisker :
>
> On Tue, 18 Feb 2020 18:15:30 GMT, Kevin Rushforth wrote:
>
>>> The pull request has been updated with 2 additional commits.
>>
>> modules/javafx.base/src/main/java/javafx/collections/ListChangeListener.java
>> line 234:
>>
>>> 233: *
>>> 234: * for (Node n : change.getAddedSubList()) {
>>> 235: * // do something
>>
>> What is the problem with the existing example? It already matches our
>> preferred pattern for example code:
>>
>> * {@code
>> * sample code
>> * goes here
>> * }
>
> Oh, in Eclipse that was not rendered correctly, probably because of the
> interaction between `` and `{@code}`. Do you want me to revert?
>
> -
>
> PR: https://git.openjdk.java.net/jfx/pull/110
Re: [EXTERNAL] Explanation of different scaling factors anywhere?
I think that can not work because layouts don't take the scale factor
into account nor does stuff like ScrollView but i could be wrong.
Tom
On 27.01.20 17:29, David Grieve wrote:
> Wouldn't this just be a scale transform?
>
>> -Original Message-
>> From: openjfx-dev On Behalf Of
>> Mike Hearn
>> Sent: Monday, January 27, 2020 11:00 AM
>> To: openjfx-dev@openjdk.java.net
>> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>>
>> Hello,
>>
>> A feature I often miss when using non-web GUIs is support for browser style
>> zooming. In JavaFX it is quite easy to specify all font sizes in terms of
>> "ems",
>> relative sizes ("largest") or percentages and then adjust the base font size
>> on a
>> root node inside key handlers. This works OK but doesn't do much for images
>> or other controls, and of course most JavaFX GUI code specifies sizes in
>> terms
>> of pixels.
>>
>> There are various scaling factors applied to pixel sizes. There is the
>> per-node
>> scaling transform, but this doesn't affect layout so isn't comparable to what
>> browsers do. There's a per-screen DPI, there's a "platform scale", there's a
>> "render scale" and then there's a "ui scale".
>> These seem related to hidpi/retina support and are all internal (for the
>> purposes of this question I'm happy to modify JavaFX itself).
>>
>> Render scale seems to affect resolution without affecting positions or
>> layout,
>> so that's not quite what I want. UI scale sounds promising but isn't
>> documented and I couldn't quite figure it out by reading the code, though I
>> could just fiddle with it and see what happens.
>>
>> It feels like someone probably explored this before now. Is there a way to
>> effectively expand the size of every node without altering the size of the
>> containing viewport, to get browser-style layout affecting zoom? If not,
>> has
>> anyone explored the complexity of the modifications required?
>>
>> thanks,
>> -mike
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Add command support for actionable controls
Hi,
I see where you are coming from but IMHO JavaFX should focus on being a
Graphic and UI-Toolkit and not leak any patterns into the core API.
These are just by 2 cents so other might have another opinion.
Tom
On 21.01.20 20:59, Michael Strauß wrote:
> 1. Abstract:
> Controls that are derived from ButtonBase generally represent an operation
> that is triggered by the control.
> In many cases, the control also reflects whether the operation can
> currently be invoked (i.e. whether the control is enabled or disabled), or
> whether the operation is currently running.
> Software patterns like MVVM often encapsulate this behavior for the purpose
> of decoupling business logic from UI code.
>
>
> 2. Implementation:
> I propose adding the following interface that represents the entirety of
> such an operation:
>
> interface Command {
> ReadOnlyBooleanProperty canExecuteProperty();
> ReadOnlyBooleanProperty executingProperty();
> void execute();
> void execute(T parameter);
> }
>
> An application's business logic can expose operations as implementations of
> the Command interface, and define the conditions when the operation can be
> executed.
>
> Additionally, ButtonBase should be extended by adding the following two
> properties:
>
> /**
> * The button's command, which is invoked whenever the button is fired.
> * If a command is set on the button, {@link Node#disableProperty()} is
> automatically
> * bound to {@link Command#canExecuteProperty()}. Any previous binding is
> removed.
> */
> ObjectProperty> commandProperty();
>
> /**
> * The button's command parameter.
> * When the command is invoked, this parameter will be passed to the
> command implementation.
> */
> ObjectProperty commandParameterProperty();
>
> These two properties are lazily instantiated to prevent allocations if an
> application doesn't use commands.
> In general, Commands are an opt-in feature, so existing code that makes no
> use of commands is not impacted.
>
> The command is invoked whenever the control fires an ActionEvent. This can
> be achieved by overriding Node.fireEvent(Event) in ButtonBase and checking
> for the presence of an ActionEvent.
>
> I can provide a PR with an implementation of this feature.
>
> Michael
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: DnD Move does not work on OS-X
I filed https://bugs.openjdk.java.net/browse/JDK-8237329 Tom On 09.01.20 15:48, Tom Schindl wrote: > I also tried with > https://docs.oracle.com/javafx/2/drag_drop/jfxpub-drag_drop.htm and it > does not work either. -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: "Using an IDE" Page outdated
I think the issue there is https://bugs.eclipse.org/bugs/show_bug.cgi?id=507629 as Nir commented there as well I'm fairly sure this is the one you see ;-) Tom On 14.01.20 09:47, Tom Schindl wrote: > On 14.01.20 09:36, Robert Lichtenberger wrote: >> I've just simply removed the two missing source folders and only one >> error remains: >> * The blank final field dialog may not have been initialized Dialog.java >> /controls/src/main/java/javafx/scene/control line 521 >> which seems to me like an error within the eclipse compiler. >> >> Ignoring this error, I've tried to execute > > yes it is and it is already logged in Bugzilla there - you can just > remove final in your local workspace ;-) > > Tom > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: "Using an IDE" Page outdated
On 14.01.20 09:36, Robert Lichtenberger wrote: > I've just simply removed the two missing source folders and only one > error remains: > * The blank final field dialog may not have been initialized Dialog.java > /controls/src/main/java/javafx/scene/control line 521 > which seems to me like an error within the eclipse compiler. > > Ignoring this error, I've tried to execute yes it is and it is already logged in Bugzilla there - you can just remove final in your local workspace ;-) Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: "Using an IDE" Page outdated
Well those are created by the build not? I have to confess, that I did not setup Eclipse for OpenJFX-Development lately but I'm fairly certain those directories are generated by the build. Tom On 14.01.20 09:11, Robert Lichtenberger wrote: > I've tried to import using "General" -> "Existing Projects in Workspace" > but get lots of errors as well. When reducing the imported projects to > base, graphics and controls: > * base is ok > * graphics has these errors: > Description Resource Path Location Type > Project 'graphics' is missing required source folder: > 'build/hlsl/Decora' graphics Build path Build Path Problem > Project 'graphics' is missing required source folder: 'build/hlsl/Prism' > graphics Build path Build Path Problem > * controls won't build due to errors in graphics > > Is hlsl the "High Level Shading Language" which may be specific to Windows? > > Am Di., 14. Jan. 2020 um 08:53 Uhr schrieb Tom Schindl > mailto:tom.schi...@bestsolution.at>>: > > Hi, > > I think Nir nor I uses them as gradle Projects because you have the > .classpath, .project, ... . > > Tom > > On 14.01.20 08:12, Robert Lichtenberger wrote: > > Yes, I did run a gradle build (for which I had to tweak > > buildSrc/linux.gradle to ignore some deprecations -- see my other > post to > > the list) successfully. > > > > I use a completely fresh workspace, updated my JFX sources, I use > Eclipse > > 2019-12 and jdk-13.0.1+9 on Fedora 31. > > > > These are my steps: > > * open eclipse, > > * choose "Import projects" then "Gradle" -> "Existing Gradle project" > > * give the top level folder of my repository (/home/rli/PWEs/jfx > in my case) > > * Use the gradle wrapper (i.e. no changes on the wizards next page) > > * The project structure is given correctly, so I click finish > > > > Eclipse then loads the projects but gives out the aforementioned > error. > > > > I've made a 1-minute video clip showing my steps: > > https://youtu.be/S9WnOHCbWLI > > > > I'll try to find out what is going wrong here. Could you tell me which > > versions (JFX sources, Eclipse, JDK) you are using? > > > > > > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker > mailto:nlis...@gmail.com>>: > > > >> Never seen this problem before. Did you run a Gradle build? [1] > It needs to > >> generated required resources. > >> > >> Also, the Eclipse files for some projects are not updated (though > for the > >> modules they are fine, so it's not the problem you are having). > My patch > >> for them was pending review by other Eclipse users and no one > tested it, so > >> if you are up for it I could resume work on it. > >> > >> - Nir > >> > >> [1] > >> > >> > > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest > >> > >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger < > >> r.lichtenber...@synedra.com <mailto:r.lichtenber...@synedra.com>> > wrote: > >> > >>> Hmm. Eclipse would suit me fine, so I've tried to import a current > >> OpenJFX > >>> repository to Eclipse but it gives me (among others) this error: > >>> > >>> Description Resource Path Location Type > >>> Cannot nest > >>> > >> > > 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base' > >>> inside library > >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main' > base > >>> Build path Build Path Problem > >>> > >>> The Workspace was completely new, all the other stuff (JDK 12, Java > >>> Compiliance Level) should be ok. > >>> > >>> Do you have any idea what is going wrong here? Smells like > module system > >>> problems :-(. > >>> > >>> > >>> Best regards, > >>> > >>> Robert > >>> On 2020-01-10 17:52, Nir Lisker wrote: > >>> > >>> Hi Rob
Re: "Using an IDE" Page outdated
Hi, I think Nir nor I uses them as gradle Projects because you have the .classpath, .project, ... . Tom On 14.01.20 08:12, Robert Lichtenberger wrote: > Yes, I did run a gradle build (for which I had to tweak > buildSrc/linux.gradle to ignore some deprecations -- see my other post to > the list) successfully. > > I use a completely fresh workspace, updated my JFX sources, I use Eclipse > 2019-12 and jdk-13.0.1+9 on Fedora 31. > > These are my steps: > * open eclipse, > * choose "Import projects" then "Gradle" -> "Existing Gradle project" > * give the top level folder of my repository (/home/rli/PWEs/jfx in my case) > * Use the gradle wrapper (i.e. no changes on the wizards next page) > * The project structure is given correctly, so I click finish > > Eclipse then loads the projects but gives out the aforementioned error. > > I've made a 1-minute video clip showing my steps: > https://youtu.be/S9WnOHCbWLI > > I'll try to find out what is going wrong here. Could you tell me which > versions (JFX sources, Eclipse, JDK) you are using? > > > Am Mo., 13. Jan. 2020 um 17:59 Uhr schrieb Nir Lisker : > >> Never seen this problem before. Did you run a Gradle build? [1] It needs to >> generated required resources. >> >> Also, the Eclipse files for some projects are not updated (though for the >> modules they are fine, so it's not the problem you are having). My patch >> for them was pending review by other Eclipse users and no one tested it, so >> if you are up for it I could resume work on it. >> >> - Nir >> >> [1] >> >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-BuildandTest >> >> On Mon, Jan 13, 2020 at 5:35 PM Robert Lichtenberger < >> r.lichtenber...@synedra.com> wrote: >> >>> Hmm. Eclipse would suit me fine, so I've tried to import a current >> OpenJFX >>> repository to Eclipse but it gives me (among others) this error: >>> >>> DescriptionResourcePathLocationType >>> Cannot nest >>> >> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main/javafx.base' >>> inside library >>> 'home/rli/PWEs/jfx/modules/javafx.base/build/classes/java/main'base >>> Build pathBuild Path Problem >>> >>> The Workspace was completely new, all the other stuff (JDK 12, Java >>> Compiliance Level) should be ok. >>> >>> Do you have any idea what is going wrong here? Smells like module system >>> problems :-(. >>> >>> >>> Best regards, >>> >>> Robert >>> On 2020-01-10 17:52, Nir Lisker wrote: >>> >>> Hi Robert, >>> >>> I've brought this up in the past. >>> >>> I think that the best solution is for someone from the community to take >>> that task. I try to keep the Eclipse section updated, we will need >> someone >>> for the other IDE's. >>> >>> - Nir >>> >>> On Fri, Jan 10, 2020 at 10:54 AM Robert Lichtenberger < >>> r.lichtenber...@gmail.com> wrote: >>> >>>> I've noticed that >>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE >>>> seems a bit outdated (refers to JDK 1.8, a folder named "rt", which no >>>> longer exists, etc.). >>>> >>>> Could someone please update this page so that it is easier for newcomers >>>> to >>>> dive into the development of OpenJFX. >>>> >>>> Thanks, >>>> Robert >>>> >>> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
DnD Move does not work on OS-X
Hi,
I must be doing something completely wrong or there is a major bug in
JavaFX-DnD from Java-8 upwards to JavaFX-14-ea.
If you run the attached application on OS-X the and press the CMD-key
while dragging you get null for the getTransferMode() inside DragOver
and you don't get a DragDropped and null on the DragDone.
I tracked that back to View#notifyDragOver() where one gets 0 from the
native side. So am I missing something in my code?
I also tried with
https://docs.oracle.com/javafx/2/drag_drop/jfxpub-drag_drop.htm and it
does not work either.
So I guess it's a major bug in openjfx but before filing a jira-ticket I
wanted to make extra sure it's not a stupid mistake, my german operating
system, ...
Tom
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
package bla;
import java.util.UUID;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.input.ClipboardContent;
import javafx.scene.input.Dragboard;
import javafx.scene.input.TransferMode;
import javafx.scene.layout.HBox;
import javafx.scene.layout.VBox;
import javafx.scene.paint.Color;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;
public class SampleApp extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
HBox b = new HBox(50);
Rectangle sourceR = new Rectangle(300, 300);
sourceR.setOnDragDetected( evt -> {
Dragboard dragboard =
sourceR.startDragAndDrop(TransferMode.ANY);
ClipboardContent content = new ClipboardContent();
content.putString(UUID.randomUUID().toString());
dragboard.setContent(content);
evt.consume();
});
sourceR.setOnDragDone( evt -> System.err.println("Done: " +
evt.getTransferMode()));
sourceR.setFill(Color.RED);
Rectangle targetR = new Rectangle(300, 300);
targetR.setOnDragOver( evt -> {
evt.acceptTransferModes(TransferMode.ANY);
System.err.println(evt.getTransferMode());
evt.consume();
});
targetR.setOnDragDropped( evt -> {
System.err.println("Completed: " +
evt.getTransferMode());
evt.setDropCompleted(true);
evt.consume();
});
targetR.setFill(Color.BLUE);
b.getChildren().setAll(sourceR, targetR);
Scene s = new Scene(new VBox(b), 800, 600);
primaryStage.setScene(s);
primaryStage.show();
}
public static void main(String[] args) {
launch(args);
}
}
Question on Git History
Hi, I'm not sure I fully understand that hg => git translation but do we see the full history https://github.com/openjdk/jfx of files or just a partial version? If I eg look at https://github.com/openjdk/jfx/commits/master/modules/javafx.graphics/src/main/java/javafx/scene/Node.java I doubt this is the fully history of this class (eg including OpenJFX-8). Another strange thing is that I see by looking at the tags (https://github.com/openjdk/jfx/tags) and releases I (https://github.com/openjdk/jfx/releases). There are some 8u* tags/releases but it's by far not all of them. Why is that? Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: JDK-8130738 TextFlow's tab width is static
Hi, Well I'm not sure this API is correct on TextFlow, if it is supposed to render complex texts like (MS Word) it rather needs a Tab-Stop API, not? Have we investigated other text-layout controls from other frameworks like Swing, Qt, WPF, ... ? What API do those expose? Tom On 20.09.19 18:57, Scott Palmer wrote: > Thanks Kevin. > > My current implementation appears to be working for TextFlow and Text, with > the TextFlow overriding the tabWidth of the child Text nodes. This seems to > work out naturally from the way TextFlow overrides the TextLayout instance > used by the Text node. > > If there are tricky corner-cases that I’m missing, I guess figuring out all > the cases it will need to handle is part of this discussion. It didn’t seem > to be that challenging so far, so perhaps I am missing something (hopefully > not). I wrote a small test app to visually see that things were working as I > expected. I have not yet written the unit tests. > > Cheers, > > Scott > >> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >> wrote: >> >> Hi Scott, >> >> I'm sure Phil will have more comments on this. While the API seems simple >> enough on the surface, I suspect that this will be a challenging feature to >> implement correctly for all of the cases it will need to handle. It would >> need careful review and testing as well. My only comment on the API itself >> is that if we do accept this feature, it should probably go on both Text and >> TextFlow, and be one of the attributes of Text that is ignored / overridden >> when a Text node is in a TextFlow. >> >> -- Kevin >> >> >> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>> I would like to implement this feature, being able to adjust the tab size >>> in a TextFlow or Text node (JDK-8130738 >>> <https://bugs.openjdk.java.net/browse/JDK-8130738>). It involves new >>> public API, so I want to start a discussion about it here. (My motivation >>> is that RichTextFX suggests an entirely unacceptable workaround of >>> substituting actual spaces when the tab character is typed and cites the >>> lack of this API.) >>> >>> I’ve already jumped the gun and taken a crack at an implementation. It is >>> currently incomplete as I was just poking around to see if it was going to >>> be easy enough to not take up too much of my time. It boils down to: >>> TextFlow and Text get a new property for tab width, an integer representing >>> the number of spaces taken by a tab. (The value is only used to initialize >>> the tab width for the TextLayout when needed.) >>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>> PrismTextLayout implements the new setTabWidth API. >>> >>> I’m not sure that the Text node needs this new property. I figured it >>> would be rarely used on that class, so I had implemented it via an added >>> property in the private TextAttributes class. Maybe it isn’t needed at all. >>> >>> What’s the next step? >>> >>> Regards, >>> >>> Scott >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Debugging JavaFX
as requested by Kevin - https://bugs.openjdk.java.net/browse/JDK-8228357 - I filed in in the other category because i could not find a better matching one. Tom On 18.07.19 08:18, Robert Lichtenberger wrote: > I started from scratch today and was able to compile and use JavaFX with > debug information. > When trying to start the test application an error was thrown: no glassgtk3 > in java.library.path; > Now thanks to the debugging information beeing present I was able to debug > GtkApplication like a charm and found out that my machine (Fedora 30) > didn't have gtk3-devel installed. > > To that end I suggest someone updates > https://wiki.openjdk.java.net/pages/viewpage.action?pageId=8257548#BuildingOpenJFX-OracleEnterpriseLinux7andFedora21 > and adds gtk3-devel to the list of required packages. The equivalent > libgtk-3-dev is already there in the Ubuntu section. > > Best regards, > Robert > > Am Do., 18. Juli 2019 um 08:09 Uhr schrieb Tom Eugelink : > >> Hm. Being able to just debug JavaFX will seriously lower the threshold for >> people to get on board. Personally if I run into a library that is behaving >> faulty and I need to download and compile it first, I'm already not very >> happy (it's a hassle). But ahm... cygwin, visual studio, directshow header >> files (on windows) is not "just type gradle". >> >> >> On 18-7-2019 06:45, Robert Lichtenberger wrote: >>> Thanks for the information. Maybe something in my setup was wrong. I'd >> also >>> appreciate if the default builds would contain debug information, this >>> would make JavaFX much more "developer friendly". >>> >>> Robert >>> >>> Am Do., 18. Juli 2019 um 00:04 Uhr schrieb Kevin Rushforth < >>> kevin.rushfo...@oracle.com>: >>> >>>> I did a quick test and the difference in size is noticeable, but not >>>> huge -- on the order of 10% larger with the local symbols. You could >>>> file an enhancement to have a binary available with the local symbols >>>> (or to add them to the default build), but I don't know whether it's >>>> generally useful enough to justify it. Maybe Johan can weigh in on this >>>> one? >>>> >>>> -- Kevin >>>> >>>> >>>> On 7/17/2019 1:50 PM, Tom Eugelink wrote: >>>>> I think I saw that one of the argument for not providing debug symbols >>>>> was size... If there is anything I would not quickly compromise on >>>>> nowadays is size. Even my smartwatch has gigabytes of internal >>>>> storage. If size is an issue for an application, it is usually not >>>>> caused by including debug symbols in a jar. >>>>> >>>>> >>>>> On 17-7-2019 21:01, Tom Schindl wrote: >>>>>> Well the main problem is that if there are no local var you can not >> set >>>>>> conditional break points in the code, inject syserr logging to >>>>>> understand what is going on and what your code does to FX. >>>>>> >>>>>> One could provide 2 artifacts one with and one without debug symbols. >>>>>> >>>>>> Tom >>>>>> >>>>>> On 17.07.19 19:12, Kevin Rushforth wrote: >>>>>>> Mainly size. Generally if a developer is going to debug JavaFX to >> point >>>>>>> of wanting to look at local variables, it doesn't seem a stretch for >>>>>>> them to build JavaFX. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> On 7/17/2019 9:57 AM, Tom Schindl wrote: >>>>>>>> so what is the reason to strip them (i guess it it size) it is >>>>>>>> extremely >>>>>>>> painful to don't see local-variables, have parameter names, >> arg1,arg2, >>>>>>>> ... . >>>>>>>> >>>>>>>> Tom >>>>>>>> >>>>>>>> On 17.07.19 17:01, Kevin Rushforth wrote: >>>>>>>>> When you say that don't see a problem, what exactly do you mean? >>>>>>>>> If you >>>>>>>>> are able to see the local variables in a production build, then >> that >>>>>>>>> would in fact be surprising. The production builds, including EA >>>>>>>>> builds, >>>>>>&g
Re: Debugging JavaFX
Well the main problem is that if there are no local var you can not set conditional break points in the code, inject syserr logging to understand what is going on and what your code does to FX. One could provide 2 artifacts one with and one without debug symbols. Tom On 17.07.19 19:12, Kevin Rushforth wrote: > Mainly size. Generally if a developer is going to debug JavaFX to point > of wanting to look at local variables, it doesn't seem a stretch for > them to build JavaFX. > > -- Kevin > > > On 7/17/2019 9:57 AM, Tom Schindl wrote: >> so what is the reason to strip them (i guess it it size) it is extremely >> painful to don't see local-variables, have parameter names, arg1,arg2, >> ... . >> >> Tom >> >> On 17.07.19 17:01, Kevin Rushforth wrote: >>> When you say that don't see a problem, what exactly do you mean? If you >>> are able to see the local variables in a production build, then that >>> would in fact be surprising. The production builds, including EA builds, >>> should be being built with "-PCONF=Release" which would exclude vars. >>> Someone from Gluon should confirm. >>> >>> -- Kevin >>> >>> >>> On 7/17/2019 7:56 AM, Michael Paus wrote: >>>> Hi, >>>> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >>>> 13-ea 9 via Maven. >>>> Michael >>>> >>>> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>>>> That should have been enough to enable local variable symbols. We >>>>> have the following logic for JavaCompile tasks: >>>>> >>>>> compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>>>> "source,lines,vars" : "source,lines" >>>>> >>>>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>>>> >>>>> Maybe something else is stripping out the symbols. >>>>> >>>>> Has anyone else debugged JavaFX recently and tried to look at local >>>>> vars? If not, I'll take a quick look later today. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>>>> I'm trying to get to the bottom of some weird layout problems in my >>>>>> application. >>>>>> >>>>>> To that end I want/need to debug JavaFX classes. >>>>>> >>>>>> But when I step into JavaFX classes I don't see local variables or >>>>>> parameter names. >>>>>> >>>>>> So I thought debug symbols are probably stripped from the official >>>>>> builds. >>>>>> >>>>>> I rolled my own and tried >>>>>> >>>>>> CONF = Debug >>>>>> >>>>>> and >>>>>> >>>>>> CONF = DebugNative >>>>>> >>>>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>>>> into a little eclipse testproject. >>>>>> >>>>>> But I still don't see parameter names or local variables. >>>>>> >>>>>> Is there something else I need to do in order to see them? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Robert >>>>>> >>>>>> >>>> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Debugging JavaFX
so what is the reason to strip them (i guess it it size) it is extremely painful to don't see local-variables, have parameter names, arg1,arg2, ... . Tom On 17.07.19 17:01, Kevin Rushforth wrote: > When you say that don't see a problem, what exactly do you mean? If you > are able to see the local variables in a production build, then that > would in fact be surprising. The production builds, including EA builds, > should be being built with "-PCONF=Release" which would exclude vars. > Someone from Gluon should confirm. > > -- Kevin > > > On 7/17/2019 7:56 AM, Michael Paus wrote: >> Hi, >> I don't see any problem of that kind with Eclipse, on MacOS, JavaFX >> 13-ea 9 via Maven. >> Michael >> >> Am 17.07.19 um 16:45 schrieb Kevin Rushforth: >>> That should have been enough to enable local variable symbols. We >>> have the following logic for JavaCompile tasks: >>> >>> compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? >>> "source,lines,vars" : "source,lines" >>> >>> IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative. >>> >>> Maybe something else is stripping out the symbols. >>> >>> Has anyone else debugged JavaFX recently and tried to look at local >>> vars? If not, I'll take a quick look later today. >>> >>> -- Kevin >>> >>> >>> >>> On 7/17/2019 7:38 AM, Robert Lichtenberger wrote: >>>> I'm trying to get to the bottom of some weird layout problems in my >>>> application. >>>> >>>> To that end I want/need to debug JavaFX classes. >>>> >>>> But when I step into JavaFX classes I don't see local variables or >>>> parameter names. >>>> >>>> So I thought debug symbols are probably stripped from the official >>>> builds. >>>> >>>> I rolled my own and tried >>>> >>>> CONF = Debug >>>> >>>> and >>>> >>>> CONF = DebugNative >>>> >>>> in gradle.properties, recompiled OpenJFX and integrated the libraries >>>> into a little eclipse testproject. >>>> >>>> But I still don't see parameter names or local variables. >>>> >>>> Is there something else I need to do in order to see them? >>>> >>>> >>>> Best regards, >>>> >>>> Robert >>>> >>>> >>> >> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: How to make a large cursor in JavaFX 12
Hi, Well this is something you can configure in your OS-Settings and FX will just pick it up. The only other option is to set a custom image. Tom On 21.06.19 09:52, Eef Custers wrote: > Hi, > > I am working on an application for visual impaired users. I like to create > a large cursor, but I cannot find a way how to do that. Can somebody push > me in the right direction? > > I am working with openjdk12 and javafx12 on windows10. > Thanks a lot, > regards. > > Eef > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Previews for shared buffer PR
Hi, This is good news but may I suggest we do something similar to OpenJDK who also has explictly marked experimental/preview features shipping in releases who can naturally get removed in a follow up release. I would appreciate this in contrast to not getting this feature integrated at all in FX-13. Tom On 07.06.19 11:40, Johan Vos wrote: > The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472, > addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a very > much wanted feature. It is important that things are done in the right way > so that the code can be maintained in the long-term future. > Therefore, feedback on this PR is extremely important before we can > consider merging it. Once this PR is merged, there is no easy way back. It > is possible to add more functionality, hence my preference is to only > implement the functionality that is safe and stable, while allowing other > functionality to be added later or by third-party extensions. (e.g. > (avoiding) copying from/to GPU) > > To make it easier to give feedback, we've build early access versions of > SDK's including this PR. Note that the PR is not merged, hence not > available in the regular EA downloads! > > If you want to give it a try, download the SDK's from the URL's below. > There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( > https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java) > that should get you started. > > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip > https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip > > - Johan > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Will there be update of openjfx-8u?
Hi Kevin, Well isn't that true as well for jfx-12 - or is this maintained? What makes jfx-12 different from jfx-8? Or is the plan to remove jfx-12 once jfx-13 is released, ...? Anyways, I accept this and I'll see how I can get that forked to my own github account (once I have a need for it :-) Tom On 11.06.19 13:55, Kevin Rushforth wrote: > If someone wants to create a new project and fork the openjfx/8u-dev/rt > repo there, that would be fine...as long as everyone understand that it > is a fork of an unmaintained code base. > > Since openjfx/8u is not being maintained, neither the > javafxports/openjdk-jfx repo nor the new (for project Skara) openjdk > project on GitHub would be suitable. > > -- Kevin > > > On 6/11/2019 3:25 AM, Tom Schindl wrote: >> Hi, >> >> What I asked some time ago is that the github fork also contains the >> latest u8-state before it got frozen - similar to eg jfx-11, jfx-12 (and >> most likely soon jfx-13 branch). >> >> This would at least give us all a central place we can create our forks >> on (I understand nobody is willing to maintain merge back changes there). >> >> Tom >> >> On 10.06.19 22:29, Kevin Rushforth wrote: >>> I recommend that you upgrade to JDK 12 + openjfx 12 if you want to keep >>> current, since openjfx-8u is not supported. >>> >>> If you must stay on JDK 8, Oracle is supporting JavaFX in JDK 8 through >>> March of 2022 [1], so you could check into that (note that this list is >>> not the place to discuss support, however). Otherwise, you are on >>> your own. >>> >>> -- Kevin >>> >>> [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html >>> >>> >>> On 6/9/2019 7:52 PM, guoge (A) wrote: >>>> Thanks for your reply, Kevin >>>> >>>> I wonder to know if I'm still using JDK8 with JFX8 because JFX 11 can >>>> not match with JDK8 (as I know), >>>> How can I deal with the vulnerabilities of JFX8? >>>> >>>> Thanks, >>>> Guo Ge > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Will there be update of openjfx-8u?
Hi, What I asked some time ago is that the github fork also contains the latest u8-state before it got frozen - similar to eg jfx-11, jfx-12 (and most likely soon jfx-13 branch). This would at least give us all a central place we can create our forks on (I understand nobody is willing to maintain merge back changes there). Tom On 10.06.19 22:29, Kevin Rushforth wrote: > I recommend that you upgrade to JDK 12 + openjfx 12 if you want to keep > current, since openjfx-8u is not supported. > > If you must stay on JDK 8, Oracle is supporting JavaFX in JDK 8 through > March of 2022 [1], so you could check into that (note that this list is > not the place to discuss support, however). Otherwise, you are on your own. > > -- Kevin > > [1] https://www.oracle.com/technetwork/java/java-se-support-roadmap.html > > > On 6/9/2019 7:52 PM, guoge (A) wrote: >> Thanks for your reply, Kevin >> >> I wonder to know if I'm still using JDK8 with JFX8 because JFX 11 can >> not match with JDK8 (as I know), >> How can I deal with the vulnerabilities of JFX8? >> >> Thanks, >> Guo Ge > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: problem with the fx:namespace
Hi, namespace != xsd - there can never ever be a XSD for FXML! Tom On 23.04.19 19:22, Larry White wrote: > Hi, I'm having trouble with the fx namespace > > Scene Builder inserts several namespaces in an FXML file by default? > > xmlns:fx="http://javafx.com/fxml/1"; > xmlns="http://javafx.com/javafx/11.0.1"; > > When I try to access either of these through IDEA, it tells me that there > is "No XML at the location." > > When I try accessing them with a browser, I'm redirected to Oracle's java > page. If I use https instead of http, I get a warning about the certificate. > > Oracle seems to have moved or removed them. How can make the fx namespace > accessible to my fxml file? > > Thanks for your help > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: [8u-dev announce] Future contributions to openjfx/8u-dev
Well maybe mirror was the wrong term - I think now that 8u-dev is force and won't see any changes anymore. A one time dump is what we should have somewhere on git/github. Tom On 18.01.19 09:27, Tom Schindl wrote: > Hi, > > Is there any documentation how the current javafxports mirror repository > got created? > > Some of our customer projects are going to be stuck on JavaFX-8 for the > forseeable future and while we won't sign up for providing general > support for JavaFX-8 it would be good to have a central place one can > fork JavaFX-8 from. > > Having a central place would allow (at least in theory) that > modifications and patches from different people can be merged without to > much manual work. > > Tom > > On 08.01.19 00:01, Kevin Rushforth wrote: >> I'm not sure that an 8u-dev mirror would be suitable for the javafxports >> project, but if someone wanted to set up such a mirror elsewhere they >> could do so. It might be best left to the future maintainer (if any >> suitable party steps forward) to determine whether and where to host a >> git mirror. >> >> -- Kevin >> >> >> On 12/21/2018 1:39 PM, Tom Schindl wrote: >>> Hi, >>> >>> Could we get a mirror of 8u setup for github as well? I wanted to ask >>> for that since some time but always forgot to do so. >>> >>> Tom >>> >>> On 21.12.18 22:32, Kevin Rushforth wrote: >>>> As has been previously announced [1][2], Oracle will no longer >>>> contribute to the JDK 8 Updates Project after the January 2019 quarterly >>>> CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part >>>> of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev >>>> code line (8u-dev/rt repo) after JDK 8u202 ships. >>>> >>>> This means that Oracle will be stepping down as the maintainer of the >>>> openjfx/8u-dev code line after January, and will call for a new >>>> maintainer. If a suitable party steps forward to maintain the OpenJFX 8 >>>> Updates code line after the final Oracle-led JDK 8 Update release has >>>> been published, we will discuss how to best enable such a transition on >>>> this Project's mailing list. >>>> >>>> I wanted to send this before the holidays, although I realize it might >>>> get lost in the shuffle, so I will resend it after the first of the >>>> year, along with a formal call for interested parties who wish to put >>>> their name forward as a maintainer for the openjfx/8u-dev release. >>>> >>>> -- Kevin >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html >>>> >>>> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: [8u-dev announce] Future contributions to openjfx/8u-dev
Hi, Is there any documentation how the current javafxports mirror repository got created? Some of our customer projects are going to be stuck on JavaFX-8 for the forseeable future and while we won't sign up for providing general support for JavaFX-8 it would be good to have a central place one can fork JavaFX-8 from. Having a central place would allow (at least in theory) that modifications and patches from different people can be merged without to much manual work. Tom On 08.01.19 00:01, Kevin Rushforth wrote: > I'm not sure that an 8u-dev mirror would be suitable for the javafxports > project, but if someone wanted to set up such a mirror elsewhere they > could do so. It might be best left to the future maintainer (if any > suitable party steps forward) to determine whether and where to host a > git mirror. > > -- Kevin > > > On 12/21/2018 1:39 PM, Tom Schindl wrote: >> Hi, >> >> Could we get a mirror of 8u setup for github as well? I wanted to ask >> for that since some time but always forgot to do so. >> >> Tom >> >> On 21.12.18 22:32, Kevin Rushforth wrote: >>> As has been previously announced [1][2], Oracle will no longer >>> contribute to the JDK 8 Updates Project after the January 2019 quarterly >>> CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part >>> of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev >>> code line (8u-dev/rt repo) after JDK 8u202 ships. >>> >>> This means that Oracle will be stepping down as the maintainer of the >>> openjfx/8u-dev code line after January, and will call for a new >>> maintainer. If a suitable party steps forward to maintain the OpenJFX 8 >>> Updates code line after the final Oracle-led JDK 8 Update release has >>> been published, we will discuss how to best enable such a transition on >>> this Project's mailing list. >>> >>> I wanted to send this before the holidays, although I realize it might >>> get lost in the shuffle, so I will resend it after the first of the >>> year, along with a formal call for interested parties who wish to put >>> their name forward as a maintainer for the openjfx/8u-dev release. >>> >>> -- Kevin >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html >>> >>> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: JDK-8193445 Performance Test (CSS applied redundantly)
Sorry to hi-jack but: > Performance improvements and a JNI mechanism to get at native window handles > are the first two items on my wish list. Though extendable media support > could potentially beat out the window handle thing.. I only need a native > window handle so I can do native rendering of video frames from a non-JavaFX > source. Couldn't you leverage our DriftFX work for this? Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 09.01.19 06:13, Ty Young wrote: > I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released > yet but apparently 13 is a thing). These issues still exist. > To really help finding and solving the problem you need to provide source code for us to reproduce the problem. Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: [8u-dev announce] Future contributions to openjfx/8u-dev
Hi, Could we get a mirror of 8u setup for github as well? I wanted to ask for that since some time but always forgot to do so. Tom On 21.12.18 22:32, Kevin Rushforth wrote: > As has been previously announced [1][2], Oracle will no longer > contribute to the JDK 8 Updates Project after the January 2019 quarterly > CPU release of JDK 8u202. Since JavaFX for JDK 8 is delivered as a part > of the JDK, Oracle will also no longer contribute to the OpenJFX 8u-dev > code line (8u-dev/rt repo) after JDK 8u202 ships. > > This means that Oracle will be stepping down as the maintainer of the > openjfx/8u-dev code line after January, and will call for a new > maintainer. If a suitable party steps forward to maintain the OpenJFX 8 > Updates code line after the final Oracle-led JDK 8 Update release has > been published, we will discuss how to best enable such a transition on > this Project's mailing list. > > I wanted to send this before the holidays, although I realize it might > get lost in the shuffle, so I will resend it after the first of the > year, along with a formal call for interested parties who wish to put > their name forward as a maintainer for the openjfx/8u-dev release. > > -- Kevin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html > [2] > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-September/007923.html > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Problem running tests in module controls inside Eclipse
i run them with -Djava.library.path=/Users/tomschindl/OpenJFX/openjdk-jfx/build/sdk/lib -Djavafx.toolkit=test.com.sun.javafx.pgstub.StubToolkit Tom On 18.11.18 17:00, Nir Lisker wrote: > I don't recall seeing this problem. Just to be sure, did you circumvent the > compilation error in Dialog's lambda? > > On Sun, Nov 18, 2018 at 5:42 PM wrote: > >> >> With the step-by-step debugging help provided by nlisker over at >> javafxports (https://github.com/javafxports/openjdk-jfx/issues/187 - >> which cleaned up some inherent misconception on my part, thanks!) I >> managed to run tests in base and graphics from inside Eclipse (right >> click and run as/unit test), but not in controls (complete stacktrace >> is at the end), barking with essentially: >> >> Caused by: java.lang.IllegalStateException: Toolkit not initialized >> >> Which is the usual complaint if the fx app thread is not yet started. >> For my own tests I have a class rule that fires it up, but how to >> start it for openjfx controls tests? >> >> The complete stacktrace: >> >> java.lang.ExceptionInInitializerError >> at >> >> javafx.controls/test.javafx.scene.control.TextAreaTest.setup(TextAreaTest.java:53) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:566) >> at >> >> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) >> at >> >> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) >> at >> >> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) >> at >> >> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24) >> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) >> at >> >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) >> at >> >> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) >> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) >> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) >> at >> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) >> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) >> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) >> at org.junit.runners.ParentRunner.run(ParentRunner.java:363) >> at >> >> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89) >> at >> >> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41) >> at >> >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541) >> at >> >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763) >> at >> >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463) >> at >> >> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209) >> Caused by: java.lang.IllegalStateException: Toolkit not initialized >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:410) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:405) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.setPlatformUserAgentStylesheet(PlatformImpl.java:695) >> at >> >> javafx.graphics/com.sun.javafx.application.PlatformImpl.setDefaultPlatformUserAgentStylesheet(PlatformImpl.java:657) >> at >> javafx.controls/javafx.scene.control.Control.(Control.java:99) >> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Building on Ubuntu 18.10
Hi, On Linux and OS-X it is chosen by default unless your graphics-card/driver is black listed - only happens on Linux. On Windows there's no OpenGL pipeline (see below) but just D3D. To integrate OpenGL on win32 you need to do some extra work. We (BestSolution.at together with some of our customers) are working on Native-Surface-Support (OpenGL and D3D). We are not yet ready to share it publicly. Once we make our first draft implementation available we hope to receive feedback from the OpenJFX community to improve and move it forward together in OSS. Tom On 16.11.18 23:38, Giuseppe Barbieri wrote: > Hi, > > after bleeding today trying to build it on Win 10 ( > https://github.com/javafxports/openjdk-jfx/issues/288), I decided to try on > Ubuntu hoping for a more friendly iter > > Luckily only a problem arises: > > https://gist.github.com/elect86/47ab39ee346873fd9c84a745a137bf46 > > Removing `Werror` from `linux.gradle` solved the problem > > Someone may want to work on those issue to easier the building process for > future users.. > > > Now, I'd like to play a little with the graphics backends, especially the > ES2 one. > > How can I be sure that OpenJFX uses that? > > Also, are there any license issues if I try to modify the sources, trying > to accomodate some lwjgl interoperability, keeping everything public on > github? > > What's the status of the OpenGLNode? Anybody looking forward to it? May we > work together? > > > Cheers, > Giuseppe > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Bug: Not on FX application thread exception is inconsistent
On 13.11.18 04:00, Ty Young wrote: > > On 11/12/18 5:39 PM, Tom Schindl wrote: >> Hi, >> >> You are supposed to interact with Nodes who are currently shown in the >> SG only only the JavaFX Application Thread. > > > I never touch the GUI in my other threads, ever. The threads simply > change the value of a type stored in a property. The ChangeListener that > is used is created in the GUI JavaFX thread. > It does not matter on which thread you create a ChangeListener the important thing is on Thread causes the change-listener to trigger. *None* of the JavaFX code-structures (Property, ObservableList) are multi-thread-safe you accessing them from multiple threads at the same time is asking for trouble. Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Bug: Not on FX application thread exception is inconsistent
I'm sorry that I'm the one to bring you the bad news that you need to do the work and can't offload multi-threading to JavaFX. I already explain why it *seems* to work one some elements (until it breaks like shown in the bug-report I referenced) and for others it breaks immediately because they somehow call out to native APIs (like win32, ...) and hence are guarded with checks. I can simply say it won't work and it won't change (well I'm not the one in charge of such a decision but I frankly can't believe it will). You are the one supposed to deal with this like you have to deal with that in Swing, Qt, WPF, Win32-API, Cocoa-API, Gtk, ... - you need to sync yourself back to the UI-Thread if you want to access resources. You are right. If there are many updates from the backend-system you would queue a lot of Runnables using Platform.runLater() who can get you in trouble. There are others ways to sync back to the JavaFX UI-Thread but Platform.runLater() is the simplest with the least amount of work and until you run into problems you should stick to that. This is my last reply in this thread, as there's nothing more to say on this topic from my side, there are many resources out there discussing Platform.runLater and friends but that's something you can (and could have) googled for and anyways looks like you don't want to listen. Tom On 13.11.18 05:38, Ty Young wrote: > > On 11/12/18 9:12 PM, Brian Hudson wrote: >> JavaFX like every other modern UI framework is single threaded. > > > Which in itself is fine, running *just* the UI isn't much on modern > processors. Adding a bunch of API object updates that cause thread > slowdown to the mix that can cause UI stuttering is, again, asking for > trouble. > > > And how is TableView, Slider, TextField, etc all working just fine but > ComboBox freaks out? What's so special about ComboBox? Is there some > hack I can do to not trigger the exception? > > >> >> The updating of your “API objects” can and should remain on a >> background thread, however once updated the changes which trigger an >> update to your UI (changing a value in a bound property) should occur >> on the JavaFX thread via Platform.runLater for example. >> > > Doing all this is just messy, inefficient, and duplicating code. It > would involve creating Runnable implementations that does about 10 lines > of code with objects that get updated as fast as they can be with > different object types, resulting in more threads and garbage being > created. Using generic magic isn't really a solution either because > different API objects convert data from String to some other type > depending on the implementation. > > > Would it not be possible to have a runPlatformListener method that just > runs the ChangeListener on the platform thread automatically? It would > reduce the amount of garbage dramatically since JavaFX only ever fires a > change event if the object is itself different(in other words, if the > current value is 0 and the new value is 0, there is no change) which is > nice and efficient. > > >> Also, take the attitude down a notch or two. >> >> Brian >> >> >> On Mon, Nov 12, 2018 at 10:02 PM Ty Young > <mailto:youngty1...@gmail.com>> wrote: >> >> >> On 11/12/18 5:39 PM, Tom Schindl wrote: >> > Hi, >> > >> > You are supposed to interact with Nodes who are currently shown >> in the >> > SG only only the JavaFX Application Thread. >> >> >> I never touch the GUI in my other threads, ever. The threads simply >> change the value of a type stored in a property. The >> ChangeListener that >> is used is created in the GUI JavaFX thread. >> >> >> > >> > JavaFX although is not checking each and every property (change) >> as this >> > would be too resource intensive but at sensitive cases (eg when >> > interacting with Glass) it does check that you run on the >> correct thread. >> >> >> The update process for updating my API objects is slow(for reasons >> beyond my control), so even assuming I somehow manage to magically >> update everything in the GUI thread, how the hell do you fix the GUI >> stuttering at that point? >> >> >> Really, having an entire application do all of it's processing on one >> thread in 2018 is really just idiotic and asking for trouble. >> >> >> > >> > Even though your TableView, ... updates seem to work you can run >> into >> > disasterous states -
Re: Bug: Not on FX application thread exception is inconsistent
Hi,
You are supposed to interact with Nodes who are currently shown in the
SG only only the JavaFX Application Thread.
JavaFX although is not checking each and every property (change) as this
would be too resource intensive but at sensitive cases (eg when
interacting with Glass) it does check that you run on the correct thread.
Even though your TableView, ... updates seem to work you can run into
disasterous states - see eg https://bugs.openjdk.java.net/browse/JDK-8198577
Tom
On 10.11.18 06:58, Ty Young wrote:
> Hi,
>
>
> My JavaFX program updates API objects in the background via a non FX
> thread that, when changed by another program, are reflected in my JavaFX
> GUI's controls by property binding, specifically TableView, Slider,
> TextField, and ComboBox. Problem is, while JavaFX is OK with this for
> TableView, Slider, and TextField, it throws a Not on FX application
> thread exception *only* for the ComboBox.
>
>
> The code for the slider looks like this:
>
> private class ValueListener implements ChangeListener
> {
> @Override
> public void changed(ObservableValue
> observable, Integer oldValue, Integer newValue)
> {
> slider.getSlider().setValue(newValue);
> slider.getTextBox().setText(newValue.toString());
> }
> }
>
>
> (the slider variable is misleading, it's actually a VBox that contains a
> Slider and a TextField. Need to change it but I digress.)
>
>
> which works fine. However this:
>
>
> private class ValueListener implements ChangeListener
> {
> @Override
> public void changed(ObservableValue observable, E
> oldValue, E newValue)
> {
> combo.setValue(newValue);
> }
> }
>
>
> doesn't for the ComboBox.
>
>
> Is this a bug or is there some legitimate invisible reason as to why the
> slider/textfield isn't throwing an error but the combobox one is?
>
>
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Running JavaFX-11 applications from within Eclipse fails
Hi, I never used the relative version but can confirm that you have to set the library path to the built DLLs Tom On 12.11.18 11:41, Nir Lisker wrote: > I managed to solve my problem. It's actually looking for the dlls, so using > > -Djava.library.path="...\rt\modules\javafx.graphics\build\module-lib" > > will start the application properly. If anyone can confirm this problem > and solution I'll add this step to the wiki. > > On Wed, Nov 7, 2018 at 6:21 PM Nir Lisker <mailto:nlis...@gmail.com>> wrote: > > I have a related problem when developing JavaFX in Eclipse and Win10 > that started in 11. > > I created a modular project and in its build configuration (in > Eclipse) I added the JavaFX base and graphics projects (that point > to rt\modules\...) and OpenJDK11 to the module path. > In the module-info file I required the JavaFX modules and exported > my package. > > Compilation is fine, but during runtime (with -Dprism.verbose=true) > I get an error: > > Prism pipeline init order: d3d sw > Using Double Precision Marlin Rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures > Using hardware CLAMP_TO_ZERO mode > Opting in for HiDPI pixel scaling > Prism pipeline name = com.sun.prism.d3d.D3DPipeline > Loading D3D native library ... > // Error here: // > GraphicsPipeline.createPipeline failed for com.sun.prism.d3d.D3DPipeline > java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: > [see below] > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829) > at java.base/java.lang.System.loadLibrary(System.java:1867) > at > > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150) > at > > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52) > at > > javafx.graphics/com.sun.prism.d3d.D3DPipeline.lambda$0(D3DPipeline.java:48) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > > javafx.graphics/com.sun.prism.d3d.D3DPipeline.(D3DPipeline.java:44) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > > javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > at java.base/java.lang.Thread.run(Thread.java:834) > *** Fallback to Prism SW pipeline > Prism pipeline name = com.sun.prism.sw.SWPipeline > GraphicsPipeline.createPipeline failed for com.sun.prism.sw.SWPipeline > java.lang.UnsatisfiedLinkError: no prism_sw in java.library.path: > [see below] > at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660) > at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829) > at java.base/java.lang.System.loadLibrary(System.java:1867) > at > > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:150) > at > > javafx.graphics/com.sun.glass.utils.NativeLibLoader.loadLibrary(NativeLibLoader.java:52) > at > javafx.graphics/com.sun.prism.sw.SWPipeline.lambda$0(SWPipeline.java:42) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at > javafx.graphics/com.sun.prism.sw.SWPipeline.(SWPipeline.java:41) > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:315) > at > > javafx.graphics/com.sun.prism.GraphicsPipeline.createPipeline(GraphicsPipeline.java:187) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:91) > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124) > at java.base/java.lang.Thread.run(Thread.java:834) > Graphics Device initialization failed for : d3d, sw > Error initializing QuantumRenderer: no suitable pipeline found > // ... > > The paths listed at the end are those from %PATH% and none point to > the development modules. So, I added to the runtime VM args in the > launch configuration: > > -Djava.library.path="...\rt\modul
Re: Support of SVG ImageLoader in JavaFX
You can use a custom URLStreamHandler not?
Tom
On 05.11.18 12:03, René Reiß wrote:
> Hi,
>
> In Java 8 I used a SVGImageLoader to support SVGs in css-Files,
> something like
> -fx-background-image : url("/svg/minusicon.svg");
>
> see also
> https://blog.codecentric.de/en/2015/03/adding-custom-image-renderer-javafx-8/
>
>
> In Java 11 I get an IllegalAccessError
>
> java.lang.IllegalAccessError: superinterface check failed: class
> SvgImageLoaderFactory (in unnamed module @0x2a8d6c41) cannot access
> class com.sun.javafx.iio.ImageLoaderFactory (in module javafx.graphics)
> because module javafx.graphics does not export com.sun.javafx.iio to
> unnamed module @0x2a8d6c41
>
> I know, the ImageLoaderFactory is not part of the official JavaFX public
> API. But, why not? Why it is no more possible to write an own
> ImageLoader? It is planned for the future?
>
> Is there another possibility to support SVGs in JavaFX applications?
> Otherwise I have to convert all SVGs to png or jpegs, but this will be a
> step backwards for me.
>
> Thanks,
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: DropShadow effect kills gfx responsiveness OS-wide
I've never seen and don't see it slowing down other applications (I'm on a MacBook Pro 13'') but I reported the DropShadow slow down and documented the solution [1]. Tom [1] https://openjfx-dev.openjdk.java.narkive.com/I8NIK0db/bad-dropshadow-performance On 04.11.18 20:22, Nir Lisker wrote: >> >> I don't have access to the OpenJDK bug tracker so I can't file a bug >> report for this >> > > You can do it at https://bugreport.java.com/bugreport/ > > On Sun, Nov 4, 2018 at 9:18 PM Mike Hearn wrote: > >> I'm on macOS High Sierra with a very new and very high end MacBook Pro. >> >> I have a pretty basic GUI that uses translucency fairly aggressively. I >> added a DropShadow effect to some nodes, which looks great, but to my great >> surprise this one line of code kills the UI performance not of my app, but >> other apps on the same machine, specifically: >> >>- I can see the frame rate of the dock's zoom animation is lower >>- Chrome becomes nearly unusable. Opening a new tab goes from nearly >>instant to sluggish, this is very noticeable if you watch the tab in the >>tab strip itself expand. It goes from smooth and fast to being able to >> see >>the individual frames. >> >> Stopping my app immediately restores the other apps to full framerate. So >> presumably, the DropShadow shader is triggering some slow path not only in >> JavaFX but the GPU or driver itself. I've experimenting with caching and >> that speeds up scrolling of nodes with drop shadows in my own app, but the >> OS-wide slowdown remains. >> >> Has anyone seen anything like this before? I'm suspecting that I'll need to >> render my own drop shadow effect using static bitmaps to work around it. >> >> I don't have access to the OpenJDK bug tracker so I can't file a bug report >> for this and I'm not sure how to reproduce it reliably. It's the first time >> I noticed it. >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Running JavaFX-11 applications from within Eclipse fails
I think the more general problem is that they don‘t run on the module-path - in
the m2e case this because the modules are transitive deps and those are not
supported properly
Tom
Von meinem iPhone gesendet
> Am 04.11.2018 um 16:17 schrieb José Pereda :
>
> I've just noticed that this issue happens not only with Maven but also with
> Gradle projects (Gradle + Eclipse 2018-09 + Windows with Oracle JDK 1.8),
> running gradle tasks from Eclipse.
>
> The same proposed workaround can be applied to the build file:
>
> run {
>
>systemProperty "java.library.path", "C:\tmp"
>
> }
>
>
>
>
> On Mon, Oct 22, 2018 at 4:43 PM Kevin Rushforth
> wrote:
>
>>
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>>
>> Yes, it seems like a workaround rather than a fix...
>>
>> -- Kevin
>>
>>
>>> On 10/21/2018 10:45 AM, Johan Vos wrote:
>>> Hi Tom,
>>>
>>> Nice workaround, but what do you think needs to be done to fix it? Can
>> the
>>> java.library.path somehow be changed in a plugin or so?
>>> Renaming the native libraries in JavaFX would probably solve this, but
>> that
>>> seems the wrong solution to me.
>>>
>>> - Johan
>>>
>>> On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl >>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I just wanted to make you aware that if you run a JavaFX-11 application
>>>> from within Eclipse it is very likely that you'll get an error like
>> this.
>>>>
>>>>> Exception in thread "WindowsNativeRunloopThread"
>>>> java.lang.NoSuchMethodError:
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native
>>>> Method)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>>> Exception in thread "JavaFX Application Thread"
>>>> java.lang.NullPointerException
>>>>> at
>>>>
>> javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
>>>>> at
>>>>
>> javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
>>>>> at
>>>> javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native
>> Method)
>>>>> at
>>>>
>> javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
>>>>> at java.base/java.lang.Thread.run(Thread.java:834)
>>>> Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll
>>>> because Eclipse sets a java.library.path who also contains the
>>>> JVM-Directories used to launch your Eclipse IDE.
>>>>
>>>> The simple work-around is to add
>>>> -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch
>>>> configuration.
>>>>
>>>> Small tiny question on the side: Wouldn't it make sense to version our
>>>> .dlls somehow to match the release eg glass-11.dll?
>>>>
>>>> Tom
>>>>
>>>> --
>>>> Tom Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>>>
>>
>>
>
> --
Re: Running JavaFX-11 applications from within Eclipse fails
Hi, Well we talk about JavaFX-11 but the important thing is that this bug only happens if your Eclipse IDE is running Oracle-Java-8 ;-) Tom On 21.10.18 21:15, Nir Lisker wrote: > Ah, I didn't realize you were talking about Java 8. > > On Sun, Oct 21, 2018 at 10:09 PM Tom Schindl > mailto:tom.schi...@bestsolution.at>> wrote: > > Well: > - Launch Eclipse 2018-09 with Orcale-Java-8 > - Create a maven-enabled project (I think this is important because if > you launch with the FX-SDK on the command line you won't run into > this) > - Boom > > Tom > > On 21.10.18 11:35, Nir Lisker wrote: > > Hi Tom, > > > > Iv'e never gotten this error. How do you reproduce this? > > > > - Nir > > > > On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl > mailto:tom.schi...@bestsolution.at> > > <mailto:tom.schi...@bestsolution.at > <mailto:tom.schi...@bestsolution.at>>> wrote: > > > > Hi, > > > > I just wanted to make you aware that if you run a JavaFX-11 > application > > from within Eclipse it is very likely that you'll get an error > like > > this. > > > > > Exception in thread "WindowsNativeRunloopThread" > > java.lang.NoSuchMethodError: > > > at > > > > javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native > > Method) > > > at > > > javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412) > > > at > > > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152) > > > at > > > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > > Method) > > > at > > > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > Exception in thread "JavaFX Application Thread" > > java.lang.NullPointerException > > > at > > > > javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205) > > > at > > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695) > > > at > > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313) > > > at > > > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258) > > > at > > > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153) > > > at > > > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > > Method) > > > at > > > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > Scary right! The reason is that JavaFX-11 is loading the wrong > glass.dll > > because Eclipse sets a java.library.path who also contains the > > JVM-Directories used to launch your Eclipse IDE. > > > > The simple work-around is to add > > -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch > > configuration. > > > > Small tiny question on the side: Wouldn't it make sense to > version our > > .dlls somehow to match the release eg glass-11.dll? > > > > Tom > > > > -- > > Tom Schindl, CTO > > BestSolution.at EDV Systemhaus GmbH > > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Running JavaFX-11 applications from within Eclipse fails
Well fixing the bug in Eclipse is the right way to address this ;-) Once I have time I'll provide a patch. https://bugs.eclipse.org/bugs/show_bug.cgi?id=540247 Tom On 21.10.18 19:45, Johan Vos wrote: > Hi Tom, > > Nice workaround, but what do you think needs to be done to fix it? Can > the java.library.path somehow be changed in a plugin or so? > Renaming the native libraries in JavaFX would probably solve this, but > that seems the wrong solution to me. > > - Johan > > On Thu, Oct 18, 2018 at 3:39 PM Tom Schindl <mailto:tom.schi...@bestsolution.at>> wrote: > > Hi, > > I just wanted to make you aware that if you run a JavaFX-11 application > from within Eclipse it is very likely that you'll get an error like > this. > > > Exception in thread "WindowsNativeRunloopThread" > java.lang.NoSuchMethodError: > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native > Method) > > at > javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412) > > at > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152) > > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > at java.base/java.lang.Thread.run(Thread.java:834) > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException > > at > > javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258) > > at > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153) > > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > at java.base/java.lang.Thread.run(Thread.java:834) > > Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll > because Eclipse sets a java.library.path who also contains the > JVM-Directories used to launch your Eclipse IDE. > > The simple work-around is to add > -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch > configuration. > > Small tiny question on the side: Wouldn't it make sense to version our > .dlls somehow to match the release eg glass-11.dll? > > Tom > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Running JavaFX-11 applications from within Eclipse fails
Well: - Launch Eclipse 2018-09 with Orcale-Java-8 - Create a maven-enabled project (I think this is important because if you launch with the FX-SDK on the command line you won't run into this) - Boom Tom On 21.10.18 11:35, Nir Lisker wrote: > Hi Tom, > > Iv'e never gotten this error. How do you reproduce this? > > - Nir > > On Thu, Oct 18, 2018 at 1:39 PM Tom Schindl <mailto:tom.schi...@bestsolution.at>> wrote: > > Hi, > > I just wanted to make you aware that if you run a JavaFX-11 application > from within Eclipse it is very likely that you'll get an error like > this. > > > Exception in thread "WindowsNativeRunloopThread" > java.lang.NoSuchMethodError: > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native > Method) > > at > javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412) > > at > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152) > > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > at java.base/java.lang.Thread.run(Thread.java:834) > > Exception in thread "JavaFX Application Thread" > java.lang.NullPointerException > > at > > javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313) > > at > > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258) > > at > > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153) > > at > javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > > at > > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > > at java.base/java.lang.Thread.run(Thread.java:834) > > Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll > because Eclipse sets a java.library.path who also contains the > JVM-Directories used to launch your Eclipse IDE. > > The simple work-around is to add > -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch > configuration. > > Small tiny question on the side: Wouldn't it make sense to version our > .dlls somehow to match the release eg glass-11.dll? > > Tom > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Running JavaFX-11 applications from within Eclipse fails
Hi, I just wanted to make you aware that if you run a JavaFX-11 application from within Eclipse it is very likely that you'll get an error like this. > Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: > > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native > Method) > at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412) > at > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > at java.base/java.lang.Thread.run(Thread.java:834) > Exception in thread "JavaFX Application Thread" java.lang.NullPointerException > at > javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313) > at > javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258) > at > javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153) > at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native > Method) > at > javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174) > at java.base/java.lang.Thread.run(Thread.java:834) Scary right! The reason is that JavaFX-11 is loading the wrong glass.dll because Eclipse sets a java.library.path who also contains the JVM-Directories used to launch your Eclipse IDE. The simple work-around is to add -Djava.library.path=C:/go-out-of-my-way-eclipse in your launch configuration. Small tiny question on the side: Wouldn't it make sense to version our .dlls somehow to match the release eg glass-11.dll? Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Aw: Re: Re: "Toolkit already initialized" error with OpenJDK 11
So how do you then load FXCanvas? It will not be found on any classpath unless you ship the FXCanvas class directly which as you see is a bad idea. I'm naturally biased but I think the approach take by e(fx)clipse is the right one as it makes sure there's ever only one instance of FXCanvas loaded in your runtime. There is more static stuff in FXCanvas (eg Transfer and DropTargets) who might or might not cause problems. BTW IIRC the SceneBuilder Eclipse integration [1] is using e(fx)clipse to load the FXCanvas. Tom [1]https://gitlab.stud.iie.ntnu.no/tobiaas/scene-builder-plugin On 05.10.18 08:46, marcel Austenfeld wrote: > Hello Tom, > > thanks for the answer. However I don't use e(fx)clipse to integrate > Javafx panels in SWT and a Rich Client Platform. > > I believe that Kevin found the problem related to different classloaders > > *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-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/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java > > On 04.10.18 15:03, marcel Austenfeld wrote: >> 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 one Eclipse > plugin. >> >> Vice versa if I try to to open the JavaFX SceneBuilder canvas which is > located in a seperate Eclipse plugin this error occurs again. >> >> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't > recognize an already started toolkit in another Eclipse plugin (which > was definitely the case with Java 8!). >> >> Maybee this has something to do with the new module system of Java >=9? >> >> >> >> >> Gesendet: Mittwoch, 26. September 2018 um 14:09 Uhr >> Von: "Kevin Rushforth" >> An: "marcel Austenfeld" , openjfx-dev@openjdk.java.net >> Betreff: Re: "Toolkit already initialized" error with OpenJDK 11 >> I'm' not aware of anything that intentionally changed between FX in JDK >> 8 and FX 11, but my guess is that the FX runtime is being shutdown after >> your first FXCanvas exits. Try making the following call (only needed >> one time) before creating your first FXCanvas: >> >> Platform.setImplicitExit(false); >> >> -- Kevin >> >> On 9/26/2018 4:22 AM, marcel Austenfeld wrote: >>> First of all congratulation to the new release and thank you for the > hard work on JavaFX. >>> >>> >>> I have a problem with JavaFX which in my case is embedded in a Rich > Client Platform of Eclipse. >>> >>> I integrated several SWT FXCanvas (some with SwingNode panels as a > SWT_AWT replacement) into my app. >>> >>> This works fine in Java 8 which my current release depends on. >>> >>> However in Java 11 after the second panel is initialized at startup I > get the following error: >>> >>> "Caused by: java.lang.IllegalStateException: Toolkit already initialized" >>> >>> Is there a new option available to avoid a new initialization of the > toolkit if several FXCanvas are embedded in an application? >>> Or do you now any changes since Java 8 which could the cause of such > an exception? >>> >>> >>> Thanks in advance for any help. >> >> > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Bad DropShadow performance
Hi Kevin,
Thank you for the comment so the trick to fix my problems is that I
don't apply the effect on the container but create a 2nd node who has
the same size and is a sibling of my area and apply the effect there?
This looks like it is working ;-)
package fxbugs;
import javafx.animation.ScaleTransition;
import javafx.application.Application;
import javafx.scene.Node;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.effect.BlurType;
import javafx.scene.effect.DropShadow;
import javafx.scene.layout.AnchorPane;
import javafx.scene.layout.GridPane;
import javafx.scene.layout.Region;
import javafx.scene.paint.Color;
import javafx.stage.Stage;
import javafx.util.Duration;
public class DropShadowPerformance extends Application {
@Override
public void start(Stage primaryStage) throws Exception {
AnchorPane p = new AnchorPane();
//
// Use a shadow
Region shadow = new Region();
shadow.setStyle("-fx-background-color: black;");
shadow.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0,
0, 0, 0.3), 10, 0.5, 0, 0));
shadow.setCache(true);
AnchorPane.setBottomAnchor(shadow, 30.0);
AnchorPane.setTopAnchor(shadow, 30.0);
AnchorPane.setLeftAnchor(shadow, 30.0);
AnchorPane.setRightAnchor(shadow, 30.0);
p.getChildren().add(shadow);
GridPane container = new GridPane();
container.setHgap(10);
container.setVgap(10);
container.setStyle("-fx-background-color: green; -fx-padding: 10;");
//container.setEffect(new DropShadow(BlurType.GAUSSIAN,
Color.rgb(0, 0, 0, 0.3), 10, 0.5, 0, 0));
for( int i = 0; i < 8; i++ ) {
for( int j = 0; j < 14; j++ ) {
container.add(createButton(), i, j);
}
}
AnchorPane.setBottomAnchor(container, 30.0);
AnchorPane.setTopAnchor(container, 30.0);
AnchorPane.setLeftAnchor(container, 30.0);
AnchorPane.setRightAnchor(container, 30.0);
p.getChildren().add(container);
Scene s = new Scene(p, 800, 600);
primaryStage.setScene(s);
primaryStage.show();
}
private Node createButton() {
Button button = new Button("hello world");
button.hoverProperty().addListener((ob,ol,ne) -> {
ScaleTransition t = new
ScaleTransition(Duration.millis(500), button);
if( ne ) {
t.setFromX(1);
t.setFromY(1);
t.setToX(1.2);
t.setToY(1.2);
} else {
t.setFromX(1.2);
t.setFromY(1.2);
t.setToX(1);
t.setToY(1);
}
t.play();
});
return button;
}
public static void main(String[] args) {
launch(args);
}
}
Tom
On 04.10.18 22:08, Kevin Rushforth wrote:
> Any effect has the potential for slowing down depending on the size if
> the node being rendered, since it is done as an image operation on the
> entire area (bounding box) covered by the Parent. Have you noticed
> whether DropShadow is worse than other effects, say, GaussianBlur? One
> other thing to note is that caching a Parent will have no effect if the
> children are animating, since it will need to be recreated each time.
>
> -- Kevin
>
>
> On 10/4/2018 11:32 AM, Dirk Lemmermann wrote:
>> Yes, I also noticed that DropShadow causes severe performance
>> degradation.
>>
>> Dirk
>>
>>> On 4 Oct 2018, at 13:10, Tom Schindl
>>> wrote:
>>>
>>> Hi,
>>>
>>> Why does applying a DropShadow on a large region cause problem when
>>> animating nodes contained in that region?
>>>
>>>> package fxbugs;
>>>>
>>>> import javafx.animation.ScaleTransition;
>>>> import javafx.application.Application;
>>>> import javafx.geometry.Insets;
>>>> import javafx.scene.Node;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.Button;
>>>> import javafx.scene.effect.BlurType;
>>>> import javafx.scene.effect.DropShadow;
>>>> import javafx.scene.layout.BorderPane;
>>>> import javafx.scene.layout.GridPane;
>>>> import javafx.scene.paint.Color;
>>>> import javafx.stage.Stage;
>>>> import javafx.util.Duration;
>>>>
>>>> public class DropShadowPerformance extends Application {
>>>>
>>>> @Override
>>>> public void start(Stage primaryStage) throws Exception {
>>>> BorderPane p = new BorderPane();
>>>> p.setPadding(new Insets(30));
>>>>
>>>>
Re: JavaFX 11 on Android
On 04.10.18 20:00, Nir Lisker wrote: > Hi Johan, > > Thanks for the work. A couple of questions: > > >> I worked from the openjfx/develop repository and created a version that >> works on Android (will work on iOS soon). > > > I'm not very familiar with the state of mobile. Doesn't Android support > only up to Java 8 API? What happens if there is 'var' in the codebase, for > example? var is a compiler only thing so it is independent of the runtime where the bytecode is 100% the same ;-) Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
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/efxclipse-rt/blob/3.x/modules/core/org.eclipse.fx.osgi/src/main/java/org/eclipse/fx/osgi/fxloader/FXClassLoader.java On 04.10.18 15:03, marcel Austenfeld wrote: > 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 one Eclipse plugin. > > Vice versa if I try to to open the JavaFX SceneBuilder canvas which is > located in a seperate Eclipse plugin this error occurs again. > > So I wonder that beginning with Java 9 the JavaFX toolkit doesn't recognize > an already started toolkit in another Eclipse plugin (which was definitely > the case with Java 8!). > > Maybee this has something to do with the new module system of Java >=9? > > > > > Gesendet: Mittwoch, 26. September 2018 um 14:09 Uhr > Von: "Kevin Rushforth" > An: "marcel Austenfeld" , openjfx-dev@openjdk.java.net > Betreff: Re: "Toolkit already initialized" error with OpenJDK 11 > I'm' not aware of anything that intentionally changed between FX in JDK > 8 and FX 11, but my guess is that the FX runtime is being shutdown after > your first FXCanvas exits. Try making the following call (only needed > one time) before creating your first FXCanvas: > > Platform.setImplicitExit(false); > > -- Kevin > > On 9/26/2018 4:22 AM, marcel Austenfeld wrote: >> First of all congratulation to the new release and thank you for the hard >> work on JavaFX. >> >> >> I have a problem with JavaFX which in my case is embedded in a Rich Client >> Platform of Eclipse. >> >> I integrated several SWT FXCanvas (some with SwingNode panels as a SWT_AWT >> replacement) into my app. >> >> This works fine in Java 8 which my current release depends on. >> >> However in Java 11 after the second panel is initialized at startup I get >> the following error: >> >> "Caused by: java.lang.IllegalStateException: Toolkit already initialized" >> >> Is there a new option available to avoid a new initialization of the toolkit >> if several FXCanvas are embedded in an application? >> Or do you now any changes since Java 8 which could the cause of such an >> exception? >> >> >> Thanks in advance for any help. > > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Aw: Re: "Toolkit already initialized" error with OpenJDK 11
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 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 refactoring for FX 9 I changed it to call FXCanvas::initFx one time > from the static block. At the same time, I changed the startup call to > use the public Platform::startup method. This change was necessary > because the javafx.swt module does not have the needed qualified exports > to call internal methods until after initialization. The public > Platform::startup method is specified to throw an exception if called > more than once. > > So if the FXCanvas class is loaded more than once, for example, if it is > called from different ClassLoaders, then that would cause the problem. > Please file a bug and I'll take a look at it. It might be as simple as > wrapping the call to Platform::startup in a try/catch and calling > Platform::runLater in the catch block. > > -- Kevin > > > On 10/4/2018 6:03 AM, marcel Austenfeld wrote: >> 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 one >> Eclipse plugin. >> Vice versa if I try to to open the JavaFX SceneBuilder canvas which >> is located in a seperate Eclipse plugin this error occurs again. >> So I wonder that beginning with Java 9 the JavaFX toolkit doesn't >> recognize an already started toolkit in another Eclipse plugin (which >> was definitely the case with Java 8!). >> Maybee this has something to do with the new module system of Java >=9? >> >> Gesendet: Mittwoch, 26. September 2018 um 14:09 Uhr >> Von: "Kevin Rushforth" >> An: "marcel Austenfeld" , openjfx-dev@openjdk.java.net >> Betreff: Re: "Toolkit already initialized" error with OpenJDK 11 >> I'm' not aware of anything that intentionally changed between FX in JDK >> 8 and FX 11, but my guess is that the FX runtime is being shutdown after >> your first FXCanvas exits. Try making the following call (only needed >> one time) before creating your first FXCanvas: >> >> Platform.setImplicitExit(false); >> >> -- Kevin >> >> On 9/26/2018 4:22 AM, marcel Austenfeld wrote: >>> First of all congratulation to the new release and thank you for the >>> hard work on JavaFX. >>> >>> >>> I have a problem with JavaFX which in my case is embedded in a Rich >>> Client Platform of Eclipse. >>> >>> I integrated several SWT FXCanvas (some with SwingNode panels as a >>> SWT_AWT replacement) into my app. >>> >>> This works fine in Java 8 which my current release depends on. >>> >>> However in Java 11 after the second panel is initialized at startup I >>> get the following error: >>> >>> "Caused by: java.lang.IllegalStateException: Toolkit already >>> initialized" >>> >>> Is there a new option available to avoid a new initialization of the >>> toolkit if several FXCanvas are embedded in an application? >>> Or do you now any changes since Java 8 which could the cause of such >>> an exception? >>> >>> >>> Thanks in advance for any help. >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Bad DropShadow performance
Hi,
Why does applying a DropShadow on a large region cause problem when
animating nodes contained in that region?
> package fxbugs;
>
> import javafx.animation.ScaleTransition;
> import javafx.application.Application;
> import javafx.geometry.Insets;
> import javafx.scene.Node;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.effect.BlurType;
> import javafx.scene.effect.DropShadow;
> import javafx.scene.layout.BorderPane;
> import javafx.scene.layout.GridPane;
> import javafx.scene.paint.Color;
> import javafx.stage.Stage;
> import javafx.util.Duration;
>
> public class DropShadowPerformance extends Application {
>
> @Override
> public void start(Stage primaryStage) throws Exception {
> BorderPane p = new BorderPane();
> p.setPadding(new Insets(30));
>
> GridPane container = new GridPane();
> container.setHgap(10);
> container.setVgap(10);
> container.setStyle("-fx-background-color: green; -fx-padding: 10;");
> container.setEffect(new DropShadow(BlurType.GAUSSIAN, Color.rgb(0, 0,
> 0, 0.3), 10, 0.5, 0, 0));
> for( int i = 0; i < 8; i++ ) {
> for( int j = 0; j < 14; j++ ) {
> container.add(createButton(), i, j);
> }
> }
> p.setCenter(container);
>
> Scene s = new Scene(p, 800, 600);
> primaryStage.setScene(s);
> primaryStage.show();
> }
>
> private Node createButton() {
> Button button = new Button("hello world");
> button.hoverProperty().addListener((ob,ol,ne) -> {
> ScaleTransition t = new ScaleTransition(Duration.millis(500),
> button);
>
> if( ne ) {
> t.setFromX(1);
> t.setFromY(1);
> t.setToX(1.2);
> t.setToY(1.2);
> } else {
> t.setFromX(1.2);
> t.setFromY(1.2);
> t.setToX(1);
> t.setToY(1);
> }
>
> t.play();
> });
> return button;
> }
>
> public static void main(String[] args) {
> launch(args);
> }
> }
If you run the following application:
* Maximize the window
* Hover over a button (eg the one in the right lower corner)
You'll notice that the animation is not smooth, setting cache flags on
the container does not improve the situation, nor does using a ONE_PASS_BOX.
Removing the effect on the container node "fixes" the problem.
This is on a MacBook Pro and Windows Surface both having a Intel Iris
Plus 650 graphics card.
Tom
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: [8u-backport] JDK-8087516 : [JavaFX] Conditional support for GTK 3 on Linux
Hi, While i can not comment on the change. This is really really great news for all people integrating JavaFX into SWT! Tom On 03.10.18 12:26, Pankaj Bansal wrote: > Hi All, > > > > Please review the patch for 8u-dev backport for HYPERLINK > "https://bugs.openjdk.java.net/browse/JDK-8087516"JDK-8087516. It adds > conditional support for gtk3. > > > > Along with the enhancement, following bug fixes have also been included in > the backport webrev > > > > 1. https://bugs.openjdk.java.net/browse/JDK-8159892: [GTK3] invalid > rendering of FX app stage in case of scaling > > 2. https://bugs.openjdk.java.net/browse/JDK-8163496: Rework Glass GTK to > correct gtk3 structure sizes > > 3. https://bugs.openjdk.java.net/browse/JDK-8145837: Remove deprecated > GTK2 calls in JavaFX > > 4. https://bugs.openjdk.java.net/browse/JDK-8165562: Upgrade to newer > version of SWT for build/test > > 5. https://bugs.openjdk.java.net/browse/JDK-8171330: Issues with > transparent stage and GTK > > 6. https://bugs.openjdk.java.net/browse/JDK-8171976: Linux: JavaFX > window not painted with background when using GTK 3 > > 7. https://bugs.openjdk.java.net/browse/JDK-8166414: Scene returns > incorrect coordinates > > 8. https://bugs.openjdk.java.net/browse/JDK-8166147: Ubuntu 16.04: > expandable content goes outside of the alert dialog > > 9. https://bugs.openjdk.java.net/browse/JDK-8152421: After initing the > modality of a non-primary stage to MODAL, closing that stage causes the > primary stage to become non-resizable > > 10. https://bugs.openjdk.java.net/browse/JDK-8090249: [Linux] Restoring > owner stage after minimize does not restore position of child stage > > 11. https://bugs.openjdk.java.net/browse/JDK-8173901: Linux: Position of > Stage is not restored after exiting full screen > > 12. https://bugs.openjdk.java.net/browse/JDK-8175204: Linux: Dialog windows > come up 1-pixel wide > > 13. https://bugs.openjdk.java.net/browse/JDK-8175205: Linux: Stage > initially in full-screen mode not shown when exiting full-screen > > 14. https://bugs.openjdk.java.net/browse/JDK-8175822: Pulldown position > regression and not painting correctly tooltips regression > > 15. https://bugs.openjdk.java.net/browse/JDK-8176844: Menus not always > selected properly with GTK 3 > > 16. https://bugs.openjdk.java.net/browse/JDK-8172219: Allow compiling > without GTK 3.0 being installed > > 17. https://bugs.openjdk.java.net/browse/JDK-8157002 Toggle gtk version if > SWT used via FXCanvas > > 18. https://bugs.openjdk.java.net/browse/JDK-8156491: Autodetect GTK > version for JFX > > > > > > The original gtk3 backport patch applied cleanly, but the bugs did not apply > cleanly. So a review is required. > > I have run the full gradle tests on Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, > Ubuntu 18.04 and have done sanity testing on Oracle Linux 7.5. > > > > webrev: http://cr.openjdk.java.net/~pbansal/gtk3_JFX_backport/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8087516 > > JDK 9 Changeset: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/8c6d0386d3f5 > > > > > > Regards, > > Pankaj > > > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
Hi, As a general rule I'm fine with that but as outlined in another reply we should only break building with older JDKs in case it really adds value. So I think we should official define the JDK N-1 and JDK N but don't pro actively break JDK N-2, ... if there's no real value. Tom On 24.09.18 16:40, Kevin Rushforth wrote: > >> In general, I think developers updating from JavaFX 11-12-13 are also >> capable of updating the JDK from 11-12-13, so I prefer the coupling >> >> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> > > This is also my preference. > > -- Kevin > > > On 9/24/2018 12:12 AM, Johan Vos wrote: >> >> >> > And it's only going to get worse as time goes on. Would it not be >> > possible to support up until the last JDK LTS(Starting at 11) >> release >> > for building JavaFX? I feel like maybe that would be more >> reasonable. >> >> This is a good question, and maybe in the future we might not be so >> quick to do this...or maybe we will. We should discuss this >> before we >> get to this point for JavaFX 13, a little less than six months >> from now. >> The choices for the model are: >> >> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> 2. Allow building JavaFX N with the most recent LTS or later. >> >> Choice #1 will allow JavaFX to better keep pace with JDK features >> (API >> or language features). Choice #2 will allow JavaFX to build and >> run with >> the most current, stable JDK LTS at the cost of not being able to use >> newer JDK features. >> >> >> One of the reasons Java is moving to a fast release cadence is because >> today, this is required to stay relevant in a fast-changing landscape. >> I think we need to do the same with JavaFX. We should be able to >> leverage the latest and greatest advances in the JDK, since this will >> allow JavaFX to move fast as well, which is required to stay relevant. >> >> If you want to run on the latest stable JDK LTS, the logical >> consequence seems to me you use the latest stable JavaFX LTS. There is >> LTS support available for both Java and JavaFX 11 and they are pretty >> well aligned. >> >> Having said that, there is no point in moving forward just for the fun >> of it. We also have to distinguish between changes in the VM or in the >> core Java API's. >> My opinion is that if a new feature is added to JDK N, we can really >> take advantage of it in JavaFX (N+1). >> In some cases, there won't be new features relevant to OpenJFX. But >> even then, I don't think we can't change our rules on a per-release >> case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; >> but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). >> >> In general, I think developers updating from JavaFX 11-12-13 are also >> capable of updating the JDK from 11-12-13, so I prefer the coupling >> >> 1. Allow building JavaFX N with either JDK N-1 or JDK N. >> >> - Johan >> >> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL
[you replied offlist but I guess that was an oversight so I bring it back] Reading through the document I don't see what concept is not working, but indeed the URL-constructor says that the protocol handler is resolved when constructing the URL. Does OneJar rely on that fact? The Stackoverflow problem who talks about Felix is strange as Felix returns in the toExternalForm() approach a custom protocol (bundle:) and Felix like eg Equinox installs an URLHandler for that protocol. URL-Handlers work prefectly fine - I know that because I maintain e(fx)clipse who is based on Equinox and we there make extensive usage of that and never had any trouble. I also found: http://one-jar.sourceforge.net/index.php?page=frameworks who talks about a custom protocol supported by OneJar but as I've never used OneJar (we use maven-shade for stuff like this) I don't know if this applies to this problem. Tom On 16.09.18 05:24, Michael Binz wrote: > Hi, > > actually this is not a problem with a particular tool we use. The > problem is that some of the concepts described in [1] that are used for > resource loading do not longer work. This impacts all tools that base > their functionality on this, See [2] for other situations where > classloader-based resource-loading fails. > > Michael. > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/lang/resources.html > [2] > https://stackoverflow.com/questions/2897/javafx-stylesheets-inside-osgi-bundle > > > Am Sa., 15. Sep. 2018 um 20:40 Uhr schrieb Tom Schindl > mailto:tom.schi...@bestsolution.at>>: > > Hi, > > I don't understand why something should be lost but anyways I don't > think JavaFX API is not the right place to fix a short coming of OneJar. > As Nir pointed out it is next to impossible to retrofit the JavaFX API > to URL with breaking it. > > Tom > > On 22.08.18 20:47, Michael Binz wrote: > > Hi all, > > > > I opened a proposal for an extension of the javafx.scene.Scene API > to allow > > to add a stylesheet using a typed java.net.URL. > > > > Currently the Scene class offers a list of stylesheet URLs in their > > stringified representation accessible by Scene.getStylesheets(). > > > > The problem is that in some cases an URL instance encapsulates > internal > > state that gets lost in the conversion into its external form and > back into > > an URL instance, namely information on an URL handler. This ultimately > > results in a failure (IOException file not found) when the Screen > class > > tries to load a stylesheet though code that loads the file > contents using > > URL#openStream() on the original URL instance can read the file > contents > > successfully. > > > > In my case the problem showed up when creating an executable jar file > > containing my JavaFX application (using OneJar). The application > startup > > in this case installs a customized Classloader that implements special > > logic for accessing the jars contained classes, This works > transparently > > for classes and resources, but the URLs returned by > Class#getResource( name > > ) do not survive the conversion to string and back because of the > described > > reason. > > > > There is a workaround that caches the resource in a temporary file and > > passes this file's URL to the Scene's list of stylesheets, but > this poses > > other problems. > > As a remark, other APIs in JavaFX use the same pattern of expecting > > stringified URLs like the Image() constructor and have the same > problem, > > but offer alternative constructors accepting a stream which allows > to solve > > the problem nicely. > > > > Please discuss and decide if the proposal can be added as a change > request > > for JavaFX. > > > > Best wishes, > > Michael. > > > > -- > Tom Schindl, CTO > BestSolution.at EDV Systemhaus GmbH > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: JI-9056801 : Scene: Allow to add a stylesheet using a typed URL, not a stringified URL
Hi, I don't understand why something should be lost but anyways I don't think JavaFX API is not the right place to fix a short coming of OneJar. As Nir pointed out it is next to impossible to retrofit the JavaFX API to URL with breaking it. Tom On 22.08.18 20:47, Michael Binz wrote: > Hi all, > > I opened a proposal for an extension of the javafx.scene.Scene API to allow > to add a stylesheet using a typed java.net.URL. > > Currently the Scene class offers a list of stylesheet URLs in their > stringified representation accessible by Scene.getStylesheets(). > > The problem is that in some cases an URL instance encapsulates internal > state that gets lost in the conversion into its external form and back into > an URL instance, namely information on an URL handler. This ultimately > results in a failure (IOException file not found) when the Screen class > tries to load a stylesheet though code that loads the file contents using > URL#openStream() on the original URL instance can read the file contents > successfully. > > In my case the problem showed up when creating an executable jar file > containing my JavaFX application (using OneJar). The application startup > in this case installs a customized Classloader that implements special > logic for accessing the jars contained classes, This works transparently > for classes and resources, but the URLs returned by Class#getResource( name > ) do not survive the conversion to string and back because of the described > reason. > > There is a workaround that caches the resource in a temporary file and > passes this file's URL to the Scene's list of stylesheets, but this poses > other problems. > As a remark, other APIs in JavaFX use the same pattern of expecting > stringified URLs like the Image() constructor and have the same problem, > but offer alternative constructors accepting a stream which allows to solve > the problem nicely. > > Please discuss and decide if the proposal can be added as a change request > for JavaFX. > > Best wishes, > Michael. > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Docs hosting for Java 11?
Well historically I think that some of those document fxml/css have been released under BSD. I know that because I needed that to ship e(fx)clipse. See http://cr.openjdk.java.net/~kcr/RT-34389/javafx-samples-8.0.0-ea/src/Ensemble8/cssref/cssref.html Tom On 31.08.18 20:58, Kevin Rushforth wrote: > I can at least ask whether this would be possible. > > -- Kevin > > > On 8/31/2018 11:51 AM, Mike Hearn wrote: >> Well, I'm not thinking about my needs here - I've already learned the >> framework. I'm more wondering how people will learn and get the tools >> for JavaFX development in future. Up until Java 11 you could at least >> go to a single website, click on fairly obvious links, end up at the >> Java 8 docs for JavaFX and start learning. Post Java 11 where do >> users go? A wiki page? That seems rather hard to find. >> >> Given the Oracle has graciously open sourced so much of the Oracle JDK >> for OpenJDK, I wonder if there's any chance of the docs being open >> sourced too so they can be reformatted, refreshed and put onto a new >> website by the community? It seems a shame to let them bit-rot. >> >> >> >> On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth >> mailto:kevin.rushfo...@oracle.com>> wrote: >> >> Ah, OK. As far as I know, the FX 8 non-API docs aren't going >> anywhere, but as you note they also aren't being updated. >> >> They are not under an open-source license. You would need to read >> the license to see what the terms of use are and whether that >> would meet your needs. >> >> -- Kevin >> >> >> On 8/31/2018 9:36 AM, Mike Hearn wrote: >>> I was actually referring to all the docs that *aren't* JavaDocs, >>> like the tutorials, the CSS reference, the getting started >>> guides, interop guides etc. >>> >>> As far as I know they haven't been updated since Java 8, however >>> the API is backwards compatible so they are still useful learning >>> materials. I am also not sure if they're open source licensed >>> though. >>> >>> It would be a huge pity and a big drag on adoption if the >>> community had to effectively produce an all new set of non-API >>> docs _from scratch_. >> >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: how to implement delayed calculation of node/shape
Why not do the necessary stuff on the next layout-pass? Tom On 27.08.18 09:48, Zsolt Kúti wrote: > Thank you for the idea, I'll explore it. > > On Sun, Aug 26, 2018 at 5:16 PM Michael Paus wrote: > >> One possible solution for this would be to use an AnimationTimer. >> Maintain a dirty state somewhere and check that when the AnimationTimer >> gets called for the next pulse. >> >> Am 26.08.18 um 16:59 schrieb Zsolt Kúti: >>> Hi, >>> Some of my classes extend Path or Group and constructed by non-trivial >>> algorithms that may use many properties, either standard (like >> strokeWidth) >>> or non-standard ones. Setting a property calculates a new state at >> present. >>> When several properties are set it means a lot of unnecessary >> calculations >>> done. >>> >>> I would like to delay geometry/shape calculations similar the way >>> Node/Shape do. They signal their state changes by dirty flagging and on >>> pulse necessary synchronization does recalculations when being dirty. >>> However relevant methods despite being public are deprecated (tipically >>> ones starting with impl_) and cannot be relied upon. >>> >>> Is there a way to achive that kind of design for own classes? >>> Thx! >>> >>> Zsolt >> >> >> -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: building webkit
I think in the longrun using the adoptjdk approch is the one to follow. Tom Von meinem iPhone gesendet > Am 25.08.2018 um 19:01 schrieb Arunprasad Rajkumar > : > > As Kevin mentioned, I tried to make WebKit build work on Travis with few > hacks(using ccache). It seemed to be working, but not consistently all the > time. > >> How does AdoptJDK solve problems of long build times? Can we not adopt >> their build chain/infrastructure? > > Looks like they host their own CI infra without relying on Travis/Appveyor. > >> On 25-Aug-2018, at 6:34 PM, Tom Schindl wrote: >> >> Hi, >> >> How does AdoptJDK solve problems of long build times? Can we not adopt >> their build chain/infrastructure? >> >> Tom >> >>> On 25.08.18 15:00, Kevin Rushforth wrote: >>> Yes, this should be possible to do. Even without build changes, we could >>> build just the SDK + WebKit (and maybe media, too, or maybe a separate >>> job for that). The problem is that even building just WebKit takes >>> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can >>> comment further. >>> >>> Irrespective of the above, as long as a compatible SDK (meaning an SDK >>> built from the current tip of jfx-dev/rt) is available for download, the >>> build can point to it, and will use the jfxwebkit and media natives from >>> that build. So if we had a nightly build available, most developers >>> could use that (it wouldn't help anyone making native changes to WebKit, >>> but would be fine for most developers who don't). >>> >>> -- Kevin >>> >>> [1] https://github.com/javafxports/openjdk-jfx/pull/121 >>> >>> >>>> On 8/25/2018 12:27 AM, Johan Vos wrote: >>>> We currently don't build WebKit with Appveyor/Travis, as the combined >>>> build >>>> time would be too long. >>>> >>>> I'm wondering though if it would be possible to have separate build jobs >>>> for webkit? Typically, when building a JavaFX SDK, the webkit part is >>>> where >>>> things go wrong (if they go wrong), and have that somehow automated would >>>> be very helpful. >>>> >>>> - Johan >>> >> >> -- >> Tom Schindl, CTO >> BestSolution.at EDV Systemhaus GmbH >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck >
Re: building webkit
Hi, How does AdoptJDK solve problems of long build times? Can we not adopt their build chain/infrastructure? Tom On 25.08.18 15:00, Kevin Rushforth wrote: > Yes, this should be possible to do. Even without build changes, we could > build just the SDK + WebKit (and maybe media, too, or maybe a separate > job for that). The problem is that even building just WebKit takes > longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can > comment further. > > Irrespective of the above, as long as a compatible SDK (meaning an SDK > built from the current tip of jfx-dev/rt) is available for download, the > build can point to it, and will use the jfxwebkit and media natives from > that build. So if we had a nightly build available, most developers > could use that (it wouldn't help anyone making native changes to WebKit, > but would be fine for most developers who don't). > > -- Kevin > > [1] https://github.com/javafxports/openjdk-jfx/pull/121 > > > On 8/25/2018 12:27 AM, Johan Vos wrote: >> We currently don't build WebKit with Appveyor/Travis, as the combined >> build >> time would be too long. >> >> I'm wondering though if it would be possible to have separate build jobs >> for webkit? Typically, when building a JavaFX SDK, the webkit part is >> where >> things go wrong (if they go wrong), and have that somehow automated would >> be very helpful. >> >> - Johan > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Swing module's module-info file
Hi, On 08.08.18 08:55, Tom Schindl wrote: > Hi Nir, > > I currently use the attached stash to make Eclipse compile all modules. > > Unfortunately I have to modify the following java-Files to get away > without any compile errors: > * Dialog => Added a method getDialog() instead of directly accessing the > field > * javafx.fxml => Add a static require for controls > * javafx.web => Add a static require for java.management Looking once more I think read-edges are completely missing in Eclipse for projects. I can patch other projects to get a read-edge but not the project itself! In the end what we want is to patch eg the javafx.fxml-module to have a read-edge for javafx.control. I don't see how this can be done with the current Eclipse setup! My work around today is to add static-require and I don't see a way around that. Tom -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Swing module's module-info file
Hi Nir, I currently use the attached stash to make Eclipse compile all modules. Unfortunately I have to modify the following java-Files to get away without any compile errors: * Dialog => Added a method getDialog() instead of directly accessing the field * javafx.fxml => Add a static require for controls * javafx.web => Add a static require for java.management * MarlinUtils => Small JavaDoc fix because one can not access sun.security Issues 1 - 3 are Eclipse issues. The error in Dialog is known by the Eclipse people. I'm not sure with the Read-Edges we'd have to add to get around the module-info.java changes, IMHO the UI in Eclipse in this area is completely senseless (or I'm too dumb to understand it) Issue 4: Is something one could discuss if the Marlin maintainers would be ok to change? Tom On 08.08.18 01:27, Nir Lisker wrote: > Ah, yes, I was trying to see what modifications each project needs so I > didn't have it modified. > > Can you share your Swing .classpath? Eclipse gives me a NPE during the > build task, I think something broke. > > On Tue, Aug 7, 2018 at 8:54 PM, Tom Schindl <mailto:tom.schi...@bestsolution.at>> wrote: > > Oh but naturally my .classpath-File is modified > > Tom > > On 07.08.18 19:51, Tom Schindl wrote: > > Yes they do! > > > > Tom > > > > On 07.08.18 19:36, Nir Lisker wrote: > >> And both newimlp and oldimpl packages compile for you? > >> > >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > mailto:tom.schi...@bestsolution.at> > >> <mailto:tom.schi...@bestsolution.at > <mailto:tom.schi...@bestsolution.at>>> wrote: > >> > >> Hi Nir, > >> > >> I'm using OpenJDK-11 in my eclipse for development so I have > that module > >> included. > >> > >> Tom > >> > >> On 07.08.18 18:34, Nir Lisker wrote: > >> > So you rebuilt the JDK with the new jdk.unsupported.desktop > module? > >> > > >> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl > mailto:tom.schi...@bestsolution.at> > <mailto:tom.schi...@bestsolution.at > <mailto:tom.schi...@bestsolution.at>> > >> > <mailto:tom.schi...@bestsolution.at > <mailto:tom.schi...@bestsolution.at> > <mailto:tom.schi...@bestsolution.at > <mailto:tom.schi...@bestsolution.at>>>> > >> wrote: > >> > > >> > Well I simply added the folder to my class-folders and > things then work > >> > perfectly fine inside Eclipse > >> > > >> > Tom > >> > > >> > On 07.08.18 14:02, Nir Lisker wrote: > >> > > Thanks for the info. I'm working on updating the > Eclipse files and > >> > this is > >> > > causing problems for javafx.swing. When will the > minimum version > >> > be bumped > >> > > to 11? > >> > > > >> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan < > >> > > prasanta.sadhuk...@oracle.com > <mailto:prasanta.sadhuk...@oracle.com> > <mailto:prasanta.sadhuk...@oracle.com > <mailto:prasanta.sadhuk...@oracle.com>> > >> > <mailto:prasanta.sadhuk...@oracle.com > <mailto:prasanta.sadhuk...@oracle.com> > >> <mailto:prasanta.sadhuk...@oracle.com > <mailto:prasanta.sadhuk...@oracle.com>>>> wrote: > >> > > > >> > >> This is because if fx is compiled with a jdk version > which does > >> > not have > >> > >> jdk.unsupported.desktop module then having > module-info.java in > >> > its original > >> > >> place would cause compilation error as module-info.java > >> contains > >> > >> > >> > >> requires static jdk.unsupported.desktop; > >> > >> > >> > >> So, the idea was to copy the file into a directory > which is not > >> > on the > >> > >> module-source-path. Then build
Re: Swing module's module-info file
Oh but naturally my .classpath-File is modified
Tom
On 07.08.18 19:51, Tom Schindl wrote:
> Yes they do!
>
> Tom
>
> On 07.08.18 19:36, Nir Lisker wrote:
>> And both newimlp and oldimpl packages compile for you?
>>
>> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl > <mailto:tom.schi...@bestsolution.at>> wrote:
>>
>> Hi Nir,
>>
>> I'm using OpenJDK-11 in my eclipse for development so I have that module
>> included.
>>
>> Tom
>>
>> On 07.08.18 18:34, Nir Lisker wrote:
>> > So you rebuilt the JDK with the new jdk.unsupported.desktop module?
>> >
>> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl
>> mailto:tom.schi...@bestsolution.at>
>> > <mailto:tom.schi...@bestsolution.at
>> <mailto:tom.schi...@bestsolution.at>>>
>> wrote:
>> >
>> > Well I simply added the folder to my class-folders and things then
>> work
>> > perfectly fine inside Eclipse
>> >
>> > Tom
>> >
>> > On 07.08.18 14:02, Nir Lisker wrote:
>> > > Thanks for the info. I'm working on updating the Eclipse files
>> and
>> > this is
>> > > causing problems for javafx.swing. When will the minimum version
>> > be bumped
>> > > to 11?
>> > >
>> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
>> > > prasanta.sadhuk...@oracle.com
>> <mailto:prasanta.sadhuk...@oracle.com>
>> > <mailto:prasanta.sadhuk...@oracle.com
>> <mailto:prasanta.sadhuk...@oracle.com>>> wrote:
>> > >
>> > >> This is because if fx is compiled with a jdk version which does
>> > not have
>> > >> jdk.unsupported.desktop module then having module-info.java in
>> > its original
>> > >> place would cause compilation error as module-info.java
>> contains
>> > >>
>> > >> requires static jdk.unsupported.desktop;
>> > >>
>> > >> So, the idea was to copy the file into a directory which is not
>> > on the
>> > >> module-source-path. Then build.gradle copy it from there to
>> gensrc
>> > >> directory optionally filtering the above line
>> > >> task copyModuleInfo(type: Copy, description: "copy module-info
>> > file to
>> > >> gensrc") {
>> > >> from "src/main/module-info/module-info.java"
>> > >> into "$buildDir/gensrc/java/"
>> > >> filter { line->
>> > >> !HAS_UNSUPPORTED_DESKTOP &&
>> > line.contains('jdk.unsupported.desktop')
>> > >> ? null : line
>> > >> }
>> > >> }
>> > >>
>> > >> Regards
>> > >> Prasanta
>> > >>
>> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
>> > >>
>> > >>> Hi,
>> > >>>
>> > >>> I didn't follow all the latest changes to the Swing
>> module, but
>> > I notice
>> > >>> now its module-info.java file is not in the same place where
>> > other modules
>> > >>> have theirs:
>> > >>>
>> > >>> It's under javafx.swing\src\main\module-info instead of
>> > >>> javafx.\src\main\java.
>> > >>>
>> > >>> Is there a reason for this?
>> > >>>
>> > >>> - Nir
>> > >>>
>> > >>
>> > >>
>> >
>> > --
>> > Tom Schindl, CTO
>> > BestSolution.at EDV Systemhaus GmbH
>> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>> >
>> >
>>
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>
>>
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Swing module's module-info file
Yes they do!
Tom
On 07.08.18 19:36, Nir Lisker wrote:
> And both newimlp and oldimpl packages compile for you?
>
> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl <mailto:tom.schi...@bestsolution.at>> wrote:
>
> Hi Nir,
>
> I'm using OpenJDK-11 in my eclipse for development so I have that module
> included.
>
> Tom
>
> On 07.08.18 18:34, Nir Lisker wrote:
> > So you rebuilt the JDK with the new jdk.unsupported.desktop module?
> >
> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl
> mailto:tom.schi...@bestsolution.at>
> > <mailto:tom.schi...@bestsolution.at
> <mailto:tom.schi...@bestsolution.at>>>
> wrote:
> >
> > Well I simply added the folder to my class-folders and things then
> work
> > perfectly fine inside Eclipse
> >
> > Tom
> >
> > On 07.08.18 14:02, Nir Lisker wrote:
> > > Thanks for the info. I'm working on updating the Eclipse files and
> > this is
> > > causing problems for javafx.swing. When will the minimum version
> > be bumped
> > > to 11?
> > >
> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> > > prasanta.sadhuk...@oracle.com
> <mailto:prasanta.sadhuk...@oracle.com>
> > <mailto:prasanta.sadhuk...@oracle.com
> <mailto:prasanta.sadhuk...@oracle.com>>> wrote:
> > >
> > >> This is because if fx is compiled with a jdk version which does
> > not have
> > >> jdk.unsupported.desktop module then having module-info.java in
> > its original
> > >> place would cause compilation error as module-info.java
> contains
> > >>
> > >> requires static jdk.unsupported.desktop;
> > >>
> > >> So, the idea was to copy the file into a directory which is not
> > on the
> > >> module-source-path. Then build.gradle copy it from there to
> gensrc
> > >> directory optionally filtering the above line
> > >> task copyModuleInfo(type: Copy, description: "copy module-info
> > file to
> > >> gensrc") {
> > >> from "src/main/module-info/module-info.java"
> > >> into "$buildDir/gensrc/java/"
> > >> filter { line->
> > >> !HAS_UNSUPPORTED_DESKTOP &&
> > line.contains('jdk.unsupported.desktop')
> > >> ? null : line
> > >> }
> > >> }
> > >>
> > >> Regards
> > >> Prasanta
> > >>
> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I didn't follow all the latest changes to the Swing
> module, but
> > I notice
> > >>> now its module-info.java file is not in the same place where
> > other modules
> > >>> have theirs:
> > >>>
> > >>> It's under javafx.swing\src\main\module-info instead of
> > >>> javafx.\src\main\java.
> > >>>
> > >>> Is there a reason for this?
> > >>>
> > >>> - Nir
> > >>>
> > >>
> > >>
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Re: Swing module's module-info file
Hi Nir,
I'm using OpenJDK-11 in my eclipse for development so I have that module
included.
Tom
On 07.08.18 18:34, Nir Lisker wrote:
> So you rebuilt the JDK with the new jdk.unsupported.desktop module?
>
> On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl <mailto:tom.schi...@bestsolution.at>> wrote:
>
> Well I simply added the folder to my class-folders and things then work
> perfectly fine inside Eclipse
>
> Tom
>
> On 07.08.18 14:02, Nir Lisker wrote:
> > Thanks for the info. I'm working on updating the Eclipse files and
> this is
> > causing problems for javafx.swing. When will the minimum version
> be bumped
> > to 11?
> >
> > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> > prasanta.sadhuk...@oracle.com
> <mailto:prasanta.sadhuk...@oracle.com>> wrote:
> >
> >> This is because if fx is compiled with a jdk version which does
> not have
> >> jdk.unsupported.desktop module then having module-info.java in
> its original
> >> place would cause compilation error as module-info.java contains
> >>
> >> requires static jdk.unsupported.desktop;
> >>
> >> So, the idea was to copy the file into a directory which is not
> on the
> >> module-source-path. Then build.gradle copy it from there to gensrc
> >> directory optionally filtering the above line
> >> task copyModuleInfo(type: Copy, description: "copy module-info
> file to
> >> gensrc") {
> >> from "src/main/module-info/module-info.java"
> >> into "$buildDir/gensrc/java/"
> >> filter { line->
> >> !HAS_UNSUPPORTED_DESKTOP &&
> line.contains('jdk.unsupported.desktop')
> >> ? null : line
> >> }
> >> }
> >>
> >> Regards
> >> Prasanta
> >>
> >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> >>
> >>> Hi,
> >>>
> >>> I didn't follow all the latest changes to the Swing module, but
> I notice
> >>> now its module-info.java file is not in the same place where
> other modules
> >>> have theirs:
> >>>
> >>> It's under javafx.swing\src\main\module-info instead of
> >>> javafx.\src\main\java.
> >>>
> >>> Is there a reason for this?
> >>>
> >>> - Nir
> >>>
> >>
> >>
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>
--
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
