Integrated: 8280841: Update SQLite to 3.37.2
On Fri, 4 Feb 2022 12:53:51 GMT, Hima Bindu Meda wrote: > Updated SQLite to 3.37.2 released on 2022-01-06 from the current version > 3.32.3. > > Website : https://www.sqlite.org/index.html > Source code can be found from https://www.sqlite.org/download.html at > [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) > > Verified the updated version with unit tests and sanity testing. > No issues are observed. This pull request has now been integrated. Changeset: 6b7b463c Author:Hima Bindu Meda Committer: Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/6b7b463cd2286658ad7d236824ded9b1020329e7 Stats: 22902 lines in 5 files changed: 11655 ins; 3597 del; 7650 mod 8280841: Update SQLite to 3.37.2 Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/727
Re: RFR: 8280841: Update SQLite to 3.37.2 [v3]
On Thu, 10 Feb 2022 05:56:47 GMT, Hima Bindu Meda wrote: >> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version >> 3.32.3. >> >> Website : https://www.sqlite.org/index.html >> Source code can be found from https://www.sqlite.org/download.html at >> [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) >> >> Verified the updated version with unit tests and sanity testing. >> No issues are observed. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Accomodated PR comments Marked as reviewed by arapte (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/727
[jfx18] Integrated: 8271085: TabPane: Redundant API docs
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in > the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. This pull request has now been integrated. Changeset: 8b879eef Author:Ajit Ghaisas URL: https://git.openjdk.java.net/jfx/commit/8b879eef96c9635a9ed16599344fa90568be2845 Stats: 173 lines in 1 file changed: 22 ins; 109 del; 42 mod 8271085: TabPane: Redundant API docs Reviewed-by: kcr, nlisker - PR: https://git.openjdk.java.net/jfx/pull/728
Re: RFR: 8280020: Underline and line-through not straight in WebView
On Thu, 10 Feb 2022 11:36:38 GMT, Jay Bhaskar wrote: > Issue: The end point of line in drawLinesForText , add thickness to the > endPoint.y(). In this case origin which is start point and the end point > would not be same, and line would be drawn not straight. > Solution: Do not add thickness to the y position of end point of line. > Start Point(x,y) --End Point(x + width, 0) The fix looks good. The test needs to be different, since it doesn't actually test this fix. A good test will fail before the fix and pass after the fix. Since you need to render something, it needs to be a system test, probably using snapshot. See [PageFillTest.java](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/javafx/scene/web/PageFillTest.java) for a recent example. - PR: https://git.openjdk.java.net/jfx/pull/731
Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v9]
On Tue, 25 Jan 2022 23:57:09 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:
>
> Capture event serial on process_key
I'll review and test it on a couple different systems.
-
PR: https://git.openjdk.java.net/jfx/pull/598
Re: [jfx18] RFR: 8271085: TabPane: Redundant API docs [v3]
On Wed, 9 Feb 2022 18:27:55 GMT, Ajit Ghaisas wrote: >> This is a Javadoc cleanup and correction fix for the TabPane as described in >> the JBS. >> >> Changes done for all the Properties of the TabPane - >> - Moved the property description to be over the property field. >> - Removed the unnecessary docs on property setter/getter and Property method. > > Ajit Ghaisas has updated the pull request incrementally with one additional > commit since the last revision: > > Address additional review comments Marked as reviewed by kcr (Lead). - PR: https://git.openjdk.java.net/jfx/pull/728
Re: Use pure X11 backend for glass native
Hi, So far, it seems native Xlib is a good fit: https://github.com/openjdk/jfx-sandbox/tree/tsayao_xlib It's still a big mess since I'm porting gradually while learning X11. -- Thiago. Em ter., 25 de jan. de 2022 às 12:06, Thiago Milczarek Sayão < thiago.sa...@gmail.com> escreveu: > > I put some thoughts on Linux glass backend and I think a pure Xlib backend > would be the ideal choice. > > Why? > > 1. X11/Xlib is supported by Xwayland, so it will work for decades > (probably). Having two backends to support for one platform would not be > ideal, so sticking with X11 would be the most "compatible choice". I will > probably be forever supported, since many applications rely on it. > > 2. Gdk4 moved away from being a "general toolkit layer" to being a "gtk4 > platform abstraction layer", so many things are missing such as: > - Moving windows; > - Drawing directly on a window; > - Relative window positioning; > - Changing window stacking; > - Pointer warping; > > Glass needs it, so it would be required to use a Xlib call anyways, since > Xwayland currently does not support those operations as well (except > through the X11 compatibility layer). > > Newer gtk3 versions deprecate a lot of functions and make a path to gtk4, > so even gtk3 is hard to use. > > 3. It would be possible to migrate from gtk3 to Xlib progressively since > Gdk3 with X11 backend translates to Xlib calls; > > 4. It would drop the gtk dependency (except for webkit-gtk). OS-specific > dialogs such as file save would be a problem (but not too hard to solve I > think). > > > References: > https://www.x.org/releases/current/doc/libX11/libX11/libX11.html > > https://discourse.gnome.org/t/gtk4-migration-window-management-functions-gone/7542/9 > https://discourse.gnome.org/t/custom-drawing-with-gtk4/7737 > > >
Integrated: 8281459: WebKit 613.1 build broken on M1
On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which > caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches > with the WebKit mainline. This pull request has now been integrated. Changeset: cdebc6cb Author:Ambarish Rapte URL: https://git.openjdk.java.net/jfx/commit/cdebc6cbafb579148b4addee44d307bd9739454b Stats: 20 lines in 1 file changed: 0 ins; 20 del; 0 mod 8281459: WebKit 613.1 build broken on M1 Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/730
Re: RFR: 8280841: Update SQLite to 3.37.2 [v3]
On Thu, 10 Feb 2022 05:56:47 GMT, Hima Bindu Meda wrote: >> Updated SQLite to 3.37.2 released on 2022-01-06 from the current version >> 3.32.3. >> >> Website : https://www.sqlite.org/index.html >> Source code can be found from https://www.sqlite.org/download.html at >> [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) >> >> Verified the updated version with unit tests and sanity testing. >> No issues are observed. > > Hima Bindu Meda has updated the pull request incrementally with one > additional commit since the last revision: > > Accomodated PR comments Marked as reviewed by kcr (Lead). - PR: https://git.openjdk.java.net/jfx/pull/727
RFR: 8280020: Underline and line-through not straight in WebView
Issue: The end point of line in drawLinesForText , add thickness to the endPoint.y(). In this case origin which is start point and the end point would not be same, and line would be drawn not straight. Solution: Do not add thickness to the y position of end point of line. Start Point(x,y) --End Point(x + width, 0) - Commit messages: - 8280020: Underline and line-through not straight in WebView Changes: https://git.openjdk.java.net/jfx/pull/731/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=731=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280020 Stats: 64 lines in 2 files changed: 63 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/731.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/731/head:pull/731 PR: https://git.openjdk.java.net/jfx/pull/731
Integrated: 8187309: TreeCell must not change tree's data
On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed > mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit > handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test > for default commit that passed also before). Also fixed a test bug (incorrect > registration of custom commit handler, see > [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in > TreeViewTest.test_rt_29650 to keep it passing. This pull request has now been integrated. Changeset: 4cf66d9f Author:Jeanette Winzenburg URL: https://git.openjdk.java.net/jfx/commit/4cf66d9f6e96aab29c4c5fc72fa3e81a38a8d783 Stats: 95 lines in 4 files changed: 89 ins; 4 del; 2 mod 8187309: TreeCell must not change tree's data Reviewed-by: mstrauss, mhanl, aghaisas - PR: https://git.openjdk.java.net/jfx/pull/724
Re: RFR: 8187309: TreeCell must not change tree's data
On Tue, 8 Feb 2022 12:49:59 GMT, Marius Hanl wrote: >> Issue was TreeView commit editing implementation violated the spec'ed >> mechanism: >> >> - no default commit handler on TreeView >> - TreeCell modifying the data directly >> >> Fix is to move the saving of the edited value from cell into a default >> commit handler in tree and set that handler in the constructor. >> >> Added tests that failed/passed before/after the fix (along with a sanity >> test for default commit that passed also before). Also fixed a test bug >> (incorrect registration of custom commit handler, see >> [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in >> TreeViewTest.test_rt_29650 to keep it passing. > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java > line 957: > >> 955: >> 956: /** >> 957: * Test test setup. > > Minor: I would rephrase that a bit. Something like: > `Tests the cell editing setup`. oops .. forgot to change this (and the other comment) before integration - sry - PR: https://git.openjdk.java.net/jfx/pull/724
Re: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v2]
On Fri, 14 Jan 2022 20:18:57 GMT, Jose Pereda wrote: >> This PR converts the change's `from` field from a list of tablePositions >> into a list of selected indices of rows. >> >> It includes two tests for TableView and one for TreeTableView (the second >> test wasn't included due to an >> [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key >> navigation), that pass with this PR and fail without it. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Apply change only when cell selection is enabled After #709 was integrated, there were merge conflicts. So I needed to merge from master to fix them. - PR: https://git.openjdk.java.net/jfx/pull/710
Re: RFR: 8273339: IOOBE with ListChangeListener added to the selectedItems list of a TableView [v3]
> This PR converts the change's `from` field from a list of tablePositions into > a list of selected indices of rows. > > It includes two tests for TableView and one for TreeTableView (the second > test wasn't included due to an > [issue|https://bugs.openjdk.java.net/browse/JDK-8232825] with key > navigation), that pass with this PR and fail without it. Jose Pereda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8273339-changefrom - Apply change only when cell selection is enabled - Convert change from list of tablePosition to list of rows - Changes: https://git.openjdk.java.net/jfx/pull/710/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=710=02 Stats: 148 lines in 5 files changed: 141 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/710.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/710/head:pull/710 PR: https://git.openjdk.java.net/jfx/pull/710
Re: RFR: 8281459: WebKit 613.1 build broken on M1
On Wed, 9 Feb 2022 19:14:47 GMT, Ambarish Rapte wrote: > This seems like a bad merge issue. > There were duplicate copies of four methods in `MacroAssemblerARM64.h` which > caused WebKit build failure on Mac M1 machines. > Just removing the methods removes the error. > With the changes in this PR, now the file `MacroAssemblerARM64.h` matches > with the WebKit mainline. Confirmed that this now builds fine on M1 - Marked as reviewed by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/730
