JDK-8088535 Memory Leak
Noticed a recent tweet (1) about an older memory leak issue (2) and was curious if with recent performance and memory changes if anyone can confirm if this is still an issue or if it has been resolved as part of the recent changes. There appears to be a test attached to the original issue. Eric References: (1) https://twitter.com/dlemmermann/status/1477340490299330566?s=21 (2) https://bugs.openjdk.java.net/browse/JDK-8088535 -- Eric Bresie ebre...@gmail.com
Re: Bidirectional binding enhancement
Regarding the enumeration… As was touched on separately, would a “TIMER” or “TIME” based case be worth considering? For the FOCUS/ACTION…with ACTION It does FOCUS + Event, should there be one that is just “Event” (I.e. not accounting for loss of focus)? Would it need to account for “multiple Enums” being applied at one time (combination of types)? Eric Bresie ebre...@gmail.com > On November 9, 2021 at 11:45:46 PM CST, Michael Strauß > mailto:michaelstr...@gmail.com)> wrote:. > > 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.
Re: Re: Proof of concept for fluent bindings for ObservableValue
I’m no expert here so take it with a grain of salt but…
I was proposing moving this sorts of ObservableValue type interfaces and
implementations out of jfx (and React) context and into JDK context. Then
these sorts of observable type properties/ bindings can be used outside of
just UI contexts.
Eric
On Tue, Sep 21, 2021 at 12:27 PM Nir Lisker wrote:
> I'm not sure what you're proposing. Move what, to where, and for what use?
>
> On Tue, Sep 21, 2021 at 8:02 PM Eric Bresie wrote:
>
>> I’m very much an Observer here ;-) but
>>
>> Given the comparisons with FX and React implementations, is there value
>> in moving some of this out of here and into the JDK proper context making
>> it potentially usable outside of fx or react circles?
>>
>> I’m reminded of old JDK workings when someone might be working a headless
>> application needing a Swing dependency.
>>
>> Eric Bresie
>> ebre...@gmail.com (mailto:ebre...@gmail.com)
>
>
>>
>> > On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker > (mailto:nlis...@gmail.com)> wrote:
>> > >
>> > > The OrElseBinding is incorrect
>> > >
>> >
>> > Yes, that was a typo with the order of the arguments in the ternary
>> > statement.
>> >
>> > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>> > > think the tests would become pretty unreadable and less useful /
>> > > thourough otherwise).
>> > >
>> > > What are the options?
>> > >
>> >
>> > This is a bigger question. Kevin will have to answer that.
>> >
>> > As for the subscription model: flat map has a more complicated one, but
>> > > orElse, orElseGet and map all have the same one.
>> > >
>> >
>> > From what I saw, ReactFX uses a different subscription model for these.
>> I
>> > could have misread it.
>> >
>> > The messages will need to be written from the perspective of the Binding
>> > > class then IMHO.
>> > >
>> >
>> > That's fine.
>> >
>> > As for the Optional methods, I'll have a look in my code base and see if
>> > the places I would like to use them at will become irrelevant anyway
>> with
>> > the fluent bindings. I'm fine with proceeding with the current names of
>> the
>> > proposed methods.
>> >
>> > On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx > hj...@xs4all.nl)> wrote:
>> >
>> > > I need to get you the tests I wrote, unfortunately, they're JUnit 5,
>> > > please see the tests here:
>> > >
>> > >
>> > >
>> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
>> > >
>> > > The OrElseBinding is incorrect, the compute value should read:
>> > >
>> > > protected T computeValue() {
>> > > T value = source.getValue();
>> > > return value == null ? constant : value;
>> > > }
>> > >
>> > > Similar for OrElseGetBinding.
>> > >
>> > > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>> > > think the tests would become pretty unreadable and less useful /
>> > > thourough otherwise).
>> > >
>> > > What are the options?
>> > >
>> > > - Integrate a nested runner (there is an Apache 2.0 licensed one
>> available)
>> > > - Create our own nested runner (about 200 lines of code)
>> > > - Can we introduce JUnit 5?
>> > > - Rewrite to plain JUnit 4?
>> > >
>> > > Let me know, and I can integrate them.
>> > >
>> > > --John
>> > >
>> > > On 19/09/2021 02:12, Nir Lisker wrote:
>> > > > I've played around with the implementation and pushed a modified
>> > > > prototype to the sandbox [1]. I ended up with something similar to
>> > > ReactFX:
>> > > > the orElse and orElseGet methods have their own binding classes that
>> > > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding.
>> The
>> > > > reason being that both their compute value and their subscription
>> models
>> > > > are slightly different. While they can be matched to MapBinding
>> like you
>> > > > did, it entails a bit of a roundabout way in my opinion. Creating a
>> > > > supplier for the constant value of orElse somewhat defeats the
>> purpose I
>>
Re: Re: Proof of concept for fluent bindings for ObservableValue
I’m very much an Observer here ;-) but
Given the comparisons with FX and React implementations, is there value in
moving some of this out of here and into the JDK proper context making it
potentially usable outside of fx or react circles?
I’m reminded of old JDK workings when someone might be working a headless
application needing a Swing dependency.
Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)
> On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker (mailto:nlis...@gmail.com)> wrote:
> >
> > The OrElseBinding is incorrect
> >
>
> Yes, that was a typo with the order of the arguments in the ternary
> statement.
>
> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> > think the tests would become pretty unreadable and less useful /
> > thourough otherwise).
> >
> > What are the options?
> >
>
> This is a bigger question. Kevin will have to answer that.
>
> As for the subscription model: flat map has a more complicated one, but
> > orElse, orElseGet and map all have the same one.
> >
>
> From what I saw, ReactFX uses a different subscription model for these. I
> could have misread it.
>
> The messages will need to be written from the perspective of the Binding
> > class then IMHO.
> >
>
> That's fine.
>
> As for the Optional methods, I'll have a look in my code base and see if
> the places I would like to use them at will become irrelevant anyway with
> the fluent bindings. I'm fine with proceeding with the current names of the
> proposed methods.
>
> On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx (mailto:hj...@xs4all.nl)> wrote:
>
> > I need to get you the tests I wrote, unfortunately, they're JUnit 5,
> > please see the tests here:
> >
> >
> > https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
> >
> > The OrElseBinding is incorrect, the compute value should read:
> >
> > protected T computeValue() {
> > T value = source.getValue();
> > return value == null ? constant : value;
> > }
> >
> > Similar for OrElseGetBinding.
> >
> > I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> > think the tests would become pretty unreadable and less useful /
> > thourough otherwise).
> >
> > What are the options?
> >
> > - Integrate a nested runner (there is an Apache 2.0 licensed one available)
> > - Create our own nested runner (about 200 lines of code)
> > - Can we introduce JUnit 5?
> > - Rewrite to plain JUnit 4?
> >
> > Let me know, and I can integrate them.
> >
> > --John
> >
> > On 19/09/2021 02:12, Nir Lisker wrote:
> > > I've played around with the implementation and pushed a modified
> > > prototype to the sandbox [1]. I ended up with something similar to
> > ReactFX:
> > > the orElse and orElseGet methods have their own binding classes that
> > > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The
> > > reason being that both their compute value and their subscription models
> > > are slightly different. While they can be matched to MapBinding like you
> > > did, it entails a bit of a roundabout way in my opinion. Creating a
> > > supplier for the constant value of orElse somewhat defeats the purpose I
> > > think.
> >
> > I have no strong opinion here, just wanted to keep the MR small. The
> > supplier should be an inline candidate, but creating a separate class is
> > fine too.
> >
> > As for the subscription model: flat map has a more complicated one, but
> > orElse, orElseGet and map all have the same one.
> >
> > > In addition, I think that it's fine to move the arguments' null checks to
> > > the binding classes themselves, even if it's a couple of levels deeper on
> > > the stack, while adding a message in the 2nd argument of
> > > Objects.requireNonNull for clarity. These classes are "self-contained" so
> > > it makes sense for them to check their arguments. They might be used in
> > > other places, perhaps in the public Bindings class.
> >
> > The messages will need to be written from the perspective of the Binding
> > class then IMHO.
> >
> > > I also moved the subscription-related methods from ObservableValue to
> > > static methods in Subscription, at least for now, to defer the API
> > related
> > > to Subscription.
> >
> > Sounds good.
> >
> > > The branch doesn't compile because I didn't finish working on the
> > > visibility issue, but it's close enough
Re: RFR: 8258499: JavaFX: Move src.zip out of the lib directory
Was reading https://stackoverflow.com/questions/29258944/where-is-the-src-zip-for-jdk8u40 on location on sec.zip and they had in similar layout for JDK and Java-Jax locations. Assume as long as jfx isn’t loaded at the same location as JDK (which since it’s a separate project now) this shouldn’t be a problem. Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On June 30, 2021 at 10:15:15 AM CDT, Kevin Rushforth (mailto:k...@openjdk.java.net)> wrote: > The JavaFX SDK bundle provides a set of modular jars in the `lib` directory. > It provides a `src.zip` file for use by IDEs in that same `lib` directory. If > a developer adds the `lib` directory to their application's module path in > the 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. > > The proposed solution is to move the `src.zip` file from the lib directory to > the top directory of the SDK. > > With this fix, the layout of the SDK will be: > > > / > bin/ (Windows) > (Windows) > > legal/ > ... > > lib/ > *.jar > (macOS and Linux) > > src.zip > > > NOTES: > 1. The JavaFX Eclipse plugin will need a minor change, which is tracked by > eclipse-efx/efxclipse-eclipse#85. > 2. This still needs to be tested on IntelliJ > > - > > Commit messages: > - 8258499 (tel:8258499): JavaFX: Move src.zip out of the lib directory > > Changes: https://git.openjdk.java.net/jfx/pull/558/files > Webrev: https://webrevs.openjdk.java.net/?repo=jfx=558=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8258499 > Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/558.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/558/head:pull/558 > > PR: https://git.openjdk.java.net/jfx/pull/558
Re: Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3]
> security manager That’s not the same security manager being discussed as being deprecated for Java 17 and beyond is it? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On June 25, 2021 at 4:20:03 PM CDT, Kevin Rushforth (mailto:k...@openjdk.java.net)> wrote: > On Thu, 24 Jun 2021 23:00:42 GMT, Phil Race (mailto:p...@openjdk.org)> wrote: > > Overall the new API and functionality looks good, and fills a void that was > discussed [in this > thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-May/023292.html) > a couple years ago. > > General comments: > > The first, which is the one we had been discussing, is where the URL is a > valid file URL, but the program can't write to it, either because we are > running with a security manager and the application doesn't have permission, > or because we can't write to the output file (e.g., the path doesn't exist or > is read-only). > > PR: https://git.openjdk.java.net/jfx/pull/543
Re: Re: Minimum JDK policy for OpenJFX
Are there any deprecated or removed (1) (2) dependencies that could cause problems? (1) https://jdk.java.net/16/release-notes#removed (2) https://mail.openjdk.java.net/pipermail/jdk-dev/2021-March/005191.html Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On May 18, 2021 at 4:42:45 PM CDT, Nir Lisker (mailto:nlis...@gmail.com)> wrote: > > > > there are some advantages in being able to run with the latest JDK LTS > > > > One *potential* issue with this approach is that LTS is not defined in > OpenJDK as far as I know. The LTS versions are a business decision of each > distributor. For now, they have all aligned on 8, 11, 17, but nothing > guarantees that this will stay so. What if different vendors LTS different > versions? Suppose that Valhalla and Loom add very attractive features in > JDK 19 (big performance enhancements, leads to big money savings on > hardware, leads to economic incentives to use these, leads to requests to > support these), now vendors can declare JDK 19 as LTS, and what will JavaFX > do? > In OpenJDK all versions are treated equally as it is a spec and not a > business model. Should JavaFX be coupled to business models? Maybe Gluon > has some insights since they give JavaFX LTS support. > > A second point, as Michael Strauß mentioned, is that maybe we should see > what features are going to be delivered in the next versions and judge if > there's something attractive enough for library developers to base our > decision on. Sealed classes from Amber are certainly one of them. Panama > might provide handy features for JavaFX's interfacing with native code, > like Foreign Memory Access, though I didn't look into it in detail. > Valhalla is certainly too far away to consider, and Loom is rather > irrelevant for JavaFX and GUIs in general. > If anyone has insights into relevant upcoming features I'll be happy to > learn. > > - Nir > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth (mailto:kevin.rushfo...@oracle.com)> > wrote: > > > A very timely question. I was already planning to raise this as a > > discussion after we update our boot JDK to JDK 16 (blocked by the > > in-progress gradle 7 update), which I hope to do later this week. > > > > I think that this is the right time to consider bumping the minimum > > required version to run JavaFX 17 to JDK 16, which would allow us to > > start using APIs and language features from JDK 12 through JDK 16 > > inclusive. > > > > In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In > > practice, though, we don't bump it for each release, as there are some > > advantages in being able to run with the latest JDK LTS. Since JavaFX 17 > > will release at roughly the same time as JDK 17 LTS, I can't think of a > > good reason to not update our minimum. > > > > Comments? > > > > -- Kevin > > > > > > On 5/18/2021 7:59 AM, Michael Strauß wrote: > > > Currently, JDK 11 is required for the latest version of OpenJFX. What > > > is the policy for bumping this requirement? Does it always correspond > > > to the latest JDK LTS release (the next of which will be JDK 17), or > > > is it independent from the release cycle of OpenJDK? > > > >
Re: Re: Build error with gradle (command line)
Assume it has to do with some of this.. https://docs.gradle.org/current/userguide/dependency_verification.html Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On May 11, 2021 at 6:41:05 AM CDT, Kevin Rushforth > mailto:kevin.rushfo...@oracle.com)> wrote: > I see that Ajit answered already with option #1 and that you are going > to try option #2. We might want to document this on the "Building > JavaFX" Wiki page. > > To expand on this a bit, what I think must have happened is that the > contents of the pom files changed some time in the not-too-distant-past > so that the current checksums don't match those previously cached pom files. > > -- Kevin > > > On 5/11/2021 4:36 AM, Kevin Rushforth wrote: > > We've had a couple other reports about this. The solutions that you > > can try (should only be needed one time) are: > > > > 1. gradle --refresh-dependencies ... > > > > 2. Remove the gradle cache before building: > > cd $USERPROFILE/.gradle > > rm -rf caches native > > gradle ... > > > > If this doesn't work, I will propose that we disable checking of the > > pom files in verification.xml. > > > > -- Kevin > > > > > > On 5/11/2021 2:28 AM, Jeanette Winzenburg wrote: > > > > > > Just sync'ed my local repository with upstream .. now can't build > > > with gradle, the error: > > > > > > * Where: > > > Build file > > > 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle' > > > line: 4249 > > > > > > * What went wrong: > > > A problem occurred evaluating root project 'jfx-fork'. > > > > Dependency verification failed for configuration ':apps:lucene' > > > 8 artifacts failed verification: > > > - apache-13.pom (org.apache:apache:13) from repository MavenRepo > > > - lucene-core-7.7.3.pom (org.apache.lucene:lucene-core:7.7.3) > > > from repository MavenRepo > > > - lucene-grouping-7.7.3.pom > > > (org.apache.lucene:lucene-grouping:7.7.3) from repository MavenRepo > > > - lucene-parent-7.7.3.pom (org.apache.lucene:lucene-parent:7.7.3) > > > from repository MavenRepo > > > - lucene-queries-7.7.3.pom > > > (org.apache.lucene:lucene-queries:7.7.3) from repository MavenRepo > > > - lucene-queryparser-7.7.3.pom > > > (org.apache.lucene:lucene-queryparser:7.7.3) from repository MavenRepo > > > - lucene-sandbox-7.7.3.pom > > > (org.apache.lucene:lucene-sandbox:7.7.3) from repository MavenRepo > > > - lucene-solr-grandparent-7.7.3.pom > > > (org.apache.lucene:lucene-solr-grandparent:7.7.3) from repository > > > MavenRepo > > > This can indicate that a dependency has been compromised. Please > > > carefully verify the checksums. > > > > > > Looks like I have to update some local files, shouldn't that happen > > > automagically? > > > > > > -- Jeanette > > > > > > > > >
Re: Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
Silly question, is the difference with Windows just the nature of the native support on each platform (Unix based vs Windows) and libraries used as part of that? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On April 1, 2021 at 4:29:09 PM CDT, Kevin Rushforth (mailto:k...@openjdk.java.net)> wrote: > On Thu, 1 Apr 2021 20:18:03 GMT, John Neffenger (mailto:jgn...@openjdk.org)> wrote: > > > > IMHO, it would make sense to merge any clear improvement of the > > > status-quo and debug+fix more in a later PR. "Perfect is the enemy of > > > good." > > > > > > Regarding Webkit, I know of > > > https://bugs.webkit.org/show_bug.cgi?id=174540 > > > https://bugs.webkit.org/show_bug.cgi?id=188738 > > > https://build.opensuse.org/request/show/667729 > > > but your version is probably not *that* old. > > > > > IMHO, it would make sense to merge any clear improvement of the > > > status-quo and debug+fix more in a later PR. > > > > I agree that we will have to draw the line somewhere, but right now I'm > > down to just one file on one operating system out of 10,633 files in the > > build output! (It's just `jfxwebkit.dll` on Windows.) It would be a shame > > to give up now. > > > > I would, though, like to postpone tests of static builds and builds for > > Android and iOS. My priorities for this pull request are: > > > > 1. Linux distributions building JavaFX > > 2. Developers building JavaFX from the repository source with the build > > defaults > > 3. Oracle, Gluon, and BellSoft building JavaFX for their customers and for > > downloading > > > > I would be happy to satisfy just the first group, but we might be close to > > getting all three. > > @sashamatveev Can you look at the changes to the media Makefiles? > > - > > PR: https://git.openjdk.java.net/jfx/pull/446
Re: Re: Implementing a shader API
Don’t suppose integrating Java OpenGL if not already done would help? https://jogamp.org/jogl/www/ They are a little dated but there are the OpenGL related JSRs like JSR 239: JavaTM Binding for the OpenGL® ES API https://www.jcp.org/en/jsr/detail?id=239 I think this was targeted at Java ME mobile platforms JSR 231: JavaTM Binding for the OpenGL® API https://www.jcp.org/en/jsr/detail?id=231 Or is some updated JSR really needed here? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On March 26, 2021 at 10:34:58 AM CDT, Nir Lisker (mailto:nlis...@gmail.com)> wrote: > Let's keep the discussion in the openjfx-disc...@openjdk.java.net > (mailto:openjfx-disc...@openjdk.java.net) list for > now. I'm sending this mail on the dev list just for continuity. > > I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > > someone give me a quick rundown on that? > > > > The D3D shader pointers are in D3DPhongShader.h. There is 1 vertex shader > and several pixel shaders that account for different illumination modes for > performance reasons, and these are swapped at runtime in D3DMeshView.cc > (http://D3DMeshView.cc) > whenever a render is requested. > In this class, the vertex shader is set > with IDirect3DDevice9::SetVertexShader, taking > in D3DPhongShader::getVertexShader. The pixel shader is set > with D3DPhongShader::setPixelShader, taking in the illumination mode > parameters and retrieving the appropriate shader. It is then set with > IDirect3DDevice9::SetPixelShader. > > Regarding the shader API, if an error occurs during shader compilation, > > should it simply default to the basic Phong shaders or throw an Exception > > (likely in a new package with other shader stuff)? > > > > If you are talking about a new API, then this is too detailed to figure out > at this point. We need to step back and figure out how to have things > working with each other before figuring out what to do on invalid input. > > On Fri, Mar 26, 2021 at 5:58 PM Jacky Guo (mailto:jackyguo...@gmail.com)> wrote: > > > Regarding the shader API, if an error occurs during shader compilation, > > should it simply default to the basic Phong shaders or throw an Exception > > (likely in a new package with other shader stuff)? > > > > I'm also very clueless as to how JavaFX links D3D shaders at runtime. Can > > someone give me a quick rundown on that? > > > > On Wed, Mar 17, 2021 at 9:06 PM Dan Howard > (mailto:spro...@videotron.ca)> wrote: > > > > > This is cool. You should like up with Almas Baimagambetov > > > > > > > > > https://github.com/AlmasB > > > > > > > > > On 3/15/2021 10:12 PM, Jacky Guo wrote: > > > > Regarding uniform parameters (i.e. variables set from Java and called on > > > > the shader): > > > > Since OpenGL's data passing uses locations, you could simply store a > > > map of > > > > uniform parameters (or whatever their JSL equivalent is) to their > > > > locations, and call the required methods and perform the necessary > > > > type-safety checks. > > > > For D3D, you would still use the parameter map, but only for type > > > safety. > > > > > > > > This is assuming I understand how the APIs work and I am not overlooking > > > > something crucial. > > > > > > > > On Mon, Mar 15, 2021 at 4:51 AM Nir Lisker > > > (mailto:nlis...@gmail.com)> wrote: > > > > > > > > > I've thought about this too for a bit. My question would be how to > > > > > tell > > > > > the CPU what data to pass to the shader. Take OpenGL for example: > > > writing > > > > > an API to pass a shader and compiling it in runtime is not hard, but > > > you > > > > > need the CPU side to feed the shader its parameters. You would need an > > > API > > > > > for arbitrary data that the shader has been preconfigured to handle. > > > That's > > > > > quite an undertaking. > > > > > And what level of flexibility is this going to give? The shader might > > > > > require data that the public Java API does not expose, so you are > > > limited > > > > > in that regard too. When I wrote the enhancements for the shaders, I > > > also > > > > > had to change the Java side, which you won't be able to do. > > > > > On the D3D side, the shaders are precompiled, so it's a slightly > > > different > > > > > story. > > > > > > > > > > - Can
Re: Re: Not really a nice comment but a real issue?
Just scanning the javafx ports/openjfx GitHub repository listed below, there appears to have been over 650 GitHub issues raised (and still growing). Some I see labeled as “bugs” but what about all the others? It looks that the port project has basically indicated moved to the official https://github.com/openjdk/jfx which no longer allows issues to be raised there like the port version. But that said what about all those issues on the port repository? Does raising issue on that need to be disable maybe? Or would allowing issues on the official repository be good in some way? Is it possible to “mirror” the ticket on GitHub to create an official one in the official Java bug tracking? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On March 19, 2021 at 2:47:32 PM CDT, John Neffenger (mailto:j...@status6.com)> wrote: > On 3/19/21 12:37 PM, Philip Race wrote: > > I'm surprised credit is considered important > > It took me weeks to figure out some bugs and create a good report, all > done as a volunteer in my spare time. Credit is my only compensation. > > I went as far as sneaking my name into the source code comments just to > have it show up somewhere in the report where it wouldn't be removed. > > > But FX never used the github bug tracker. It should never have been > > possible to submit bugs there. > > Oh, but it did! > > https://github.com/javafxports/openjdk-jfx/issues > > John
Re: Re: RFR: 8262276: Debug build of WebKit fails
Silly question, when building, at what point would any sort of memory setting be provided? Is that a lack of enough physical memory, not enough memory based on an environment variable or config file? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On March 9, 2021 at 12:42:05 AM CST, PrimosK > (mailto:github.com+1519324+prim...@openjdk.java.net)> wrote: > On Tue, 9 Mar 2021 06:30:46 GMT, PrimosK > (mailto:github.com+1519324+prim...@openjdk.org)> wrote: > > > > > > The build failed again. The only difference I can spot at this time > > > > > is the line at which the build failed (it changed from 3445 to 3453): > > > > > ... > > > > > Please let me know if you need any further information. > > > > > > > > You might be running into a different problem then, since this patch > > > > solve the compilation problem for Arun, for me, and for our CI build > > > > systems, when building with `-PCONF=DebugNative` (as a side note, we > > > > have some problems running the unit tests, but that's a separate > > > > issue). I have a couple questions for you: > > > > > > > > 1. Does the build work if you build without `-PCONF=DebugNative`? If it > > > > still fails, then you are definitely running into a different problem, > > > > likely something in your environment. > > > > 2. Can you double-check the versions of the build tools that you are > > > > using? We build using Visual Studio 2019 rather than the 2017 that you > > > > are using, although it will build with the latest VS2017 update. The > > > > versions of the other tools should be: > > > > > > > > * gradle 6.3 > > > > * cmake 3.13.3 > > > > * ninja 1.8.2 > > > > > > > > 1. Have you tried building on a platform other than Windows? > > > > > > **1.** > > > No, it doesn't work. As already stated in the > > > [JDK-8262276](https://bugs.openjdk.java.net/browse/JDK-8262276), the > > > build fails for me with the exactly same error also when I set: > > > COMPILE_WEBKIT = true > > > CONF = Release > > > > > > in `gradle.properties`. > > > > > > **2.** > > > ATM I am using these libraries: > > > > > > - Javafx (`pull/417`) > > > - Java 15 (installed on Windows) > > > - Ant 1.10.5 (installed on Windows) > > > - **CMake 3.13.3** (installed on Windows) > > > - Visual Studio 2017 community edition (**Ninja 1.8.2**) > > > - **Gradlew 6.3** > > > - CygWin (installed on Windows) with the following packages: > > > - bison 3.0.4-1 > > > - flex 2.6.4-2 > > > - gcc-g++ 10.2.0-1 > > > - git 2.30.0-1 > > > - gperf 3.1-1 > > > - make 4.3-1 > > > - makedepend 1.0.6-1 > > > - openssh 8.4p1-2 > > > - perl 5.32.1-1 > > > - python27 2.7.18-4 > > > - ruby 2.6.4-1 > > > - unzip 6.0-17 > > > - zip 3.0-12 > > > > > > But I am seeing exactly the same error. > > > > > > **3.** > > > No - I've tried it only with Windows as we need debug symbols there... > > > > > > Side note: > > > > > > Could you guys please provide me with the versions of the above libraries > > > that are used in the case of your CI build system? Is now Visual Studio > > > the only difference? I tried to check it by myself by going through the > > > log files at https://github.com/arun-Joseph/jfx/runs/2028653928 but I > > > couldn't found CygWin plugin versions (bison, flex...). > > > > > > Tomorrow I will try building it using Visual Studio 2019. > > > > Hi everyone, > > > > Today I've tried to create a build using **Visual Studio 2019** but with no > > success. I am seeing the same error. > > > > There is a complete output of `./gradlew --scan`: > > [build-output.txt](https://github.com/openjdk/jfx/files/6106294/build-output.txt) > > > > The build scan is available there: > > https://scans.gradle.com/s/dimrfirscg7hm > > > > OS: > > - Windows 10 > > > > Repository: > > - JavaFx (pull/417) > > > > Installed libraries: > > - Java 15 (15+36-1562) > > - Ant 1.10.5 > > - Gradlew 6.3 > > - CMake 3.13.3 > > - Visual Studio 2019 community edition (VS2019-16.7.2+1.0) > > - Ninja 1.8.2 > > > > CygWin (installed on Windows) with the following packages: > > - bison 3.0.4-1 > > - flex 2.6.4
Re: Re: font color fringes on macOS, not a priority?
Just curious...while reading up on the below Metal API / MacOS OpenGL depreciation, I notice reference to coming changes with OpenGL relating to transition to “Vulkan” which if I understand correctly may be a similar change in lower level graphics API (I think similar to Metal). Will updated to JFX with something similar eventually also be needed there as well? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On February 26, 2021 at 12:02:11 PM CST, Kevin Rushforth > mailto:kevin.rushfo...@oracle.com)> wrote: > Part of that 11+ minutes of the macOS build on GitHub Actions (which > starts from a clean machine) is downloading and installing the JDK and > other tools (gradle, etc), and cloning the repo. Also, incremental > builds are much faster after the first one. So even if you do a full > build once, subsequent builds for the debug-edit-build cycle is pretty > quick. > > Phil might want to comment about the possibility of eliminating > sub-pixel (LCD) text entirely on macOS. If it does turn out to be > something worth doing, I note that macOS 10.13 is pretty old by now, so > that wouldn't be a compelling reason to hold off (as long as it doesn't > regress horribly). > > As for Project Lanai, that isn't related to this issue. Lanai is an > implementation of the Java2D back end on Apple's Metal API (as an > alternative to OpenGL). See JEP 382 [1] for more information. We will > very likely do the same for FX starting in the not-too-distant future. > > -- Kevin > > [1] https://openjdk.java.net/jeps/382 > > > On 2/26/2021 9:39 AM, John Neffenger wrote: > > On 2/26/21 6:56 AM, Rob Nikander wrote: > > > I wonder if I can get a dev setup with a quick edit-compile-run > > > cycle, or if the compile step takes a long time. > > > > The builds for macOS are taking just over 11 minutes on GitHub. > > > > To speed that up, I do my development in a project with only the > > JavaFX Graphics module, linked below, and then use a guest machine to > > do a full build for amd64 and armhf. Things go pretty quickly with the > > help of 'rsync'. Not sure whether the same setup would help on macOS. > > > > JavaFX Graphics > > https://github.com/jgneff/javafx-graphics > > > > > Do you know if the color fringes are being produced by the Core Text > > > rendering to a bitmap, and not the subsequent OpenGL phase? > > > > No, I don't. I also don't know how the JavaFX code for macOS relates > > to what's going on with the Lanai Project: > > > > Lanai Project > > https://wiki.openjdk.java.net/display/lanai/Main > > > > Regarding my suggestion of removing the sub-pixel rendering, it would > > be good to check how many Macs out there are still running on macOS > > 10.13 High Sierra and earlier. Apple removed its sub-pixel rendering > > and switched to grayscale anti-aliasing in macOS 10.14 Mojave. > > > > John >
Re: Layering JavaFX onto an external rendering context
There was a thread around obsolete rendering code (1) around removal of Prisim rendering and related api layers architectural elements later on. Is this relevant here? Eric (1) https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-January/028581.html On Wed, Feb 17, 2021 at 8:11 AM Herve Girod wrote: > There is also something that we should be aware of. The external graphic > context is a fragile thing. In our case, for example with OpenGL, it was > very easy to create problems with the Java app which try to paint things on > the context. Which can lead to crashes or artefacts. > > Le mer. 17 févr. 2021 à 12:06, Neil C Smith a écrit > : > > > On Tue, 16 Feb 2021 at 23:33, Michael Strauß > > wrote: > > > The main problem with this idea is that there is no universally > available > > > hardware rendering backend in JavaFX. There's OpenGL on Linux and > macOS, > > > Direct3D on Windows, and potentially a software renderer on all > > platforms. > > > > How is that a problem? Not all platforms support PosixFilePermissions > > either. I used that io -> nio2 comparison because of that similar > > choice of lowest denominator abstraction as opposed to an API for > > querying capabilities and exposing them if available. Most, if not > > all, of the use cases here are about interaction with libraries using > > native components that are either not universally available or provide > > platform-specific alternatives too? > > > > Incidentally, does the OpenGL renderer not work on Windows at all, or > > just not get used by default? Can't remember. > > > > > It is generally not safe to expose the OpenGL rendering context > > > that is used internally by JavaFX, because users might inadvertently > > change > > > the GL state machine. > > > > Why is that actually a problem? Surely caveat emptor has to apply > > here? And potentially access can be managed within scopes that > > require permissions, push/pop state, etc if required? > > > > Best wishes, > > > > Neil > > > > -- > > Neil C Smith > > Codelerity Ltd. > > www.codelerity.com > > > > Codelerity Ltd. is a company registered in England and Wales > > Registered company number : 12063669 > > Registered office address : Office 4 219 Kensington High Street, > > Kensington, London, England, W8 6BD > > > -- Eric Bresie ebre...@gmail.com
Re: Re: Make javafx.controls open and community-driven
I assume since JFX stated with and was closely coupled with Java prior to being removed from the JDK/JRE, this allow for the link up with the java bug link. The case could be made it could be similar to the other library’s. I believe some other existing libraries (JAXB?) were removed [maybe more for modularity and smaller profiles but] in favor of the having dependency when needed but allowing development separately as independent projects but the specific I’m a little fuzzy on). Since JFX was Sun/Oracle IP, I assume this also accounts for some of the restrictions. As I understand in the grand open bizaar scheme that if there are areas that are closed, re-implement and replace it with open where applicable. Now with all those comments out of the way... Regarding the decoupling java fix.controls...With modularity in mind, would it be worth having a service layer / package / module interface added in some way and then make existing controls implementations of the service then further improvements could implement and/or extend as preferred as implementations of this? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On February 3, 2021 at 6:24:20 AM CST, naast...@gmail.com > (mailto:naast...@gmail.com) wrote: > What do you think about decoupling javafx.controls from other modules private > API? Is it possible? In current situation > it may be the best solution, because this would allow to fork it. So, those > who interested could play with fork(s) and > backport changes when neccessary. It would also allow to develop other > controls libs, those aren't based of > javafx.controls, e.g. just for mobile. > > Best regards > Mike > > On Tue, 2021-02-02 at 13:40 -0800, Kevin Rushforth wrote: > > There are two separate issues here. I won't address the first point from > > the initial poster, other than to say that I understand that the lack of > > direct write access to JBS for occasional contributors is a pain point. > > I don't think it is stopping anyone from contributing, though. As for > > the other part of this point, JavaFX is already on GitHub along with the > > rest of the JDK, and it's easy enough for someone who is motivated to > > provide a pull request for a bug fix. > > > > The more interesting question is the one about extensibility that others > > have also responded to. This raises the question of which areas are most > > in need of new public API to facilitate this. "Just make every internal > > detail of your implementation public or protected" isn't the right way > > to frame the discussion. Anything that makes it into the public API is > > something that needs to be documented, tested, and supported. It > > requires us to consider what it means to support that API forever; we > > take compatibility seriously. The main idea is to think in terms of > > "stewardship" when evolving the JavaFX API. > > > > Keeping that in mind, there are certainly areas that could be made > > easier to extend. Two things in the UI Controls area that were brought > > up are skins, which are public API with not all of the fields and > > methods of the skins are public/protected, and behaviors. The former > > isn't too difficult to address. It requires some amount of thought, > > discussion, API documentation, implementation, and testing, but doesn't > > need a whole new design. VirtualFlow has been extended in this fashion > > to provide missing pieces for third-party controls. If there are others, > > developers can propose them and we can discuss them. This is definitely > > an area we would welcome well-thought-out contributions in. > > > > The harder area is that of behaviors. For a little background, a public > > behaviors API was originally part of the proposed new public API for FX > > in JDK 9, which was done via JEP 253 [1]. It was decoupled from that > > JEP, but still remains an open enhancement request tracked by > > JDK-8091189 [2]. That JBS issue has a very long discussion thread about > > possible approaches for the API. This would be a very large effort, and > > would require someone with a very good understanding of both UI control > > design in general and the design and implementation of JavaFX UI > > Controls in particular to lead the effort. It isn't something that we > > would accept from an application developer who is just wanting to make > > their life easier. Again, think of it in terms of API stewardship. I'm > > not saying there is no way this could be done, just that it's unlikely. > > > > I'm sure there are other areas outside of UI controls that could be made > > more extensible, too (although knowing how fragile CSS is, I wouldn't >
Re: Re: cleanup obsolete code
Would removal of this break anything on other platforms (OS or hardware
[embedded/non-embedded], Wayland)? Assume since focused x11 (mainly Unix
platforms) it shouldn’t but figured I’d ask.
A little off topic but is an architecture diagram with applicable elements
available someplace? If not am I correct in saying from a high to lower layer
there is
- Prism - which renders scenes. A believe this was deprecated/removed at some
point in more recent updated
- ES2 - provide acceleration (possibly hardware if supporting)
- GL - open gl for graphical / harder rendering
- X11 - UNIX windowing client/server protocols communications between
- Monocle - the “glass” layer where the above are rendered
- OS/Kernel
Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)
> On January 18, 2021 at 2:38:17 AM CST, Johan Vos (mailto:johan@gluonhq.com)> wrote:
> Related to this question, there is the comment from Kevin about removing
> references to es2-eglfb/es2-eglx11 in other files, e.g. ES2Pipeline.java [1]
> While I believe this is a good idea, it opens room for more cleanup (or at
> least more consistency):
> In some cases, library names indicate a configuration. For example,
> prism-es2-monocle indicates that the glass-platform monocle is used. In
> most cases though, the library names do not contain this information. On
> mac/linux/windows/ios, we simply use prism-es2 . Obviously, the contents of
> the library vary for the different platforms, but this is taken care of by
> the build process.
>
> This inconsistency leads to avoidable logic in the Java classes, e.g. in
> ES2Pipeline. After cleaning up for the unused egl{fb,x11} variants, there
> will still be a check about which library should be loaded: if the glass
> variant is monocle, prism-es2-monocle is loaded. In all other cases,
> prism-es2 is loaded.
> I think the name of the library should either always contain the glass
> variant name, or never. I have a preference for removing the variant in the
> name completely, as this will allow us to remove even more logic in the
> .java files.
>
> [1] https://github.com/openjdk/jfx/pull/378#issuecomment-761673755
>
>
> On Sat, Jan 16, 2021 at 1:26 PM Johan Vos (mailto:johan@gluonhq.com)> wrote:
>
> > I would guess those were used before Monocle was introduced.
> >
> > On Sat, Jan 16, 2021 at 12:47 PM Nir Lisker > (mailto:nlis...@gmail.com)> wrote:
> >
> > > Out of curiosity, what were they used for?
> > >
> > > On Thu, Jan 14, 2021 at 3:54 PM Johan Vos > > (mailto:johan@gluonhq.com)> wrote:
> > >
> > > > Hi,
> > > >
> > > > We currently have a number of GLFactory implementations in the ES2 Prism
> > > > pipeline that are probably never used: EGLX11 and EGLFX. On Linux, we
> > > > use
> > > > X11, and systems with monocle can use either egl, X11, fb,... but that
> > > > is
> > > > then managed by the MonocleGLFactory.
> > > >
> > > > Unless these files are used, I suggest they are removed (that is the
> > > > java
> > > > classes and the native code).
> > > >
> > > > The static initialiser of GLFactory will then have only 2 choices for
> > > > factoryClasses that can be used on Linux: X11, or Monocle. The latter is
> > > > only used if the System Property `embedded` is set to `monocle` (as
> > > > checked
> > > > in PlatformUtil). We can replace this in a check on the Glass platform
> > > > (which is already done in Glass: com.sun.glass.ui.Platform will check
> > > > the
> > > > value of `glass.platform`, and Monocle will be selected in Glass in case
> > > > the value is set to `Monocle`.)
> > > > Clearly, Prism and Glass are 2 different things, but I personally would
> > > > prefer to have the decision whether to use X11 or Monocle to be based on
> > > > this `glass.platform` property rather then on yet another property
> > > > (`embedded`) that is apart from this not used for anything else.
> > > >
> > > > I will create an issue for this, but in case I'm missing something,
> > > > please
> > > > let me know.
> > > >
> > > > - Johan
> > > >
> > >
Re: Re: RFR: 8254691: Enable GitHub actions for jfx repo
So this doesn’t show lower level test just basically a build successfully pass/fail on each platform? Or would it show any low level tests if they failed? Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On October 28, 2020 at 9:43:53 AM CDT, Kevin Rushforth (mailto:k...@openjdk.java.net)> wrote: > On Tue, 27 Oct 2020 19:02:40 GMT, Kevin Rushforth (mailto:k...@openjdk.org)> wrote: > > > > ### Note to reviewers: > > > > > > If you want to test this yourself you can pull the PR branch into a > > > branch in your local repo and push it to your personal fork. Something > > > like the following should work for you, assuming that you are in your > > > local repo with `origin` pointing to your personal fork: > > > > > > git fetch https://github.com/openjdk/jfx.git pull/338/head:pr-338 > > > git push -u origin pr-338 > > > > > > Then you will be able to see the GitHub action workflow and track its > > > progress by clicking on the "Actions" tab on your personal fork repo page. > > > > See PR #339 for an example (using an intentionally injected failure) of > > what a failed build or test will look like. > > I merged `master` into my local branch so it would run the tests again on an > up-to-date repo. > > - > > PR: https://git.openjdk.java.net/jfx/pull/338
Re: Re: Can't load fxml on Macos
What is fxml set to? Could maybe be a “classpath” type issue where it’s looking on the classpath and can’t find it. Eric Bresie ebre...@gmail.com (mailto:ebre...@gmail.com) > On October 20, 2020 at 8:56:52 AM CDT, Davide Perini > mailto:perini.dav...@dpsoftware.org)> wrote: > I'm creating my binary file using JPackage but I don't signed the binary. > can this be the problem. > > why a simple line like this > > FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( fxml + > Constants.FXML)); > > return null if it works on WIndows and Linux? > > Thanks > Davide > > > > > > Il 20/10/2020 15:54, Dirk Lemmermann ha scritto: > > I worked with JavaFX on MacOS since 2013 and except for issues related to > > font rendering I never got the impression that MacOS is the black sheep. I > > also happen to know that many of the developers that are working on JavaFX > > use MacOS. > > > > Dirk > > > > > On Oct 20, 2020, at 12:28 PM, Davide Perini > > (mailto:perini.dav...@dpsoftware.org)> wrote: > > > > > > 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: 8252191: Update to gcc 10.2 on Linux
On Tue, 6 Oct 2020 13:14:05 GMT, Ambarish Rapte wrote: >> Marked as reviewed by jvos (Reviewer). > >> What OS are you using? (I'm running a test on Ubuntu 18.04) > > I also have 18.04. Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the change? - PR: https://git.openjdk.java.net/jfx/pull/311
Re: RFR: 8252192: Update to Visual Studio 2019 version 16.7.2 [v2]
On Wed, 7 Oct 2020 12:54:20 GMT, Ambarish Rapte wrote: >> Kevin Rushforth has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now >> contains two commits: >> - Merge branch 'master' into 8252192-vs2019-16.7.2 >> - 8252192: Update to Visual Studio 2019 version 16.7.2 > > Marked as reviewed by arapte (Reviewer). Does the [documentation](https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX) need updating to reflect the change? - PR: https://git.openjdk.java.net/jfx/pull/312
Re: RFR: 8253086: Optimization of removeAll and retainAll of ObservableListWrapper [v4]
On Wed, 7 Oct 2020 12:06:09 GMT, Jeanette Winzenburg wrote: >> I'm preparing a change that won't break compatibility, so stay tuned. >> The test seems to need to be added. > >> >> >> I'm preparing a change that won't break compatibility, so stay tuned. >> The test seems to need to be added. > > sounds good :) Note, that I'm working on > [JDK-8254040](https://bugs.openjdk.java.net/browse/JDK-8254040) which will add > regression tests that your change will have to pass (turned out that f.i. > FilteredList also relies on the two-pass > approach). Until you are done, you might consider changing the state of this > to Draft. Hopefully not looking in the wrong version but: (1) When dealing with BitSets previously, maybe this was by design butI didn’t see any usage of BitSet’s “clear()” to remove items from the BitSet. Although given move to remove it may be moot now. (2) If no longer using the BitSet, may want to remove the import for this (3) In context, usage of HashSet was suggested. I don’t believe HashSet is thread safe. If using it, may want to consider ConcurrentHashSet. Although not sure if this is more efficient either. - PR: https://git.openjdk.java.net/jfx/pull/305
Re: Re: Deadlock: JFXPanel, ContextMenu, macOS
What was the ticket? Eric Bresie ebre...@gmail.com > On July 30, 2020 at 10:54:47 AM CDT, Kevin Rushforth > wrote: > Thanks, I'll take a look at it and let you know if we need anything else. > > -- Kevin > > > On 7/30/2020 8:45 AM, Steven Yi wrote: > > Hi Kevin, > > > > I pasted in the minimal reproducible example with the issue I filed as > > well as a link to the github repo; I hope the everything is in order. > > > > Thanks, > > Steven > > > > > > On Thu, Jul 30, 2020 at 10:57 AM Kevin Rushforth > > mailto:kevin.rushfo...@oracle.com>> wrote: > > > > If you can provide a small, standalone test case as part of the bug > > report, that would be ideal. > > > > Thanks. > > > > -- Kevin > > > > > > On 7/30/2020 6:46 AM, Steven Yi wrote: > > > Hi Michael, > > > > > > Thanks for the link, I missed that when I went to explore JBS. > > I'll report > > > the issue there. > > > > > > All best, > > > Steven > > > > > > > > > On Thu, Jul 30, 2020 at 3:25 AM Michael Paus > <mailto:m...@jugs.org>> wrote: > > > > > > > Hi Steven, > > > > the right place for bug reports like this is here: > > > > <https://bugs.java.com/bugdatabase/> > > > > Michael > > > > > > > > Am 30.07.20 um 01:28 schrieb Steven Yi: > > > > > Hi All, > > > > > > > > > > I'm not sure if this is the place to report this, but > > hopefully so. (I > > > > did > > > > > not see a way to create an account or report issues on JBS.) > > > > > > > > > > I am using JavaFX embedded within a Swing application and had > > found > > > > > intermittent deadlocks on macOS that I wasn't sure why it was > > happening. > > > > I > > > > > was finally able to create a minimal working example and have > > published > > > > it > > > > > here: > > > > > > > > > > https://github.com/kunstmusik/ContextMenuHangingTest > > > > > > > > > > The switching applications seems to be a key to getting the > > deadlock to > > > > > happen. Testing with debugger in Netbeans, when the app > > freezes, I paused > > > > > the app and saw this in the Java FX Application Thread stack: > > > > > > > > > > "JavaFX Application Thread" > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java) > > > > > at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913) > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694) > > > > > at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639) > > > > > at > > sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94) > > > > > at > > sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548) > > > > > at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java) > > > > > at com.sun.glass.ui.Window.setView(Window.java:416) > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287) > > > > > at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get > > > > > at > > > > > > > > > > > com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430) > > > > > at > > com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286) > > > > > at javafx.stage.Window$12.invalidated(Window.java:1085) > > > > > at > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110) > > > > > at > > > > > > > > > > > javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145) > > > > > at javafx.stage.Window.setShowing(Window.java:1174) > > > > > at javafx.stage.Window.show(Window.java:1189) > > > > > at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472) > > > > > at javafx.stage.PopupWindow.show(PopupWindow.java:417) > > > > > at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323) > > > > > at javafx.scene.control.ContextMenu
Re: Fixing NetBeans Gradle Support for OpenJFX
Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow some 'timestamp" without impacting the generated jar name also be worth considering? Eric Bresie ebre...@gmail.com On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth wrote: > In that case, we can probably remove the time stamp from MAVEN_VERSION > altogether in a follow-up fix, since it is never used for any released > version, including early access builds. Not a high priority though once > the entire publishing task is qualified by a property. > > -- Kevin > > > On 7/23/2020 10:26 AM, Joeri Sykora wrote: > > We have never had the need to publish snapshot versions. We do however > > publish early access builds quite regularly (e.g. 15-ea+6) for the > > versions that are in development. > > > > Op do 23 jul. 2020 18:44 schreef Kevin Rushforth > > mailto:kevin.rushfo...@oracle.com>>: > > > > The proposed fix will be to disable the maven publishing tasks by > > default, and to not set the project.version at all. So this will > > decouple the maven publishing tasks, and they won't interfere with > > normal developer or production builds. > > > > Joeri or Johan can confirm, but if they ever do upload a bundle for > > testing, I'm pretty sure they would use a SNAPSHOT designation (set > > manually). > > > > -- Kevin > > > > > > On 7/23/2020 5:55 AM, Eric Bresie wrote: > > > Is there a need for some further cleanup dependency between > > builds maybe to remove duplicate jars / modules with different > > time stamps? > > > > > > Rather than time stamp in these cases should it just use a > > SNAPSHOT designation instead? > > > > > > Eric Bresie > > > ebre...@gmail.com <mailto:ebre...@gmail.com> > > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth > > mailto:kevin.rushfo...@oracle.com>> > > wrote: > > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to > > track fixing > > >> the build.gradle to not include the time stamp, at least by > > default. > > >> > > >> -- Kevin > > >> > > >> > > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > > >>>> On 7/20/20 1:15 PM, Kevin Rushforth wrote: > > >>>>>> That could be prevented by removing line 1547: > > project.version = > > >>>>>> MAVEN_VERSION from the build script. > > >>>>> Interesting. That is only used for the maven "publishing" > > tasks, and > > >>>>> shouldn't affect the main build artifacts. I don't see the > > generated > > >>>>> version number showing up anywhere in the build output. It > > would be > > >>>>> easy enough to suppress this for non-production builds, but > > I'd want > > >>>>> to understand how it is causing problems. Does gradle (and > > thus the > > >>>>> NetBeans gradle plugin), assign some semantic meaning to the > > >>>>> project.version attribute? > > >>>> There is no semantic association. It is just the binding of the > > >>>> sub-projects together. Recent Gradle doesn't generate the jar > > files > > >>>> of the sub-projects if not asked for that specifically. Though > if > > >>>> javafx:base project is asked of it's main output it would be > > a jar > > >>>> file with a second precision suffix in it's name. Also if you > > ask for > > >>>> the dependencies of javafx:graphics it will list a dependency > > on a > > >>>> javafx:base base jar with the second precision suffix in its > > name. > > >>>> The jar file does not have to be exist, NetBeans still would > > able to > > >>>> find out the dependency between the two sub-projects, but > > these jar > > >>>> names shall be the same. So if these two queries happen in > > different > > >>>> times the jar name would not match. > > >>> Got it. We explicitly disable the jar task for each modular > > project, > > >>> since we don't need them, so we never would have noticed this. > > If I > > >>> enable them, I can see the jar files with the full version > number, > > >>> including the date string. > > >>> > > >>> I'll file a bug to fix it. I'll need to do it in such a way > > that won't > > >>> disrupt generating maven artifacts for testing (actual maven > > artifacts > > >>> for uploading won't be affected anyway), but it should be easy > > to do. > > >>> > > >>> -- Kevin > > >>> > > > >
Re: Re: Fixing NetBeans Gradle Support for OpenJFX
Is there a need for some further cleanup dependency between builds maybe to remove duplicate jars / modules with different time stamps? Rather than time stamp in these cases should it just use a SNAPSHOT designation instead? Eric Bresie ebre...@gmail.com > On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth > wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing > the build.gradle to not include the time stamp, at least by default. > > -- Kevin > > > On 7/20/2020 3:16 PM, Kevin Rushforth wrote: > > > > On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote: > > > On 7/20/20 1:15 PM, Kevin Rushforth wrote: > > > > > That could be prevented by removing line 1547: project.version = > > > > > MAVEN_VERSION from the build script. > > > > > > > > Interesting. That is only used for the maven "publishing" tasks, and > > > > shouldn't affect the main build artifacts. I don't see the generated > > > > version number showing up anywhere in the build output. It would be > > > > easy enough to suppress this for non-production builds, but I'd want > > > > to understand how it is causing problems. Does gradle (and thus the > > > > NetBeans gradle plugin), assign some semantic meaning to the > > > > project.version attribute? > > > There is no semantic association. It is just the binding of the > > > sub-projects together. Recent Gradle doesn't generate the jar files > > > of the sub-projects if not asked for that specifically. Though if > > > javafx:base project is asked of it's main output it would be a jar > > > file with a second precision suffix in it's name. Also if you ask for > > > the dependencies of javafx:graphics it will list a dependency on a > > > javafx:base base jar with the second precision suffix in its name. > > > The jar file does not have to be exist, NetBeans still would able to > > > find out the dependency between the two sub-projects, but these jar > > > names shall be the same. So if these two queries happen in different > > > times the jar name would not match. > > > > Got it. We explicitly disable the jar task for each modular project, > > since we don't need them, so we never would have noticed this. If I > > enable them, I can see the jar files with the full version number, > > including the date string. > > > > I'll file a bug to fix it. I'll need to do it in such a way that won't > > disrupt generating maven artifacts for testing (actual maven artifacts > > for uploading won't be affected anyway), but it should be easy to do. > > > > -- Kevin > > >
Re: [jfx15] RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]
On Fri, 10 Jul 2020 05:20:03 GMT, Ambarish Rapte wrote: >> John Neffenger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove assert statements > > Marked as reviewed by arapte (Reviewer). Just curious and this may be OBE by now but... I see the check thread but when accessing the buffer itself, should it have some sort of synchronization of some type to make it more thread safe? - PR: https://git.openjdk.java.net/jfx/pull/255
Re: Re: Remove JavaFX JPMS enforcement
Thought I would provide a few references (1,2,3,4,5) on JPMS over time with a few pros and cons embedded within them . Maybe some will be of help. (1) https://blog.joda.org/2018/03/jpms-negative-benefits.html?m=1 (2) https://jaxenter.com/java-9-modules-jpms-basics-135885.html (3) http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-March/013689.html (4) https://stackoverflow.com/questions/45655210/benefits-of-jpms-project-jigsaw-for-small-applications-libraries (5) https://www.javaworld.com/article/2878952/modularity-in-java-9.html Eric Bresie ebre...@gmail.com > On April 21, 2020 at 6:30:21 AM CDT, Mike Hearn wrote: > Maybe openjfx.io needs more maintainers? I opened a PR against that repo > some days ago and it's not been looked at. The JavaFX docs are certainly a > weak point right now, given that the Java 8 era docs aren't really being > maintained, and aren't open source, and the main docsite isn't really > actively worked on either. > > > > On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges > wrote: > > > One thing I do miss in openjfx.io website in terms of documentation is > > the definition of a jmods file and the sdk. > > > > For new developers looking at the download page, it's really not simple to > > figure it out. > > > > On Mon, Apr 20, 2020, 15:55 Kevin Rushforth > > wrote: > > > > As of JDK 9, there are a few places in JavaFX that assume the JavaFX > > modules are, in fact modules. While it would likely be technically possible > > to find them all, and make modifications that will allow running JavaFX > > either on the classpath or on the module path, I am not in favor of that. I > > think it would be a step backwards. For one thing, we would lose the > > encapsulation that the module system provides, and applications would be > > able to access internal packages without so much as a warning that it's not > > public API. Also it would increase the testing burden, since that would be > > one more mode in which it would need to be tested to ensure that it doesn't > > break. > > > > I tend to agree with those who say that this is mostly a documentation > > issue. I suppose it's also a bit of a tooling problem, since first class > > support for modules is still in progress in various IDEs and build tools > > (gradle, maven, etc). The support in the IDEs is pretty good now, and > > gradle 6.4 reportedly has full support for modules. Someone with more > > familiarity with Maven can comment about their module support. > > > > -- Kevin > > > > On 4/20/2020 10:31 AM, Michael Paus wrote: > > > > Oh I see. You are obviously not familiar with the fact that the JDK has a > > built-in test > > which checks whether the JavaFX graphics module is on the module path when > > you > > try to launch an application main class which is derived from the JavaFX > > Application class. > > If you try this and the graphics module is not on the module path the > > launch will fail > > with an error message. That's the only reason why JavaFX programs cannot > > be launched > > completely on the classpath and that's where all the trouble starts. If > > you circumvent this > > test with the trick, I have mentioned before, everything becomes nice and > > easy. > > > > So for me there are only two questions. > > 1. Is there any proof of a technical reason why JavaFX could not run > > correctly on the classpath? > > 2. If there is no such reason, then why do we torture all the newbies with > > the "intricacies" of the > > module system instead of just removing this barrier? > > > > As I said before, I have not found any such problem in all the time since > > JavaFX was separated > > from the JDK, so this test seems to be quite artificial to me but of > > course I may be wrong. That's > > why I asked here. > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > I'm a bit confused here. if you don't want JPMS then you should be able to > > run everything on the classpath like normal. Netbeans at least doesn't > > force modules wtih Maven. Or is reflection disabled on classpath as of Java > > 9 too unless you have a module-info? > > > > Michael > > > > Am 18.04.20 um 12:58 schrieb Ty Young: > > > > On 4/18/20 5:01 AM, Michael Paus wrote: > > > > Getting started with JavaFX is made overly complicated by the fact that > > the use of the > > module system is enforced by some code in the JDK. Especially for > > beginners, who just > > want to get some small program running, this is almost always a big source > &g
Re: Re: Windows Installation Instructions, All DLL Files Missing
Would jdeps help to see what dependencies are needed? Eric Bresie ebre...@gmail.com > On April 18, 2020 at 1:44:43 PM CDT, Michael Paus wrote: > Hi Christopher, > I do not know what your specific problem is but maybe you just have to > shift your goals a little bit. > Continuing like you did in the Java 8 days is not a good idea for > various reasons. The current trend > for distributing desktop software with Java is to build a platform > specific installer. The tools for that > are all there. Just give it a try. Together with Dirk Lemmermann I have > set up a working example > and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac > and Windows (should also work > on Linux but I haven't tested it.) > <https://github.com/dlemmermann/JPackageScriptFX> > The nice thing about this approach is that your customer does not have > to have anything installed on his > own machine. He can just install your software like he would install any > other piece of software. > Michael > > Am 18.04.20 um 20:18 schrieb Christopher Miles: > > Yep, that's where I downloaded it from. > > > > > PS C:\Users\cmiles\source\repos\xmltool> java --version > > > openjdk 14.0.1 2020-04-14 > > > OpenJDK Runtime Environment (build 14.0.1+7) > > > OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing) > > > > When I look at the "bin" directory that came with the JavaFX SDK and > > compare it to the "bin" directory that comes with OpenJDK there are > > things in the JavaFX distribution that aren't present in the OpenJDK > > distribution. These three caught my attention: > > > > + prism_common.dll > > + prism_d3d.dll > > + prism_sw.dll > > > > I suspect missing these DLL's is what is causing the exception when I > > try to launch my application. > > > > I took a look at "JDK-8207015" and I don't think that is my problem, > > yet. It could be that if the "prism_xxx.dll" files were present, I > > might run into this issue. > > > > I changed my `jlink` command to point at the "mods" as this seems like > > the correct way to do this. Still, the app refuses to launch with the > > same error message. > > > > > Graphics Device initialization failed for : d3d, sw > > > Error initializing QuantumRenderer: no suitable pipeline found > > > java.lang.RuntimeException: java.lang.RuntimeException: Error > > initializing QuantumRenderer: no suitable pipeline found > > > > I would very much like to avoid adding switches to a `java` invocation > > in order to run the application. In your example, I would need to have > > customer installed the JavaFX JDK to a specific location in order for > > that to work. I'd also need to have some kind of wrapper to handle > > other operating systems, like Linux or OS X. My goal is to distribute > > one package with custom launching scripts (i.e. one for batch, > > Powershell, and Linux/OS X shell) as I did under Java 8. This makes me > > think that using `jlink` with the mods is the way to go, as long as I > > can figure out why that is not working. > > > > Thank you for your help with this. :-) > > > > Kevin Rushforth wrote on 4/17/2020 17:34: > > > From where are you getting your OpenJDK build? > > > https://jdk.java.net/14 ? Somewhere else? > > > > > > -- Kevin > > > > > > > > > On 4/17/2020 2:16 PM, Christopher Miles wrote: > > > > Yeah, I've tried it with both. The instructions on the JavaFX page > > > > tell you to add the "lib" directory to the `javac` path and the > > > > "mods" to the `jlink` path. I figured, since nothing is working, why > > > > not try them the other way around? In all cases the results are the > > > > same. > > > > > > > > I'm using OpenJDK, wouldn't that project have the same issue > > > > distributing these DLL files? I would bet they would, since they are > > > > also an open source project. I can run Swing projects, however, > > > > without these DLL files. > > > > > > > > I can give the Oracle JDK a try. I had been shying away from it > > > > since OpenJDK is getting to be so popular. If that works, I will let > > > > the list know. > > > > > > > > As an aside, the JavaFX home page recommends using OpenJDK right now: > > > > > > > > https://openjfx.io/openjfx-docs/#install-java > > > > > > > > Thank you! > > > > &g
Re: Re: Seeking help with latest master ...
Are you behind a proxy? I had problems with another application which required registering certificates and related credentials keys to be added for java. Eric Bresie ebre...@gmail.com > On April 2, 2020 at 2:20:44 PM CDT, Johan Vos wrote: > I have no scientific evidence for this, but I remember issues related to > SSL with some JDK's as well, which may or may not be related to the cacerts > file that is bundled. > > - Johan > > On Thu, Apr 2, 2020 at 6:52 PM Rony G. Flatscher > wrote: > > > Being stuck (tried the previous working gradle 5.6.4, could get "gradle > > clean", but not further) in > > the end I just tried Java 14 and that allowed me to run "gradle" > > successfully (currently building > > webkit to get going again). Just wanted to let interested readers know. > > (Would be great though, if > > it worked with the 11 LTS version as well.) > > > > ---rony > > > > > > On 31.03.2020 20:36, Rony G. Flatscher wrote: > > > On 31.03.2020 20:21, Scott Palmer wrote: > > > > > Could not resolve all dependencies for configuration ':apps:lucene'. > > > > > Multiple build operations failed. > > > > java.lang.ExceptionInInitializerError > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.ExceptionInInitializerError > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > java.lang.NoClassDefFoundError: Could not initialize class > > > > sun.security.ssl.SSLContextImpl$TLSContext > > > > > > > > > > > > This to me looks like it may be failing to make an https connection to > > a repository when > > > > attempting to download dependencies. > > > > > > > > There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when > > running gradle builds, see: > > > > https://github.com/gradle/gradle/issues/7842 > > > > > > > > Claims to be fixed, but maybe not? > > > > > > > > If it is related to Gradle changing java.home while compiling, I wonder > > if using --no-parallel > > > > might work around it? Of course try with --debug as well to see if it > > offers more clues. > > > Scott, thank you! > > > > > > Not having any knowledge about gradle I am unfortunately lost in this > > case. However, I used "gradle > > > --no-parallel --debug" which did not succeed but created a 1.2 MB text > > file which I keep temporarily > > > in my DrobBox at: < > > https://www.dropbox.com/sh/e7seg9kgnm4wn4j/AAB4H4beZd9cJKbpvjyxdNMBa?dl=0 > > > . > > > > > > Will have to leave in a few minutes for today so can only try other > > things tomorrow. > > > > > > ---rony > > > >
Re: RE: JDK-8177945 : Single cell selection flickers when adding data to TableView
Not sure if this is the cause of some of this but...
I see some similar flags like needsRecreateCells and needsRebuildCells.
In one context (around line 1025) I see a recreateOrRebuild flag based on the
two.
Is it possible something similar is needed around here to only do something
once if either is set?
Maybe it’s doing the reset twice as part of recreate and rebuild.
Eric Bresie
ebre...@gmail.com
> On March 10, 2020 at 11:48:27 AM CDT, David Grieve
> wrote:
> The flickering is happening because of the way VirtualFlow reuses cells. The
> selected state gets cleared and reset, which is the flicker.
> This change fixed the flickering for me. I'm not sure why the index of a cell
> was being set to -1, but the effect of doing so is that when the
> cell is pulled out of the pile, it looks like a new cell that has to have its
> index set, selected state set, etc, etc. By commenting out the
> updateIndex(-1), VirtualFlow can reuse the cell - setting the index, selected
> state, etc turns into noops (more or less).
>
> Again, there may have been a good reason for setting index to -1 in this
> condition. More investigation needs to be done.
>
> diff --git
> a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
>
> b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
> index 728e7c5513..a58859bd05 100644
> ---
> a/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
> +++
> b/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
> @@ -991,9 +991,9 @@ public class VirtualFlow extends
> Region {
> lastWidth = -1;
> lastHeight = -1;
> releaseCell(accumCell);
> - for (int i = 0, max = cells.size(); i < max; i++) {
> - cells.get(i).updateIndex(-1);
> - }
> +// for (int i = 0, max = cells.size(); i < max; i++) {
> +// cells.get(i).updateIndex(-1);
> +// }
> addAllToPile();
> releaseAllPrivateCells();
> } else if (needsReconfigureCells) {
>
> > -Original Message-
> > From: openjfx-dev On Behalf Of
> > David Grieve
> > Sent: Friday, March 6, 2020 9:29 AM
> > To: Danny Gonzalez
> > Cc: openjfx-dev@openjdk.java.net
> > Subject: RE: JDK-8177945 : Single cell selection flickers when adding data
> > to
> > TableView
> >
> > This might fix the issue, but I’d like to understand better what the root
> > of the
> > problem is. My concern is that this fix might cause a performance
> > regression.
> > I’m using the code in JDK-8177945. I want to look at what TableView does
> > when it adds a cell. Is there something about the selected state that
> > changes? Or is this just the CSS implementation recalculating styles and un-
> > necessarily clearing old values? Some debugging is in order.
> >
> > From: Danny Gonzalez
> > Sent: Wednesday, March 4, 2020 4:34 AM
> > To: David Grieve
> > Cc: openjfx-dev@openjdk.java.net
> > Subject: [EXTERNAL] Re: JDK-8177945 : Single cell selection flickers when
> > adding data to TableView
> >
> > Hi David,
> >
> > Just wanted to add some more information.
> >
> > The cell selection flashing issue goes away If I put back the following
> > code in
> > the layout function in Parent.java:
> >
> > //
> > // One idiom employed by developers is to, during the layout pass,
> > // add or remove nodes from the scene. For example, a ScrollPane
> > // might add scroll bars to itself if it determines during layout
> > // that it needs them, or a ListView might add cells to itself if
> > // it determines that it needs to. In such situations we must
> > // apply the CSS immediately and not add it to the scene's queue
> > // for deferred action.
> > //
> > // Note that we only call processCSS if the flag is update. If the
> > // flag is DIRTY_BRANCH, then the whatever children need UPDATE
> > // will be visited during this layout anyway. On the next pulse,
> > // doCSSPass will clean up the DIRTY_BRANCH nodes.
> > //
> > if (cssFlag == CssFlags.UPDATE) {
> > processCSS();
> > }
> >
> > This code was originally added in in the following commit:
> >
> > commit e76b5755d4d2752037cc95eb75cb2615a740cc30
> > Author: David Grieve
> > mailto:dgri...@openjdk.org>>
> > Date: Thu Apr 10 15:40:34 2014 -0400 (tel:34%202014%20-0400)
> >
> > RT-36559: Some css optimizations: 1 - on impl_reapplyCSS, do not reapply
> > css to child nodes if nothing has changed. 2 - on applyCss, only look for
> > ancestor node with css state = UPDATE. 3 - only recalculate checksum of css
> > file if the
Re: Re: RFR: 8240688: Remove the JavaBeanXxxPropertyBuilders constructors
Is there any external skara documentation available on all these flags etc? Eric Bresie ebre...@gmail.com > On March 7, 2020 at 8:25:02 AM CST, Kevin Rushforth > wrote: > On Fri, 6 Mar 2020 20:46:39 GMT, Kevin Rushforth wrote: > > > > Marked as reviewed by kcr (Lead). > > > > @arapte can you also review this? > > Now the the CSR is approved, we need something to "wake up" the Skara bot to > notice that. > @edvbld @rwestberg is there a command that you would recommend to do this? > Maybe typing `/summary` without actually adding a summary? Failing that we > can wait for the second reviewer, but it would be nice to test Skara's CSR > support prior to that (this is the first one where we've had an approved CSR > since starting to use the `/csr` feature). > > - > > PR: https://git.openjdk.java.net/jfx/pull/140
Re: Re: RFR: 8240466: AppJSCallback* apps launched by ModuleLauncherTest intermittently hang
This may be a little off topic but given this is a Javascript concern, is this (or will this) be impacted by Nashhorns depreciation (as of jdk11 I believe) and potential removal at some point? I see reference to Netscape JObject do maybe that circumvents some of that but does this need to eventually transition to graalvm or other means? Eric Bresie ebre...@gmail.com > On March 10, 2020 at 6:22:01 AM CDT, Ajit Ghaisas > wrote: > On Fri, 6 Mar 2020 19:53:04 GMT, Kevin Rushforth wrote: > > > > Please ignore this comment as well, it is also for debugging issues with > > > Skara and mailman :email: > > > > @aghaisas can you review this? > > I executed these tests without this patch. They did not hang on my Macbook. > > I applied patch and executed the tests. They continue to pass. > I see the merit of this change to make tests predictable. +1. > > - > > PR: https://git.openjdk.java.net/jfx/pull/134
Re: Re: Request for adding my github userid ..
Silly question... Is this whole new contributor process (i.e. including the GitHub id association, sakara notations in the ticket, etc.) documented someplace outside of mailing list? Eric Bresie ebre...@gmail.com > On February 26, 2020 at 4:17:59 AM CST, Dalibor Topic > wrote: > Yeah, he did. ;) > > On 22.02.2020 17:58, Kevin Rushforth wrote: > > You should be all set now. Dalibor will likely take care of this early > > next week. > > > > -- Kevin > > > > > > On 2/22/2020 8:42 AM, Rony G. Flatscher wrote: > > > On 22.02.2020 17:33, Philip Race wrote: > > > > What openjdk ID would this be associated with ? > > > 8234959 (tel:8234959): FXMLLoader does not populate ENGINE_SCOPE Bindings > > > with > > > FILENAME and ARGV #122 > > > > > > One PR is the fix another one is dubbed as WIP and has the test unit > > > for this bug (such that one can > > > apply it before and after the fix). > > > > > > > I don't see a Rony Flatscher in the census : > > > > https://openjdk.java.net/census > > > > > > > > Rony, Have you made contributions and been granted author status ? > > > No, this is the first time I try to contribute code. > > > > If yes, where is it on that page ? If not, then you need to make > > > > contributions > > > > (not just sign the OCA) before you get author status and until then > > > > there is nothing > > > > with which to associate your github id. > > > Hmm, how should I then submit a fix/a pull request? > > > > > > The OCA was processed in 2017-03-01 (reported by Dalibor Topic), as > > > suggested I introduced myself in > > > [1]. However, for various reasons I got side tracked and only came > > > back this last November. > > > > > > @Kevin: thank you for your advice, did comment on both PR > > > > > > ---rony > > > > > > [1] "Introduction": > > > <https://mail.openjdk.java.net/pipermail/discuss/2017-March/004160.html> > > > > > > > > > > > > > On 2/22/20, 8:27 AM, Kevin Rushforth wrote: > > > > > What you need to do is this: > > > > > > > > > > > Once you have signed the OCA, please let us know by writing > > > > > > `/signed` in a comment in this pull > > > > > request. > > > > > > > > > > Omit the quotes in the command. > > > > > > > > > > This will alert the Skara maintainers to check your OCA status and > > > > > make the association. > > > > > > > > > > -- Kevin > > > > > > > > > > > > > > > On 2/22/2020 8:20 AM, Rony G. Flatscher wrote: > > > > > > Trying to place my first pull requests via github and received the > > > > > > following e-mail: > > > > > > > > > > > > --- cut --- > > > > > > > > > > > > Hi ronyfla, welcome to this OpenJDK project and thanks for > > > > > > contributing! > > > > > > > > > > > > We do not recognize you as Contributor > > > > > > <https://openjdk.java.net/bylaws#contributor> and need to > > > > > > ensure you have signed the Oracle Contributor Agreement (OCA). If > > > > > > you have not signed the OCA, > > > > > > please follow the instructions > > > > > > <https://www.oracle.com/technetwork/community/oca-486395.html>. > > > > > > Please fill in your GitHub username in the "Username" field of the > > > > > > application. Once you have > > > > > > signed > > > > > > the OCA, please let us know by writing |/signed| in a comment in > > > > > > this pull request. > > > > > > > > > > > > If you already are an OpenJDK Author > > > > > > <https://openjdk.java.net/bylaws#author>, Committer > > > > > > <https://openjdk.java.net/bylaws#committer> or Reviewer > > > > > > <https://openjdk.java.net/bylaws#reviewer>, > > > > > > please click here > > > > > > <https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300=1> > > > > > > to > > > > > > open a new issue so that we can record that fact. Please use "Add > > > > > > GitHub user ronyfla" as summary > > > > > > for the issue. > > > > > > > > > > > > If you are contributing this work on behalf of your employer and > > > > > > your employer has signed the OCA, > > > > > > please let us know by writing |/covered| in a comment in this pull > > > > > > request. > > > > > > > > > > > > --- cut --- > > > > > > > > > > > > So I am kindly requesting to associate my github user id 'ronyfla' > > > > > > with my signed OCA form such > > > > > > that > > > > > > the pull requests can go forward. > > > > > > > > > > > > TIA > > > > > > > > > > > > ---rony > > > > > > > > > > > > P.S.: In the meantime I have changed the github e-mail address for > > > > > > 'ronyfla' to the one in the OCA > > > > > > if that makes a difference. > > > > -- > <http://www.oracle.com> Dalibor Topic > Consulting Product Manager > Phone: +494089091214 (tel:+494089091214) , Mobile: > +491737185961 (tel:+491737185961) > , Video: dalibor.to...@oracle.com > > > Oracle Global Services Germany GmbH > Hauptverwaltung: Riesstr. 25, D-80992 München > Registergericht: Amtsgericht München, HRB 246209 > Geschäftsführer: Ralf Herrmann >
Re: Re: "Using an IDE" Page outdated (Openjfx)
Wanted to ping the netbeans mailing list to see if there is any input that could be provided to help on the open jfx as it relates to recent netbeans.. See https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE#UsinganIDE-UsingNetBeans(JDK-8) I seem to recall sometime back that there was some discussion on usage of the newer OpenJFX libraries, examples, and additional configuration of new ones but not an expert on that really. Eric Bresie ebre...@gmail.com On Wed, Jan 15, 2020 at 2:44 PM Eric Bresie wrote: > Anyone on the Netbeans community want to provide any updates on the > openjfx IDE page listed below? > > Eric Bresie > ebre...@gmail.com > > On January 10, 2020 at 10:52:26 AM CST, 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 > > > >
Re: Re: "Using an IDE" Page outdated (Openjfx)
Anyone on the Netbeans community want to provide any updates on the openjfx IDE page listed below? Eric Bresie ebre...@gmail.com > On January 10, 2020 at 10:52:26 AM CST, 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 > >
Re: Re: Proposed schedule for JavaFX 14
Out of curiosity...are there any labels, milestones, targets or any such type added in github and/or bug systema for changes going in? Or is there a PR of some type with all relevant changes expected? Eric Bresie ebre...@gmail.com > On January 7, 2020 at 9:18:00 AM CST, thevenet.f...@free.fr wrote: > Ok, it is quite clear to me now. > Thanks for the clarifications. > > Regards, > Frederic. > > - Mail original - > De: "Kevin Rushforth" > À: "thevenet fred" > Cc: "openjfx-dev" > Envoyé: Mardi 7 Janvier 2020 15:54:41 > Objet: Re: Proposed schedule for JavaFX 14 > > Hi Frederic, > > P3 bug fixes can go in during RDP1 if they are safe enough fixes. The > RDP2 deadline is Feb 3, so there is still time. Any bug that misses 14 > and is ready for integration into mainline will go into 15. A case can > be made for pulling in a very limited number of safe fixes from 15 into > a 14.0.x release, but I wouldn't expect that in this case. If the fix is > safe enough to get into 14, it will likely make it. If not, then it > isn't a good candidate for 14.0.1 anyway. > > -- Kevin > > > On 1/7/2020 5:51 AM, thevenet.f...@free.fr wrote: > > Hi Kevin, > > > > I am wondering about the likelihood for the fix to JDK-8088198 that I > > proposed in PR #68 (https://github.com/openjdk/jfx/pull/68) to make it into > > JavaFX 14. > > I think it is unlikely to be integrated into master by Thursday since it > > has yet to be fully reviewed, but since it is marked as a P3 bug, I > > understand > > that it could still be integrated during RDP1(provided it works as expected, > > of course); am I correct? > > In the event it doesn't make it on time for 14, would it qualify to be > > backported for inclusion in an intermediate release like 14.0.1, or would > > it have to wait for JavaFX 15? > > > > Thanks, > > Frederic. > > > > - Mail original - > > De: "Kevin Rushforth" > > À: "openjfx-dev" > > Envoyé: Mardi 7 Janvier 2020 00:26:03 > > Objet: Re: Proposed schedule for JavaFX 14 > > > > This is a final reminder that JavaFX 14 enters rampdown phase one (RDP1) > > on January 9, 2020 at 23:59 Pacific time. > > > > Any change integrated to the default 'master' branch after that will be > > for JavaFX 15. I will fork a new 'jfx14' stabilization branch early > > Friday morning (Pacific time). As with previous releases, P1-P3 bug > > fixes, and test or documentation fixes of any priority can still get > > into JavaFX 14 during RDP1. I'll send out more details Friday morning. > > > > -- Kevin > > > > > > On 12/16/2019 11:34 AM, Kevin Rushforth wrote: > > > The announced RDP1 date is the first Monday of the new year. In taking > > > a closer look at the upcoming holiday schedule and accounting for > > > additional days off some will be taking before or after, this doesn't > > > allow enough time for the final stages of the review process to > > > complete, including CSR approval. It is quite possible that an > > > enhancement with a mostly-completed review and a CSR that is Finalized > > > this Thursday or Friday (Dec 19 or 20), won't be approved in time for > > > integration. > > > > > > To address this, we are delaying RDP1 by three days. The new RDP1 date > > > is: > > > > > > Thursday, Jan 9, 23:59 PST > > > > > > The dates for RDP2, code freeze, and GA are unchanged. > > > > > > Please be aware that this three-day extension isn't an invitation to > > > try to get additional features into 14 at the last minute, but rather > > > an adjustment to better align with the holiday schedule in order to > > > give the already-in-flight features that are nearing completion a > > > little more time to make it. It is still the case that if an > > > enhancement isn't ready (meaning API discussed & approved, code review > > > mostly done, and CSR finalized) by this Friday, it should be > > > retargeted to JavaFX 15. > > > > > > -- Kevin > > > > > > > > > On 12/10/2019 1:45 PM, Kevin Rushforth wrote: > > > > As a reminder, RDP1 for JavaFX 14 starts on January 6, 2020 (at 23:59 > > > > Pacific time). > > > > > > > > With the holidays approaching, please allow sufficient time for any > > > > feature that needs a CSR. New features should be far enough along in > > > > the review process so you can finalize the CSR before next Friday, > > > > Dec 20, or
Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator (Code Analysis Discussion)
Accepting that static analysis tools are not best at finding memory leaks...however they can find some easy to find ones. I was just wondering if some of these can be run across the code base to find these "easy to find" ones to help in the process. Additionally, if there are certain checks that want to be flowed out across the code base (i.e. checks for initialization, then having the analysis run as part of a CI build jobs which could be periodically run and reported on to might help maintain some level of code quality over time. I know this can potentially find a lot of false failures but just thought it might be worth considering at some point. Eric Bresie ebre...@gmail.com On Fri, Dec 20, 2019 at 7:30 AM Kevin Rushforth wrote: > On Fri, 20 Dec 2019 09:53:56 GMT, Florian Kirmaier > wrote: > > >> @dsgrieve > >> It's worth mentioning that JavaFX already has many tests based on > System.gc(). > >> An advantage of having a testsuit as an library (or copyied from an > library) is, that its stability is regulary verified by the travis builds > for different JVMs. > >> The alternative would be to not test for memory-leaks at all which is > much worse than having slightly unstable tests. > >> Maybe it can make sense to seperate these tests for leaks in an own > testgroup. > >> > >> I'm introducing this library in more and more projects. I never had > problems with unstable tests. > >> I only had this kind of problem when I wrote the > WeakReference/System.gc/sleep-logic for every single test. > > > > I highly doubt that a code analysis tool will find such memoryleaks. > > I agree. Static analysis tools are quite limited in this regard, and are > in now way a substitute for regression testing. > > So the question is how best to test fixes for memory leaks at runtime. Our > current approach can be best characterized as "ad hoc", and is not all that > robust (although works well enough in most cases and is still much better > than doing no testing at all). I would welcome discussion of a more robust > approach for testing, but it should be decoupled from this bug fix, and > discussed as a separate JBS Enhancement request. > > - > > PR: https://git.openjdk.java.net/jfx/pull/71 >
Re: Re: [Rev 01] RFR: 8236259: MemoryLeak in ProgressIndicator
Would it just be better to run some code analysis tools on the code base to hunt for these? Like maybe sonarqube integratedas part of CI build analysis? Eric Bresie ebre...@gmail.com > On December 19, 2019 at 4:23:14 PM CST, Florian Kirmaier > wrote: > On Thu, 19 Dec 2019 19:59:07 GMT, David Grieve wrote: > > > > Yes, exactly. > > > > > > @FlorianKirmaier Proposing to add test class to the test infrastructure > > > would be a reasonable alternative to pulling it in as a third-party > > > dependency. I recommend separating it out into its own enhancement, with > > > a separate JBS issue. I see that it has a dependency on the > > > `jdk.management` module. As long as that dependency only surfaces as a > > > test dependency, that won't be a problem. It would be nice if it were > > > available to all modules, meaning that putting it somewhere in > > > `javafx.base` would be good. > > > > I would urge caution about incorporating JMemoryBuddy without seeking out > > advice from GC experts. I have my doubts that it will work reliably given > > its reliance on System.gc(). (Opinion is my own, not my employer's). > > @dsgrieve > It's worth mentioning that JavaFX already has many tests based on System.gc(). > An advantage of having a testsuit as an library (or copyied from an library) > is, that its stability is regulary verified by the travis builds for > different JVMs. > The alternative would be to not test for memory-leaks at all which is much > worse than having slightly unstable tests. > Maybe it can make sense to seperate these tests for leaks in an own testgroup. > > I'm introducing this library in more and more projects. I never had problems > with unstable tests. > I only had this kind of problem when I wrote the > WeakReference/System.gc/sleep-logic for every single test. > > - > > PR: https://git.openjdk.java.net/jfx/pull/71
Re: Re: Skara - bot sending can-be-integrated message prematurely?
So is there some “review complete” or “review closed” or some following state available for the bot to key on maybe instead of reacting to one reviewer completion? Eric Bresie ebre...@gmail.com > On December 16, 2019 at 9:38:00 AM CST, Kevin Rushforth > wrote: > That's a good question about whether we can ask for a slight rewording > of the Skara bot message to indicate that there might be other things to > check before "/integrate". I'll raise that question with the Skara team. > > As an aside, I noticed the other day that you typed "/integrate" after a > single review, but in that case, there was no clear indication from Ajit > (the first reviewer and the sponsor) that a second review was required, > so I didn't comment on it. > > -- Kevin > > > On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote: > > > > Kevin, > > > > thanks for the clarification :) My bad that I didn't re-read the > > contrib.md. But then, who does? The lazy like myself do it > > occasionally only (down to once and then forget about it ) > > > > Maybe the bot message can be improved? With some indication that its > > (the bot's) knowledge about review requirements is limited, so would > > require a careful check by the contributor before actually post the > > /integrate comment? Actually, I think I goofed the other day, was > > safed only by Ajit who waited for the 2nd review before his /sponsor. > > > > -- Jeanette > > > > Zitat von Kevin Rushforth : > > > > > I added a comment to the two PRs in question, but it bears discussion > > > here. > > > > > > The Skara bot can't know whether all criteria have been met. It > > > can't, for example, know whether there are outstanding comments from > > > some reviewers that need to be addressed. Nor does it know which PRs > > > need two reviewers (or sometimes a third if there is a specific > > > person we would like to review it), which ones need a CSR, etc. > > > > > > So having it state authoritatively that the PR is ready to integrate > > > is a bit misleading. This is documented in the Code Review section of > > > the CONTRIBUTING [1] doc: > > > > > > > NOTE: while the Skara tooling will indicate that the PR is ready to > > > > integrate once the first reviewer with a "Reviewer" role in the > > > > project has approved it, this may or may not be sufficient depending > > > > on the type of fix. For example, you must wait for a second approval > > > > for enhancements or high-impact bug fixes. > > > > > > If anyone can think of a way to improve this and make it more clear, > > > that would be helpful. > > > > > > -- Kevin > > > > > > [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md > > > > > > > > > On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote: > > > > > > > > Looks like it assumes a pull request as properly reviewed as soon as > > > > it gets a single approve - independent on how many reviewers are > > > > required, see f.i. > > > > > > > > https://github.com/openjdk/jfx/pull/15#issuecomment-565964995 > > > > https://github.com/openjdk/jfx/pull/6#issuecomment-566028296 > > > > > > > > -- Jeanette > > > > > > > > > > >
Re: RFR: 8087980: Add property to disable Monocle cursor
First time poster so forgive my inexperience...not really anything against
the specific changes just seeking insight...
(1) Notice some of these packages are still in com/sun/glass namespace. Is
this still valid or at some point should this transition to a more open jfx
equivalent or has that part still not fully been considered yet?
(2) General practices...When should a property be a system environment (1)
in system specific way - Windows environment variable, UNIX shell based
property user or global, (2) app specific properties - internal as a
resource or META-INF type or external to a given jar, (3) application
specific in a give jfx component or class specific properties, or some css
type properties, etc.), (4) command line type parameter passed in, etc?
And that said which type would the properties discussed here for in?
I ask because curious when and where these are needing to be setup as well
(I.e when installing the app set the system environment variable once,
delivered with a property set, run with defaults and later customized in
case by case basis, etc.)
Eric Bresie
ebre...@gmail.com
On Sat, Nov 16, 2019 at 12:14 AM Dell Green wrote:
> On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger 1413266+jgn...@openjdk.org> wrote:
>
> > On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green 12861109+dellgr...@openjdk.org> wrote:
> >
> >> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger 1413266+jgn...@openjdk.org> wrote:
> >>
> >>> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <
> 12861109+dellgr...@users.noreply.github.com> wrote:
> >>>
> >>>> Often on embedded systems a cursor is not a valid input modality. On
> some of these systems, when the javafx toolkit initialises the native
> hardware cursor, it produces artefacts which can be seen on screen (in the
> framebuffer for example). This change adds a system property
> "monocle.cursor.enabled" that can disable the creation of a native cursor
> in each of the Monocle NativePlatform implementations in favour of a
> NullCursor which is a no-op implementation of the NativeCursor abstract
> class that all native cursors have to implement.
> >>>>
> >>>> NullCursor class already existed and was being returned for some
> implementations like AndroidPlatform and HeadlessPlatform. This change
> builds upon that and conditionally returns NullCursor for all platforms.
> >>>>
> >>>> A system property "monocle.debugcursor" has also been added to turn
> on logging of which NativeCursor has been selected when the toolkit
> initialises.
> >>>>
> >>>>
> >>>>
> >>>> Commits:
> >>>> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor
> >>>>
> >>>> Changes: https://git.openjdk.java.net/jfx/pull/5/files
> >>>> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
> >>>> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
> >>>> Patch: https://git.openjdk.java.net/jfx/pull/5.diff
> >>>> Fetch: git fetch https://git.openjdk.java.net/jfx
> pull/5/head:pull/5
> >>>
> >>>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java
> line 50:
> >>>
> >>>> 49: AccessController.doPrivileged((PrivilegedAction)
> () -> {
> >>>> 50: final String str =
> >>>> 51: System.getProperty("monocle.debugcursor", "");
> >>>
> >>> Just a nit, but why `monocle.debugcursor` rather than
> `monocle.cursor.debug` (my preference), or at least `monocle.debugCursor`?
> Below is the full list, for comparison, including the two added by this
> pull request.
> >>>
> >>> monocle.cursor.enabled
> >>> monocle.debugcursor
> >>> monocle.epd.bitsPerPixel
> >>> monocle.epd.enableInversion
> >>> monocle.epd.forceMonochrome
> >>> monocle.epd.noWait
> >>> monocle.epd.rotate
> >>> monocle.epd.useDitheringY1
> >>> monocle.epd.useDitheringY4
> >>> monocle.epd.waveformMode
> >>> monocle.epd.y8inverted
> >>> monocle.input..flipXY
> >>> monocle.input..maxX
> >>> monocle.input..maxY
> >>> monocle.input..minX
> >>> monocle.input..minY
> >>> monocle.input..touchFilters
> >>> monocle.input.touchFilters
> >>> monocle.input.touchRadius
> >>> monocle.input.traceEvents
> >>&g
Re: Re: Details on move to Skara-enabled GIT repos
I was wondering, does any of this information need to be added into any of the existing documentation? Eric Bresie ebre...@gmail.com > On September 25, 2019 at 1:45:52 PM CDT, Kevin Rushforth > wrote: > > > It also presumes that you have configured an upstream remote named > > 'upstream' as suggested here... > > I forgot to include the link to the GitHub help page for setting up an > upstream repo. Here is is: > > https://help.github.com/en/articles/configuring-a-remote-for-a-fork > > -- Kevin > > > On 9/25/2019 11:40 AM, Kevin Rushforth wrote: > > To: OpenJFX Contributors with open pull requests > > > > If you have an open pull request [4] in the javafxports/openjdk-jfx > > sandbox that isn't merged before the switch (i.e., one that is still > > open on Tuesday when the HG repo goes read-only), here are some > > instructions that should help you port your PR to the new openjfx/jfx > > repo: > > > > These instructions presume that you have already created a personal > > fork of both the existing javafxports/openjdk-jfx sandbox repo and the > > new openjdk/jfx repo, and that you have locally cloned each of them. > > It also presumes that you have configured an upstream remote named > > 'upstream' as suggested here [1]. > > > > 1. In your local clone of your personal fork of the old > > javafxports/openjdk-jfx sandbox repo: > > > > The "upstream" remote should point to: > > https://github.com/javafxports/openjdk-jfx.git > > > > cd "MY-JAVAFXPORTS-FORK" > > git checkout "MYBRANCH" > > git fetch upstream > > git merge upstream/develop > > rm 0*.patch > > git format-patch upstream/develop..HEAD > > > > where "MY-JAVAFXPORTS-FORK" is the local directory into which you have > > cloned your fork of javafxports/openjdk-jfx, and "MYBRANCJH" is the > > name of the branch against which you have made the pull request. > > > > 2. In your local clone of your personal fork of the new openjdk/jfx repo: > > > > The "upstream" remote should point to: https://github.com/openjdk/jfx.git > > > > cd "MY-OPENJDK-FORK" > > git fetch upstream > > git checkout -b "MYBRANCH" upstream/master > > git am --keep-cr "MY-JAVAFXPORTS-FORK"/0*.patch > > > > where "MY-OPENJDK-FORK" is the local directory into which you have > > cloned your fork of openjdk/jfx, and "MYBRANCJH" is the name of the > > branch against which you will make the pull request. > > > > Then you can push your branch to your local fork of the new > > openjdk/jfx repo. Once the repo is open for pull requests (next > > Wednesday), you can submit a new pull request. > > > > -- Kevin > > > > [4] https://github.com/javafxports/openjdk-jfx/pulls > > > > > > On 9/24/2019 2:10 PM, Kevin Rushforth wrote: > > > To: OpenJFX Contributors > > > > > > Here is some additional information on the mechanics of the impending > > > switch to GIT [1]. The high-level overview is as follows. > > > > > > _OVERVIEW_ > > > > > > Before the switch: > > > > > > 1. File an issue to associate your GitHub username with your OpenJDK > > > ID (if you have one) > > > 2. Fork the openjdk/jfx GitHub repo and create a local clone > > > > > > After the switch: > > > > > > 3. Submitting a pull request to openjdk/jfx > > > > > > _DETAILS_ > > > > > > The following can be done at any time. I recommend you do these > > > before the switch to GIT, since they must be completed before you > > > submit your first pull request to the openjdk/jfx repo: > > > > > > 1. Associate your GitHub username with your OpenJDK ID > > > > > > Everyone with an OpenJDK ID (everyone who is and Author, Committer, > > > or Reviewer in OpenJFX or any other Project) who wants to contribute > > > to OpenJFX needs to file a JBS issue in the Skara project to > > > associate their GitHub username with their OpenJDK ID. This allows > > > the Skara tooling to know what role you have in the Project, and also > > > serves as verification that you have signed the OCA (people without > > > an OpenJDK ID will go through a separate verification step the first > > > time they submit a PR). > > > > > > Click here to file the issue: > > > https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300=1 > > > > > > > > > Use
Re: Re: Gitter chat + StackOverflow [was: Concatenating transforms to scale positions but not objects]
They don’t appear to be rejecting it per say...It sounds like they just want clear and concise question with code snippets (apparently not a link to the code) added and what the desired behavior is. Eric Bresie ebre...@gmail.com > On August 13, 2019 at 5:43:38 AM CDT, John-Val Rose > wrote: > I’ve all but given up on StackOverflow. > > It seems to be a haven for trolls or control freaks who deem perfectly > reasonable questions as off-topic or inappropriate whereby the question then > gets put on hold and can’t be answered. > > It’s ridiculous and makes the forum almost unusable. > > Some people enjoy the power they have to make this happen and have no > interest in helping you or assisting in having your question answered. > > Sad. > > > On 13 Aug 2019, at 20:34, Mark Raynsford wrote: > > > > On 2019-08-12T14:25:37 +0100 > > Mark Raynsford wrote: > > > > > > Hello! > > > > > > Here's the StackOverflow question: > > > > > > https://stackoverflow.com/questions/57461988/using-an-alternate-coordinate-system-inside-a-pane-or-region > > > > And, right on cue, the question has been marked as "off-topic". > > > > I don't believe that StackOverflow is suitable for general community > > support. At least half of the interactions I have had with it have ended > > similarly. > > > > Thanks, Michael, for attempting to respond on StackOverflow. > > Unfortunately, the somewhat rabid moderators have decided that my > > question isn't worth asking and that your response isn't worth > > listening to. Sadness. > > > > -- > > Mark Raynsford | http://www.io7m.com > >
Re: Re: Concatenating transforms to scale positions but not objects
Are you focused on things from a pane/layout perspective here? Maybe some different layout might help. https://openjfx.io/javadoc/11/javafx.graphics/javafx/scene/layout/package-summary.html Or are you looking for some form of “chart” component to allow lines to be graphed? https://docs.oracle.com/javafx/2/charts/line-chart.htm For others on the list...while I can see this list as more focused on development of openjfx...is there a list for users of openjfx and how to code with it? Eric Bresie ebre...@gmail.com > On August 10, 2019 at 10:51:56 AM CDT, Mark Raynsford > wrote: > On 2019-08-06T19:11:42 +0100 > Mark Raynsford wrote: > > > Hello! > > > > I realize the subject is somewhat convoluted. I'm putting together > > something that bears a passing resemblance to a DAW such as Ardour: > > Given the tumbleweeds and sounds of crickets, I'm guessing that I > expressed my question rather poorly. > > Here's what I'm trying to do: I'm trying to set up a pane with a > transform such that I can place objects inside that pane using > positions that don't correspond to JavaFX "scene pixels". For example, > 1024 units in my coordinate system might correspond to 1 "scene pixel" > (is there a better name for the units that JavaFX uses?). However: The > objects that are *inside* the objects that I add to the pane want to > work in "scene pixels" (for example; Labels seem to want to work in > pixel positions when rendering text). > > Here's a GitHub gist that gives a short example of this: > > https://gist.github.com/io7m/20b071e11da2dcd96896a43fad6df644 > > I create one container group (actually a Pane) that adds a transform > such that 1 unit == 32 pixels. I add objects to this container. Each > object I add has an *external* pane with a size and position specified > in units, and an *internal* pane that solely exists to invert the scale > of the transform of the *external* pane. Inside this *internal* pane, I > can add Labels and so on and these all render correctly. > > I set up bindings between the transforms so that I can effectively > scale and pan the scene by adjusting the transform on the group > container. However: Something about this setup seems to be confusing > something inside JavaFX; the results I'm seeing onscreen don't seem to > match what JavaFX believes the bounds of various objects are. This > causes visual issues when I try to do things like set borders on > objects, and also seems to confuse ScenicView. > > Here's a shot with the container group selected (looks correct): > > https://ataxia.io7m.com/2019/08/10/view0.png > > Here's a shot with the *external* pane of the bottom object selected: > > https://ataxia.io7m.com/2019/08/10/view1.png > > Note that, although the object actually renders onscreen as the right > size (one of the pale grey boxes), ScenicView seems to believe that the > object's bounds are 1x1: They *are* 1x1, but they're 1x1 when expressed > in my custom coordinate system, not in JavaFX "scene pixels". > > Here's a shot with the *internal* pane of the bottom object selected: > > https://ataxia.io7m.com/2019/08/10/view2.png > > This looks correct in the sense that the bounds encompass the label and > nothing else. > > Am I doing something wrong here? I can't tell if I'm basically abusing > transforms or not. > > -- > Mark Raynsford | http://www.io7m.com >
