Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20]
On Sun, 18 Feb 2024 23:10:12 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative >> positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 >> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > 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 94 commits: > > - Merge branch 'master' into new_ime > - Add signals to avoid warnings > - Merge branch 'master' into new_ime > ># Conflicts: ># modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp > - Add check for jview > - - Fix comment path > - - Fix double keyrelease > - - Use a work-around to relative positioning (until wayland is not > officially supported) >- Unref pango attr list > - Merge branch 'master' into new_ime > - Account the case of !filtered > - Fix change of focus when on preedit + add filter on key release > - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 I did all of my testing on a Mac Retina display running Ubuntu 22 at 200% scale. Everything worked fine. - PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1951805227
Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]
On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and >> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and >> wrapped functions for GTK 3.20+ (so systems without it still run with GTK >> 3.8+), and fixes the dragging issue on Wayland. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Add compile-time checks to GdkSeat A shot in the dark since I don't own a touch enabled monitor: Test 1: Add `GDK_SCROLL_MASK` on the original `gdk_pointer_grab` function; Test 2: This PR uses `GDK_SEAT_CAPABILITY_ALL_POINTING` which includes the touch masks. So the equivalent would include `GDK_TOUCH_MASK` on `gdk_pointer_grab`. I would bet on option 2. - PR Comment: https://git.openjdk.org/jfx/pull/1305#issuecomment-1951510764
Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v20]
> This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative > positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 > 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) 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 94 commits: - Merge branch 'master' into new_ime - Add signals to avoid warnings - Merge branch 'master' into new_ime # Conflicts: #modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp - Add check for jview - - Fix comment path - - Fix double keyrelease - - Use a work-around to relative positioning (until wayland is not officially supported) - Unref pango attr list - Merge branch 'master' into new_ime - Account the case of !filtered - Fix change of focus when on preedit + add filter on key release - ... and 84 more: https://git.openjdk.org/jfx/compare/1fb56e33...eb988565 - Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=19 Stats: 448 lines in 7 files changed: 62 ins; 265 del; 121 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080
Re: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v19]
On Wed, 17 Jan 2024 17:10:24 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative >> positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 >> 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Add signals to avoid warnings I need help to test positioning on a HiDPI monitor. - PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-1951477097
RFR: JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen
This PR fixes the dialog freeze problem once and for all. This one is a bit tricky to understand, here is how it works: This bug happens on every platform, although the implementation of nested event loops differs on every platform. E.g. on Linux we use `gtk_main` and `gtk_main_quit`, on Windows and Mac we have an own implementation of a nested event loop (while loop), controlled by a boolean flag. Funny enough, the reason why this bug happens is always the same: Timing. 1. When we hide a dialog, `_leaveNestedEventLoop` is called. 2. This will call native code to get out of the nested event loop, e.g. on Windows we try to break out of the while loop with a boolean flag, on Linux we call `gtk_main_quit`. 3. Now, if we immediately open a new dialog, we enter a new nested event loop via `_enterNestedEventLoop`, as a consequence we do not break out of the while loop on Windows (the flag is set back again, the while loop is still running), and we do not return from `gtk_main` on Linux. 4. And this will result in the Java code never returning and calling `notifyLeftNestedEventLoop`, which we need to recover the UI. So it is actually not trivial to fix this problem, and we can not really do anything on the Java side. We may can try to wait until one more frame has run so that things will hopefully be right, but that sounds rather hacky. I therefore analyzed, if we even need to return from `_enterNestedEventLoop`. Turns out, we don't need to. There is a return value which we actually do not use (it does not have any meaning to us, other that it is used inside an assert statement). Without the need of a return value, we also do not need to care when `_enterNestedEventLoop` is returning - instead we cleanup and call `notifyLeftNestedEventLoop` in `_leaveNestedEventLoop`, after the native code was called. Lets see if this is the right approach (for all platforms). Testing appreciated. # - [x] Tested on Windows - [x] Tested on Linux - [x] Tested on Mac - [ ] Tested on iOS (although the nested event loop code is the same as for Mac) (I would appreciate if someone can do this as I have no access to an iOS device) - [ ] Adjust copyright - [ ] Write Systemtest - Commit messages: - JDK-8285893: Hiding dialog and showing new one causes dialog to be frozen Changes: https://git.openjdk.org/jfx/pull/1324/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285893 Stats: 164 lines in 13 files changed: 12 ins; 81 del; 71 mod Patch: https://git.openjdk.org/jfx/pull/1324.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1324/head:pull/1324 PR: https://git.openjdk.org/jfx/pull/1324
Re: Proposal: Bump minimum JDK version for JavaFX 23 to JDK 21
+1 On Sat, Feb 17, 2024, 15:37 John Hendrikx wrote: > +1 > > On 16/02/2024 23:11, Kevin Rushforth wrote: > > All, > > > > Even though we build JavaFX binaries with JDK 21 as the boot JDK, the > > latest version of JavaFX still runs with JDK 17, although it isn't > > tested with older JDK versions. In order for JavaFX to be able to use > > newer JDK features, such as code snippets (in API docs), record > > patterns, pattern matching for switch statements, and so forth, we > > need to increase the minimum version of the JDK that can run the > > latest JavaFX. Additionally, there is an ongoing cost to keeping > > JavaFX buildable and runnable on older versions of Java, and very > > little reason to continue to do so. > > > > A question was raised [1] as to whether we should go even further and, > > once JDK 22 is released, jump straight to JDK 22 as a minimum. While > > we could do that, I feel that there isn't sufficient justification for > > this at this time, although we could reconsider for next release. > > > > To this end, I propose to bump the minimum version of the JDK needed > > to run JavaFX 23 to JDK 21. I filed JDK-8321603 [2] to track this and > > prepared PR #1370 [3] (I've moved the PR back to Draft, pending this > > discussion). This will not affect update releases of earlier versions > > of JavaFX (e.g., JavaFX 21.0.NN or JavaFX 17.0.NN), which will > > continue to run with the same minimum JDK that they run on today. > > > > As a reminder, we only assure that JavaFX NN will run with JDK NN-1 or > > later, although in practice, we don't bump the minimum required JDK > > version without a good reason. For example, while JavaFX 22 is built > > using JDK 21 as the boot JDK, it produces class files that will run > > with JDK 17, using "--release 17". The proposed change discussed here > > would update that in JavaFX 23 to "--release 21". > > > > NOTE: this will not be an invitation to do wholesale refactoring of > > existing classes or methods to use newer language features (e.g., a PR > > that refactors existing switch statements and switch expressions into > > pattern-matching switch expressions would not be welcome). Rather, > > this can be seen as enabling judicious use of new features in new > > code, much as we did when we started allowing the use of "var", > > records, and pattern-matching instanceof. > > > > Comments are welcome. > > > > -- Kevin > > > > [1] > > https://mail.openjdk.org/pipermail/openjfx-dev/2023-December/044081.html > > [2] https://bugs.openjdk.org/browse/JDK-8321603 > > [3] https://github.com/openjdk/jfx/pull/1370 > > >
