Re: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+
On Tue, 21 May 2024 14:25:51 GMT, Michael Strauß wrote: > This PR fixes a bug > ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was > introduced with #394, which changed the following line in the > `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function > `GetMessageExtraInfo` to distinguish between mouse events and pen events as > described in this article: > https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events > and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) > [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are > receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported > for `WM_TOUCH` messages, but my testing shows that that's probably not the > case (I tested this with a XPS 15 touchscreen laptop, where > `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` > structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; @jperedadnr Maybe you could test this PR with the pen digitizer that you used for #394 to ensure that this change doesn't introduce yet another regression. - PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124119824
Re: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+
On Tue, 21 May 2024 14:25:51 GMT, Michael Strauß wrote: > This PR fixes a bug > ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was > introduced with #394, which changed the following line in the > `NotifyTouchInput` function (ViewContainer.cpp): > > - const bool isDirect = true; > + const bool isDirect = IsTouchEvent(); > > > `IsTouchEvent` is a small utility function that uses the Windows SDK function > `GetMessageExtraInfo` to distinguish between mouse events and pen events as > described in this article: > https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages > > I think that using this function to distinguish between touchscreen events > and pen events is erroneous. The linked article states: > _"When your application receives a **mouse message** (such as WM_LBUTTONDOWN) > [...]"_ > > But we are not receiving a mouse message in `NotifyTouchInput`, we are > receiving a `WM_TOUCH` message. > I couldn't find any information on whether this API usage is also supported > for `WM_TOUCH` messages, but my testing shows that that's probably not the > case (I tested this with a XPS 15 touchscreen laptop, where > `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). > > My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` > structure instead: > > const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; Yes, I'll do that, I still have it around. - PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124142803
Re: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8]
On Wed, 22 May 2024 06:39:18 GMT, Johan Vos wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
>> line 1918:
>>
>>> 1916: * Returns the length of the viewport portion of the {@code
>>> VirtualFlow} as computed during the layout pass.
>>> 1917: * For a vertical flow, this corresponds to the height and for a
>>> horizontal flow to the width of the clip view,
>>> 1918: * but it does not necessarily have to be the same value.
>>
>> @johanvos added a question in the CSR about this last part:
>>
>>> I understand and agree with the goal behind this.
>>>
>>> I'm a bit confused though about the following: "...but it does not
>>> necessarily have to be the same value." -> can you elaborate a bit about
>>> this?
>>
>> I share this concern. I think that removing that last clause and putting a
>> period after "clip view" is probably the best.
>>
>> Johan: what do you think?
>
>> @johanvos added a question in the CSR about this last part:
>>
>> > I understand and agree with the goal behind this.
>> > I'm a bit confused though about the following: "...but it does not
>> > necessarily have to be the same value." -> can you elaborate a bit about
>> > this?
>>
>> I share this concern. I think that removing that last clause and putting a
>> period after "clip view" is probably the best.
>>
>> Johan: what do you think?
>
> I agree that removing that clause is probably best to avoid confusion. Having
> open-ended suggestions in javadoc can lead to broad speculation, so I think
> it either should be explained (like you did in the CSR issue with the
> rubberband effect example) or removed.
We should probably also avoid the word "corresponds".
/**
* Returns the length of the viewport portion of the {@code VirtualFlow} as
computed during the layout pass.
* For a vertical flow this is based on the height and for a horizontal flow on
the width of the clip view.
*
* @return the viewport length in pixels
* @since 23
*/
The text explains that depending on the orientation of the view height or width
is used in the calculation and the word "based" makes it clear that the value
can differ from the respective size of the view.
This version looks good to me. If it is fine for you too, I would check it in.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1609542246
Re: RFR: 8332313: Update code review guidelines [v4]
On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX >> [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) >> guidelines includes guidance for creating, reviewing, and integrating >> changes to JavaFX, along with a pointer to a [Code Review >> Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a >> goal of improving JavaFX and decreasing the chance of introducing a serious >> regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a >> [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) >> file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor >> changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at >> the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, >> and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review >> policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code >> review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one > additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Marked as reviewed by jhendrikx (Committer). - PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2070822120
Re: RFR: 8332313: Update code review guidelines [v4]
On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX >> [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) >> guidelines includes guidance for creating, reviewing, and integrating >> changes to JavaFX, along with a pointer to a [Code Review >> Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a >> goal of improving JavaFX and decreasing the chance of introducing a serious >> regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a >> [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) >> file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor >> changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at >> the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, >> and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review >> policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code >> review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one > additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added @johanvos Do you want to review this? - PR Comment: https://git.openjdk.org/jfx/pull/1455#issuecomment-2124636248
Re: RFR: 8289115: Touch events is not dispatched after upgrade to JAVAFX17+
On Wed, 22 May 2024 08:10:16 GMT, Jose Pereda wrote: >> This PR fixes a bug >> ([JDK-8289115](https://bugs.openjdk.org/browse/JDK-8289115)) that was >> introduced with #394, which changed the following line in the >> `NotifyTouchInput` function (ViewContainer.cpp): >> >> - const bool isDirect = true; >> + const bool isDirect = IsTouchEvent(); >> >> >> `IsTouchEvent` is a small utility function that uses the Windows SDK >> function `GetMessageExtraInfo` to distinguish between mouse events and pen >> events as described in this article: >> https://learn.microsoft.com/en-us/windows/win32/tablet/system-events-and-mouse-messages >> >> I think that using this function to distinguish between touchscreen events >> and pen events is erroneous. The linked article states: >> _"When your application receives a **mouse message** (such as >> WM_LBUTTONDOWN) [...]"_ >> >> But we are not receiving a mouse message in `NotifyTouchInput`, we are >> receiving a `WM_TOUCH` message. >> I couldn't find any information on whether this API usage is also supported >> for `WM_TOUCH` messages, but my testing shows that that's probably not the >> case (I tested this with a XPS 15 touchscreen laptop, where >> `GetMessageExtraInfo` returns 0 for `WM_TOUCH` messages). >> >> My suggestion is to check the `TOUCHEVENTF_PEN` flag of the `TOUCHINPUT` >> structure instead: >> >> const bool isDirect = (ti->dwFlags & TOUCHEVENTF_PEN) == 0; > > Yes, I'll do that, I still have it around. Reviewer: @jperedadnr - PR Comment: https://git.openjdk.org/jfx/pull/1459#issuecomment-2124650489
Re: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v8]
On Wed, 22 May 2024 08:36:22 GMT, eduardsdv wrote:
>>> @johanvos added a question in the CSR about this last part:
>>>
>>> > I understand and agree with the goal behind this.
>>> > I'm a bit confused though about the following: "...but it does not
>>> > necessarily have to be the same value." -> can you elaborate a bit about
>>> > this?
>>>
>>> I share this concern. I think that removing that last clause and putting a
>>> period after "clip view" is probably the best.
>>>
>>> Johan: what do you think?
>>
>> I agree that removing that clause is probably best to avoid confusion.
>> Having open-ended suggestions in javadoc can lead to broad speculation, so I
>> think it either should be explained (like you did in the CSR issue with the
>> rubberband effect example) or removed.
>
> We should probably also avoid the word "corresponds".
>
>
> /**
> * Returns the length of the viewport portion of the {@code VirtualFlow} as
> computed during the layout pass.
> * For a vertical flow this is based on the height and for a horizontal flow
> on the width of the clip view.
> *
> * @return the viewport length in pixels
> * @since 23
> */
>
> The text explains that depending on the orientation of the view height or
> width is used in the calculation and the word "based" makes it clear that the
> value can differ from the respective size of the view.
>
> This version looks good to me. If it is fine for you too, I would check it in.
I'm happy with this wording.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1326#discussion_r1609847508
Integrated: 8313138: Scrollbar Keyboard enhancement
On Wed, 6 Mar 2024 19:55:54 GMT, Andy Goryachev wrote: > Adding alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key > bindings to > > - ListView > - TreeView > - TableView > - TreeTableView > > to support keyboard-only horizontal and vertical scrolling. The main reason > for the change is to improve accessibility. > > **NOTE: For controls in right-to-left orientation, the direction of > horizontal scrolling is reversed.** > > As far as I can tell, these key combinations do not interfere with editing. > > The proposed solution can be further optimized by adding a public method to > the VirtualFlow class, something like > > > public void horizontalUnitScroll(boolean right); > public void verticalUnitScroll(boolean down); > > > Q: Does this change require a CSR to explain the change in the controls' > behavior? We don't yet have the key bindings documented in > /doc-files/behavior > > Note: > Jenkins headful test passed on all mac configurations, failed on all linux > configurations (master branch failed also, so it is test issue), while > windows configuration is not yet available. This pull request has now been integrated. Changeset: b685db23 Author:Andy Goryachev URL: https://git.openjdk.org/jfx/commit/b685db23f07df32a3caea7af36206c48b52bb6eb Stats: 1283 lines in 15 files changed: 1221 ins; 37 del; 25 mod 8313138: Scrollbar Keyboard enhancement Reviewed-by: arapte, kcr, kizune - PR: https://git.openjdk.org/jfx/pull/1393
Re: RFR: 8332313: Update code review guidelines [v4]
On Tue, 21 May 2024 22:32:21 GMT, Kevin Rushforth wrote: >> Update the code review guidelines for JavaFX. >> >> The JavaFX >> [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) >> guidelines includes guidance for creating, reviewing, and integrating >> changes to JavaFX, along with a pointer to a [Code Review >> Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. >> >> This PR updates these guidelines to improve the quality of reviews, with a >> goal of improving JavaFX and decreasing the chance of introducing a serious >> regression or other critical bug. >> >> The source branch has three commits: >> 1. Converts the Code Review Policies Wiki page to a >> [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) >> file in the repo and updates hyperlinks to the new location. >> 2. Update `README-code-reviews.md` with new guidelines >> 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor >> changes to `README-code-reviews.md`) >> >> Commit 1 is content neutral, so it might be helpful for reviewers to look at >> the changes starting from the second commit. >> >> The updates are: >> >> * In the Overview section, add a list of items for Reviewers, PR authors, >> and sponsoring Committers to verify prior to integration >> * Create a "Guidelines for reviewing a PR" subsection of the Code review >> policies section >> * Create a "Before you integrate or sponsor a PR" subsection of the Code >> review policies section >> * Update the `CONTRIBUTING.md` page to highlight important requirements > > Kevin Rushforth has updated the pull request incrementally with one > additional commit since the last revision: > > Clarify need for CSR when API is modified or removed as well as added Overall, this is a great improvement. Reviewing code is a huge responsibility and it's good that we make it more clear now how we expect reviews to be executed. - Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1455#pullrequestreview-2071576062
Re: RFR: 8323511: Scrollbar Click jumps inconsistent amount of pixels [v9]
> As seen in the unit test of the PR, when we click on the area above/below the > scrollbar the position jumps - but the jump is now not always consistent. > In the current version on the last cell - the UI always jumps to the top. In > the other cases, the assumed default cell height is used. > > With this PR, always the default cell height is used, to determine how much > is scrolled. > This makes the behavior more consistent. > > Especially from the unit-test, it's clear that with this PR the behavior is > much more consistent. > > This is also related to the following PR: > https://github.com/openjdk/jfx/pull/1194 Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision: JDK-8323511: Adjust javadoc of VirtualFlow.getViewportLength() - Changes: - all: https://git.openjdk.org/jfx/pull/1326/files - new: https://git.openjdk.org/jfx/pull/1326/files/023613d6..adfc3ef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1326&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1326.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1326/head:pull/1326 PR: https://git.openjdk.org/jfx/pull/1326
Integrated: 8332313: Update code review guidelines
On Wed, 15 May 2024 17:45:56 GMT, Kevin Rushforth wrote: > Update the code review guidelines for JavaFX. > > The JavaFX > [CONTRIBUTING](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/CONTRIBUTING.md) > guidelines includes guidance for creating, reviewing, and integrating > changes to JavaFX, along with a pointer to a [Code Review > Policies](https://wiki.openjdk.org/display/OpenJFX/Code+Reviews) Wiki page. > > This PR updates these guidelines to improve the quality of reviews, with a > goal of improving JavaFX and decreasing the chance of introducing a serious > regression or other critical bug. > > The source branch has three commits: > 1. Converts the Code Review Policies Wiki page to a > [README-code-reviews.md](https://github.com/kevinrushforth/jfx/blob/8332313-contributing/README-code-reviews.md) > file in the repo and updates hyperlinks to the new location. > 2. Update `README-code-reviews.md` with new guidelines > 3. Update `CONTRIBUTING.md` to highlight important requirements (and minor > changes to `README-code-reviews.md`) > > Commit 1 is content neutral, so it might be helpful for reviewers to look at > the changes starting from the second commit. > > The updates are: > > * In the Overview section, add a list of items for Reviewers, PR authors, and > sponsoring Committers to verify prior to integration > * Create a "Guidelines for reviewing a PR" subsection of the Code review > policies section > * Create a "Before you integrate or sponsor a PR" subsection of the Code > review policies section > * Update the `CONTRIBUTING.md` page to highlight important requirements This pull request has now been integrated. Changeset: 94aa2b68 Author:Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/94aa2b68d01af6096a18316ab36c911fe8cec572 Stats: 119 lines in 2 files changed: 110 ins; 0 del; 9 mod 8332313: Update code review guidelines Reviewed-by: jhendrikx, angorya, nlisker, jvos - PR: https://git.openjdk.org/jfx/pull/1455
PLEASE READ: Updates Code Review Policies
To: All jfx contributors, particularly those with a Reviewer or Committer role in the OpenJFX project on OpenJDK [1] As some of you are already aware, we have modified the JavaFX Code Review policies, including additional requirements for Reviewers, PR authors, and sponsoring Committers. The updated policy can be found in the README-code-reviews.md [2] doc in the mainline jfx repo; it is linked from the CONTRIBUTING.md [3] doc. Everyone contributing, reviewing or sponsoring a PR should become familiar with the updated Code Review Policies. ACTION: All Reviewers should read the "Guidelines for reviewing a PR" [4] section of the Code Review Policies ACTION: All PR authors, sponsoring Committers, and Reviewers should read the "Before you integrate or sponsor a PR" section [5] of the Code Review Policies Let me know if you have any questions. -- Kevin [1] https://openjdk.org/census#openjfx [2] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md [3] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md [4] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md#guidelines-for-reviewing-a-pr [5] https://github.com/openjdk/jfx/blob/master/README-code-reviews.md#before-you-integrate-or-sponsor-a-pr
RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage
This fixes two bugs appointed on the JBS issue: 1) Sometimes window was moving to the top left corner - seems to be a bug somewhere in `gdk_window_get_origin` when used before map (a X concept when the window appears). The change is to ignore the configure events (happens when location or size changes) until window is mapped. Before map java is notified in the `set_bounds` function. This seems to happen on newer versions of linux distros. 2) Specific to KDE, in the case of the example provided, when an MODAL window pops, it calls `set_enabled` `false` on the child (or all other windows if APPLICATION_MODAL) which causes it to update the window constraints. When maximized, the constraints where applied anyways, causing the window to still be maximized but not show as maximized. The change is to not apply constraints when not floating (meaning floating on the screen - not maximized, fullscreen or iconified). - Commit messages: - Fix - Teste - Teste - Teste - Fix 833 Changes: https://git.openjdk.org/jfx/pull/1460/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1460&range=00 Issue: https://bugs.openjdk.org/browse/JDK-833 Stats: 45 lines in 3 files changed: 28 ins; 6 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1460.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1460/head:pull/1460 PR: https://git.openjdk.org/jfx/pull/1460
Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v11]
On Sun, 12 May 2024 11:03:36 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, >> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to >> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on >> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Use prismES2EGLX11 as build name Reopening so maybe it could be usefult to [8332108](https://bugs.openjdk.org/browse/JDK-8332108) - PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2125800352
Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v12]
> Wayland implementation will require EGL. > > EGL works with Xorg as well. The idea is to be EGL first and if it fails, > fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. > > > See: > [Switching the Linux graphics stack from GLX to > EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) > [Prefer EGL to GLX for the GL support on > X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'refs/heads/master' into egl - Use prismES2EGLX11 as build name - Merge branch 'master' into egl - Prefer EGL over GLX - Merge branch 'master' into egl - Merge branch 'master' into egl # Conflicts: #modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c - Use EGL instead of GLX - Changes: https://git.openjdk.org/jfx/pull/1381/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1381&range=11 Stats: 2441 lines in 36 files changed: 1857 ins; 489 del; 95 mod Patch: https://git.openjdk.org/jfx/pull/1381.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1381/head:pull/1381 PR: https://git.openjdk.org/jfx/pull/1381
Re: RFR: 8329820: [Linux] Prefer EGL over GLX [v12]
On Wed, 22 May 2024 22:02:33 GMT, Thiago Milczarek Sayao wrote: >> Wayland implementation will require EGL. >> >> EGL works with Xorg as well. The idea is to be EGL first and if it fails, >> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available. >> >> >> See: >> [Switching the Linux graphics stack from GLX to >> EGL](https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/) >> [Prefer EGL to GLX for the GL support on >> X11](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/3540) > > Thiago Milczarek Sayao has updated the pull request with a new target base > due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'refs/heads/master' into egl > - Use prismES2EGLX11 as build name > - Merge branch 'master' into egl > - Prefer EGL over GLX > - Merge branch 'master' into egl > - Merge branch 'master' into egl > ># Conflicts: ># modules/javafx.graphics/src/main/native-prism-es2/x11/X11GLContext.c > - Use EGL instead of GLX Testing [8332108](https://bugs.openjdk.org/browse/JDK-8332108) with this branch seems to have a significance in favor of EGL: Using this branch, compare the attached example with and without `-Dprism.es2.forceGLX=true` - PR Comment: https://git.openjdk.org/jfx/pull/1381#issuecomment-2125863535
CFV: New OpenJFX Reviewer: John Hendrikx
I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. John is an OpenJFX community member, who has contributed 39 commits [2] to OpenJFX. John regularly participates in code reviews, especially in the areas of JavaFX properties, scene graph and UI controls, offering valuable feedback. Votes are due by June 5, 2024 at 23:59 UTC. Only current OpenJFX Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Nomination to a project Reviewer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#jhendrikx [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%22&type=commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#three-vote-consensus [5] https://openjdk.java.net/projects#project-reviewer
Re: CFV: New OpenJFX Reviewer: John Hendrikx
Vote: YES -- Kevin On 5/22/2024 4:24 PM, Kevin Rushforth wrote: I hereby nominate John Hendrikx [1] to OpenJFX Reviewer.
Re: CFV: New OpenJFX Reviewer: John Hendrikx
Vote: YES -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Wednesday, May 22, 2024 at 16:24 To: openjfx-dev , John Hendrikx Subject: CFV: New OpenJFX Reviewer: John Hendrikx I hereby nominate John Hendrikx [1] to OpenJFX Reviewer. John is an OpenJFX community member, who has contributed 39 commits [2] to OpenJFX. John regularly participates in code reviews, especially in the areas of JavaFX properties, scene graph and UI controls, offering valuable feedback. Votes are due by June 5, 2024 at 23:59 UTC. Only current OpenJFX Reviewers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [4]. Nomination to a project Reviewer is described in [5]. Thanks. -- Kevin [1] https://openjdk.org/census#jhendrikx [2] https://github.com/search?q=repo%3Aopenjdk%2Fjfx+author-name%3A%22John+Hendrikx%22&type=commits [3] https://openjdk.java.net/census#openjfx [4] https://openjdk.java.net/bylaws#three-vote-consensus [5] https://openjdk.java.net/projects#project-reviewer
Withdrawn: 8327179: Update the 3D lighting application
On Sun, 3 Mar 2024 22:29:02 GMT, Nir Lisker wrote: > Update for the 3D lighting test tool as described in the JBS issue. This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jfx/pull/1387
Re: RFR: 8332222: Linux Debian: Maximized stage shrinks when opening another stage
On Wed, 22 May 2024 21:28:47 GMT, Thiago Milczarek Sayao wrote: > This fixes two bugs appointed on the JBS issue: > > 1) Sometimes window was moving to the top left corner - seems to be a bug > somewhere in `gdk_window_get_origin` when used before map (a X concept when > the window appears). The change is to ignore the configure events (happens > when location or size changes) until window is mapped. Before map java is > notified in the `set_bounds` function. > > This seems to happen on newer versions of linux distros. > > 2) Specific to KDE, in the case of the example provided, when an MODAL window > pops, it calls `set_enabled` `false` on the child (or all other windows if > APPLICATION_MODAL) which causes it to update the window constraints. When > maximized, the constraints where applied anyways, causing the window to still > be maximized but not show as maximized. The change is to not apply > constraints when not floating (meaning floating on the screen - not > maximized, fullscreen or iconified). I was checking if this fix resolves the issue reported in [JDK-8332352](https://bugs.openjdk.org/browse/JDK-8332352) and found that this fix is causing change of behaviour in Ubuntu with KDE desktop environment. To reproduce the issue follow the steps given in [JDK-8332352](https://bugs.openjdk.org/browse/JDK-8332352). On selecting File menu, the popup window remains open until the mouse is pressed and closes as the mouse is released. The popup window is also not displayed below the File menu, it gets displayed with some offset, almost on the centre of the screen. This issue is not observed in MacOS. Screen recording of the above issue https://github.com/openjdk/jfx/assets/26969459/1a8cc7ce-5cd0-4562-85cb-01ea7f02b1de - PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126302490 PR Comment: https://git.openjdk.org/jfx/pull/1460#issuecomment-2126305088
