Integrated: 8284654: Modal behavior returns to wrong stage
On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 This pull request has now been integrated. Changeset: 864792d8 Author:Thiago Milczarek Sayao URL: https://git.openjdk.java.net/jfx/commit/864792d84811b64815357722be0378397d212408 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8284654: Modal behavior returns to wrong stage Reviewed-by: arapte, kcr - PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage [v3]
On Tue, 10 May 2022 12:56:53 GMT, Thiago Milczarek Sayao
wrote:
>> When there's an APPLICATION_MODAL window, all other windows are disabled and
>> re-enabled when the APPLICATION_MODAL window closes. This causes
>> `requestToFront()` to be called on every window, and it does not guarantee
>> order.
>>
>> The fix also works for:
>> https://bugs.openjdk.java.net/browse/JDK-8269429
>>
>> But this one might need another fix:
>> https://bugs.openjdk.java.net/browse/JDK-8240640
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Revert "Set the focus on the latest window when re-enabling them"
>
> This reverts commit b024de586c187f9000f791dab99507a4979cc027.
I reverted the last change.
After more analysis I think it's not a bug, but a side-effect of not using
native window modality in favor of enabling/disabling windows.
It works like this:
On the original step 5 ("Click anywhere in Window One") the window would get
the focus, but instead will send a FOCUS_DISABLED event, which will bring up
the MODAL window.
The problem is that the window will get the focus, to be lost in favor of the
last window (which is the MODAL one).
To prevent this, a disabled window should never be focused. But that prevents
the whole FOCUS_DISABLED logic.
Note that the APPLICATION_MODAL window on the example has no owner, so I think
it's ok to consider a side effect and not a bug.
-
PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage [v3]
> When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert "Set the focus on the latest window when re-enabling them" This reverts commit b024de586c187f9000f791dab99507a4979cc027. - Changes: - all: https://git.openjdk.java.net/jfx/pull/784/files - new: https://git.openjdk.java.net/jfx/pull/784/files/b024de58..a6cad45b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=784=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=784=01-02 Stats: 8 lines in 2 files changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage
On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 The test does not set the Window owner. It's one APPLICATION_MODAL window. I have adjusted the PR to handle this case. It will set focus on the latest opened window when re-enabling, but will not change stacking order. - PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage [v2]
> When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Set the focus on the latest window when re-enabling them - Changes: - all: https://git.openjdk.java.net/jfx/pull/784/files - new: https://git.openjdk.java.net/jfx/pull/784/files/72317b21..b024de58 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=784=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=784=00-01 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage
On Fri, 22 Apr 2022 19:26:36 GMT, Thiago Milczarek Sayao wrote: > When there's an APPLICATION_MODAL window, all other windows are disabled and > re-enabled when the APPLICATION_MODAL window closes. This causes > `requestToFront()` to be called on every window, and it does not guarantee > order. > > The fix also works for: > https://bugs.openjdk.java.net/browse/JDK-8269429 > > But this one might need another fix: > https://bugs.openjdk.java.net/browse/JDK-8240640 Step 5 falls on: mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled); which is correct, so might be a bug on java code. - PR: https://git.openjdk.java.net/jfx/pull/784
Re: RFR: 8284654: Modal behavior returns to wrong stage
On Thu, 5 May 2022 13:46:56 GMT, Ambarish Rapte wrote:
>> When there's an APPLICATION_MODAL window, all other windows are disabled and
>> re-enabled when the APPLICATION_MODAL window closes. This causes
>> `requestToFront()` to be called on every window, and it does not guarantee
>> order.
>>
>> The fix also works for:
>> https://bugs.openjdk.java.net/browse/JDK-8269429
>>
>> But this one might need another fix:
>> https://bugs.openjdk.java.net/browse/JDK-8240640
>
> This change fixes the exact issue that is reported in
> [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654).
> and [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) does not
> reproduce with this change.
>
>
> But I observed another issue that occurs with this change.
> Steps:
> 1. Run the sample attached to
> [JDK-8284654](https://bugs.openjdk.java.net/browse/JDK-8284654).
> 2. Click button One and Two both once
> 3. Re-arrange both the windows such that they are visible.
> 4. Click the button "Click here" in Window Two: Error dialog will be displayed
> 5. Click anywhere in Window One
> 6. Close the Error dialog
> => Observe that Window One gets the focus and not Window Two.
>
> I think the expected behavior here should be: After closing a dialog the
> Focus should return to its parent window.
@arapte I think it's another bug on Linux, as the window should not accept
focus when disabled, so it should not reorder windows when you click it
("Window One" on step 5).
Did you test it on Linux?
-
PR: https://git.openjdk.java.net/jfx/pull/784
RFR: 8284654: Modal behavior returns to wrong stage
When there's an APPLICATION_MODAL window, all other windows are disabled and re-enabled when the APPLICATION_MODAL window closes. This causes `requestToFront()` to be called on every window, and it does not guarantee order. The fix also works for: https://bugs.openjdk.java.net/browse/JDK-8269429 But this one might need another fix: https://bugs.openjdk.java.net/browse/JDK-8240640 - Commit messages: - Fix for JDK-8284654 - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - ... and 12 more: https://git.openjdk.java.net/jfx/compare/d1110f47...72317b21 Changes: https://git.openjdk.java.net/jfx/pull/784/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=784=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284654 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/784.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/784/head:pull/784 PR: https://git.openjdk.java.net/jfx/pull/784
Re: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2]
On Mon, 14 Mar 2022 18:18:38 GMT, Kevin Rushforth wrote: >> doc-files/release-notes-18.md line 105: >> >>> 103: [JDK-8274929](https://bugs.openjdk.java.net/browse/JDK-8274929)|Crash >>> while reading specific clipboard content|window-toolkit >>> 104: [JDK-8275723](https://bugs.openjdk.java.net/browse/JDK-8275723)|Crash >>> on macOS 12 in GlassRunnable::dealloc|window-toolkit >>> 105: >> >> [REDO] Wrong stage gets focused after modal stage creation >> https://bugs.openjdk.java.net/browse/JDK-8271054 ? > > No, that fix is in 19. These release notes are for 18. Sorry, my mistake. - PR: https://git.openjdk.java.net/jfx/pull/752
Re: [jfx18] RFR: 8282766: Create release notes for JavaFX 18 [v2]
On Sun, 13 Mar 2022 10:07:26 GMT, Abhinay Agarwal wrote: >> Add release notes for JavaFX 18 to the repository > > Abhinay Agarwal has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - s/Enhancement/Enhancements > - Create release notes for JavaFX 18 doc-files/release-notes-18.md line 105: > 103: [JDK-8274929](https://bugs.openjdk.java.net/browse/JDK-8274929)|Crash > while reading specific clipboard content|window-toolkit > 104: [JDK-8275723](https://bugs.openjdk.java.net/browse/JDK-8275723)|Crash on > macOS 12 in GlassRunnable::dealloc|window-toolkit > 105: [REDO] Wrong stage gets focused after modal stage creation https://bugs.openjdk.java.net/browse/JDK-8271054 ? - PR: https://git.openjdk.java.net/jfx/pull/752
Integrated: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
This pull request has now been integrated.
Changeset: c6069d68
Author:Thiago Milczarek Sayao
URL:
https://git.openjdk.java.net/jfx/commit/c6069d6845df4b90cca226e2b3dff49e3b48d8ac
Stats: 23 lines in 2 files changed: 22 ins; 0 del; 1 mod
8271054: [REDO] Wrong stage gets focused after modal stage creation
Reviewed-by: kcr, arapte
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v10]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Review adjustments
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/ee8ab1e2..42157fec
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=09
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=08-09
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
On Tue, 8 Mar 2022 13:12:03 GMT, Ambarish Rapte wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Capture event serial on process_key
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 780:
>
>> 778: }
>> 779:
>> 780: event_serial = 0;
>
> should we use GDK_CURRENT_TIME instead of 0 ?
> GDK_CURRENT_TIME is defined also as 0 and represent current time.
GDK_CURRENT_TIME is always 0, but it looks better. Changed it.
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1390:
>
>> 1388: // prevents activeWindows on WindowStage.java to be out of
>> order which may cause the FOCUS_DISABLED event
>> 1389: // to bring up the wrong window (it brings up the last which
>> will not be the real "last" if out of order).
>> 1390: gtk_window_present_with_time(GTK_WINDOW(gtk_widget),
>> event_serial);
>
> `event_serial` is not reset after use. I could observe that a stale value of
> `event_serial` gets reused several times.
> Steps to observe the behavior:
> 1. Print event_serial in this method
> 2. Run the sample program attached to JBS.
> 3. Press the "Click Me!" button
> 4. Answer YES on the Alert
> 5. Three stages should be visible on the screen.
> 6. Relocate such that all stages are visible
> 7. Click on 'This should be on Top' Stage
> 8. Click on "This is a stage with no owner' stage.
> 9. Click on StageTest icon in Taskbar. Keep repeating this step. The stage
> gains and looses focus and the same event_serial gets printed on terminal.
> => It does not look harmful behavior wise. But can observe that
> `event_serial` gets reused.
> Screenshot:
> src="https://user-images.githubusercontent.com/11330676/157248115-61240f6c-1710-461e-ba60-08e6210774e7.png;>
>
>
>
> Will it be good idea to reset it to 0/GDK_CURRENT_TIME and use something like,
>
>
> if (event_serial == GDK_CURRENT_TIME) {
> gtk_window_present(GTK_WINDOW(gtk_widget));
> } else {
> gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
> event_serial = GDK_CURRENT_TIME;
> }
>
>
> OR
>
>
> gtk_window_present_with_time(GTK_WINDOW(gtk_widget), event_serial);
> event_serial = GDK_CURRENT_TIME;
You're right, it can avoid other possible errors.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Sat, 11 Dec 2021 00:32:06 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Minimize changes > > On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix. @kevinrushforth can you try this lastest version, please? - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Capture event serial on process_key
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/8630c557..ee8ab1e2
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=08
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=07-08
Stats: 7 lines in 2 files changed: 6 ins; 1 del; 0 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v8]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Another approach.
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/196cecfe..8630c557
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=07
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=06-07
Stats: 22 lines in 3 files changed: 12 ins; 7 del; 3 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao
wrote:
>> Found the problem thru this path:
>>
>> **WindowStage.java**
>>
>> final void handleFocusDisabled() {
>> if (activeWindows.isEmpty()) {
>> return;
>> }
>> WindowStage window = activeWindows.get(activeWindows.size() - 1);
>> window.setIconified(false);
>> window.requestToFront();
>> window.requestFocus();
>> }
>>
>>
>> **glass_window.cpp**
>>
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>...
>>
>> if (jwindow) {
>> if (!event->in || isEnabled()) {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>> event->in ?
>> com_sun_glass_events_WindowEvent_FOCUS_GAINED :
>> com_sun_glass_events_WindowEvent_FOCUS_LOST);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> } else {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> }
>> }
>> }
>>
>>
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
>> triggered the java code on the Primary Stage (on the bug reproduce code).
>>
>> The docs states:
>>
>> /**
>> * Enables or disables the window.
>> *
>> * A disabled window is unfocusable by definition.
>> * Also, key or mouse events aren't generated for disabled windows.
>> *
>> * When a user tries to activate a disabled window, or the window gets
>> * accidentally brought to the top of the stacking order, the window
>> * generates the FOCUS_DISABLED window event. A Glass client should react
>> * to this event and bring the currently active modal blocker of the
>> * disabled window to top by calling blocker's minimize(false),
>> toFront(),
>> * and requestFocus() methods. It may also 'blink' the blocker window to
>> * further attract user's attention.
>> *
>> .
>>
>>
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
>> not understand why it `requestToFront` and `requestFocus` on the latest
>> window.
>>
>> The solution makes disabled windows unfocusable and prevents mouse and
>> keyboard events as the docs states, making it compatible with other
>> platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Minimize changes
It would be nice to have this fix on jfx 17, since currently the issue causes
random windows to be focused and it's very confusing to the end user.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Mon, 1 Nov 2021 16:46:34 GMT, Thiago Milczarek Sayao
wrote:
>> Found the problem thru this path:
>>
>> **WindowStage.java**
>>
>> final void handleFocusDisabled() {
>> if (activeWindows.isEmpty()) {
>> return;
>> }
>> WindowStage window = activeWindows.get(activeWindows.size() - 1);
>> window.setIconified(false);
>> window.requestToFront();
>> window.requestFocus();
>> }
>>
>>
>> **glass_window.cpp**
>>
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>...
>>
>> if (jwindow) {
>> if (!event->in || isEnabled()) {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>> event->in ?
>> com_sun_glass_events_WindowEvent_FOCUS_GAINED :
>> com_sun_glass_events_WindowEvent_FOCUS_LOST);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> } else {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> }
>> }
>> }
>>
>>
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
>> triggered the java code on the Primary Stage (on the bug reproduce code).
>>
>> The docs states:
>>
>> /**
>> * Enables or disables the window.
>> *
>> * A disabled window is unfocusable by definition.
>> * Also, key or mouse events aren't generated for disabled windows.
>> *
>> * When a user tries to activate a disabled window, or the window gets
>> * accidentally brought to the top of the stacking order, the window
>> * generates the FOCUS_DISABLED window event. A Glass client should react
>> * to this event and bring the currently active modal blocker of the
>> * disabled window to top by calling blocker's minimize(false),
>> toFront(),
>> * and requestFocus() methods. It may also 'blink' the blocker window to
>> * further attract user's attention.
>> *
>> .
>>
>>
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
>> not understand why it `requestToFront` and `requestFocus` on the latest
>> window.
>>
>> The solution makes disabled windows unfocusable and prevents mouse and
>> keyboard events as the docs states, making it compatible with other
>> platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Minimize changes
The ideal fix would be to know the original event and save it's X11 serial
event number to pass to `gtk_window_present_with_time` so "focus stealing"
would not happen. But I don't think it's possible because it should save the
"event serial number" on the original mouse click to open a window (for
example). As you have thought, many "original event" combinations are possible.
The fix just reorders the `WindowStage.activeWindows` by calling
`FOCUS_GAINED`. So when `FOCUS_DISABLED` happens it focuses the correct window.
Please not that with this fix there are extra calls to FOCUS events and reorder
of `WindowStage.activeWindows` (although they are not expensive).
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Minimize changes
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/d51988c8..196cecfe
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=06
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=05-06
Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v6]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Fixes de problem
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/c54a5413..d51988c8
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=05
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=04-05
Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v5]
On Fri, 29 Oct 2021 22:35:47 GMT, Thiago Milczarek Sayao
wrote:
>> Found the problem thru this path:
>>
>> **WindowStage.java**
>>
>> final void handleFocusDisabled() {
>> if (activeWindows.isEmpty()) {
>> return;
>> }
>> WindowStage window = activeWindows.get(activeWindows.size() - 1);
>> window.setIconified(false);
>> window.requestToFront();
>> window.requestFocus();
>> }
>>
>>
>> **glass_window.cpp**
>>
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>...
>>
>> if (jwindow) {
>> if (!event->in || isEnabled()) {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>> event->in ?
>> com_sun_glass_events_WindowEvent_FOCUS_GAINED :
>> com_sun_glass_events_WindowEvent_FOCUS_LOST);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> } else {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> }
>> }
>> }
>>
>>
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
>> triggered the java code on the Primary Stage (on the bug reproduce code).
>>
>> The docs states:
>>
>> /**
>> * Enables or disables the window.
>> *
>> * A disabled window is unfocusable by definition.
>> * Also, key or mouse events aren't generated for disabled windows.
>> *
>> * When a user tries to activate a disabled window, or the window gets
>> * accidentally brought to the top of the stacking order, the window
>> * generates the FOCUS_DISABLED window event. A Glass client should react
>> * to this event and bring the currently active modal blocker of the
>> * disabled window to top by calling blocker's minimize(false),
>> toFront(),
>> * and requestFocus() methods. It may also 'blink' the blocker window to
>> * further attract user's attention.
>> *
>> .
>>
>>
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
>> not understand why it `requestToFront` and `requestFocus` on the latest
>> window.
>>
>> The solution makes disabled windows unfocusable and prevents mouse and
>> keyboard events as the docs states, making it compatible with other
>> platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Still not correct
The problem occurs because `WindowStage.activeWindows` gets out of order,
because of focus events. So when "Focus Disabled" happens it brings up the
wrong window.
Probably because "Focus Stealing" situation which is mentioned on:
https://docs.gtk.org/gtk3/method.Window.present_with_time.html
I'm working on the fix.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v5]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Still not correct
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/eca324df..c54a5413
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=04
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=03-04
Stats: 18 lines in 5 files changed: 3 ins; 6 del; 9 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v4]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request with a new target base due
to a merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains 23 additional commits
since the last revision:
- Prevent focus stealing
- Merge branch 'master' into
jdk_8271054_wrong_stage_gets_focused_after_modal_stage_creation
- Merge branch 'openjdk:master' into master
- Break if reach self
- handleFocusDisabled() should bring up the blocker window not the previous
one.
- Fix for JDK-8271054
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Merge pull request #18 from openjdk/master
Merge master
- Merge pull request #17 from openjdk/master
Pull from origin
- ... and 13 more: https://git.openjdk.java.net/jfx/compare/fa234fdd...eca324df
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/eb93b8b9..eca324df
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=03
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=02-03
Stats: 9848 lines in 801 files changed: 8688 ins; 160 del; 1000 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Tue, 12 Oct 2021 15:16:53 GMT, Pankaj Bansal wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
>> line 861:
>>
>>> 859:
>>> 860: // walk backwards to find a blocker
>>> 861: for (int i = activeWindows.size() - 1; i > 0; i--) {
>>
>> I think you will need to revert this part of the change.
>
> The test "WrongStageFocusWithApplicationModalityTest" passed for me on Ubuntu
> 20.04 VM. It failed first time, but when I re-ran it, it passed for me. I
> will run this change in Linux, Windows and Mac again today and report back.
@pankaj-bansal Wait, because I will rework it since it fails on JDK-8269429 and
JDK-8240640.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal wrote: >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > > I am running a 20.04 VM. The test fails for me 60-70% of the time. I will > request someone in team to try this once. @pankaj-bansal Can you try the test attached to the JBS on macos and windows? Thanks. - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
On Wed, 22 Sep 2021 16:39:15 GMT, Thiago Milczarek Sayao
wrote:
>> Found the problem thru this path:
>>
>> **WindowStage.java**
>>
>> final void handleFocusDisabled() {
>> if (activeWindows.isEmpty()) {
>> return;
>> }
>> WindowStage window = activeWindows.get(activeWindows.size() - 1);
>> window.setIconified(false);
>> window.requestToFront();
>> window.requestFocus();
>> }
>>
>>
>> **glass_window.cpp**
>>
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>...
>>
>> if (jwindow) {
>> if (!event->in || isEnabled()) {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>> event->in ?
>> com_sun_glass_events_WindowEvent_FOCUS_GAINED :
>> com_sun_glass_events_WindowEvent_FOCUS_LOST);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> } else {
>> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>> CHECK_JNI_EXCEPTION(mainEnv)
>> }
>> }
>> }
>>
>>
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
>> triggered the java code on the Primary Stage (on the bug reproduce code).
>>
>> The docs states:
>>
>> /**
>> * Enables or disables the window.
>> *
>> * A disabled window is unfocusable by definition.
>> * Also, key or mouse events aren't generated for disabled windows.
>> *
>> * When a user tries to activate a disabled window, or the window gets
>> * accidentally brought to the top of the stacking order, the window
>> * generates the FOCUS_DISABLED window event. A Glass client should react
>> * to this event and bring the currently active modal blocker of the
>> * disabled window to top by calling blocker's minimize(false),
>> toFront(),
>> * and requestFocus() methods. It may also 'blink' the blocker window to
>> * further attract user's attention.
>> *
>> .
>>
>>
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
>> not understand why it `requestToFront` and `requestFocus` on the latest
>> window.
>>
>> The solution makes disabled windows unfocusable and prevents mouse and
>> keyboard events as the docs states, making it compatible with other
>> platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Break if reach self
Just a note, our javafx application at the company I work for is unusable with
javafx17 on Linux, windows go behind their owner or pops up wrongly. Can't use
17 line until it's fixed.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v3]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
Break if reach self
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/850cfc8b..eb93b8b9
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=02
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=01-02
Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
I have proposed a different fix, but it might have concurrency issues and
probably others that should be investigated.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v2]
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Thiago Milczarek Sayao has updated the pull request incrementally with one
additional commit since the last revision:
handleFocusDisabled() should bring up the blocker window not the previous one.
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/598/files
- new: https://git.openjdk.java.net/jfx/pull/598/files/3770f101..850cfc8b
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jfx=598=01
- incr: https://webrevs.openjdk.java.net/?repo=jfx=598=00-01
Stats: 16 lines in 2 files changed: 10 ins; 0 del; 6 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Docs states:
/*
* When a user tries to activate a disabled window, or the window gets
* accidentally brought to the top of the stacking order, the window
* generates the FOCUS_DISABLED window event. A Glass client should
react
* to this event and bring the currently active modal blocker of the
* disabled window to top by calling blocker's minimize(false),
toFront(),
* and requestFocus() methods. It may also 'blink' the blocker window to
* further attract user's attention.
*/
But `WindowStage.java` actually does:
final void handleFocusDisabled() {
if (activeWindows.isEmpty()) {
return;
}
WindowStage window = activeWindows.get(activeWindows.size() - 1);
window.setIconified(false);
window.requestToFront();
window.requestFocus();
}
It brings up current activeWindows.size() - 1, not actually the MODAL blocker.
Seems wrong to me.
The event is born on `glass_window.cpp`:
```c++
mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
The current proposed code (which I will redo) blocks this line from being sent
(on non-virtual machines apparently). But commenting the
`jWindowNotifyFocusDisabled` should make the problem disappear (just to test
the theory).
-
PR: https://git.openjdk.java.net/jfx/pull/598
Integrated: 8271398: GTK3 drag view image swaps red and blue color channels
On Fri, 6 Aug 2021 02:18:38 GMT, Thiago Milczarek Sayao wrote: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor This pull request has now been integrated. Changeset: b2ecfacf Author:Thiago Milczarek Sayao Committer: Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/b2ecfacf0d8c9512d0b4cc13c1ac6c104a20f396 Stats: 112 lines in 2 files changed: 93 ins; 18 del; 1 mod 8271398: GTK3 drag view image swaps red and blue color channels Reviewed-by: pbansal, kcr - PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v5]
> It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: - Fix leak - Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/29c6148e..ccbe4708 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=599=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=599=03-04 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4]
On Thu, 16 Sep 2021 21:57:08 GMT, Kevin Rushforth wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Review requests.
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_dnd.cpp line 916:
>
>> 914:
>> 915: if (is_raw_image) {
>> 916: data = (guchar*)
>> convert_BGRA_to_RGBA((const int*) data, w * 4, h);
>
> This will leak memory, since the original buffer allocated by the call to
> `g_try_malloc0` on line 911 is never freed. I recommend something like this:
>
>
> guchar* origdata = data;
> data = (guchar*) convert_BGRA_to_RGBA((const int*) origdata, w * 4,
> h);
> g_free(origdata);
Fixed. I really felt something was missing :)
-
PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal wrote: >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > >> Weird, It works consistently for me on 20.04. Just tested again to be sure. > > I am running a 20.04 VM. The test fails for me 60-70% of the time. I will > request someone in team to try this once. @pankaj-bansal Could you please re-test to confirm that it does not work on your VM? - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3]
On Tue, 17 Aug 2021 13:10:53 GMT, Pankaj Bansal wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Change test to manual
>
> tests/manual/dnd/DndTestDragViewRawImage.java line 59:
>
>> 57: });
>> 58:
>> 59: Label label = new Label("Drag image should match source colors
>> when dragged");
>
> Could you please make the instructions a bit more clear?
I tried :)
-
PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v4]
> It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Review requests. - Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/4509462a..29c6148e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=599=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=599=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3]
On Sun, 15 Aug 2021 21:18:51 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses >> `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with >> `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the >> old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar >> dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar >> dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp >> apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp >> apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Change test to manual `gdk_cairo_set_source_pixbuf` is available since gtk 2.8. I can't find the minimum gtk version for 2.0. - PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v3]
> It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Change test to manual - Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/5530488c..4509462a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=599=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=599=01-02 Stats: 254 lines in 2 files changed: 83 ins; 171 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v2]
On Wed, 11 Aug 2021 23:42:47 GMT, Thiago Milczarek Sayao wrote: >> It seems raw images need to be converted BRGA -> RGBA. >> >> It was being converted on gtk2 code path, but gtk3 only uses >> `gtk_drag_set_icon_pixbuf`. >> >> I have simplified the gtk2 `DragView::View::expose` to paint with >> `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the >> old way was somehow converting again. >> >> Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. >> >> To test: >> >> `./gradlew apps` >> >> >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar >> dragdrop.DragDropWithControls >> java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar >> dragdrop.DragDropColor >> >> java -Djdk.gtk.version=2 @build/run.args -cp >> apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls >> java -Djdk.gtk.version=2 @build/run.args -cp >> apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Provide test JBS: https://bugs.openjdk.java.net/browse/JDK-8272492 Changed test to manual. - PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
Weird, It works consistently for me on 20.04. Just tested again to be sure.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels
On Sun, 15 Aug 2021 16:26:59 GMT, Pankaj Bansal wrote: >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests >> test.robot.javafx.dnd.DndRawImageTest` > >> Test works on Linux, don't know on other platforms. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests >> test.robot.javafx.dnd.DndRawImageTest` > > The fix does solve the issue and looks good to me. > > The test is failing on Windows 10 and Mac 10.15. As Kevin has mentioned in > other comment, if the automated test is too complex, you can change the test > to manual one and file a new bug for automated test and assign it to me. I > will write an automated in future. @pankaj-bansal Do you prefer I switch the test to manual or make the current one only for Linux? - PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels [v2]
> It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Provide test - Changes: - all: https://git.openjdk.java.net/jfx/pull/599/files - new: https://git.openjdk.java.net/jfx/pull/599/files/de2d8ddc..5530488c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=599=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=599=00-01 Stats: 171 lines in 1 file changed: 171 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels
On Fri, 6 Aug 2021 02:18:38 GMT, Thiago Milczarek Sayao wrote: > It seems raw images need to be converted BRGA -> RGBA. > > It was being converted on gtk2 code path, but gtk3 only uses > `gtk_drag_set_icon_pixbuf`. > > I have simplified the gtk2 `DragView::View::expose` to paint with > `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8) because the > old way was somehow converting again. > > Run the issue sample with `-Djdk.gtk.version=2` to test the gtk2 code path. > > To test: > > `./gradlew apps` > > > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropWithControls > java @build/run.args -cp apps/toys/DragDrop/dist/DragDrop.jar > dragdrop.DragDropColor > > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropWithControls > java -Djdk.gtk.version=2 @build/run.args -cp > apps/toys/DragDrop/dist/DragDrop.jar dragdrop.DragDropColor Test works on Linux, don't know on other platforms. `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests test.robot.javafx.dnd.DndRawImageTest` - PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271398: GTK3 drag view image swaps red and blue color channels
On Fri, 6 Aug 2021 05:30:39 GMT, Pankaj Bansal wrote: > I will look at this. Meanwhile, could you please write an automated system > test for this? Sure, I would provide it, but in the past drag and drop tests were not possible. Any ideas? - PR: https://git.openjdk.java.net/jfx/pull/599
RFR: 8271398: GTK3 drag view image swaps red and blue color channels
It seems raw images need to be converted BRGA -> RGBA. It was being converted on gtk2 code path, but gtk3 only uses `gtk_drag_set_icon_pixbuf`. It simplified the gtk2 `DragView::View::expose` to paint with `gdk_cairo_set_source_pixbuf` (that is available since Gtk 2.8). The existing path seems to be converting again. Run the issue sample with `-Djdk.gtk.version=2` to test. - Commit messages: - Fix JDK-8271398 - Merge branch 'openjdk:master' into master - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - Merge pull request #15 from openjdk/master - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - ... and 8 more: https://git.openjdk.java.net/jfx/compare/ba61a173...de2d8ddc Changes: https://git.openjdk.java.net/jfx/pull/599/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=599=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271398 Stats: 24 lines in 1 file changed: 5 ins; 18 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/599.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/599/head:pull/599 PR: https://git.openjdk.java.net/jfx/pull/599
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
On Thu, 5 Aug 2021 23:38:06 GMT, Thiago Milczarek Sayao
wrote:
> Found the problem thru this path:
>
> **WindowStage.java**
>
> final void handleFocusDisabled() {
> if (activeWindows.isEmpty()) {
> return;
> }
> WindowStage window = activeWindows.get(activeWindows.size() - 1);
> window.setIconified(false);
> window.requestToFront();
> window.requestFocus();
> }
>
>
> **glass_window.cpp**
>
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>...
>
> if (jwindow) {
> if (!event->in || isEnabled()) {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
> event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED
> : com_sun_glass_events_WindowEvent_FOCUS_LOST);
> CHECK_JNI_EXCEPTION(mainEnv)
> } else {
> mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
> CHECK_JNI_EXCEPTION(mainEnv)
> }
> }
> }
>
>
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
> triggered the java code on the Primary Stage (on the bug reproduce code).
>
> The docs states:
>
> /**
> * Enables or disables the window.
> *
> * A disabled window is unfocusable by definition.
> * Also, key or mouse events aren't generated for disabled windows.
> *
> * When a user tries to activate a disabled window, or the window gets
> * accidentally brought to the top of the stacking order, the window
> * generates the FOCUS_DISABLED window event. A Glass client should react
> * to this event and bring the currently active modal blocker of the
> * disabled window to top by calling blocker's minimize(false), toFront(),
> * and requestFocus() methods. It may also 'blink' the blocker window to
> * further attract user's attention.
> *
> .
>
>
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did
> not understand why it `requestToFront` and `requestFocus` on the latest
> window.
>
> The solution makes disabled windows unfocusable and prevents mouse and
> keyboard events as the docs states, making it compatible with other platforms.
-
PR: https://git.openjdk.java.net/jfx/pull/598
RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation
Found the problem thru this path:
**WindowStage.java**
final void handleFocusDisabled() {
if (activeWindows.isEmpty()) {
return;
}
WindowStage window = activeWindows.get(activeWindows.size() - 1);
window.setIconified(false);
window.requestToFront();
window.requestFocus();
}
**glass_window.cpp**
void WindowContextBase::process_focus(GdkEventFocus* event) {
...
if (jwindow) {
if (!event->in || isEnabled()) {
mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED :
com_sun_glass_events_WindowEvent_FOCUS_LOST);
CHECK_JNI_EXCEPTION(mainEnv)
} else {
mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
CHECK_JNI_EXCEPTION(mainEnv)
}
}
}
So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which
triggered the java code on the Primary Stage (on the bug reproduce code).
The docs states:
/**
* Enables or disables the window.
*
* A disabled window is unfocusable by definition.
* Also, key or mouse events aren't generated for disabled windows.
*
* When a user tries to activate a disabled window, or the window gets
* accidentally brought to the top of the stacking order, the window
* generates the FOCUS_DISABLED window event. A Glass client should react
* to this event and bring the currently active modal blocker of the
* disabled window to top by calling blocker's minimize(false), toFront(),
* and requestFocus() methods. It may also 'blink' the blocker window to
* further attract user's attention.
*
.
So I guess the C++ side is ok, java side on `handleFocusDisabled` looks fishy
to me, but not sure about that.
-
Commit messages:
- Fix for JDK-8271054
- Merge branch 'openjdk:master' into master
- Merge branch 'openjdk:master' into master
- Merge pull request #18 from openjdk/master
- Merge pull request #17 from openjdk/master
- Merge pull request #16 from openjdk/master
- Merge pull request #15 from openjdk/master
- Merge pull request #14 from openjdk/master
- Merge pull request #13 from openjdk/master
- Merge pull request #12 from openjdk/master
- ... and 8 more: https://git.openjdk.java.net/jfx/compare/ba61a173...3770f101
Changes: https://git.openjdk.java.net/jfx/pull/598/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx=598=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8271054
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jfx/pull/598.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598
PR: https://git.openjdk.java.net/jfx/pull/598
Withdrawn: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly
On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on > APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL > windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right > function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` > fits for `WINDOW_MODAL`. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v3]
On Sat, 10 Jul 2021 16:06:18 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on >> APPLICATION_MODAL windows, so they will not stay behind non >> APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the >> right function to be called for `APPLICATION_MODAL`, as >> `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Remove unneeded test for modal This is also fixed by #581. - PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2]
On Fri, 9 Jul 2021 18:41:11 GMT, Kevin Rushforth wrote:
>> Thiago Milczarek Sayao has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reuse existing set_modal (which was previously unused).
>
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 1436:
>
>> 1434: gtk_window_set_transient_for(GTK_WINDOW(gtk_widget),
>> parent->get_gtk_window());
>> 1435: } else {
>> 1436: gtk_window_set_keep_above(GTK_WINDOW(gtk_widget), modal ?
>> TRUE : FALSE);
>
> The test of `modal` is unnecessary here, since this is all within an `if
> (modal)` block.
Done.
-
PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v3]
> The PR approach is to set `gtk_window_set_keep_above` to true on > APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL > windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right > function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` > fits for `WINDOW_MODAL`. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded test for modal - Changes: - all: https://git.openjdk.java.net/jfx/pull/551/files - new: https://git.openjdk.java.net/jfx/pull/551/files/612a61ea..f7d2a9dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=551=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=551=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551 PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2]
On Tue, 29 Jun 2021 21:58:36 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on >> APPLICATION_MODAL windows, so they will not stay behind non >> APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the >> right function to be called for `APPLICATION_MODAL`, as >> `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Reuse existing set_modal (which was previously unused). The first approach was to make the window not clickable or not "activable" when `setEnabled(false)` but I did not find a solution for that on Gdk or Gtk. Gtk has `gtk_widget_set_sensitive` but that did not work (probably only if using gtk signals). I did make other attempts with no success. - PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2]
On Tue, 29 Jun 2021 21:58:36 GMT, Thiago Milczarek Sayao wrote: >> The PR approach is to set `gtk_window_set_keep_above` to true on >> APPLICATION_MODAL windows, so they will not stay behind non >> APPLICATION_MODAL windows. >> >> This is passed on WindowStage.java:198 as a mask. >> >> The weird thing is that `_enterModal()` is never called. This seems the >> right function to be called for `APPLICATION_MODAL`, as >> `_enterModalWithWindow` fits for `WINDOW_MODAL`. > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Reuse existing set_modal (which was previously unused).  - PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2]
On Tue, 29 Jun 2021 21:05:06 GMT, Kevin Rushforth wrote:
> I tried the test program attached to the JBS bug, and I'm not seeing the
> problem. Are there any special steps I need to take to see the bug? I also
> left a question about `WINDOW_MODAL` vs `APPLICATION_MODAL` windows.
>
> Regarding the `{enter/exit/is}Modal` methods in `Window.java`, it looks like
> they stubs that are never called. Modality is handled by the toolkit using
> (as you found out) only the `setEnabled` method.
>
> Finally, you have a typo in the title of both this PR and the JBS bug:
> `corretly` --> `correctly`
- Added steps to reproduce on JBS. Basically the window manager will let you
click the window in the back (primary stage in the example) and the
APPLICATION_MODAL will go behind it, still blocking events;
- Fixed the typo.
> modules/javafx.graphics/src/main/native-glass/gtk/glass_window.cpp line 741:
>
>> 739: } else if (modal) {
>> 740: //this is used for APPLICATION_MODAL
>> 741: gtk_window_set_keep_above(GTK_WINDOW(gtk_widget), TRUE);
>
> Won't this also be set for `WINDOW_MODAL` windows? And if so, is this really
> what we want?
Yes. I have refactored it.
-
PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves correctly [v2]
> The PR approach is to set `gtk_window_set_keep_above` to true on > APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL > windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right > function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` > fits for `WINDOW_MODAL`. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Reuse existing set_modal (which was previously unused). - Changes: - all: https://git.openjdk.java.net/jfx/pull/551/files - new: https://git.openjdk.java.net/jfx/pull/551/files/7b483449..612a61ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=551=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=551=00-01 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551 PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly
On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on > APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL > windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right > function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` > fits for `WINDOW_MODAL`. It's working as expected: If there's two APPLICATION_MODAL (*1) and (*2) and a WINDOW_MODAL (*3) as a child of the primary stage the order of the windows on the screen will be (*2) (*1) (*3). Will run the tests and post here. - PR: https://git.openjdk.java.net/jfx/pull/551
RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly
The PR approach is to set `gtk_window_set_keep_above` to true on APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL windows. This is passed on WindowStage.java:198 as a mask. The weird thing is that `_enterModal()` is never called. This seems the right function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` fits for `WINDOW_MODAL`. - Commit messages: - Only if not WINDOW_MODAL - Fix for JDK-8210973 - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master - Merge pull request #17 from openjdk/master - Merge pull request #16 from openjdk/master - Merge pull request #15 from openjdk/master - Merge pull request #14 from openjdk/master - Merge pull request #13 from openjdk/master - Merge pull request #12 from openjdk/master - ... and 8 more: https://git.openjdk.java.net/jfx/compare/78179be1...7b483449 Changes: https://git.openjdk.java.net/jfx/pull/551/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=551=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269429 Stats: 14 lines in 3 files changed: 10 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/551.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/551/head:pull/551 PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8269429: Linux: Only the last APPLICATION_MODAL window behaves corretly
On Mon, 28 Jun 2021 16:56:44 GMT, Thiago Milczarek Sayao wrote: > The PR approach is to set `gtk_window_set_keep_above` to true on > APPLICATION_MODAL windows, so they will not stay behind non APPLICATION_MODAL > windows. > > This is passed on WindowStage.java:198 as a mask. > > The weird thing is that `_enterModal()` is never called. This seems the right > function to be called for `APPLICATION_MODAL`, as `_enterModalWithWindow` > fits for `WINDOW_MODAL`. It's odd that glass `Window.java` defines `enterModal` but it seems to be never called. Modality is handled by calling `setEnabled(false)` on other windows. I would refactor that some day :) - PR: https://git.openjdk.java.net/jfx/pull/551
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v27]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix build gtk_widget_set_sensitive has no effect - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/f4a13314..9ff5a7b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=26 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=25-26 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v26]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. 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 20 commits: - Small compilation fix for ubuntu 16.04 - Merge branch 'openjdk:master' into master - Merge pull request #18 from openjdk/master Merge master - Fix bug in content oriented child windows - Small compilation fix for ubuntu 16.04 - Replace the window size & positining code Default to 320x200 if no size is assigned Hopefully fix all "extra resize" problems due to frame extents. Small change to reuse get_net_frame_extents_atom() Fix more tests (restore 1 behaviour) More test fixes Partial progress Adjust positioning (not 100% yet) It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. It's probably good now One more small issue - Merge pull request #17 from openjdk/master Pull from origin - Merge pull request #16 from openjdk/master Update - Merge pull request #15 from openjdk/master Update from jfx - Merge pull request #14 from openjdk/master Merge master - ... and 10 more: https://git.openjdk.java.net/jfx/compare/78179be1...f4a13314 - Changes: https://git.openjdk.java.net/jfx/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=367=25 Stats: 615 lines in 7 files changed: 150 ins; 311 del; 154 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8217955: Problems with touch input and JavaFX 11
On Mon, 5 Apr 2021 22:25:55 GMT, Kevin Rushforth wrote: >> This PR filters out `GDK_TOUCH_EVENT_MASK` from `GDK_ALL_EVENTS_MASK` to >> prevent touch events from being used instead of regular mouse events on >> Linux platforms. Note that the touch events will be delivered as mouse >> pressed/dragged events. >> >> Since we still compile with GTK 2.x the bit flag (that was introduced in GTK >> 3.4) needs to be defined. >> >> This PR has been tested on Ubuntu 20.04 with a touch enabled display. > > @pankaj-bansal It looks OK to me, but can you also take a look at this? If anyone would implement touch events, the change would need to be rolled back? If you catch and consume touch events, would it also work? I don't own a touch device and `GTK_DEBUG=touchscreen` seems to work only with gtk signals (not gdk events). - PR: https://git.openjdk.java.net/jfx/pull/457
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code
On Sat, 6 Mar 2021 23:53:06 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP while we run some more tests to make sure latest changes are >> ok. >> I'm fixing some residual "extra resize" issues (these issues exists on the >> current versions, so this makes it better, hopefully). > > Looks good now. Testing: **master**  **tsayao:glass_gtk_new_position_and_size**  `--tests test.robot.javafx.scene.RobotTest` causes some intermittent error but eventually all passes. - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v25]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix bug in content oriented child windows - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/6a48f2a6..0dd478a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=24 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=23-24 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v24]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Small compilation fix for ubuntu 16.04 - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/34518b8e..6a48f2a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=23 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=22-23 Stats: 8 lines in 2 files changed: 5 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v23]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. 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 15 commits: - Replace the window size & positining code Default to 320x200 if no size is assigned Hopefully fix all "extra resize" problems due to frame extents. Small change to reuse get_net_frame_extents_atom() Fix more tests (restore 1 behaviour) More test fixes Partial progress Adjust positioning (not 100% yet) It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. It's probably good now One more small issue - Merge pull request #17 from openjdk/master Pull from origin - Merge pull request #16 from openjdk/master Update - Merge pull request #15 from openjdk/master Update from jfx - Merge pull request #14 from openjdk/master Merge master - Merge pull request #13 from openjdk/master Merge master - Merge pull request #12 from openjdk/master Merge with main - Merge pull request #11 from openjdk/master Merge from upstream - Merge pull request #10 from openjdk/master Update from master - Merge pull request #9 from openjdk/master Merge from upstream - ... and 5 more: https://git.openjdk.java.net/jfx/compare/e394b0a6...34518b8e - Changes: https://git.openjdk.java.net/jfx/pull/367/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=367=22 Stats: 630 lines in 5 files changed: 170 ins; 337 del; 123 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code
On Wed, 3 Mar 2021 12:14:47 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP to reduce sizing events. > > Changed to WIP while we run some more tests to make sure latest changes are > ok. > I'm fixing some residual "extra resize" issues (these issues exists on the > current versions, so this makes it better, hopefully). Looks good now. - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v22]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: One more small issue - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/ece5f926..c601603d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=21 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=20-21 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v21]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: It's probably good now - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/b5547410..ece5f926 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=20 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=19-20 Stats: 22 lines in 2 files changed: 16 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v20]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: It's looking good. Except for fixed initial extents, but it seems a reasonable fix due to nature o frame extents. - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/24b388f2..b5547410 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=19 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=18-19 Stats: 145 lines in 3 files changed: 35 ins; 68 del; 42 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v19]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Adjust positioning (not 100% yet) - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/180a1ea9..24b388f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=18 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=17-18 Stats: 96 lines in 2 files changed: 58 ins; 25 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v18]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Partial progress - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/1d085aad..180a1ea9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=17 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=16-17 Stats: 97 lines in 2 files changed: 27 ins; 38 del; 32 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v17]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: More test fixes - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/41f48dc2..1d085aad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=16 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=15-16 Stats: 12 lines in 2 files changed: 4 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v16]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix more tests (restore 1 behaviour) - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/0de9fc96..41f48dc2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=15 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=14-15 Stats: 14 lines in 2 files changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v15]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Small change to reuse get_net_frame_extents_atom() - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/5f8d7731..0de9fc96 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=14 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=13-14 Stats: 13 lines in 1 file changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
On Thu, 18 Feb 2021 21:24:31 GMT, Thiago Milczarek Sayao wrote: >> Current Status: >> >>  > > Ready to be reviewed. Changed to WIP while we run some more tests to make sure latest changes are ok. I'm fixing some residual "extra resize" issues (these issues exists on the current versions, so this makes it better, hopefully). - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v14]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Hopefully fix all "extra resize" problems due to frame extents. - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/0c89a4da..5f8d7731 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=13 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=12-13 Stats: 51 lines in 2 files changed: 14 ins; 22 del; 15 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v13]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Default to 320x200 if no size is assigned - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/6766502e..0c89a4da Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=12 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=11-12 Stats: 11 lines in 2 files changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code [v12]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Replace the window size & positining code - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/07219e70..6766502e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=11 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=10-11 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code
On Thu, 18 Feb 2021 21:14:44 GMT, Thiago Milczarek Sayao wrote: >> Changed to WIP to reduce sizing events. > > Current Status: > >  Ready to be reviewed. - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
On Sun, 14 Feb 2021 22:06:34 GMT, Thiago Milczarek Sayao wrote: >> It's been pointed out about this >> https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events >> >> My tests point out that this PR causes less sizing events that the current >> master branch, but I also think this could be improved further. >> >> But, by the nature of X and window managers, window sizes does not account >> decoration frames, but javafx does (probably mimicking windows behavior). >> Given this information I probably could reduce further the sizing events, >> but not make it equivalent to windows. > > Changed to WIP to reduce sizing events. Current Status:  - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v11]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix centering of Stages and Dialogs - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/636114b5..07219e70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=10 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=09-10 Stats: 26 lines in 1 file changed: 19 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v10]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Turns out gravity is used! - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/30d5291e..636114b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=09 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=08-09 Stats: 21 lines in 2 files changed: 5 ins; 15 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v9]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Pass PixelBufferDrawTest - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/fedccf56..30d5291e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=07-08 Stats: 32 lines in 1 file changed: 9 ins; 1 del; 22 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v8]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix maximize bug - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/ff2f0f8e..fedccf56 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=06-07 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v7]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Another approach to avoid extra size notify events - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/b3b0adcd..ff2f0f8e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=05-06 Stats: 30 lines in 2 files changed: 6 ins; 15 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v6]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fixes - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/f04d3b40..b3b0adcd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=04-05 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v5]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Prefer bool - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/5f87da28..f04d3b40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code [v4]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision: - Reduce size notify to java - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #16 from openjdk/master Update - Reduce size notify to java - Revert change to reduce size notify events due to frame extents adjustment - it makes some tests fail. - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #15 from openjdk/master Update from jfx - Avoid redundant resize notify - Fix parent window being resizable (it should not) - Minor fix to positioning - ... and 15 more: https://git.openjdk.java.net/jfx/compare/2e19b548...5f87da28 - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/e8528ef2..5f87da28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=02-03 Stats: 257585 lines in 5458 files changed: 125365 ins; 93757 del; 38463 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: WIP: 8260528: Clean glass-gtk sizing and positioning code
On Wed, 27 Jan 2021 16:39:55 GMT, Thiago Milczarek Sayao wrote: >> This does look like a much more manageable approach. >> >> One thing to be aware of from a bookkeeping point of view is that a JBS >> issues is resolved by a single PR. Once a PR has been integrated for a given >> JBS bug ID, that bug ID cannot be reused. >> >> This means that each separate PR will need it's own JBS issue to be filed, >> even if those enhancements taken together are part of a larger set of >> improvements. Incremental improvements are fine (and in this case a good way >> to proceed), but you might give some thought to the title of each such >> improvement. I wouldn't want to see 5 fixes go in each with the same title >> of `Simplify and update glass gtk backend`. > > It's been pointed out about this > https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events > > My tests point out that this PR causes less sizing events that the current > master branch, but I also think this could be improved further. > > But, by the nature of X and window managers, window sizes does not account > decoration frames, but javafx does (probably mimicking windows behavior). > Given this information I probably could reduce further the sizing events, but > not make it equivalent to windows. Changed to WIP to reduce sizing events. - PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8260528: Clean glass-gtk sizing and positioning code
On Tue, 26 Jan 2021 00:01:44 GMT, Kevin Rushforth wrote: >> This is a new approach to rewrite parts of gtk glass backend to be more >> clean. >> >> I will provide small "manageable" PR to incrementally make the backend >> better. >> >> This PR adresses cleanup of the Size and Positioning code. It makes code >> more "straightforward" and easier to maintain. >> >> Current status (Ubuntu 20.04): >>  >> >> (*) Some of the iconify tests are also failing on the main branch. >> >> `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests >> test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 >> failures. > > This does look like a much more manageable approach. > > One thing to be aware of from a bookkeeping point of view is that a JBS > issues is resolved by a single PR. Once a PR has been integrated for a given > JBS bug ID, that bug ID cannot be reused. > > This means that each separate PR will need it's own JBS issue to be filed, > even if those enhancements taken together are part of a larger set of > improvements. Incremental improvements are fine (and in this case a good way > to proceed), but you might give some thought to the title of each such > improvement. I wouldn't want to see 5 fixes go in each with the same title of > `Simplify and update glass gtk backend`. It's been pointed out about this https://stackoverflow.com/questions/49512491/javafx-getting-single-resize-events My tests point out that this PR causes less sizing events that the current master branch, but I also think this could be improved further. But, by the nature of X and window managers, window sizes does not account decoration frames, but javafx does (probably mimicking windows behavior). Given this information I probably could reduce further the sizing events, but not make it equivalent to windows. - PR: https://git.openjdk.java.net/jfx/pull/367
Withdrawn: 8236651: Simplify and update glass gtk backend
On Mon, 6 Jan 2020 00:28:14 GMT, Thiago Milczarek Sayao wrote: > ### Summary > * Simplify and update the Gtk glass backend, making Linux a first-class > OpenJFX platform. > > ### Goals > * Make Linux a first-class OpenJFX platform (see Motivation); > * Simplify the code and reduce it's size; > * Update to gtk3 (it was originally a port from gtk2); > * Remove unused code (such as applets and web start); > * Prepare the ground for a possible future Wayland support. > ### Testing > ./gradlew -PEXTRA_TEST_ARGS='-Djavafx.gtk.experimental=true' -PFULL_TEST=true > -PUSE_ROBOT=true :systemTests:test This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Mon, 25 Jan 2021 23:49:38 GMT, Kevin Rushforth wrote: >> I would prefer this approach: >> https://github.com/openjdk/jfx/pull/367 > > Given the alternate approach that you propose to pursue (which I agree is a > better option), this PR should either be closed or moved to Draft. Closing it in favor of #367 - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend [v3]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Revert change to reduce size notify events due to frame extents adjustment - it makes some tests fail. - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/2be1ba7e..e8528ef2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8236651: Simplify and update glass gtk backend [v2]
> This is a new approach to rewrite parts of gtk glass backend to be more clean. > > I will provide small "manageable" PR to incrementally make the backend better. > > This PR adresses cleanup of the Size and Positioning code. It makes code more > "straightforward" and easier to maintain. > > Current status (Ubuntu 20.04): >  > > (*) Some of the iconify tests are also failing on the main branch. > > `gradlew -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests > test.robot.javafx.stage.IconifyTest` on a second run produces 4 tests, 2 > failures. Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Merge branch 'master' into glass_gtk_new_position_and_size - Merge pull request #15 from openjdk/master Update from jfx - Avoid redundant resize notify - Fix parent window being resizable (it should not) - Minor fix to positioning - Small adjustment - Fixes - Revert files - Replace the window size & positining code - Merge pull request #14 from openjdk/master Merge master - ... and 10 more: https://git.openjdk.java.net/jfx/compare/d304d2ea...2be1ba7e - Changes: - all: https://git.openjdk.java.net/jfx/pull/367/files - new: https://git.openjdk.java.net/jfx/pull/367/files/bdfd0deb..2be1ba7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=367=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=367=00-01 Stats: 15117 lines in 291 files changed: 1191 ins; 12297 del; 1629 mod Patch: https://git.openjdk.java.net/jfx/pull/367.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/367/head:pull/367 PR: https://git.openjdk.java.net/jfx/pull/367
Re: RFR: 8236651: Simplify and update glass gtk backend
On Tue, 22 Sep 2020 01:12:44 GMT, Thiago Milczarek Sayao wrote: >> Rebased onto "master" and squashed commits. > > Tested on Ubuntu 20.04 > > 756 tests completed, 6 failed, 110 skipped > > Failed: > test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED > java.lang.AssertionError: Timeout: Failed to receive onAction callback. > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at > test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) > at > test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) > at > test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) > > test.robot.javafx.scene.RobotTest > testKeyPress FAILED > org.junit.ComparisonFailure: letter 'a' should be pressed by Robot > expected:<[a]> but was:<[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) > at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) > > test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > > resizeColumnToFitContentTest FAILED > java.lang.AssertionError: resizeColumnToFitContent failed > at org.junit.Assert.fail(Assert.java:91) > at org.junit.Assert.assertTrue(Assert.java:43) > at > test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) > > test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but > was:rgba(62,62,62,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED > junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but > was:rgba(88,88,88,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) > > test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but > was:rgba(44,44,44,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > > For some reason the html report is not being generated. > > **Second run:** > 756 tests completed, 4 failed, 110 skipped > > test.robot.javafx.scene.RobotTest > testKeyPress FAILED > org.junit.ComparisonFailure: letter 'a' should be pressed by Robot > expected:<[a]> but was:<[]> > at org.junit.Assert.assertEquals(Assert.java:123) > at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) > at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) > > test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but > was:rgba(44,44,44,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) > > test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED > junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but > was:rgba(88,88,88,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) > > test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED > junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but > was:rgba(44,44,44,255) > at > test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) > at > test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) I would prefer this approach: https://github.com/openjdk/jfx/pull/367 - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Mon, 21 Sep 2020 23:40:50 GMT, Thiago Milczarek Sayao wrote: >>> I would starting hooking gtk event signals >>> (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the >>> "touch-event" to JavaFx events (probably need to add through JNI). Should >>> be simple. Contact me at thiago.sayao (gmail). >> >> Would it be safe you think to branch from your PR to have the updated gtk >> backend? It would be much easier to work with. > > Rebased onto "master" and squashed commits. Tested on Ubuntu 20.04 756 tests completed, 6 failed, 110 skipped Failed: test.robot.javafx.scene.ColorPickerTest > testColorPickerSceneChange FAILED java.lang.AssertionError: Timeout: Failed to receive onAction callback. at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.ColorPickerTest.waitForLatch(ColorPickerTest.java:203) at test.robot.javafx.scene.ColorPickerTest.clickColorPickerPalette(ColorPickerTest.java:88) at test.robot.javafx.scene.ColorPickerTest.testColorPickerSceneChange(ColorPickerTest.java:119) test.robot.javafx.scene.RobotTest > testKeyPress FAILED org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> at org.junit.Assert.assertEquals(Assert.java:123) at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest > resizeColumnToFitContentTest FAILED java.lang.AssertionError: resizeColumnToFitContent failed at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at test.robot.javafx.scene.tableview.TableViewResizeColumnToFitContentTest.resizeColumnToFitContentTest(TableViewResizeColumnToFitContentTest.java:96) test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(62,62,62,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) For some reason the html report is not being generated. **Second run:** 756 tests completed, 4 failed, 110 skipped test.robot.javafx.scene.RobotTest > testKeyPress FAILED org.junit.ComparisonFailure: letter 'a' should be pressed by Robot expected:<[a]> but was:<[]> at org.junit.Assert.assertEquals(Assert.java:123) at test.robot.javafx.scene.RobotTest.testKeyboard(RobotTest.java:193) at test.robot.javafx.scene.RobotTest.testKeyPress(RobotTest.java:144) test.robot.javafx.stage.IconifyTest > canIconifyDecoratedStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) test.robot.javafx.stage.IconifyTest > canIconifyTransparentStage FAILED junit.framework.AssertionFailedError: expected:rgba(0,255,0,255) but was:rgba(88,88,88,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$6(IconifyTest.java:108) test.robot.javafx.stage.IconifyTest > canIconifyNonResizableStage FAILED junit.framework.AssertionFailedError: expected:rgba(255,0,0,255) but was:rgba(44,44,44,255) at test.robot.testharness.VisualTestBase.assertColorEquals(VisualTestBase.java:179) at test.robot.javafx.stage.IconifyTest.lambda$canIconifyStage$4(IconifyTest.java:97) - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Wed, 29 Jul 2020 21:01:42 GMT, Tor (torbuntu) wrote: >> @Torbuntu Not to this PR, I don't want to delay it too much. But can be done >> (I just do not own a touch device currently). > > Sounds good! I have a few devices I'd be more than excited to test on, and > even help add the feature myself if I can figure it out if time is a big > issue? I would starting hooking gtk event signals (https://developer.gnome.org/gtk3/stable/GtkWidget.html), specially the "touch-event" to JavaFx events (probably need to add through JNI). Should be simple. Contact me at thiago.sayao (gmail). - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Fri, 12 Jun 2020 13:51:58 GMT, Kevin Rushforth wrote:
>>> After the latest commit on June 10, this is not building for me on my
>>> Ubuntu 18.04. I am attaching the build log for reference.
>>> [build.log](https://github.com/openjdk/jfx/files/4770864/build.log)
>>
>> It's now fixed. I had used two compilation parameters to limit Gtk on 3.8
>> (so it would generate error if any symbol > 3.8 were used). But that does
>> not seem to work on 18.04, so I removed it.
>
>> I had used two compilation parameters to limit Gtk on 3.8 (so it would
>> generate error if any symbol > 3.8 were used). But that does not seem to
>> work on 18.04, so I removed it.
>
> Good. I was going to ask you about that, so I'm happy to see it gone.
I have investigated the Tab Pane Drag Test and it works manually.
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Tab;
import javafx.scene.control.TabPane;
import javafx.stage.Stage;
public class Test
extends Application {
@Override
public void start(Stage stage) {
TabPane tabPane = new TabPane();
tabPane.setTabDragPolicy(TabPane.TabDragPolicy.REORDER);
Scene scene = new Scene(tabPane, 800, 600);
stage.setScene(scene);
Tab tab1 = new Tab("Tab1");
Tab tab2 = new Tab("Tab2");
tabPane.getTabs().addAll(tab1, tab2);
stage.setAlwaysOnTop(true);
stage.show();
}
public static class Main {
public static void main(String[] args) {
Application.launch(Test.class, args);
}
}
}
It also works if I switch back to GDK Events instead of Gtk Signals. But it is
a drag test, by experience they don't work well on Robot.
-
PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Tue, 9 Jun 2020 23:14:31 GMT, Kevin Rushforth wrote: > I am running a full test using GTK 3 on Ubuntu 20.04 and will publish > results. I will later do the same for Oracle Linux 7.7. > > One thing to note is that this new GTK pipeline doesn't run on Ubuntu 16.04. > I get the following running any program: > > ``` > $ java -Djavafx.gtk.experimental=true -Djdk.gtk.verbose=true HelloRectangle > checking GTK version 3 > trying GTK library libgtk-3.so.0 > using GTK library version 3 set libgtk-3.so.0 > Glass GTK library to load is glassgtk3_exp > loaded gdk_x11_display_set_window_scale > java: symbol lookup error: > /localhome/kcr/javafx/jfx-tmp/jfx/rt/build/sdk/lib/libglassgtk3_exp.so: > undefined symbol: gdk_display_get_n_monitors > ``` I have limited GTK compilation to use GTK 3.8 symbols. Will run more tests, but should fix it. - PR: https://git.openjdk.java.net/jfx/pull/77
Re: RFR: 8236651: Simplify and update glass gtk backend
On Sun, 14 Jun 2020 11:55:45 GMT, Pankaj Bansal wrote: >> Following are results in Ubuntu 18.04 after fix for tab pane tests. >> > src="https://user-images.githubusercontent.com/6153953/84587007-3abc2880-ae39-11ea-8b61-0cbb86e4d4b5.png;> > > This is the result on OL 82 with latest commit > src="https://user-images.githubusercontent.com/6153953/84592508-d82c5200-ae63-11ea-87d3-7f55671ed302.png;> @pankaj-bansal Sorry for commiting again. Now the Tab Pane test works properly. - PR: https://git.openjdk.java.net/jfx/pull/77
