From perini.davide at dpsoftware.org Sun Dec 1 11:42:49 2024 From: perini.davide at dpsoftware.org (Davide Perini) Date: Sun, 1 Dec 2024 12:42:49 +0100 Subject: Is there an ETA for Linux Wayland support? Message-ID: As title. It seems that JavaFX is not fully compliant with Linux Wayland. Is there an ETA for the complete wayland support? Thanks From thiago.sayao at gmail.com Sun Dec 1 12:31:55 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Sun, 1 Dec 2024 09:31:55 -0300 Subject: Is there an ETA for Linux Wayland support? In-Reply-To: References: Message-ID: I don?t officially speak on this matter, nor will I attempt to answer your question directly, as I?m unaware of any internal company efforts in this area. However, it would be beneficial to have a centralized resource to track ongoing efforts, ensuring we avoid duplicating work that might otherwise go to waste. That said, I?ve observed some progress in improving XWayland (*), and I?ve personally tested it and submitted bug fixes. Efforts have also been made to enable Robot to work with XWayland using PipeWire, which is a great step forward. (*) XWayland is the compatibility layer that allows X11 applications to run on Wayland. Creating a simple state-based display using the pure Wayland protocol is relatively straightforward (specially with Java 22 and FFM). However, implementing all the necessary details for a fully functional and feature-complete Wayland backend is a substantial endeavor. One challenge, for instance, is that Wayland?s design choices intentionally avoid certain features (like not having a global cursor position and not allowing window management operations). I submitted a pull request to enable EGL on Prism ES2 with Wayland in mind. This enhancement allows for GL rendering using EGL, which is a critical requirement for a Wayland compositor. I also conducted some experiments and managed to display a window using only the Wayland protocol (*) in Java, leveraging jextract and the Foreign Function & Memory (FFM) API. However, this is far from achieving a fully functional Wayland Glass backend. (*) Wayland is just a specification, many compositors implement it. -- Thiago. Em dom., 1 de dez. de 2024 ?s 08:43, Davide Perini < perini.davide at dpsoftware.org> escreveu: > As title. > It seems that JavaFX is not fully compliant with Linux Wayland. > > Is there an ETA for the complete wayland support? > > Thanks > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Sun Dec 1 15:08:25 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 1 Dec 2024 16:08:25 +0100 Subject: Is there an ETA for Linux Wayland support? In-Reply-To: References: Message-ID: Hi, I had this high on my list a couple of years ago, but because of XWayland I didn't feel the urgent need to work on it, so it dropped a bit on my priority list. Thiago did great experimental work in this area, and I should raise Wayland higher on my list again. It's something I would love to spend more time on, it's just that there are often things bumping on the stack that require "urgent" attention. - Johan On Sun, Dec 1, 2024 at 1:32?PM Thiago Milczarek Say?o < thiago.sayao at gmail.com> wrote: > I don?t officially speak on this matter, nor will I attempt to answer your > question directly, as I?m unaware of any internal company efforts in this > area. However, it would be beneficial to have a centralized resource to > track ongoing efforts, ensuring we avoid duplicating work that might > otherwise go to waste. > > That said, I?ve observed some progress in improving XWayland (*), and I?ve > personally tested it and submitted bug fixes. Efforts have also been made > to enable Robot to work with XWayland using PipeWire, which is a great step > forward. > > (*) XWayland is the compatibility layer that allows X11 applications to > run on Wayland. > > Creating a simple state-based display using the pure Wayland protocol is > relatively straightforward (specially with Java 22 and FFM). However, > implementing all the necessary details for a fully functional and > feature-complete Wayland backend is a substantial endeavor. One challenge, > for instance, is that Wayland?s design choices intentionally avoid certain > features (like not having a global cursor position and not allowing window > management operations). > > I submitted a pull request to enable EGL on Prism ES2 with Wayland in > mind. This enhancement allows for GL rendering using EGL, which is a > critical requirement for a Wayland compositor. > > I also conducted some experiments and managed to display a window using > only the Wayland protocol (*) in Java, leveraging jextract and the > Foreign Function & Memory (FFM) API. However, this is far from achieving a > fully functional Wayland Glass backend. > > (*) Wayland is just a specification, many compositors implement it. > > -- Thiago. > > Em dom., 1 de dez. de 2024 ?s 08:43, Davide Perini < > perini.davide at dpsoftware.org> escreveu: > >> As title. >> It seems that JavaFX is not fully compliant with Linux Wayland. >> >> Is there an ETA for the complete wayland support? >> >> Thanks >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.hendrikx at gmail.com Sun Dec 1 21:40:28 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 1 Dec 2024 22:40:28 +0100 Subject: Possible mistakes in com.sun.javafx.geom.AreaOp In-Reply-To: References: <9b353ec7-3b13-45b8-834b-8b162ae431e4@gmail.com> Message-ID: Yeah, that AWT code is changed almost exactly the same way.? Don't know why they kept Vector, could be AWT specific reason that doesn't apply to FX.? Uncontested synchronized blocks should however be practically free, so I don't think it's worth doing more than copying their changes. --John On 30/11/2024 18:51, Nir Lisker wrote: > You're right, these geometry classes were copied from AWT. Here is the > offending > AreOp:?https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/awt/geom/AreaOp.java. > > > They generified their code at some point like John did. They also just > create a new vector in the 'numedges' check. I wonder why they kept > Vector though. > > On Sat, Nov 30, 2024 at 7:43?PM Laurent Bourg?s > wrote: > > Probably derived from java.awt.Area: > https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/geom/Area.java > > > Le sam. 30 nov. 2024, 17:59, Nir Lisker a ?crit?: > > I agree?with your type analysis. However, I'm hesitant to > change the logic in regarding 'numedges' without someone who > is familiar with the domain taking a look; these sorts of > computations often have non-obvious sides to them. > > I also think that the class was copied. The raw types usage > suggests a 1.4 era. Vector itself suggests even earlier times, > perhaps AWT. If the code doesn't require thread > synchronization, and I don't think it does, using List could > even speed it up a bit. > > Do you have an idea about the needless 'toArray' calls? The > return is not captured and it doesn't have side effects. Maybe > to check the types? > > On Sat, Nov 30, 2024 at 10:25?AM John Hendrikx > wrote: > > Hi Nir, > > I encountered that class before while doing raw warning > clean-ups in graphics (which were never integrated). > > The problem IMHO is in the assignment in `calculate`: > > edges = pruneEdges(edges); > > This assignment is both confusing and unnecessary, and > violates the principle of re-using variables for different > purposes.? Method pruneEdges must return CURVES (the name > even implies it -- remove edges), and the debug code in > this block even assumes it does (it assigned `numcurves` > to `edges.size()` then assumes that it contains curves > when converting to the array format): > > Rewrite the code as follows and it will be much clearer: > > publicVectorcalculate(Vector left, > Vector right) { > > Vector edges = newVector<>(); > > addEdges(edges, left, AreaOp.CTAG_LEFT); > > addEdges(edges, right, AreaOp.CTAG_RIGHT); > > Vector curves = pruneEdges(edges); > > if(false) { > > System.out.println("result: "); > > intnumcurves = curves.size(); > > Curve[] curvelist = (Curve[]) > edges.toArray(newCurve[numcurves]); > > for(inti = 0; i < numcurves; i++) { > > System.out.println("curvelist["+i+"] = "+curvelist[i]); > > } > > } > > returncurves; > > } > > Then the initial code?in `pruneEdges` is just plain wrong, > and seems to be an attempt at optimization done > incorrectly by returning an existing vector to save having > to allocate a new one: > > privateVectorpruneEdges(Vector edges) { > > intnumedges = edges.size(); > > if(numedges < 2) { > > returnedges; > > } > > Method pruneEdges however is supposed to return a minimum > set of curves that enclose an area.? A single edge can't > contribute any area. I'm pretty sure that if you change > the check to `numedges < 1` that if the remaining code > runs normally it would also come to that conclusion (it > would return an empty vector of curves).? So this > "optimization" here is doing the wrong thing by > potentially returning a single edge instead of always > returning an empty curve vector. > > Now, I'm pretty sure we'll never see this case in > practice, due to other checks being done (specifically the > `getOrder() > 0` check when adding edges) and the likely > fact that there is always going to be a minimum of 2 > curves being passed to `calculate.? Adding an assert or > just modifying the code,?and then running all tests may > help verify this.? I believe however that the code needs > to be this: > > privateVectorpruneEdges(Vector edges) { > > intnumedges = edges.size(); > > if(numedges < 2) { > > returnnumedges == 0 ? (Vector)(Vector)edges : > new Vector(); // as a single edge can't encompass any > area, a single edge also results in no curves being returned > > } > > The reason why we do need to return a mutable Vector here > is because the classes using the return value of calculate > assume that it is writable and doesn't need copying.? The > ugly double cast of edges is relatively contained -- it is > only casted when empty (to avoid creating another vector > instance), and it was created by this class so its under > control.? Always returning `new Vector()` would also work, > but it may perform a tiny bit slower in some cases > (probably not measurable IMHO). > > I suspect the entire class is copied from somewhere, as at > the time JavaFX was written using Vector while at the same > time trying to do these kinds of optimizations is odd to > say the least. > > --John > > > On 30/11/2024 00:12, Nir Lisker wrote: >> I came across a potential mistake in the >> class?com.sun.javafx.geom.AreaOp. It uses raw Vector >> types and while trying to add generic parameters there >> for type safety, I got some conflicts. >> >> In the method AreaOp::calculate, the arguments should be >> Vector and the return type should also be >> Vector, but it returns a Vector called 'edges'. >> 'edges' is passed to the 'addEdges' method that should >> take?Vector and Vector. This means that >> 'edges' is a Vector and not Vector. Already >> a conflict. >> Then it is passed to 'pruneEdges', which, if it takes and >> returns Vector, runs into a conflict with the >> return type: 'Vector ret' has Curve added to it. If I try >> to return Vector instead, then in the 'numedges < >> 2' check the input Vector can't be returned unless it's >> also Vector, which again causes a conflict in >> 'calculate'. >> >> There are also 'toArray' calls that seem to not do >> anything, like in 'resolveLinks' (line 454) and in >> 'finalizeSubCurves' (429). >> >> Can?anyone who knows this part of the code take?a look? >> >> - Nir > -------------- next part -------------- An HTML attachment was scrubbed... URL: From azvegint at openjdk.org Mon Dec 2 02:22:45 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 02:22:45 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. These 3 classes are all different from each other. They use different types of variables to store data (`double`, `float`, `int`). We have `com.sun.javafx.geom.Rectangle` which uses `int`, and the `com.sun.javafx.geom.Dimension` was specifically introduced as its pair which also uses `int`. (just as we have a pair of `javafx.geometry.Rectangle2D` and `javafx.geometry.Dimension2D.java`). Switching from `int` to `float` may have some side effects on stream processing due to the imprecise comparison. So I would prefer to keep the `com.sun.javafx.geom.Dimension`. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2510424626 From arapte at openjdk.org Mon Dec 2 05:26:57 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 2 Dec 2024 05:26:57 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v50] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 18:07:14 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace Providing a few more comments, I still have to take a look at rtf charset and util files. Shall review those in a day or 2. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 48: > 46: /** > 47: * InputMap is a property of the {@link Control} class which enables customization > 48: * by allowing for custom key mappings and event handlers. suggestion: minor rephrase: `by allowing for custom` -> `by allowing creation of custom` modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 50: > 48: * by allowing for custom key mappings and event handlers. > 49: *

> 50: * The {@code InputMap} serves as an integration point between the Control and its Skin. suggestion: `an integration point` -> `a bridge` modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 51: > 49: *

> 50: * The {@code InputMap} serves as an integration point between the Control and its Skin. > 51: * The {@code InputMap} The InputMap provides an ordered repository of event handlers, Minor typo: `The {@code InputMap} The InputMap` -> `The InputMap` or `The {@code InputMap}` modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 53: > 51: * The {@code InputMap} The InputMap provides an ordered repository of event handlers, > 52: * working together with the input map managed by the skin, which > 53: * guarantees the order in which handers are invoked. minor typo: handers -> handlers modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 64: > 62: *

  • map a new function to an existing key binding > 63: *
  • obtain the default function > 64: *
  • ensure that the application key mappings take priority over mappings created by the skin Minor rewording, Uppercase letter at first word *
  • Mapping a key binding to a function *
  • Removing a key binding *
  • Mapping a new function to an existing key binding *
  • Retrieving the default function *
  • Ensuring that the application key mappings take priority over mappings created by the skin ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2465004534 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1860701305 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1860704123 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1860648588 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1860651768 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1860716036 From nlisker at openjdk.org Mon Dec 2 11:27:46 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 2 Dec 2024 11:27:46 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 02:19:46 GMT, Alexander Zvegintsev wrote: >> A small refactoring of the Dimension classes. >> >> * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. >> * `com.sun.javafx.geom.Dimension2D` became a record. >> * `javafx.geometry.Dimension2D`: fields became `final`. >> >> I'm not sure we need the implementation class at all considering we are free to use the public one. > > These 3 classes are all different from each other. They use different types of variables to store data (`double`, `float`, `int`). > > We have `com.sun.javafx.geom.Rectangle` which uses `int`, and the `com.sun.javafx.geom.Dimension` was specifically introduced as its pair which also uses `int`. > (just as we have a pair of `javafx.geometry.Rectangle2D` and `javafx.geometry.Dimension2D.java`). > > Switching from `int` to `float` may have some side effects on stream processing due to the imprecise comparison. > > So I would prefer to keep the `com.sun.javafx.geom.Dimension`. Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2511272926 From nlisker at openjdk.org Mon Dec 2 11:35:44 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 2 Dec 2024 11:35:44 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: <4qjIGWhyepEYJsnoufxIogcDrBg6MYs0pZ_IFwgHv7g=.5c4f82aa-4ace-408d-ac31-ec929bd330a3@github.com> On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. I also looked at the uses of `com.sun.javafx.geom.Rectangle` and in almost all cases I've looked at, its values are widened to floats later on. I'm not going to change anything there, but there is an indication that it's not the right tool for the job. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2511288436 From mhanl at openjdk.org Mon Dec 2 13:48:47 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 2 Dec 2024 13:48:47 GMT Subject: Integrated: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 23:42:42 GMT, Marius Hanl wrote: > This PR changes all `RT-XXXX` references to `JDK-XXXXXXX`. > It also removes all `http://javafx-jira.kenai.com/browse/` occurrences. > > As discussed, this will help a lot when looking up old issues, especially since not everybody know how to do a lookup with the `RT-XXXX` number in the JIRA. > > Thanks to @kevinrushforth who provided the mapping! > I wrote a small Java program that replaces all the occurrences. This includes the following files: > - `.java, .css, .m, .h, .cc, .vert, .jsl, .c, .cpp` This pull request has now been integrated. Changeset: 03eb8b11 Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/03eb8b11affbc084b3f22d41b5bbe7bd7ee11e16 Stats: 1012 lines in 361 files changed: 0 ins; 4 del; 1008 mod 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1648 From mhanl at openjdk.org Mon Dec 2 13:53:46 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 2 Dec 2024 13:53:46 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. Not sure if it helps, but when working on https://github.com/openjdk/jfx/pull/1462, I also found that inconsistencies. Sometimes `doubl`e is used and later 'degraded' to a `float`, sometimes a `float` is promoted to a `double`. And as we found here, `int` is used but later changed to `float`. I'm not sure why this happens, but maybe worth to take a deeper look. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2511601492 From azvegint at openjdk.org Mon Dec 2 14:36:56 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Mon, 2 Dec 2024 14:36:56 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 11:25:14 GMT, Nir Lisker wrote: > would you object to making Dimension an inner class of Rectangle? I am fine with it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2511707325 From andy.goryachev at oracle.com Mon Dec 2 15:58:41 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 2 Dec 2024 15:58:41 +0000 Subject: Result: New OpenJFX Reviewer: Lukasz Kostyra In-Reply-To: References: Message-ID: Congratulations, Lukasz! -andy From: openjfx-dev on behalf of Kevin Rushforth Date: Tuesday, November 26, 2024 at 09:03 To: registrar , Lukasz Kostyra Cc: openjfx-dev Subject: Result: New OpenJFX Reviewer: Lukasz Kostyra Voting for Lukasz Kostyra [1] to OpenJFX Reviewer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. -- Kevin [1] https://openjdk.org/census#lkostyra [2] https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050772.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Dec 2 16:22:41 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 2 Dec 2024 17:22:41 +0100 Subject: CSS Media Queries Message-ID: Hi everyone, here's a proposal to add media queries to JavaFX, which is a powerful feature to adjust stylesheets to changes in the runtime environment. Proposal: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7 PR: https://github.com/openjdk/jfx/pull/1655 From kevin.rushforth at oracle.com Mon Dec 2 16:41:30 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Dec 2024 08:41:30 -0800 Subject: Is there an ETA for Linux Wayland support? In-Reply-To: References: Message-ID: Hi Davide, As both Thiago and Johan both mentioned, JavaFX is supported on Wayland using XWayland. This is the same way that AWT in the core JDK is supported on Wayland. Your JavaFX applications should run fine on Wayland, and if they don't, it's a bug that we should fix. Longer term, there is value in switching to pure Wayland, both for AWT and for JavaFX, but you shouldn't see any difference in how your application behaves. Some windowing operations might perform better, depending on how the pure Wayland port is ultimately implemented, but your application should otherwise run the same as it does now. -- Kevin On 12/1/2024 7:08 AM, Johan Vos wrote: > Hi, > > I had this high on my list a couple of years ago, but because of > XWayland I didn't feel the urgent need to work on it, so it dropped a > bit on my priority list. Thiago did great experimental work in this > area, and I should?raise Wayland higher on my list again. It's > something I would love to spend more time on, it's just that there are > often things bumping on the stack that require "urgent" attention. > > - Johan > > On Sun, Dec 1, 2024 at 1:32?PM Thiago Milczarek Say?o > wrote: > > I don?t officially speak on this matter, nor will I attempt to > answer your question directly, as I?m unaware of any internal > company efforts in this area. However, it would be beneficial to > have a centralized resource to track ongoing efforts, ensuring we > avoid duplicating work that might otherwise go to waste. > > That said, I?ve observed some progress in improving XWayland (*), > and I?ve personally tested it and submitted bug fixes. Efforts > have also been made to enable Robot to work with XWayland using > PipeWire, which is a great step forward. > > (*) XWayland is the compatibility layer that allows X11 > applications to run on Wayland. > > Creating a simple state-based display using the pure Wayland > protocol is relatively straightforward (specially with Java 22 and > FFM). However, implementing all the necessary details for a fully > functional and feature-complete Wayland backend is a substantial > endeavor. One challenge, for instance, is that Wayland?s design > choices intentionally avoid certain features (like not having a > global cursor position and not allowing window management operations). > > I submitted a pull request to enable EGL on Prism ES2 with Wayland > in mind. This enhancement allows for GL rendering using EGL, which > is a critical requirement for a Wayland compositor. > > I also conducted some experiments and managed to display a window > using only the Wayland protocol (*) in Java, leveraging |jextract| > and the Foreign Function & Memory (FFM) API. However, this is far > from achieving a fully functional Wayland Glass backend. > > (*) Wayland is just a specification, many compositors implement it. > > -- Thiago. > > > Em dom., 1 de dez. de 2024 ?s 08:43, Davide Perini > escreveu: > > As title. > It seems that JavaFX is not fully compliant with Linux Wayland. > > Is there an ETA for the complete wayland support? > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Dec 2 17:20:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:20:45 GMT Subject: RFR: 8342233: Regression: TextInputControl selection is backwards in RTL mode In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 14:15:53 GMT, Lukasz Kostyra wrote: >> A fix for [JDK-8319844](https://bugs.openjdk.org/browse/JDK-8319844) Text/TextFlow.hitTest() introduced a regression in the `TextArea`/`TextField`/`PasswordField` in the RTL mode. >> >> The fix is to flip the x coordinates when needed in the `TextAreaSkin`/`TextFieldSkin`. >> >> The RTL node orientation also breaks navigation using keyboard arrow keys, but that's a different issue: [JDK-8296266](https://bugs.openjdk.org/browse/JDK-8296266). >> >> --- >> >> I tried to devise a headful test, but it is currently blocked by [JDK-8189167](https://bugs.openjdk.org/browse/JDK-8189167) >> >> The fix can be tested manually using the Monkey Tester, with the headful test to be added probably as a part of [JDK-8326869](https://bugs.openjdk.org/browse/JDK-8326869) . > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextAreaSkin.java line 831: > >> 829: protected int getInsertionPoint(double x, double y) { >> 830: TextArea textArea = getSkinnable(); >> 831: Text n = getTextNode(); > > What's the reason for the name change `paragraphNode -> n`? The change made the following `if` statement easier to digest fit on a single line. It's a local variable within a short function, I think it should be ok. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1609#discussion_r1866278668 From kcr at openjdk.org Mon Dec 2 17:22:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 17:22:07 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: > This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following: > > 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules). > 2. A utility class to produce warnings when first using an incubator module. > 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2. > > See PR #1617 for a sample module that is built on top of this PR's source branch. > > This is almost ready to review. I will take it out of Draft in the next day or so. Kevin Rushforth 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 six additional commits since the last revision: - Add pointer to CSR in JBS - Remove extra blank lines - Merge branch 'master' into 8309381-incubator.dev - Merge branch 'master' into 8309381-incubator.dev - Remove call to doPrivileged - 8309381: Support JavaFX incubator modules ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1616/files - new: https://git.openjdk.org/jfx/pull/1616/files/1d262fb3..cc2499bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1616&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1616&range=01-02 Stats: 1947 lines in 382 files changed: 448 ins; 427 del; 1072 mod Patch: https://git.openjdk.org/jfx/pull/1616.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1616/head:pull/1616 PR: https://git.openjdk.org/jfx/pull/1616 From kcr at openjdk.org Mon Dec 2 17:22:07 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 17:22:07 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 22:31:14 GMT, Andy Goryachev wrote: >> Kevin Rushforth 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 six additional commits since the last revision: >> >> - Add pointer to CSR in JBS >> - Remove extra blank lines >> - Merge branch 'master' into 8309381-incubator.dev >> - Merge branch 'master' into 8309381-incubator.dev >> - Remove call to doPrivileged >> - 8309381: Support JavaFX incubator modules > > build.gradle line 2877: > >> 2875: // Add a project declaration for each incubator module here, leaving the >> 2876: // incubator placeholder lines as an example. >> 2877: // BEGIN: incubator placeholder > > Q: maybe we should mention the JBS every time we say the word "incubator"? > > It might be useful to anyone who is looking at the code and has no access to git history (or when git history is obscured by a move). I mean, JBS is our knowledge base, and it usually helps. I generally prefer not to do this. In this case, the JBS Enhancement isn't what we would want to point to anyway (it would just be a placeholder). I can see some value in pointing to the CSR, so I'll add that here (I don't think there a need to repeat it). What would really be useful, though, is a pointer to a template with a sample module, along the lines of what I mentioned in #1617, and a pointer to the JEP (which gets back to an earlier discussion of a permanent repository for JEPs). I'll file a follow-up issue to address this. > settings.gradle line 42: > >> 40: "web", >> 41: "media", >> 42: "systemTests" > > thank you for placing each entry on a separate line! > > I would prefer to remove the blank lines around the comment so as not to break the visual grouping (the comments are typically syntax colored anyway unless the user is on TRS80) OK ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1866245340 PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1866249974 From angorya at openjdk.org Mon Dec 2 17:25:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:25:47 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 17:22:07 GMT, Kevin Rushforth wrote: >> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following: >> >> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules). >> 2. A utility class to produce warnings when first using an incubator module. >> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2. >> >> See PR #1617 for a sample module that is built on top of this PR's source branch. >> >> This is almost ready to review. I will take it out of Draft in the next day or so. > > Kevin Rushforth 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 six additional commits since the last revision: > > - Add pointer to CSR in JBS > - Remove extra blank lines > - Merge branch 'master' into 8309381-incubator.dev > - Merge branch 'master' into 8309381-incubator.dev > - Remove call to doPrivileged > - 8309381: Support JavaFX incubator modules Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1616#pullrequestreview-2473400343 From angorya at openjdk.org Mon Dec 2 17:25:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:25:48 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 17:04:06 GMT, Kevin Rushforth wrote: >> build.gradle line 2877: >> >>> 2875: // Add a project declaration for each incubator module here, leaving the >>> 2876: // incubator placeholder lines as an example. >>> 2877: // BEGIN: incubator placeholder >> >> Q: maybe we should mention the JBS every time we say the word "incubator"? >> >> It might be useful to anyone who is looking at the code and has no access to git history (or when git history is obscured by a move). I mean, JBS is our knowledge base, and it usually helps. > > I generally prefer not to do this. In this case, the JBS Enhancement isn't what we would want to point to anyway (it would just be a placeholder). I can see some value in pointing to the CSR, so I'll add that here (I don't think there a need to repeat it). > > What would really be useful, though, is a pointer to a template with a sample module, along the lines of what I mentioned in #1617, and a pointer to the JEP (which gets back to an earlier discussion of a permanent repository for JEPs). I'll file a follow-up issue to address this. thank you, the CSR is definitely better. Referring to a ticket has another positive side effect: it's easy to grep. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1616#discussion_r1866286281 From angorya at openjdk.org Mon Dec 2 17:32:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:32:49 GMT Subject: RFR: 8344899: Map RT-nnnn bug IDs to JDK-mmmmmmm in JavaFX sources [v3] In-Reply-To: References: Message-ID: <3AE2ly3tcJjT2Cdxalv_Il1hXBFQdWO9LEZ-oS5ivkA=.47dadf8f-5703-4056-823d-fd0ef0db34b1@github.com> On Fri, 29 Nov 2024 09:20:37 GMT, Marius Hanl wrote: >> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision: >> >> 8344899: Revert accidentally renamed test comments > > Solved the merge conflict with `GlassView3D.m`. Thank you @Maran23 so much for the cleanup! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1648#issuecomment-2512234634 From angorya at openjdk.org Mon Dec 2 17:46:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:46:35 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v51] In-Reply-To: References: Message-ID: <5_7rd6RU0kJZZKaG-kNlTI-eFIKJjFM3UJH64ErDacU=.1688bd0c-b534-45c7-bc10-92026140c9a3@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - whitespace - since 24 - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - hide skin input map - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - whitespace - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - ... and 61 more: https://git.openjdk.org/jfx/compare/03eb8b11...e04847eb ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=50 Stats: 40064 lines in 210 files changed: 40050 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From kcr at openjdk.org Mon Dec 2 17:50:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 17:50:42 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v3] In-Reply-To: References: Message-ID: On Sat, 30 Nov 2024 16:14:22 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix test package Reviewers: @kevinrushforth @lukostyra The code changes look good. I'll test and then approve if no issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2512274519 PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2512275343 From angorya at openjdk.org Mon Dec 2 17:52:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:52:49 GMT Subject: RFR: 8343336: Add persistentScrollBars preference [v6] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 00:26:16 GMT, Michael Strau? wrote: >> This PR adds another accessibility preference that is available on all supported desktop platforms: >> >> 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars >> 2. **macOS**: System Settings -> Appearance -> Show scroll bars >> 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars >> >> When the OS setting is changed, all platforms report updates that can be observed in JavaFX. >> The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature. > > Michael Strau? 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 six additional commits since the last revision: > > - Merge branch 'master' into feature/accessibility-hide-scrollbars > - check whether gtk-overlay-scrolling exists > - Merge branch 'master' into feature/accessibility-hide-scrollbars > - add platform keys to javadoc > - Change reducedScrollBars to persistentScrollBars > - Add reducedScrollBars preference ship it! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1618#pullrequestreview-2473467428 From angorya at openjdk.org Mon Dec 2 17:57:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 17:57:45 GMT Subject: RFR: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D [v8] In-Reply-To: References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Sat, 9 Nov 2024 07:45:14 GMT, Michael Strau? wrote: >> None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. >> >> In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). >> >> I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. > > Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into feature/sealed-classes > - Merge branch 'master' into feature/sealed-classes > - Merge branch 'master' into feature/sealed-classes > - Merge branch 'master' into feature/sealed-classes > - add comment > - Merge branch 'master' into feature/sealed-classes > - remove documentation > - Seal Node, Camera, LightBase, Shape, Shape3D looks good. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1556#pullrequestreview-2473477598 From mstrauss at openjdk.org Mon Dec 2 18:07:45 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Dec 2024 18:07:45 GMT Subject: Integrated: 8343336: Add persistentScrollBars preference In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 03:56:30 GMT, Michael Strau? wrote: > This PR adds another accessibility preference that is available on all supported desktop platforms: > > 1. **Windows**: Settings -> Accessibility -> Visual Effects -> Always show scroll bars > 2. **macOS**: System Settings -> Appearance -> Show scroll bars > 3. **Ubuntu**: Settings -> Accessibility -> Seeing -> Always show scroll bars > > When the OS setting is changed, all platforms report updates that can be observed in JavaFX. > The manual test application `test/manual/events/PlatformPreferencesChangedTest` can be used to test the feature. This pull request has now been integrated. Changeset: da6ad4b1 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/da6ad4b1e8c2aac59114949826db1e4b013a3bc5 Stats: 208 lines in 18 files changed: 153 ins; 16 del; 39 mod 8343336: Add persistentScrollBars preference Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1618 From angorya at openjdk.org Mon Dec 2 18:56:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 18:56:53 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: <8uwIvyX1aDeYmpA06Z2tyIjmqNGkfVxTXL5SSsUsItU=.cb06d400-2056-4344-9a3d-7159a8ca23d1@github.com> On Mon, 2 Dec 2024 17:22:07 GMT, Kevin Rushforth wrote: >> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following: >> >> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules). >> 2. A utility class to produce warnings when first using an incubator module. >> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2. >> >> See PR #1617 for a sample module that is built on top of this PR's source branch. >> >> This is almost ready to review. I will take it out of Draft in the next day or so. > > Kevin Rushforth 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 six additional commits since the last revision: > > - Add pointer to CSR in JBS > - Remove extra blank lines > - Merge branch 'master' into 8309381-incubator.dev > - Merge branch 'master' into 8309381-incubator.dev > - Remove call to doPrivileged > - 8309381: Support JavaFX incubator modules This PR has been reviewed by 2 "R"eviewers, the last changes are trivial (added a comment and removed some blank lines). I am going to downgrade the requirements so it can be integrated. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2512433833 From kcr at openjdk.org Mon Dec 2 18:56:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 18:56:54 GMT Subject: RFR: 8309381: Support JavaFX incubator modules [v3] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 17:22:07 GMT, Kevin Rushforth wrote: >> This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following: >> >> 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules). >> 2. A utility class to produce warnings when first using an incubator module. >> 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2. >> >> See PR #1617 for a sample module that is built on top of this PR's source branch. >> >> This is almost ready to review. I will take it out of Draft in the next day or so. > > Kevin Rushforth 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 six additional commits since the last revision: > > - Add pointer to CSR in JBS > - Remove extra blank lines > - Merge branch 'master' into 8309381-incubator.dev > - Merge branch 'master' into 8309381-incubator.dev > - Remove call to doPrivileged > - 8309381: Support JavaFX incubator modules Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1616#issuecomment-2512440211 From kcr at openjdk.org Mon Dec 2 18:56:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 18:56:54 GMT Subject: Integrated: 8309381: Support JavaFX incubator modules In-Reply-To: References: Message-ID: <11OGy67VqsF27IT9QYj-_-Lp9UJFeOT5NE53YJ266SI=.ff16b829-5104-4c31-a24e-24d036e267d0@github.com> On Tue, 29 Oct 2024 22:23:35 GMT, Kevin Rushforth wrote: > This PR add the necessary support for [JavaFX Incubator Modules](https://github.com/kevinrushforth/jfx/blob/jfx.incubator/INCUBATOR-MODULES.md). It includes the following: > > 1. Changes to the build scripts `build.gradle` and `settings.gradle` to document where to add your incubator module. Also added `jlink` flags to not resolve incubator modules by default and warn when resolving (same as is done for JDK incubator modules). > 2. A utility class to produce warnings when first using an incubator module. > 3. Changes to `javafx.base/module-info.java` to document where to add the needed qualified exports to your module to access the utility class in 2. > > See PR #1617 for a sample module that is built on top of this PR's source branch. > > This is almost ready to review. I will take it out of Draft in the next day or so. This pull request has now been integrated. Changeset: 67eed6d8 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/67eed6d8d63c1047a117b08418c65e1ad341f392 Stats: 164 lines in 4 files changed: 160 ins; 0 del; 4 mod 8309381: Support JavaFX incubator modules Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1616 From andy.goryachev at oracle.com Mon Dec 2 19:04:00 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 2 Dec 2024 19:04:00 +0000 Subject: CSS Media Queries In-Reply-To: References: Message-ID: At first glance, this proposal looks good, with it we could provide a dark mode stylesheet. Questions: 1. what are the plans / commitments for actually developing the dark mode stylesheet? 2. are there plans / necessity of adding more similar properties to the Scene? 3. are there plans to provide a similar proposal for variables, for example to be able to size controls consistently https://bugs.openjdk.org/browse/JDK-8314683 ? One more tangentially related question: do you think it's possible to be able to determine which selector in which stylesheet was used, for debugging purposes? For example, be able to enable logging? Thanks! -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, December 2, 2024 at 08:23 To: openjfx-dev Subject: CSS Media Queries Hi everyone, here's a proposal to add media queries to JavaFX, which is a powerful feature to adjust stylesheets to changes in the runtime environment. Proposal: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7 PR: https://github.com/openjdk/jfx/pull/1655 -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Mon Dec 2 19:20:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 19:20:47 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/screencast/TokenStorage.java line 372: > 370: affectedScreenBounds > 371: .stream() > 372: .map(rectangle -> new Dimension2D(rectangle.width, rectangle.height)) the largest positive integer that can be stored in a float exactly is ~16M. we are fine here. modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2D.java line 29: > 27: > 28: /** > 29: * A 2D dimension object that contains a width and a height. maybe mention that this class uses `float`s? modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2D.java line 31: > 29: * A 2D dimension object that contains a width and a height. > 30: */ > 31: public record Dimension2D(float width, float height) {} I wish this class was named differently to signify it's based on float... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1866470555 PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1866467764 PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1866477629 From michaelstrau2 at gmail.com Mon Dec 2 19:32:14 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 2 Dec 2024 20:32:14 +0100 Subject: CSS Media Queries In-Reply-To: References: Message-ID: > 1. what are the plans / commitments for actually developing the dark mode stylesheet? I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've added focusVisible, platform preferences, CSS transitions, and now hopefully media queries. After this is done, I think we should leverage all of those new features, and create a bold new theme for JavaFX that feels at home in the year 2025. > 2. are there plans / necessity of adding more similar properties to the Scene? Yes, where it makes sense. I think it should also have persistentScrollBars / prefers-persistent-scrollbars. After that, we're probably good for a while. > 3. are there plans to provide a similar proposal for variables, for example to be able to size controls consistently https://bugs.openjdk.org/browse/JDK-8314683 ? Yes, although this requires a new CSS parser. Have a look at this proposal, specifically the "Variable substitution" section: https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926 Variable substitution requires a value resolution algorithm that works on the level of CSS tokens, not on pre-parsed objects. > One more tangentially related question: do you think it's possible to be able to determine which selector in which stylesheet was used, for debugging purposes? For example, be able to enable logging? Interesting question. I don't have an answer (or a guess) at the moment, but I'll think about it. From kcr at openjdk.org Mon Dec 2 19:48:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 19:48:43 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 19:18:18 GMT, Andy Goryachev wrote: >> A small refactoring of the Dimension classes. >> >> * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. >> * `com.sun.javafx.geom.Dimension2D` became a record. >> * `javafx.geometry.Dimension2D`: fields became `final`. >> >> I'm not sure we need the implementation class at all considering we are free to use the public one. > > modules/javafx.graphics/src/main/java/com/sun/javafx/geom/Dimension2D.java line 31: > >> 29: * A 2D dimension object that contains a width and a height. >> 30: */ >> 31: public record Dimension2D(float width, float height) {} > > I wish this class was named differently to signify it's based on float... Most of the classes in this package are based on floats. As this is an internal class, adding a comment seems sufficient. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1653#discussion_r1866515370 From nlisker at openjdk.org Mon Dec 2 20:21:43 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Mon, 2 Dec 2024 20:21:43 GMT Subject: RFR: 8345261: Refactor the Dimension2D classes In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 17:00:42 GMT, Nir Lisker wrote: > A small refactoring of the Dimension classes. > > * `com.sun.javafx.geom.Dimension` was removed and its uses were replaced by `com.sun.javafx.geom.Dimension2D`. > * `com.sun.javafx.geom.Dimension2D` became a record. > * `javafx.geometry.Dimension2D`: fields became `final`. > > I'm not sure we need the implementation class at all considering we are free to use the public one. You reviewed the PR before the requested changes were made :) I'm going to move the `int` one into an inner class anyway. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2512712866 From kcr at openjdk.org Mon Dec 2 20:37:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 20:37:44 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v3] In-Reply-To: References: Message-ID: <4IRCKZrXNVxBpQceCSwUcEiSXRbKw1aw6F1N79cPItw=.ec1e9ed4-5879-4cfe-bbed-9f199047b236@github.com> On Sat, 30 Nov 2024 16:14:22 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix test package The fix works as expected. The test will catch the failure, but fails for me almost always on one of my machines and very infrequently on another. There is a race condition in the test where the `onShown` event can be delivered before the initial stage size has been realized. I recommend sleeping for 500 msec after getting the `onShown` event and before changing the width of the Stage. ------------- PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2473855881 From john.hendrikx at gmail.com Mon Dec 2 20:45:58 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Mon, 2 Dec 2024 21:45:58 +0100 Subject: CSS Media Queries In-Reply-To: References: Message-ID: <1472273b-795f-4995-b875-0ebdeba5ab5a@gmail.com> This looks like a good addition, allowing FX applications to blend in better with their platform, and responding to certain accessibility settings. --John On 02/12/2024 17:22, Michael Strau? wrote: > Hi everyone, > > here's a proposal to add media queries to JavaFX, which is a powerful > feature to adjust stylesheets to changes in the runtime environment. > > Proposal: https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7 > PR: https://github.com/openjdk/jfx/pull/1655 From kcr at openjdk.org Mon Dec 2 20:55:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 20:55:44 GMT Subject: RFR: 8345188: Set :root pseudo-class on root node In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 14:02:36 GMT, Michael Strau? wrote: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. This will require a change to `cssref.html` to list the `:root` pseudo-class in the list of pseudo-classes for `Parent`. Additionally, changes will likely be needed to the two places where we say that JavaFX doesn't support structural pseudo-classes, [here](https://github.com/openjdk/jfx/blob/da6ad4b1e8c2aac59114949826db1e4b013a3bc5/modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html#L542-L543) and [here](https://github.com/openjdk/jfx/blob/da6ad4b1e8c2aac59114949826db1e4b013a3bc5/modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/cssref.html#L872), since `:root` is a structural pseudo-class. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2512805375 From tsayao at openjdk.org Mon Dec 2 21:14:18 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 2 Dec 2024 21:14:18 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v4] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add sleep to avoid intermittent failures ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/e74b18c1..fd8c3efa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=02-03 Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From kcr at openjdk.org Mon Dec 2 21:28:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 21:28:42 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v4] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 21:14:18 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add sleep to avoid intermittent failures tests/system/src/test/java/test/javafx/stage/StageMixedSizeTest.java line 103: > 101: > 102: mainStage.setOnShown(e -> { > 103: Util.sleep(500); We don't want to sleep on the FX application thread. I think you'll need to split this into separate `Runnable`s for separate calls to `Util::runAndWait` and have the sleeps between them. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1866640776 From kcr at openjdk.org Mon Dec 2 21:28:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 21:28:44 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v3] In-Reply-To: References: Message-ID: On Sat, 30 Nov 2024 16:14:22 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Fix test package tests/system/src/test/java/test/javafx/stage/StageMixedSizeTest.java line 111: > 109: > 110: Util.waitForLatch(showLatch, 5, "Stage failed to setup and show"); > 111: Util.sleep(500); This sleep was already in the right place... on the test thread after the latch is triggered. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1866641774 From kevin.rushforth at oracle.com Mon Dec 2 21:40:25 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 2 Dec 2024 13:40:25 -0800 Subject: CSS Media Queries In-Reply-To: References: Message-ID: I also think this is a good addition to JavaFX CSS. On 12/2/2024 11:32 AM, Michael Strau? wrote: >> 1. what are the plans / commitments for actually developing the dark mode stylesheet? > I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've > added focusVisible, platform preferences, CSS transitions, and now > hopefully media queries. After this is done, I think we should > leverage all of those new features, and create a bold new theme for > JavaFX that feels at home in the year 2025. Depending on the scope, that's a pretty ambitious goal. :)? Were you thinking of something derived from Modena (e.g., a "Modena 2025") that incorporates all of those things and maybe a few other tweaks? Or are you thinking a brand new "from scratch" theme? Based on past experience (the switch from Caspian to Modena in FX 8), the latter will require quite a lot of work, and someone with a good artistic eye and attention to detail to drive it. I expect it would be a fairly long process and require a *lot*? of testing. Anyway, that doesn't need to slow down this feature. This feature would help with either approach. And application developers would be able to take advantage in their own stylesheets before that. >> 2. are there plans / necessity of adding more similar properties to the Scene? > Yes, where it makes sense. I think it should also have > persistentScrollBars / prefers-persistent-scrollbars. Yes, this would be useful. > After that, we're probably good for a while. Sounds good. -- Kevin >> 3. are there plans to provide a similar proposal for variables, for example to be able to size controls consistently https://bugs.openjdk.org/browse/JDK-8314683 ? > Yes, although this requires a new CSS parser. > Have a look at this proposal, specifically the "Variable substitution" > section: https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926 > Variable substitution requires a value resolution algorithm that works > on the level of CSS tokens, not on pre-parsed objects. > > >> One more tangentially related question: do you think it's possible to be able to determine which selector in which stylesheet was used, for debugging purposes? For example, be able to enable logging? > Interesting question. I don't have an answer (or a guess) at the > moment, but I'll think about it. From tsayao at openjdk.org Mon Dec 2 22:17:00 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 2 Dec 2024 22:17:00 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v5] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Wait before setting size and after to allow realization ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/fd8c3efa..7c14539b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=03-04 Stats: 17 lines in 1 file changed: 13 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From tsayao at openjdk.org Mon Dec 2 22:17:01 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 2 Dec 2024 22:17:01 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v4] In-Reply-To: References: Message-ID: <5Jl0mhE09ecVwFcyTZrxpRJXYWyo0Lhf1XPfODwIaV8=.762bfd83-797e-4f28-a7ad-dac7baa097dc@github.com> On Mon, 2 Dec 2024 21:24:42 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add sleep to avoid intermittent failures > > tests/system/src/test/java/test/javafx/stage/StageMixedSizeTest.java line 103: > >> 101: >> 102: mainStage.setOnShown(e -> { >> 103: Util.sleep(500); > > We don't want to sleep on the FX application thread. I think you'll need to split this into separate `Runnable`s for separate calls to `Util::runAndWait` and have the sleeps between them. I did it with a Timeline, is it ok? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1866694597 From tsayao at openjdk.org Mon Dec 2 22:17:01 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 2 Dec 2024 22:17:01 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v3] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 21:25:34 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test package > > tests/system/src/test/java/test/javafx/stage/StageMixedSizeTest.java line 111: > >> 109: >> 110: Util.waitForLatch(showLatch, 5, "Stage failed to setup and show"); >> 111: Util.sleep(500); > > This sleep was already in the right place... on the test thread after the latch is triggered. Restored ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1866694303 From andy.goryachev at oracle.com Mon Dec 2 22:27:56 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 2 Dec 2024 22:27:56 +0000 Subject: CSS Media Queries In-Reply-To: References: Message-ID: Thank you for clarifications! As Kevin already mentioned, developing a new stylesheet would be a monumental task. It might be easier to adjust the modena.css, since it's already pretty good (in my opinion). I wish there was a simpler way to introduce variables - I think the variables might be a better solution from the stylesheet maintainability point of view, and to help with supporting light/dark, compact/roomy variants and simple things like updating the base font size. Doing a different CSS parser is definitely a much larger project than we can afford, probably. On the other hand, if it enables programmatic creation of style sheets... -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, December 2, 2024 at 11:32 To: Cc: openjfx-dev Subject: Re: CSS Media Queries > 1. what are the plans / commitments for actually developing the dark mode stylesheet? I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've added focusVisible, platform preferences, CSS transitions, and now hopefully media queries. After this is done, I think we should leverage all of those new features, and create a bold new theme for JavaFX that feels at home in the year 2025. > 2. are there plans / necessity of adding more similar properties to the Scene? Yes, where it makes sense. I think it should also have persistentScrollBars / prefers-persistent-scrollbars. After that, we're probably good for a while. > 3. are there plans to provide a similar proposal for variables, for example to be able to size controls consistently https://bugs.openjdk.org/browse/JDK-8314683 ? Yes, although this requires a new CSS parser. Have a look at this proposal, specifically the "Variable substitution" section: https://gist.github.com/mstr2/f416996caf48e11193f0b6a5883a3926 Variable substitution requires a value resolution algorithm that works on the level of CSS tokens, not on pre-parsed objects. > One more tangentially related question: do you think it's possible to be able to determine which selector in which stylesheet was used, for debugging purposes? For example, be able to enable logging? Interesting question. I don't have an answer (or a guess) at the moment, but I'll think about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Dec 2 22:27:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 2 Dec 2024 22:27:47 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v4] In-Reply-To: <5Jl0mhE09ecVwFcyTZrxpRJXYWyo0Lhf1XPfODwIaV8=.762bfd83-797e-4f28-a7ad-dac7baa097dc@github.com> References: <5Jl0mhE09ecVwFcyTZrxpRJXYWyo0Lhf1XPfODwIaV8=.762bfd83-797e-4f28-a7ad-dac7baa097dc@github.com> Message-ID: On Mon, 2 Dec 2024 22:14:11 GMT, Thiago Milczarek Sayao wrote: >> tests/system/src/test/java/test/javafx/stage/StageMixedSizeTest.java line 103: >> >>> 101: >>> 102: mainStage.setOnShown(e -> { >>> 103: Util.sleep(500); >> >> We don't want to sleep on the FX application thread. I think you'll need to split this into separate `Runnable`s for separate calls to `Util::runAndWait` and have the sleeps between them. > > I did it with a Timeline, is it ok? That should be OK. I'll test it tomorrow. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1866709146 From tsayao at openjdk.org Mon Dec 2 22:51:23 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 2 Dec 2024 22:51:23 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v6] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Fix mistake ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/7c14539b..b3c453a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=04-05 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From mstrauss at openjdk.org Mon Dec 2 23:35:53 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Dec 2024 23:35:53 GMT Subject: RFR: 8345348: CSS Media Queries Message-ID: Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). ------------- Commit messages: - Add persistentScrollBars media feature - Merge branch 'master' into feature/media-queries - Merge branch 'master' into feature/media-queries - Implementation of media queries Changes: https://git.openjdk.org/jfx/pull/1655/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345348 Stats: 4607 lines in 37 files changed: 3510 ins; 1026 del; 71 mod Patch: https://git.openjdk.org/jfx/pull/1655.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1655/head:pull/1655 PR: https://git.openjdk.org/jfx/pull/1655 From angorya at openjdk.org Mon Dec 2 23:35:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 2 Dec 2024 23:35:53 GMT Subject: RFR: 8345348: CSS Media Queries In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 16:19:46 GMT, Michael Strau? wrote: > Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1212: > 1210: * @since 24 > 1211: */ > 1212: private final ObjectProperty colorScheme = new MediaProperty<>( is it possible for two different scenes to have different color schemes or any other properties derived from the platform preferences? would it make more sense to use the platform preferences properties directly? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r1866640976 From mstrauss at openjdk.org Mon Dec 2 23:35:53 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Mon, 2 Dec 2024 23:35:53 GMT Subject: RFR: 8345348: CSS Media Queries In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 21:24:52 GMT, Andy Goryachev wrote: >> Implementation of [CSS media queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7). > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1212: > >> 1210: * @since 24 >> 1211: */ >> 1212: private final ObjectProperty colorScheme = new MediaProperty<>( > > is it possible for two different scenes to have different color schemes or any other properties derived from the platform preferences? > > would it make more sense to use the platform preferences properties directly? I think we need a way for applications to override the OS preferences. Most applications that offer light and dark themes also allow users to switch between them independently from the OS. The advantage of allowing `Scene` to override those properties is that an application can mix and match light and dark themes (so to answer your question: yes, different scenes can have different color schemes). This might be useful for stylistic or compatibility reasons. For example, an application might use third-party UI components in tool windows that don't work well with a dark theme (maybe even Swing content), so these windows would use a color scheme that is different from the main window. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r1866729598 From michaelstrau2 at gmail.com Tue Dec 3 00:03:19 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 3 Dec 2024 01:03:19 +0100 Subject: A new theme for JavaFX In-Reply-To: References: Message-ID: Continuing the discussion that was started in the CSS media queries thread: On Mon, Dec 2, 2024 at 11:55?PM Kevin Rushforth wrote: > > I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've > > added focusVisible, platform preferences, CSS transitions, and now > > hopefully media queries. After this is done, I think we should > > leverage all of those new features, and create a bold new theme for > > JavaFX that feels at home in the year 2025. > > Depending on the scope, that's a pretty ambitious goal. :) Were you > thinking of something derived from Modena (e.g., a "Modena 2025") that > incorporates all of those things and maybe a few other tweaks? Or are > you thinking a brand new "from scratch" theme? Based on past experience > (the switch from Caspian to Modena in FX 8), the latter will require > quite a lot of work, and someone with a good artistic eye and attention > to detail to drive it. I expect it would be a fairly long process and > require a *lot* of testing. > > Anyway, that doesn't need to slow down this feature. This feature would > help with either approach. And application developers would be able to > take advantage in their own stylesheets before that. While I think that Modena is a nice-looking theme, I can't help but think that it's a nice-looking theme for the mid-2010's. It dates the JavaFX platform, and its look and feel is the first thing that people see when they interact with JavaFX (either with the framework itself, or with user-facing applications). The UI landscape has evolved quite a lot in the past decade. I think there is great value in completely modernizing the JavaFX user experience, firmly and boldly moving it forward, and making the framework attractive again for a new generation of developers. Ideally, this is more than a "Modena 2025" refresh. I completely agree that this is a big project, and it requires talented people to pull it off. However, there _are_ talented UI designers and developers in the JavaFX community. I hope this will start a discussion on how a modern JavaFX user experience can look like, and how we'd be able to achieve it. From michaelstrau2 at gmail.com Tue Dec 3 00:08:16 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 3 Dec 2024 01:08:16 +0100 Subject: CSS Media Queries In-Reply-To: References: Message-ID: > I wish there was a simpler way to introduce variables - I think the variables might be a better solution from the stylesheet maintainability point of view, and to help with supporting light/dark, compact/roomy variants and simple things like updating the base font size. Doing a different CSS parser is definitely a much larger project than we can afford, probably. On the other hand, if it enables programmatic creation of style sheets... Custom variables would undoubtedly be a great feature. This is orthogonal to media queries, though: at some point, even when using custom variables, you have to ask "the medium" about things like the color scheme or user preferences. From arapte at openjdk.org Tue Dec 3 01:09:54 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 3 Dec 2024 01:09:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v50] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 18:07:14 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace A few more minor suggestions. I shall test the sample apps and provide any feedback. modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/D.java line 1: > 1: package com.sun.jfx.incubator.scene.control.richtext.util; Missing copyright header. modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/D.java line 12: > 10: StringBuilder sb = new StringBuilder(); > 11: for (Object x : a) { > 12: if (sb.length() > 0) { suggestion: `if (!sb.empty())` modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/ListenerHelper.java line 85: > 83: public static ListenerHelper get(SkinBase skin) { > 84: return accessor.apply(skin); > 85: } I think ideally, a get method should not do any processing but just return the desired value/object. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2472714954 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1865860373 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1865879649 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1866135904 From tsayao at openjdk.org Tue Dec 3 10:27:22 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 3 Dec 2024 10:27:22 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v7] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Add test for Height ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/b3c453a1..2cffd52e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=05-06 Stats: 17 lines in 1 file changed: 14 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From lkostyra at openjdk.org Tue Dec 3 10:46:46 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 3 Dec 2024 10:46:46 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v7] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 10:27:22 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test for Height Good timing with the height test, I was mid-verification, about to suggest adding it :) On my end the test does pass on Ubuntu 22.04 with Xorg and with the fix. However, without the fix, the tests still succeed despite the GTK assertions showing up: > gradle --info -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test --tests StageMixedSizeTest ... Successfully started process 'Gradle Test Executor 479' (java:29375): Gtk-CRITICAL **: 11:38:34.936: gtk_window_resize: assertion 'width > 0' failed (java:29375): Gtk-CRITICAL **: 11:38:36.596: gtk_window_resize: assertion 'height > 0' failed Gradle Test Executor 479 finished executing tests. Not having an actually failing test when there's a problem kind of invalidates the reason for tests to exist, these messages will probably be drowned in the sea of log messages. Do you think there is a way to capture those and fail the test (even as a follow-up)? ------------- PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2475272865 From john.hendrikx at gmail.com Tue Dec 3 10:47:06 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 3 Dec 2024 11:47:06 +0100 Subject: A new theme for JavaFX In-Reply-To: References: Message-ID: I think we can leave this to the community as FX provides sufficient means to have a 3rd party provide a theme.? There are other themes out there, and they can be updated with new functionality once it becomes available in a FX version they're willing to support.? Perhaps this one: https://github.com/mkpaz/atlantafx I also don't think modena looks that dated.? As it is pretty smart with colors (using variables and?ladders to select contrasting colors), adjusting just its base colors may be sufficient to have it work nicely as a dark theme. The modern "super flat almost borderless" look is IMHO counterproductive and often annoying as it is hard to see where one thing ends and another thing starts. --John On 03/12/2024 01:03, Michael Strau? wrote: > Continuing the discussion that was started in the CSS media queries thread: > > > On Mon, Dec 2, 2024 at 11:55?PM Kevin Rushforth > wrote: >>> I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've >>> added focusVisible, platform preferences, CSS transitions, and now >>> hopefully media queries. After this is done, I think we should >>> leverage all of those new features, and create a bold new theme for >>> JavaFX that feels at home in the year 2025. >> Depending on the scope, that's a pretty ambitious goal. :) Were you >> thinking of something derived from Modena (e.g., a "Modena 2025") that >> incorporates all of those things and maybe a few other tweaks? Or are >> you thinking a brand new "from scratch" theme? Based on past experience >> (the switch from Caspian to Modena in FX 8), the latter will require >> quite a lot of work, and someone with a good artistic eye and attention >> to detail to drive it. I expect it would be a fairly long process and >> require a *lot* of testing. >> >> Anyway, that doesn't need to slow down this feature. This feature would >> help with either approach. And application developers would be able to >> take advantage in their own stylesheets before that. > > While I think that Modena is a nice-looking theme, I can't help but > think that it's a nice-looking theme for the mid-2010's. It dates the > JavaFX platform, and its look and feel is the first thing that people > see when they interact with JavaFX (either with the framework itself, > or with user-facing applications). The UI landscape has evolved quite > a lot in the past decade. I think there is great value in completely > modernizing the JavaFX user experience, firmly and boldly moving it > forward, and making the framework attractive again for a new > generation of developers. > > Ideally, this is more than a "Modena 2025" refresh. I completely agree > that this is a big project, and it requires talented people to pull it > off. However, there _are_ talented UI designers and developers in the > JavaFX community. I hope this will start a discussion on how a modern > JavaFX user experience can look like, and how we'd be able to achieve > it. From john.hendrikx at gmail.com Tue Dec 3 11:16:45 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Tue, 3 Dec 2024 12:16:45 +0100 Subject: Less in FX (was Re: CSS Media Queries) In-Reply-To: References: Message-ID: <0c99141e-14c6-4be8-8297-8faadbfacdf6@gmail.com> I've been using LESS for ages in combination with FX.?? I adapted this project: https://github.com/i-net-software/jlessc In FX I use it with this helper class: https://github.com/hjohn/MediaSystem-v2/blob/master/mediasystem-runner/src/main/java/hs/mediasystem/runner/util/LessLoader.java Then to use a stylesheet with a control, you do something like this: finalString CLOCK_STYLES_URL= LessLoader.compile(RootNodeFactory.class, "clock-pane.less") Where "RootNodeFactory.class" is just a reference class as my .less files are located in the same package as the controls. The resulting URL can then simply be set on a control or scene: clockPane.getStylesheets().add(CLOCK_STYLES_URL); This allows me to use all kinds of handy features from LESS.? Here is the clock-pane.less file for example: @import"hs/mediasystem/runner/properties.less"; .clock-pane { -fx-alignment: bottom-right; -fx-padding: 5; .clock-box { -fx-padding: 5 15 5 15; -fx-alignment: center; .clock { .style-p1-extra-light; } .date { .style-p3; } } } As you can see, it uses imports, style nesting and references to groups of other styles (like ".style-p3").? In properties.less we find many custom variables, like: @tinted-glass: fade(@theme-primary, 60%); @glass-color: rgba(0, 0, 0, 0.6); @shape-disc: "M256 8C119 8 8 119 8 256s111 248 248 248 248-111 248-248S393 8 256 8z"; @text-primary: lighten(@theme-primary, 5%, relative); I'm probably only scratching the surface of what you can do with LESS, as I'm hardly a CSS designer :) The LessLoader class I wrote has one more handy feature; it allows suffixes on your CSS files to allow for customization per platform. I use this to select appropriate fonts per platform (as their names can vary apparently!). See here the Windows file. The Linux variant has slightly different font family names but map to the same LESS variables so I don't need to fix this everywhere. /* * The Noto Sans font supports many variations. To get the correct variation * in JavaFX, select them as follows: * * - Black = Noto Sans Blk * - Bold = Noto Sans + font-weight: bold * - Semi Bold = Noto Sans SemBd * - Medium = Noto Sans Med * - Regular = Noto Sans + font-weight: normal * - Light = Noto Sans Light * * Note that these names are for Windows. Other platforms can use * slightly different names. */ .light{ -fx-font-family: "Noto Sans Light"; -fx-font-weight: normal; } .regular{ -fx-font-family: "Noto Sans"; -fx-font-weight: normal; } .medium{ -fx-font-family: "Noto Sans Med"; -fx-font-weight: bold; } .semi-bold{ -fx-font-family: "Noto Sans SemBd"; -fx-font-weight: bold; } .bold{ -fx-font-family: "Noto Sans"; -fx-font-weight: bold; } .black{ -fx-font-family: "Noto Sans Blk"; -fx-font-weight: bold; } --John On 03/12/2024 01:08, Michael Strau? wrote: >> I wish there was a simpler way to introduce variables - I think the variables might be a better solution from the stylesheet maintainability point of view, and to help with supporting light/dark, compact/roomy variants and simple things like updating the base font size. Doing a different CSS parser is definitely a much larger project than we can afford, probably. On the other hand, if it enables programmatic creation of style sheets... > Custom variables would undoubtedly be a great feature. This is > orthogonal to media queries, though: at some point, even when using > custom variables, you have to ask "the medium" about things like the > color scheme or user preferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Dec 3 13:35:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 13:35:46 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v7] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 10:43:42 GMT, Lukasz Kostyra wrote: > On my end the test does pass on Ubuntu 22.04 with Xorg and with the fix. However, without the fix, the tests still succeed despite the GTK assertions showing up: When I tested the earlier version yesterday, the test failed for me on Ubuntu 22.04 without the fix. I haven't tested the updated version, but if it no longer catches the error by failing without the fix, then something is wrong with the updated test. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2514571292 From mariushanl at web.de Tue Dec 3 13:41:32 2024 From: mariushanl at web.de (Marius Hanl) Date: Tue, 3 Dec 2024 13:41:32 +0000 Subject: Aw: CSS Media Queries In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mariushanl at web.de Tue Dec 3 13:57:42 2024 From: mariushanl at web.de (Marius Hanl) Date: Tue, 3 Dec 2024 13:57:42 +0000 Subject: Aw: A new theme for JavaFX In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Tue Dec 3 14:00:25 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 3 Dec 2024 15:00:25 +0100 Subject: CSS Media Queries In-Reply-To: References: Message-ID: @media queries test the viewport, while @container queries test the container of the element to which they apply. We can add either, both, or none of them in the future. Testing "width" and "height" is probably a bit more difficult than testing user preferences. With the current implementation, all stylesheets are re-evaluated when a user preference is changed. We probably wouldn't want to do that for every change of width and height, because it might impact window resizing performance quite significantly. More likely, we'd analyze the width/height media queries in the stylesheet, and then compute a set of boundary points when re-evaluation is triggered. In your example, we would only need to re-evaluate the stylesheets when the width crosses the 1250px boundary. On Tue, Dec 3, 2024 at 2:41?PM Marius Hanl wrote: > > I also agree that this is a good idea. > As of now, we can only change the theme by reacting to the Platform Preferences (listener) and change the Stylesheet of the Scene(s). > I'm not sure how well this works as I never tried it as of now (Might even be problematic for Tooltips, Dialogs and Dialogs without an owner). > > So media queries are the better and correct solution for this problem. > I use them myself for light/dark theme in the Web and they work pretty good, are easy to set up and read. So following this standard is the right choice. > > Media queries are normally often used with 'width' and 'height' as well, e.g. > > @media (width <= 1250px) { > /* ? */ > } > > I wonder if we want to support that as well. > Since JavaFX follows the 'container' approach, where the container (Pane) is responsible for the layout, this does not seem to be that useful or needed in JavaFX (compared to the Web). > Although I can think of some usecases like changing (decrease/increase) the padding or the alignment of some Controls when a specific width or height is reached. > > Are there any plans to include this at a later date? If not, perhaps we should document this. > Other opinions on this topic are also welcome. > > In any case, starting with the preferences is the right decision and IMO will bring the most benefit. > > -- Marius From lkostyra at openjdk.org Tue Dec 3 15:11:57 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 3 Dec 2024 15:11:57 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v52] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 20:00:13 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - since 24 > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - hide skin input map > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - ... and 62 more: https://git.openjdk.org/jfx/compare/67eed6d8...4b27b891 Got a few comments/questions for you from my section of RTA (jfx.incubator.scene.control.richtext and jfx.incubator.scene.control.richtext.skin), most are minor. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 392: > 390: * This is a {@link StyleableProperty} with the name {@code -fx-caret-blink-period}. > 391: *

    > 392: * alternative:
    I see an `alternative:` here. I suspect it's a good time to pick one version for the docs =) (either is fine) modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1193: > 1191: * @see RichTextArea.Tags#CUT > 1192: */ > 1193: public void cut() { We have `copy(DataFormat)` and `paste(DataFormat)`. Would it make sense to also have `cut(DataFormat)`? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SelectionModel.java line 74: > 72: * @param pos the new caret position, must be non-null > 73: */ > 74: public void extendSelection(StyledTextModel model, TextPos pos); Kind of picky-thinking of nomenclature here (but do correct me if I'm wrong) - "extend" strictly means to make something larger, while this assumes you can also make the selection smaller. How does `modifySelection` or `adjustSelection` sound like instead? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SingleSelectionModel.java line 88: > 86: a = pos; > 87: } else { > 88: if(pos.compareTo(sel.getMin()) < 0) { Minor: styling mistake - `s/if(/if (` here and L91 ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2472964042 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1867884183 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1867901791 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1867710940 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1867676038 From lkostyra at openjdk.org Tue Dec 3 15:11:59 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 3 Dec 2024 15:11:59 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v50] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 18:07:14 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > whitespace modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 82: > 80: *

  • virtualized text cell flow > 81: *
  • support for text styling with an application stylesheet or {@link StyleAttributeMap inline attributes} > 82: *
  • supports for multiple views connected to the same model Minor: `s/supports for/supports` or `s/supports/support` modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 111: > 109: *

    > 110: * A view-only information control requires a different model. The following example illustrates how to > 111: * create a model that uses a style sheet for styling: Minor: `s/style sheet/stylesheet` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1866015635 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1866020046 From mstrauss at openjdk.org Tue Dec 3 15:23:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 15:23:15 GMT Subject: RFR: 8343398: Add reducedData preference Message-ID: The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. This corresponds to the following OS settings: Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. ------------- Commit messages: - error message tweak - add macOS implementation - add linux implementation - Implementation of reducedData Changes: https://git.openjdk.org/jfx/pull/1656/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343398 Stats: 250 lines in 17 files changed: 211 ins; 28 del; 11 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Tue Dec 3 15:36:04 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 15:36:04 GMT Subject: RFR: 8345188: Set :root pseudo-class on root node [v2] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: update cssref ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/1299f0b2..bdb33c2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From mstrauss at openjdk.org Tue Dec 3 15:44:01 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 15:44:01 GMT Subject: RFR: 8345188: Set :root pseudo-class on root node [v3] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add pseudo-class table to Parent ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/bdb33c2f..58363439 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=01-02 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From andy.goryachev at oracle.com Tue Dec 3 15:57:20 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 3 Dec 2024 15:57:20 +0000 Subject: A new theme for JavaFX In-Reply-To: References: Message-ID: I agree with John on the subject of modena and flat themes. From the platform point of view, I would think we should focus on *enabling* the complex themes by providing the necessary tools. It is currently possible to create e.g. a dark theme, or react to platform preferences' changes, by, for instance, dynamically generating a stylesheet - but the process is not easy. Adding variables might help more than anything else, in my opinion. Maybe there is a way to publish platform preferences via another set of variables available to CSS. To be specific, I see the following features that should be available to the CSS designer: 1. consistent padding for compact/roomy user preference 2. derived colors for dark/light/custom themes (I suspect the currently used derive() will not be sufficient) 3. base font 4. component sizing which depends on the base font size On topic of modena.css, I think we may want to consider updating the stylesheet to support the dark theme as our first priority, leaving designing more elaborate custom theme to the public. What do you think? -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, December 3, 2024 at 02:47 To: openjfx-dev at openjdk.org Subject: Re: A new theme for JavaFX I think we can leave this to the community as FX provides sufficient means to have a 3rd party provide a theme. There are other themes out there, and they can be updated with new functionality once it becomes available in a FX version they're willing to support. Perhaps this one: https://github.com/mkpaz/atlantafx I also don't think modena looks that dated. As it is pretty smart with colors (using variables and ladders to select contrasting colors), adjusting just its base colors may be sufficient to have it work nicely as a dark theme. The modern "super flat almost borderless" look is IMHO counterproductive and often annoying as it is hard to see where one thing ends and another thing starts. --John On 03/12/2024 01:03, Michael Strau? wrote: > Continuing the discussion that was started in the CSS media queries thread: > > > On Mon, Dec 2, 2024 at 11:55?PM Kevin Rushforth > wrote: >>> I'm thinking a bit bigger than just "Modena Dark". Since JFX 19, we've >>> added focusVisible, platform preferences, CSS transitions, and now >>> hopefully media queries. After this is done, I think we should >>> leverage all of those new features, and create a bold new theme for >>> JavaFX that feels at home in the year 2025. >> Depending on the scope, that's a pretty ambitious goal. :) Were you >> thinking of something derived from Modena (e.g., a "Modena 2025") that >> incorporates all of those things and maybe a few other tweaks? Or are >> you thinking a brand new "from scratch" theme? Based on past experience >> (the switch from Caspian to Modena in FX 8), the latter will require >> quite a lot of work, and someone with a good artistic eye and attention >> to detail to drive it. I expect it would be a fairly long process and >> require a *lot* of testing. >> >> Anyway, that doesn't need to slow down this feature. This feature would >> help with either approach. And application developers would be able to >> take advantage in their own stylesheets before that. > > While I think that Modena is a nice-looking theme, I can't help but > think that it's a nice-looking theme for the mid-2010's. It dates the > JavaFX platform, and its look and feel is the first thing that people > see when they interact with JavaFX (either with the framework itself, > or with user-facing applications). The UI landscape has evolved quite > a lot in the past decade. I think there is great value in completely > modernizing the JavaFX user experience, firmly and boldly moving it > forward, and making the framework attractive again for a new > generation of developers. > > Ideally, this is more than a "Modena 2025" refresh. I completely agree > that this is a big project, and it requires talented people to pull it > off. However, there _are_ talented UI designers and developers in the > JavaFX community. I hope this will start a discussion on how a modern > JavaFX user experience can look like, and how we'd be able to achieve > it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Tue Dec 3 16:08:14 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 3 Dec 2024 16:08:14 +0000 Subject: Less in FX (was Re: CSS Media Queries) In-Reply-To: <0c99141e-14c6-4be8-8297-8faadbfacdf6@gmail.com> References: <0c99141e-14c6-4be8-8297-8faadbfacdf6@gmail.com> Message-ID: My approach is to create a single stylesheet, see for example https://github.com/andy-goryachev/MP3Player/blob/main/src/goryachev/mp3player/Styles.java and this little guy allows to (re-)regenerate and (re-)load the stylesheet dynamically https://github.com/andy-goryachev/MP3Player/blob/main/src/goryachev/fx/internal/CssLoader.java since the stylesheet is being generated by a java class, I have all the tools I need - platform preferences, proper color mixing logic, lookups, and so on. The only downside is that JavaFX does not allow programmatic creation of CSS, so the process ends up with overhead of creating a string, data url encoding, decoding, and parsing. -andy From: openjfx-dev on behalf of John Hendrikx Date: Tuesday, December 3, 2024 at 03:17 To: openjfx-dev at openjdk.org Subject: Less in FX (was Re: CSS Media Queries) I've been using LESS for ages in combination with FX. I adapted this project: https://github.com/i-net-software/jlessc In FX I use it with this helper class: https://github.com/hjohn/MediaSystem-v2/blob/master/mediasystem-runner/src/main/java/hs/mediasystem/runner/util/LessLoader.java Then to use a stylesheet with a control, you do something like this: final String CLOCK_STYLES_URL = LessLoader.compile(RootNodeFactory.class, "clock-pane.less") Where "RootNodeFactory.class" is just a reference class as my .less files are located in the same package as the controls. The resulting URL can then simply be set on a control or scene: clockPane.getStylesheets().add(CLOCK_STYLES_URL); This allows me to use all kinds of handy features from LESS. Here is the clock-pane.less file for example: @import "hs/mediasystem/runner/properties.less"; .clock-pane { -fx-alignment: bottom-right; -fx-padding: 5; .clock-box { -fx-padding: 5 15 5 15; -fx-alignment: center; .clock { .style-p1-extra-light; } .date { .style-p3; } } } As you can see, it uses imports, style nesting and references to groups of other styles (like ".style-p3"). In properties.less we find many custom variables, like: @tinted-glass: fade(@theme-primary, 60%); @glass-color: rgba(0, 0, 0, 0.6); @shape-disc: "M256 8C119 8 8 119 8 256s111 248 248 248 248-111 248-248S393 8 256 8z"; @text-primary: lighten(@theme-primary, 5%, relative); I'm probably only scratching the surface of what you can do with LESS, as I'm hardly a CSS designer :) The LessLoader class I wrote has one more handy feature; it allows suffixes on your CSS files to allow for customization per platform. I use this to select appropriate fonts per platform (as their names can vary apparently!). See here the Windows file. The Linux variant has slightly different font family names but map to the same LESS variables so I don't need to fix this everywhere. /* * The Noto Sans font supports many variations. To get the correct variation * in JavaFX, select them as follows: * * - Black = Noto Sans Blk * - Bold = Noto Sans + font-weight: bold * - Semi Bold = Noto Sans SemBd * - Medium = Noto Sans Med * - Regular = Noto Sans + font-weight: normal * - Light = Noto Sans Light * * Note that these names are for Windows. Other platforms can use * slightly different names. */ .light { -fx-font-family: "Noto Sans Light"; -fx-font-weight: normal; } .regular { -fx-font-family: "Noto Sans"; -fx-font-weight: normal; } .medium { -fx-font-family: "Noto Sans Med"; -fx-font-weight: bold; } .semi-bold { -fx-font-family: "Noto Sans SemBd"; -fx-font-weight: bold; } .bold { -fx-font-family: "Noto Sans"; -fx-font-weight: bold; } .black { -fx-font-family: "Noto Sans Blk"; -fx-font-weight: bold; } --John On 03/12/2024 01:08, Michael Strau? wrote: I wish there was a simpler way to introduce variables - I think the variables might be a better solution from the stylesheet maintainability point of view, and to help with supporting light/dark, compact/roomy variants and simple things like updating the base font size. Doing a different CSS parser is definitely a much larger project than we can afford, probably. On the other hand, if it enables programmatic creation of style sheets... Custom variables would undoubtedly be a great feature. This is orthogonal to media queries, though: at some point, even when using custom variables, you have to ask "the medium" about things like the color scheme or user preferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Tue Dec 3 16:21:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 16:21:02 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v50] In-Reply-To: References: Message-ID: <-fS_MwdUUUzIdxVlzclDqzaMOzQCWQarYa01LIy95Ic=.6db31d5a-46c6-4248-887d-c684288bf6b2@github.com> On Mon, 2 Dec 2024 16:12:14 GMT, Ambarish Rapte wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> whitespace > > modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/ListenerHelper.java line 85: > >> 83: public static ListenerHelper get(SkinBase skin) { >> 84: return accessor.apply(skin); >> 85: } > > I think ideally, a get method should not do any processing but just return the desired value/object. not sure what you mean, it's a standard helper/accessor pattern - there is no "processing" involved. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868023324 From angorya at openjdk.org Tue Dec 3 16:32:07 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 16:32:07 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v52] In-Reply-To: References: Message-ID: <7lvBfRAQn2E4BecR0kzZOsVGCH1j2JtnpIg6MeaKhkw=.bb4306e8-a91b-4d72-ae41-0de4cc9dc409@github.com> On Tue, 3 Dec 2024 13:19:54 GMT, Lukasz Kostyra wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - since 24 >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - hide skin input map >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - ... and 62 more: https://git.openjdk.org/jfx/compare/67eed6d8...4b27b891 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SelectionModel.java line 74: > >> 72: * @param pos the new caret position, must be non-null >> 73: */ >> 74: public void extendSelection(StyledTextModel model, TextPos pos); > > Kind of picky-thinking of nomenclature here (but do correct me if I'm wrong) - "extend" strictly means to make something larger, while this assumes you can also make the selection smaller. > > How does `modifySelection` or `adjustSelection` sound like instead? named after `TextInputControl.extendSelection()` L1126 I might leave it as is for consistency sake. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868040934 From angorya at openjdk.org Tue Dec 3 16:45:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 16:45:45 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v53] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/4b27b891..5972f7de Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=52 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=51-52 Stats: 62 lines in 3 files changed: 0 ins; 58 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Dec 3 16:45:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 16:45:48 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v52] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 20:00:13 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - since 24 > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - hide skin input map > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - ... and 62 more: https://git.openjdk.org/jfx/compare/67eed6d8...4b27b891 thank you all for the insightful comments. keep them coming! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2515065953 From angorya at openjdk.org Tue Dec 3 16:45:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 16:45:48 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v52] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 15:05:54 GMT, Lukasz Kostyra wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - since 24 >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - hide skin input map >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - ... and 62 more: https://git.openjdk.org/jfx/compare/67eed6d8...4b27b891 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1193: > >> 1191: * @see RichTextArea.Tags#CUT >> 1192: */ >> 1193: public void cut() { > > We have `copy(DataFormat)` and `paste(DataFormat)`. Would it make sense to also have `cut(DataFormat)`? I would say there is no use case for `cut(DataFormat)`. The copy and paste are used for "Copy Special..." and "Paste Special..." items in the context menu - see `RichTextAreaDemoPane:416` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868060684 From j.tosovsky at email.cz Tue Dec 3 17:28:09 2024 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Tue, 3 Dec 2024 18:28:09 +0100 Subject: A new theme for JavaFX In-Reply-To: References: Message-ID: <00b701db45a8$b9bfab10$2d3f0130$@email.cz> On 2024-12-03 Andy Goryachev wrote: > From the platform point of view, I would think we should focus on *enabling* the complex themes by providing the necessary tools Beside PrimeFaces I watch their sister UI suites projects for Vue, React etc. They try making their components handy for custom styling. For PrimeVue they utilize a design token concept, see https://primevue.org/theming/styled/, but they also offer an alternative styling approach https://primevue.org/theming/unstyled/ I suppose this is the result of their theming experience for last couple of years. Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Tue Dec 3 18:24:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 18:24:00 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v53] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 16:45:45 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Here are a few comments on the merge of master to pick up the build changes for supporting incubator modules. I'll get back to the API review next. build.gradle line 2879: > 2877: > 2878: // FIXME: KCR > 2879: // processResources { I recommend deleting this commented-out block unless you plan to deliver resources as part of the `jfx.incubator.input` module. build.gradle line 2968: > 2966: > 2967: // FIXME: KCR > 2968: // processResources { I recommend deleting this commented-out block unless you plan to deliver resources as part of the `jfx.incubator.richtext` module. build.gradle line 4633: > 4631: project(":web") > 4632: ] > 4633: Minor: this blank line looks like a leftover from the merge of master. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2466096692 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868180155 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868180564 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868182047 From kcr at openjdk.org Tue Dec 3 18:24:06 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 18:24:06 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47] In-Reply-To: References: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com> Message-ID: <2BhInPtFLBc07le_0RydNXCboqbg8Pqg1XDP7QkAPYw=.e90f9e39-c8ae-415d-a03c-61fc8a36d469@github.com> On Thu, 21 Nov 2024 20:15:00 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/FunctionTag.java line 51: >> >>> 49: public final class FunctionTag { >>> 50: /** Constructs the function tag. */ >>> 51: public FunctionTag() { >> >> Should this be more than a simple "marker" Object with identity, but no state? There is no way to get the information from a particular function tag instance as to what it represents, nor is there a useful "toString()" method. There is also no way to get the set of available FunctionTag objects from the nested .Tag class. Perhaps we could be informed by the Enum class? >> >> If there was value in doing this, maybe it could be a record? >> >> >> public final record FunctionTag(String name) { } >> >> >> This would be mostly useful for tooling, since most applications aren't likely to need it. >> >> It might be worth noting, even if you prefer not to make this change. > > The main reason there is no name field in the FunctionTag is to simplify the life of custom components or internal skin developers. There is just not enough value, in my opinion. > > The argument about tooling is an interesting one. At first glance, I think it is possible to retrieve both function tag name and the list of tags declared by the control using trivial reflection. > > The other possibility is to forgo FunctionTag completely and just use naked Strings, losing some degree of type clarity. I don't like the idea of using a raw String at all. Let's leave it as is for now and see if we get any requests to add a name. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1861351121 From kcr at openjdk.org Tue Dec 3 18:24:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 18:24:02 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v52] In-Reply-To: References: Message-ID: On Mon, 2 Dec 2024 20:00:13 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 72 commits: > > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - since 24 > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - hide skin input map > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - ... and 62 more: https://git.openjdk.org/jfx/compare/67eed6d8...4b27b891 build.gradle line 4174: > 4172: 'fxml' > 4173: ] > 4174: Minor: this blank line looks like a leftover from the merge of master, and is now unrelated to the addition of a specific incubator module. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1866561147 From kcr at openjdk.org Tue Dec 3 18:24:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 18:24:04 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 22:49:29 GMT, Andy Goryachev wrote: >> build.gradle line 5996: >> >>> 5994: moduleProjList.each { project -> >>> 5995: if (project.hasProperty("moduleName") && project.buildModule) { >>> 5996: def incubating = project.hasProperty("incubating") && project.ext.incubating >> >> After the merge of master, you can remove this (it is unused). I removed it from the PR #1616 (Support JavaFX incubator modules). > > I plan to update (merge) the build script once #1616 is integrated. This is still an issue after the merge, and needs to now be removed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868182438 From angorya at openjdk.org Tue Dec 3 19:08:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 19:08:46 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v35] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 18:03:27 GMT, Kevin Rushforth wrote: >> I plan to update (merge) the build script once #1616 is integrated. > > This is still an issue after the merge, and needs to now be removed. missed this spot, thanks! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868241768 From angorya at openjdk.org Tue Dec 3 19:08:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 19:08:44 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v54] In-Reply-To: References: Message-ID: <_V-VxKNrumJZf_gQwWSTc1J9VoxAa34ywyWI0SpYQkU=.3073f28f-5932-4bce-b4df-76ed3055a709@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/5972f7de..22fce6a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=53 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=52-53 Stats: 69 lines in 1 file changed: 2 ins; 67 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From mstrauss at openjdk.org Tue Dec 3 19:55:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 19:55:39 GMT Subject: RFR: 8345188: Set :root pseudo-class on root node [v4] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add child-indexed pseudo-classes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/58363439..b52816e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=02-03 Stats: 250 lines in 3 files changed: 227 ins; 9 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From mstrauss at openjdk.org Tue Dec 3 20:02:15 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 20:02:15 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v5] In-Reply-To: References: Message-ID: > The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: > https://www.w3.org/TR/selectors-4/#the-root-pseudo > > JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. > > Additionally, we should also support the following child-indexed pseudo-classes: > `:first-child` > `:last-child` > `:only-child` > `:nth-child()` with arguments `even` and `odd` > > The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: whitespace error ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1652/files - new: https://git.openjdk.org/jfx/pull/1652/files/b52816e3..afb5fa40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1652&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1652.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1652/head:pull/1652 PR: https://git.openjdk.org/jfx/pull/1652 From mstrauss at openjdk.org Tue Dec 3 20:04:52 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 3 Dec 2024 20:04:52 GMT Subject: RFR: 8345188: Support tree-structural pseudo-classes [v5] In-Reply-To: References: Message-ID: <5gJXsAgZp4FdCN2xLyRYgm2gIzXcgrJerb4GOkXx9yg=.58c95cdf-2d12-4d0a-91e0-5430e8c4b19d@github.com> On Tue, 3 Dec 2024 20:02:15 GMT, Michael Strau? wrote: >> The CSS Selectors specification defines the `:root` pseudo-class that matches root nodes: >> https://www.w3.org/TR/selectors-4/#the-root-pseudo >> >> JavaFX uses the non-standard `.root` style class for the same purpose. We should also support the `:root` pseudo-class for increased compatibility of JavaFX CSS with the web specification. >> >> Additionally, we should also support the following child-indexed pseudo-classes: >> `:first-child` >> `:last-child` >> `:only-child` >> `:nth-child()` with arguments `even` and `odd` >> >> The `An+B [of S]?` microsyntax for `:nth-child()` is not supported, as this would require major changes in JavaFX CSS. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > whitespace error I've expanded the scope of this enhancement to also include several child-indexed pseudo-classes, which are also structural pseudo-classes. I specifically didn't include the `:empty` structual pseudo-class (matching a `Parent` with no children), as this pseudo-class is alrady being used by `ComboBoxListViewSkin`. Perhaps we should deprecate the use of standard pseudo-classes in skins? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1652#issuecomment-2515438643 From angorya at openjdk.org Tue Dec 3 20:53:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 20:53:45 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Tue, 12 Nov 2024 15:08:11 GMT, Martin Fox wrote: >> Input methods don?t work for text controls inside Popups. This PR fixes that. >> >> Some background: >> >> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. >> >> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. >> >> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. >> >> There are several reasons why Input Methods aren?t currently working for Popups. >> >> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. >> >> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. >> >> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. >> >> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. >> >> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha... > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Tweak to satisfy system test. Running the branch (with the latest master merged) on macOS 14.7.1, noticed that IME window does not show reliably: ![Screenshot 2024-12-03 at 12 46 13](https://github.com/user-attachments/assets/3f30078c-c8f9-4df7-b246-c0be46b3f61f) It gets eventually shown if I commit and keep typing. Also, it almost feels like the internal state is not cleared when the popup gets dismissed - can you try that please? Also, you may want to merge the latest master, this branch has been out for quite some time. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1634#issuecomment-2515525320 From kcr at openjdk.org Tue Dec 3 21:32:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 21:32:59 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47] In-Reply-To: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com> References: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com> Message-ID: On Wed, 20 Nov 2024 23:56:32 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 66 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - hide skin input map >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - whitespace >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - save as >> - removed function handler >> - removed add handler last >> - use focus traversal api >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - ... and 56 more: https://git.openjdk.org/jfx/compare/3a8a5598...e45be7b7 > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 163: > >> 161: * @return the KeyBinding, or null >> 162: */ >> 163: public static KeyBinding option(KeyCode code) { > > In the documentation of `alt` you say that it is equivalent to `option` on macOS. So what we have is an `alt` method that works on all platforms and an `option` method that does the same thing as `alt` on macOS and returns `null` on other platforms? This seems like an odd situation. Do we really need the `option` method? If you intend to keep this method, please add a comment that, on macOS, it is equivalent to calling `alt`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868260269 From kcr at openjdk.org Tue Dec 3 21:33:00 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 21:33:00 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v47] In-Reply-To: References: <3N3aiCX_FHJg3jLR-CUo1tU41Ab9Cn5xftwMkwLHj0k=.5c4014fc-9368-408f-96d9-afd86754b37b@github.com> Message-ID: On Thu, 21 Nov 2024 20:59:37 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 343: >> >>> 341: /** >>> 342: * Creates a {@link Builder} with the specified KeyCode. >>> 343: * @param character the character >> >> Since the type is String what if it is more than one character? > > Good point. Added a link to `KeyEvent.getCharacter()` Does this set the event type to `KEY_TYPED`? If so, then document that. If not...should it? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868380986 From kcr at openjdk.org Tue Dec 3 21:32:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 21:32:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v54] In-Reply-To: <_V-VxKNrumJZf_gQwWSTc1J9VoxAa34ywyWI0SpYQkU=.3073f28f-5932-4bce-b4df-76ed3055a709@github.com> References: <_V-VxKNrumJZf_gQwWSTc1J9VoxAa34ywyWI0SpYQkU=.3073f28f-5932-4bce-b4df-76ed3055a709@github.com> Message-ID: On Tue, 3 Dec 2024 19:08:44 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Here are my comments on the updated KeyBinding / KeyBinding.Builder API. Mostly it's just documentation suggestions with a couple method renaming suggestions. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 214: > 212: * and the {@code shift} + shortcut key modifier ({@code ? command} on macOS, {@code ctrl} elsewhere). > 213: *

    > 214: * This method returns {@code null} on non-macOS platforms. This comment is wrong, since this method is valid on all platforms. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 459: > 457: // } > 458: > 459: /** Key bindings builder */ Can you expand this a bit? Also, end with a period. At a minimum, something like this: * A builder for {@code KeyBinding} objects. but maybe also adding an additional sentence or two along with a pointer to the `KeyBinding.builder` methods and the `build` method of this class? modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 473: > 471: * @return the Builder instance > 472: */ > 473: public Builder onKeyReleased() { We use methods named `onXxxx` for handers, so the `on` is misleading here. I recommend one of the following alternatives: * `keyReleased` / `keyTyped` (for symmetry, we might consider adding `keyPressed` even though it is default) * `eventType(EventType)` The first alternative seems more convenient. If you stick with that (basically a renamed version of what you have), I recommend adding a sentence that it will clear `KEY_PRESSED` and `KEY_TYPED`. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 501: > 499: > 500: /** > 501: * Sets the {@code alt} key down condition (the {@code Option} key on macOS). The docs for this method could be clarified, especially since there is also a no-arg `alt()` method with exactly the same description. I presume that if `condition` is true then it sets the alt key down condition and if `condition` is false then it clears the alt key down condition? If so, say that (or something similar). This applies to all of the modifer methods that take a boolean. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 513: > 511: > 512: /** > 513: * Sets {@code command} key down condition. You need to document what this method does on non-macOS platforms. Maybe something like * Sets {@code command} key down condition on macOS. * *

    * Setting this condition on non-macOS platforms will result in the * {@code build} method returning {@code null}. This comment also applies to the other macOS-specific key modifier methods. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 537: > 535: * @return this Builder > 536: */ > 537: public Builder ctrl() { s/ctrl/control/ modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 653: > 651: > 652: /** > 653: * Creates a new {@link KeyBinding} instance. Suggestion: add "from the current settings" after "instance" ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2476565912 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868288678 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868367573 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868276670 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868282333 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868355962 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868345590 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868358133 From kcr at openjdk.org Tue Dec 3 21:32:58 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 21:32:58 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v53] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 16:45:45 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 147: > 145: * @return the KeyBinding > 146: */ > 147: public static KeyBinding ctrl(KeyCode code) { We should spell out `control` in the public API methods and fields, matching `KeyCode`. It's fine to use "CTRL" as an abbreviation in the docs. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 158: > 156: * @return the KeyBinding > 157: */ > 158: public static KeyBinding ctrlShift(KeyCode code) { `ctrlShift` -> `controlShift` for the name of the method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868253408 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868254382 From kcr at openjdk.org Tue Dec 3 21:49:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 21:49:57 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v54] In-Reply-To: <_V-VxKNrumJZf_gQwWSTc1J9VoxAa34ywyWI0SpYQkU=.3073f28f-5932-4bce-b4df-76ed3055a709@github.com> References: <_V-VxKNrumJZf_gQwWSTc1J9VoxAa34ywyWI0SpYQkU=.3073f28f-5932-4bce-b4df-76ed3055a709@github.com> Message-ID: On Tue, 3 Dec 2024 19:08:44 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments One more gradle comment (on your last commit) build.gradle line 4562: > 4560: project(":incubator.input"), > 4561: project(":incubator.richtext"), > 4562: // END: incubator placeholder This part was correct before. Please revert. It should look like this when you are done: // Add an entry for each incubator module here, leaving the incubator // placeholder lines as an example. // BEGIN: incubator placeholder //project(":incubator.mymod"), // END: incubator placeholder project(":incubator.input"), project(":incubator.richtext"), ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2476794771 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1868392896 From angorya at openjdk.org Tue Dec 3 22:11:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 22:11:45 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Tue, 12 Nov 2024 15:08:11 GMT, Martin Fox wrote: >> Input methods don?t work for text controls inside Popups. This PR fixes that. >> >> Some background: >> >> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. >> >> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. >> >> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. >> >> There are several reasons why Input Methods aren?t currently working for Popups. >> >> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. >> >> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. >> >> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. >> >> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. >> >> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha... > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Tweak to satisfy system test. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/InputMethodStateManager.java line 48: > 46: * PopupWindow. > 47: */ > 48: public class InputMethodStateManager { All this feels overly complicated - Why do we need to keep a list of scenes? Can't we get this information indirectly `from Window.getWindows()` ? Since the `PopupWindow` has the `ownerWindowProperty`, could we simply listen to the focusOwner property and get the "root" window and its scene by traversing the hierarchy? Do we really need to maintain derived lists when the InputMethodRequests is only needed during the handling of a specific event? modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 578: > 576: // still monitoring owner events. > 577: Scene scene = getScene(); > 578: SceneHelper.getInputMethodStateManager(scene).removeScene(scene); `Window.scene` is a property, so theoretically the application code can set a new Scene at any moment. How will that be handled? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1868427884 PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1868400092 From angorya at openjdk.org Tue Dec 3 22:17:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 22:17:45 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v6] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:52:57 GMT, Marius Hanl wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of Java... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling looks like there might be a new merge conflict in `NGNode` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2515660044 From kcr at openjdk.org Tue Dec 3 22:53:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 3 Dec 2024 22:53:44 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v7] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 10:43:42 GMT, Lukasz Kostyra wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test for Height > > Good timing with the height test, I was mid-verification, about to suggest adding it :) > > On my end the test does pass on Ubuntu 22.04 with Xorg and with the fix. However, without the fix, the tests still succeed despite the GTK assertions showing up: > > >> gradle --info -PUSE_ROBOT=true -PFULL_TEST=true :systemTests:test --tests StageMixedSizeTest > ... > Successfully started process 'Gradle Test Executor 479' > > > (java:29375): Gtk-CRITICAL **: 11:38:34.936: gtk_window_resize: assertion 'width > 0' failed > > (java:29375): Gtk-CRITICAL **: 11:38:36.596: gtk_window_resize: assertion 'height > 0' failed > Gradle Test Executor 479 finished executing tests. > > > Not having an actually failing test when there's a problem kind of invalidates the reason for tests to exist, these messages will probably be drowned in the sea of log messages. Do you think there is a way to capture those and fail the test (even as a follow-up)? I see the same behavior as @lukostyra -- the current version of the test no longer catches the error. I took a quick look and didn't spot anything. The timeline looks correct; the sleep now looks redundant since you wait for 500ms in the timeline and then again after the latch.await, but that wouldn't cause the test to miss catching the error. Odd. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2515712796 From tsayao at openjdk.org Tue Dec 3 22:59:20 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 3 Dec 2024 22:59:20 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Move it to a Robot test - Fix test to fail without the fix ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/2cffd52e..6433d772 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=06-07 Stats: 250 lines in 2 files changed: 110 ins; 140 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From tsayao at openjdk.org Tue Dec 3 22:59:20 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Tue, 3 Dec 2024 22:59:20 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v7] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 10:27:22 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Add test for Height The problem is that JavaFx has the wrong size, so I moved it to a Robot test to do color checking at the position. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2515719057 From angorya at openjdk.org Tue Dec 3 23:49:21 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 3 Dec 2024 23:49:21 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v55] In-Reply-To: References: Message-ID: <_fpZEbuzjaqvkgsSCYcs_MqhTJjoUKhJAtiZ7-twB0A=.065b3cc0-6a69-4bf3-80e6-9d1e60e1d3d2@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/22fce6a7..7ed4e6ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=54 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=53-54 Stats: 87 lines in 3 files changed: 37 ins; 4 del; 46 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From mstrauss at openjdk.org Wed Dec 4 00:42:14 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Dec 2024 00:42:14 GMT Subject: RFR: 8343398: Add reducedData preference [v2] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: javadoc change ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/0245c2e4..5c2e255f Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From arapte at openjdk.org Wed Dec 4 09:21:49 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 4 Dec 2024 09:21:49 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com> References: <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com> Message-ID: On Fri, 22 Nov 2024 20:55:27 GMT, Kevin Rushforth wrote: > @arapte As I recall, you were looking into VirtualFlow in connection with an a11y at one point. Can you test this? I tested the PR changes with a few a11y scenarios, and did not observe any issues. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2516654454 From john.hendrikx at gmail.com Wed Dec 4 10:29:13 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Wed, 4 Dec 2024 11:29:13 +0100 Subject: Less in FX (was Re: CSS Media Queries) In-Reply-To: References: <0c99141e-14c6-4be8-8297-8faadbfacdf6@gmail.com> Message-ID: <92993282-4b2c-44a8-9424-7ab85f1adbae@gmail.com> That's an interesting approach, however I think?that the readability suffers greatly.? Also, I'd like to give users the opportunity to modify stylesheets in a convenient way (ie. modifying one of the base colors or base fonts) so I package them separately; stylesheets are something that most users understand or can be told to modify in a certain way easily enough. --John On 03/12/2024 17:08, Andy Goryachev wrote: > > My approach is to create a single stylesheet, see for example > > ? > > https://github.com/andy-goryachev/MP3Player/blob/main/src/goryachev/mp3player/Styles.java > > ? > > and this little guy allows to (re-)regenerate and (re-)load the > stylesheet dynamically > > ? > > https://github.com/andy-goryachev/MP3Player/blob/main/src/goryachev/fx/internal/CssLoader.java > > ? > > since the stylesheet is being generated by a java class, I have all > the tools I need - platform preferences, proper color mixing logic, > lookups, and so on.? The only downside is that JavaFX does not allow > programmatic creation of CSS, so the process ends up with overhead of > creating a string, data url encoding, decoding, and parsing. > > ? > > -andy > > ? > > ? > > ? > > *From: *openjfx-dev on behalf of John > Hendrikx > *Date: *Tuesday, December 3, 2024 at 03:17 > *To: *openjfx-dev at openjdk.org > *Subject: *Less in FX (was Re: CSS Media Queries) > > I've been using LESS for ages in combination with FX.?? I adapted this > project: https://github.com/i-net-software/jlessc > > In FX I use it with this helper class: > > https://github.com/hjohn/MediaSystem-v2/blob/master/mediasystem-runner/src/main/java/hs/mediasystem/runner/util/LessLoader.java > > Then to use a stylesheet with a control, you do something like this: > > *final*String CLOCK_STYLES_URL= > LessLoader./compile/(RootNodeFactory.*class*, "clock-pane.less") > > Where "RootNodeFactory.class" is just a reference class as my .less > files are located in the same package as the controls. > > The resulting URL can then simply be set on a control or scene: > > clockPane.getStylesheets().add(CLOCK_STYLES_URL); > > This allows me to use all kinds of handy features from LESS.? Here is > the clock-pane.less file for example: > > @import"hs/mediasystem/runner/properties.less"; > > .clock-pane > > { > > -fx-alignment: bottom-right; > > _-__fx__-__padding_: 5; > > .clock-box > > { > > _-__fx__-__padding_: 515515; > > -fx-alignment: center; > > .clock > > { > > .style-p1-extra-light; > > } > > .date > > { > > .style-p3; > > } > > } > > } > > As you can see, it uses imports, style nesting and references to > groups of other styles (like ".style-p3").? In properties.less we find > many custom variables, like: > > @tinted-glass: fade(@theme-primary, 60%); > > @glass-color: rgba(0, 0, 0, 0.6); > > @shape-disc: "M256 8C119 8 8 119 8 256s111 248 248 248 248-111 > 248-248S393 8 256 8z"; > > @text-primary: lighten(@theme-primary, 5%, relative); > > I'm probably only scratching the surface of what you can do with LESS, > as I'm hardly a CSS designer :) > > The LessLoader class I wrote has one more handy feature; it allows > suffixes on your CSS files to allow for > > customization per platform. I use this to select appropriate fonts per > platform (as their names can > > vary apparently!). See here the Windows file. The Linux variant has > slightly different font family names > > but map to the same LESS variables so I don't need to fix this > everywhere. > > /* > > * The Noto Sans font supports many variations. To get the correct > variation > > * in JavaFX, select them as follows: > > * > > * - Black = Noto Sans Blk > > * - Bold = Noto Sans + font-weight: bold > > * - Semi Bold = Noto Sans SemBd > > * - Medium = Noto Sans Med > > * - Regular = Noto Sans + font-weight: normal > > * - Light = Noto Sans Light > > * > > * Note that these names are for Windows. Other platforms can use > > * slightly different names. > > */ > > .light{ > > _-__fx__-__font-family_: "Noto Sans Light"; > > _-__fx__-__font-weight_: normal; > > } > > .regular{ > > _-__fx__-__font-family_: "Noto Sans"; > > _-__fx__-__font-weight_: normal; > > } > > .medium{ > > _-__fx__-__font-family_: "Noto Sans Med"; > > _-__fx__-__font-weight_: bold; > > } > > .semi-bold{ > > _-__fx__-__font-family_: "Noto Sans SemBd"; > > _-__fx__-__font-weight_: bold; > > } > > .bold{ > > _-__fx__-__font-family_: "Noto Sans"; > > _-__fx__-__font-weight_: bold; > > } > > .black{ > > _-__fx__-__font-family_: "Noto Sans Blk"; > > _-__fx__-__font-weight_: bold; > > } > > --John > > ? > > On 03/12/2024 01:08, Michael Strau? wrote: > > I wish there was a simpler way to introduce variables - I think the variables might be a better solution from the stylesheet maintainability point of view, and to help with supporting light/dark, compact/roomy variants and simple things like updating the base font size.? Doing a different CSS parser is definitely a much larger project than we can afford, probably.? On the other hand, if it enables programmatic creation of style sheets... > > ? > > Custom variables would undoubtedly be a great feature. This is > > orthogonal to media queries, though: at some point, even when using > > custom variables, you have to ask "the medium" about things like the > > color scheme or user preferences. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arapte at openjdk.org Wed Dec 4 12:32:49 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Wed, 4 Dec 2024 12:32:49 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v6] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:52:57 GMT, Marius Hanl wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of Java... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling Looks good, I tested that issue occurs without this patch and get fixed with the patch. Also, I tested several other samples as the fix touches NGNode. Observed no issues at different scale factors. Providing a minor suggestion, I shall re-approve if you choose to make that change. modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3226: > 3224: clipRect.setLayoutY(snappedY); > 3225: } > 3226: The method names sound a little confusing to me. The methods only set the values for clip rect and clip view. The hbar.getValue() represents the x value for the visible content of control. I would recommend to rename these methods to something as, setClipLayoutX or setClipX.. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1462#pullrequestreview-2478438224 PR Review Comment: https://git.openjdk.org/jfx/pull/1462#discussion_r1869402979 From tsayao at openjdk.org Wed Dec 4 13:13:48 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 13:13:48 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: <1RedbzSzEG9FNQdbQPVa7rAyhBFLRqQ4Oae68lcTcwA=.89ebecb0-0015-48ca-828e-74dda8687b57@github.com> On Tue, 3 Dec 2024 22:59:20 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Move it to a Robot test > - Fix test to fail without the fix Updated the explanation of the tests above. "Pre-submit tests" are failing. Is it "my fault"? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2517307323 From kcr at openjdk.org Wed Dec 4 13:19:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 13:19:46 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: <1RedbzSzEG9FNQdbQPVa7rAyhBFLRqQ4Oae68lcTcwA=.89ebecb0-0015-48ca-828e-74dda8687b57@github.com> References: <1RedbzSzEG9FNQdbQPVa7rAyhBFLRqQ4Oae68lcTcwA=.89ebecb0-0015-48ca-828e-74dda8687b57@github.com> Message-ID: On Wed, 4 Dec 2024 13:11:05 GMT, Thiago Milczarek Sayao wrote: > "Pre-submit tests" are failing. Is it "my fault"? No, it looks like a transient glitch of some sort. I was going to suggest that you rerun them, and I see that you did. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2517321494 From tsayao at openjdk.org Wed Dec 4 13:25:47 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 13:25:47 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: <9EZ0B7413m1evd-RCbpAeX1YT7Jex3LTogAJTK3oa4U=.b1ecec9f-9c91-4844-9a84-c68572756f88@github.com> On Tue, 3 Dec 2024 22:59:20 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Move it to a Robot test > - Fix test to fail without the fix I updated the tests to use Robot, using color validation. This ensures that the tests can verify whether the window has correctly shrunk as expected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2517337845 From kcr at openjdk.org Wed Dec 4 13:28:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 13:28:49 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 22:59:20 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Move it to a Robot test > - Fix test to fail without the fix I'll re-test when I get a chance. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2517347355 From lkostyra at openjdk.org Wed Dec 4 14:07:49 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 4 Dec 2024 14:07:49 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 22:59:20 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Move it to a Robot test > - Fix test to fail without the fix Test works well and now it indeed fails when the fix is not there. LGTM ------------- Marked as reviewed by lkostyra (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2478777646 From mfox at openjdk.org Wed Dec 4 14:42:46 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 4 Dec 2024 14:42:46 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Tue, 3 Dec 2024 22:06:48 GMT, Andy Goryachev wrote: >> Martin Fox has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak to satisfy system test. > > modules/javafx.graphics/src/main/java/com/sun/javafx/scene/InputMethodStateManager.java line 48: > >> 46: * PopupWindow. >> 47: */ >> 48: public class InputMethodStateManager { > > All this feels overly complicated - > > Why do we need to keep a list of scenes? Can't we get this information indirectly `from Window.getWindows()` ? > > Since the `PopupWindow` has the `ownerWindowProperty`, could we simply listen to the focusOwner property and get the "root" window and its scene by traversing the hierarchy? Do we really need to maintain derived lists when the InputMethodRequests is only needed during the handling of a specific event? I don't like trying to maintain derived lists either. What you're proposing is an interesting idea but I won't have time to work out the details until next week. > modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 578: > >> 576: // still monitoring owner events. >> 577: Scene scene = getScene(); >> 578: SceneHelper.getInputMethodStateManager(scene).removeScene(scene); > > `Window.scene` is a property, so theoretically the application code can set a new Scene at any moment. How will that be handled? In a PopupWindow the scene there is no API to set the scene. It's managed internally by the system and should not change over the lifetime of the popup window. I will take a second look at that code next week to verify. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1869663328 PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1869663211 From angorya at openjdk.org Wed Dec 4 15:38:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 15:38:55 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Wed, 4 Dec 2024 14:39:52 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 578: >> >>> 576: // still monitoring owner events. >>> 577: Scene scene = getScene(); >>> 578: SceneHelper.getInputMethodStateManager(scene).removeScene(scene); >> >> `Window.scene` is a property, so theoretically the application code can set a new Scene at any moment. How will that be handled? > > In a PopupWindow the scene there is no API to set the scene. It's managed internally by the system and should not change over the lifetime of the popup window. I will take a second look at that code next week to verify. One can extend `PopupWindow` and call the protected `setScene()`, so this is a valid scenario, I think. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1869804903 From mstrauss at openjdk.org Wed Dec 4 15:55:20 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Dec 2024 15:55:20 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: refactor macOS PlatformSupport ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/5c2e255f..8b8b1bdb Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=02 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=01-02 Stats: 229 lines in 4 files changed: 74 ins; 70 del; 85 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Wed Dec 4 16:01:52 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 4 Dec 2024 16:01:52 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 15:55:20 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactor macOS PlatformSupport This PR also includes a small refactor of the GTK and macOS `PlatformSupport` classes. The previous implementations had some parts of the change notification mechanism implemented outside of `PlatformSupport` in their respective `GlassApplication` class. The refactor moves this into `PlatformSupport`, which centralizes all aspects related to platform preference change detection. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2517866653 From andy.goryachev at oracle.com Wed Dec 4 17:19:58 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 4 Dec 2024 17:19:58 +0000 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> Message-ID: I've never seen this... what is the font that causes the issue? -andy From: openjfx-dev on behalf of Christopher Schnick Date: Monday, November 25, 2024 at 02:44 To: openjfx-dev at openjdk.org Subject: Windows default font glyphs are rendered wrong on some systems Hello, for some of our users, the font glyphs of the default Windows font are wrong by an offset of +2. E.g. the letter D is rendered as F, the symbol - is rendered as /, and so on ... However, the glyph spacings and kernings are using the correct values for the original letter, only the actual glyph itself is wrong. This is happening on the latest 24-ea build on Windows 11, but also occurred on version 21 a while ago. I wasn't able to reproduce it myself, only some users were. This has happened now for multiple users of our application, so I figured to report it (Didn't find this in the bug tracker). Here is there issue, next to how it should look like: [cid:part1.1kRBhQ05.RLwnvj8o at xpipe.io] [cid:part2.a5C3DfO5.gpCzH0gk at xpipe.io] (It is in danish because the user played around with the language settings to troubleshoot) There was no explicit -fx-font set, so the application uses the default one. When the users change to using -fx-font: Roboto, which is bundled with our application, the glyphs are rendered normally. So this issue is specific to certain fonts. If there's any additional information required, I can relay that request to our affected users. Best Christopher Schnick (I resent this mail as it got stuck in the moderation queue for being too big due to me accidentally pasting the screenshot as a .bmp) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: s.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: Ls6xRvPGaI1BL10B.png URL: From lkostyra at openjdk.org Wed Dec 4 17:20:00 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Wed, 4 Dec 2024 17:20:00 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Mon, 28 Oct 2024 20:42:44 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Set IBUS_ENABLE_SYNC_MODE=1 > - Revert "Set IBUS_ENABLE_SYNC_MODE=1" > > This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. I think this is almost ready, it's been on my backlog for a while and I'd like to give it one more look and some final testing. @tsayao can you merge latest master? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2518069679 From angorya at openjdk.org Wed Dec 4 17:25:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 17:25:45 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 20:31:08 GMT, Marius Hanl wrote: > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. Tested with the Monkey Tester, both TreeTableView and TableView - looks good, responds to fixed cell size changes. Left a few minor comments. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 323: > 321: > 322: boolean isVisible = true; > 323: if (getFixedCellSize() > 0) { `getFixedCellSize()` is getting called four times, also inside the `for` loop. I'd suggest to add double fixedCellSize = getFixedCellSize(); before L318 (outside of the for loop) and use the local variable instead. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 432: > 430: } > 431: > 432: double getFixedCellSize() { should this method be `abstract`? ------------- PR Review: https://git.openjdk.org/jfx/pull/1645#pullrequestreview-2479255931 PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1869884280 PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1869886562 From crschnick at xpipe.io Wed Dec 4 17:26:37 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Wed, 4 Dec 2024 18:26:37 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> Message-ID: This is the default Windows font. If you compare the glyphs between both images, they are the same. They are just rendered for the wrong characters somehow. Or more formally, this is the font that is used by JavaFX on Windows if no -fx-font is set. I'm not sure what causes this issue on some Windows systems, but it happened for multiple users. For most others it's fine. On 04/12/2024 18:19, Andy Goryachev wrote: > > I've never seen this...? what is the font that causes the issue? > > -andy > > *From: *openjfx-dev on behalf of > Christopher Schnick > *Date: *Monday, November 25, 2024 at 02:44 > *To: *openjfx-dev at openjdk.org > *Subject: *Windows default font glyphs are rendered wrong on some systems > > Hello, > > for some of our users, the font glyphs of the default Windows font are > wrong by an offset of +2. E.g. the letter D is rendered as F, the > symbol - is rendered as /, and so on ... However, the glyph spacings > and kernings are using the correct values for the original letter, > only the actual glyph itself is wrong. This is happening on the latest > 24-ea build on Windows 11, but also occurred on version 21 a while > ago. I wasn't able to reproduce it myself, only some users were. > > This has happened now for multiple users of our application, so I > figured to report it (Didn't find this in the bug tracker). > > Here is there issue, next to how it should look like: > > (It is in danish because the user played around with the language > settings to troubleshoot) > > There was no explicit -fx-font set, so the application uses the > default one. When the users change to using -fx-font: Roboto, which is > bundled with our application, the glyphs are rendered normally. So > this issue is specific to certain fonts. > > If there's any additional information required, I can relay that > request to our affected users. > > > Best > Christopher Schnick > > (I resent this mail as it got stuck in the moderation queue for being > too big due to me accidentally pasting the screenshot as a .bmp) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From andy.goryachev at oracle.com Wed Dec 4 17:37:09 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Wed, 4 Dec 2024 17:37:09 +0000 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> Message-ID: I might suggest trying to run some other JavaFX application using the same setup. Or better yet, if you can come up with a short reproducer, please file a bug. Thanks! -andy From: openjfx-dev on behalf of Andy Goryachev Date: Wednesday, December 4, 2024 at 09:20 To: Christopher Schnick , openjfx-dev at openjdk.org Subject: Re: Windows default font glyphs are rendered wrong on some systems I've never seen this... what is the font that causes the issue? -andy From: openjfx-dev on behalf of Christopher Schnick Date: Monday, November 25, 2024 at 02:44 To: openjfx-dev at openjdk.org Subject: Windows default font glyphs are rendered wrong on some systems Hello, for some of our users, the font glyphs of the default Windows font are wrong by an offset of +2. E.g. the letter D is rendered as F, the symbol - is rendered as /, and so on ... However, the glyph spacings and kernings are using the correct values for the original letter, only the actual glyph itself is wrong. This is happening on the latest 24-ea build on Windows 11, but also occurred on version 21 a while ago. I wasn't able to reproduce it myself, only some users were. This has happened now for multiple users of our application, so I figured to report it (Didn't find this in the bug tracker). Here is there issue, next to how it should look like: [cid:part1.1kRBhQ05.RLwnvj8o at xpipe.io] [cid:part2.a5C3DfO5.gpCzH0gk at xpipe.io] (It is in danish because the user played around with the language settings to troubleshoot) There was no explicit -fx-font set, so the application uses the default one. When the users change to using -fx-font: Roboto, which is bundled with our application, the glyphs are rendered normally. So this issue is specific to certain fonts. If there's any additional information required, I can relay that request to our affected users. Best Christopher Schnick (I resent this mail as it got stuck in the moderation queue for being too big due to me accidentally pasting the screenshot as a .bmp) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: s.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: Ls6xRvPGaI1BL10B.png URL: From crschnick at xpipe.io Wed Dec 4 17:43:02 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Wed, 4 Dec 2024 18:43:02 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> Message-ID: <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> I'm not able to reproduce it, but some of my users are. If anyone who knows the font renderer maybe wants additional information or has some ideas on what the users can try to either fix or diagnose the root cause, I can relay that request to them. I can ask them to try other JavaFX applications, but either way how that goes, it doesn't show the cause. On 04/12/2024 18:37, Andy Goryachev wrote: > > I might suggest trying to run some other JavaFX application using the > same setup.? Or better yet, if you can come up with a short > reproducer, please file a bug. > > Thanks! > > -andy > > *From: *openjfx-dev on behalf of Andy > Goryachev > *Date: *Wednesday, December 4, 2024 at 09:20 > *To: *Christopher Schnick , > openjfx-dev at openjdk.org > *Subject: *Re: Windows default font glyphs are rendered wrong on some > systems > > I've never seen this...? what is the font that causes the issue? > > -andy > > *From: *openjfx-dev on behalf of > Christopher Schnick > *Date: *Monday, November 25, 2024 at 02:44 > *To: *openjfx-dev at openjdk.org > *Subject: *Windows default font glyphs are rendered wrong on some systems > > Hello, > > for some of our users, the font glyphs of the default Windows font are > wrong by an offset of +2. E.g. the letter D is rendered as F, the > symbol - is rendered as /, and so on ... However, the glyph spacings > and kernings are using the correct values for the original letter, > only the actual glyph itself is wrong. This is happening on the latest > 24-ea build on Windows 11, but also occurred on version 21 a while > ago. I wasn't able to reproduce it myself, only some users were. > > This has happened now for multiple users of our application, so I > figured to report it (Didn't find this in the bug tracker). > > Here is there issue, next to how it should look like: > > (It is in danish because the user played around with the language > settings to troubleshoot) > > There was no explicit -fx-font set, so the application uses the > default one. When the users change to using -fx-font: Roboto, which is > bundled with our application, the glyphs are rendered normally. So > this issue is specific to certain fonts. > > If there's any additional information required, I can relay that > request to our affected users. > > > Best > Christopher Schnick > > (I resent this mail as it got stuck in the moderation queue for being > too big due to me accidentally pasting the screenshot as a .bmp) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From kcr at openjdk.org Wed Dec 4 18:17:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 18:17:45 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Wed, 4 Dec 2024 15:36:00 GMT, Andy Goryachev wrote: >> In a PopupWindow the scene there is no API to set the scene. It's managed internally by the system and should not change over the lifetime of the popup window. I will take a second look at that code next week to verify. > > One can extend `PopupWindow` and call the protected `setScene()`, so this is a valid scenario, I think. PopupWindow already specifies that subclasses should not do this: Note to subclasses: the scene used by PopupWindow is very specifically managed by PopupWindow. This method is overridden to throw UnsupportedOperationException. You cannot specify your own scene. So no, it is not a valid use case. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1870055363 From kcr at openjdk.org Wed Dec 4 18:34:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 18:34:44 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Wed, 4 Dec 2024 18:14:58 GMT, Kevin Rushforth wrote: >> One can extend `PopupWindow` and call the protected `setScene()`, so this is a valid scenario, I think. > > PopupWindow already specifies that subclasses should not do this: > > > Note to subclasses: the scene used by PopupWindow is very specifically managed by PopupWindow. This method is overridden to throw UnsupportedOperationException. You cannot specify your own scene. > > > So no, it is not a valid use case. More to the point, the `setScene` method is final in `PopupWindow` and will unconditionally throw `UnsupportedOperationException` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1870085558 From angorya at openjdk.org Wed Dec 4 18:57:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 18:57:18 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction there seems to be a merge conflict, please sync up with the latest `master` branch. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2518276629 From tsayao at openjdk.org Wed Dec 4 20:11:08 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 20:11:08 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: Message-ID: > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits: - Merge branch 'master' into new_ime - Set IBUS_ENABLE_SYNC_MODE=1 - Revert "Set IBUS_ENABLE_SYNC_MODE=1" This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. - Set IBUS_ENABLE_SYNC_MODE=1 - Merge branch 'master' into new_ime - Merge branch 'master' into new_ime - Revert "Fix for Polish AltGR combinations" This reverts commit 78e27e9deba2eda96b86186692da4f8dc2a3a1ff. - Revert "Fix the case when IME filters key_press (Polish ALT Gr + C)" This reverts commit 112ed6f4306a42378255c858306f9625ea2b5fa8. - Revert "Remove idea file" This reverts commit e56588baad42c07a5b872d27603a97e06be97649. - Remove idea file - ... and 104 more: https://git.openjdk.org/jfx/compare/67eed6d8...16b3eebe ------------- Changes: https://git.openjdk.org/jfx/pull/1080/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=30 Stats: 454 lines in 7 files changed: 68 ins; 269 del; 117 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Wed Dec 4 20:11:09 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 20:11:09 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Mon, 28 Oct 2024 20:42:44 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Set IBUS_ENABLE_SYNC_MODE=1 > - Revert "Set IBUS_ENABLE_SYNC_MODE=1" > > This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. Done (merged master) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2518458790 From angorya at openjdk.org Wed Dec 4 20:15:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 20:15:48 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Testing on macOS 14.7.1 with the latest Monkey Tester (where I've added 200 columns case for Tree/TableView, https://github.com/andy-goryachev-oracle/MonkeyTest ) looks good. It feels like the horizontal scrolling has improved a bit, the vertical exhibits the same slight hiccups as with the master branch. modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 141: > 139: fixedCellSizeEnabled = fixedCellSize > 0.0; > 140: > 141: if (fixedCellSizeEnabled) { is this PR going to clash with #1645 ? modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 228: > 226: if (disclosureNodeDirty) { > 227: updateDisclosureNodeAndGraphic(); > 228: disclosureNodeDirty = false; shouldn't `disclosureNodeDirty = false;` be moved to `updateDisclosureNodeAndGraphic();` ? here and in L257, L216 ------------- PR Review: https://git.openjdk.org/jfx/pull/1644#pullrequestreview-2479780396 PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1870205287 PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1870209024 From angorya at openjdk.org Wed Dec 4 20:19:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 20:19:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction I've got an exception on the TreeTableView page in the monkey tester after clicking a cell and then pressing control+command+RIGHT_ARROW with the VoiceOver on: Exception in thread "JavaFX Application Thread" java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 1 at javafx.graphics/com.sun.glass.ui.mac.MacAccessible.accessibilityArrayAttributeValues(MacAccessible.java:1135) settings: ![Screenshot 2024-12-04 at 12 16 18](https://github.com/user-attachments/assets/32fff886-73e0-47d1-922d-6866bf440035) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2518474630 From kcr at openjdk.org Wed Dec 4 20:54:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 20:54:51 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: On Tue, 3 Dec 2024 22:59:20 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: > > - Move it to a Robot test > - Fix test to fail without the fix The updated test looks good. It is stable on both my systems and it reliably catches the error. I left a couple minor suggestions and will reapprove if you decide to make changes. tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 61: > 59: final int finalWidth = 200; > 60: > 61: setupContentSizeTestStage(300, 300, Minor: consider using a final variable for the initial size tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 67: > 65: assertTrue(latch.await(TIMEOUT, TimeUnit.MILLISECONDS), "Timeout waiting for test stage to be shown"); > 66: > 67: runAndWait(() -> assertColorDoesNotEqual(BACKGROUND_COLOR, getColor(290, 100), TOLERANCE)); Minor: consider deriving the x pos as initial size - 10 tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 102: > 100: } > 101: > 102: Minor: extra blank line can be removed ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2479738509 PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870179525 PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870181283 PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870209730 From kcr at openjdk.org Wed Dec 4 21:09:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 21:09:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: <7Ej3i-xKzUDa7U27TJDTPtOMZCEQ9v_5VmFaDEe03X8=.fad7a49b-048e-4d91-a251-f17c413be3d1@github.com> On Wed, 4 Dec 2024 20:16:45 GMT, Andy Goryachev wrote: > I've got an exception on the TreeTableView page in the monkey tester after clicking a cell and then pressing control+command+RIGHT_ARROW with the VoiceOver on: Is this reproducible? Does it happen without this fix? If this is a regression then it needs to be fixed. UPDATE: nm, I just read Andy's updated comment. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2518562139 From tsayao at openjdk.org Wed Dec 4 21:10:24 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 21:10:24 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v9] In-Reply-To: References: Message-ID: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: Address minor review observations ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1654/files - new: https://git.openjdk.org/jfx/pull/1654/files/6433d772..4902430e Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1654&range=07-08 Stats: 9 lines in 1 file changed: 4 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1654.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1654/head:pull/1654 PR: https://git.openjdk.org/jfx/pull/1654 From tsayao at openjdk.org Wed Dec 4 21:10:24 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Wed, 4 Dec 2024 21:10:24 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 19:39:33 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Move it to a Robot test >> - Fix test to fail without the fix > > tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 61: > >> 59: final int finalWidth = 200; >> 60: >> 61: setupContentSizeTestStage(300, 300, > > Minor: consider using a final variable for the initial size Done. > tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 67: > >> 65: assertTrue(latch.await(TIMEOUT, TimeUnit.MILLISECONDS), "Timeout waiting for test stage to be shown"); >> 66: >> 67: runAndWait(() -> assertColorDoesNotEqual(BACKGROUND_COLOR, getColor(290, 100), TOLERANCE)); > > Minor: consider deriving the x pos as initial size - 10 Done. > tests/system/src/test/java/test/robot/javafx/stage/StageMixedSizeTest.java line 102: > >> 100: } >> 101: >> 102: > > Minor: extra blank line can be removed Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870280844 PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870280681 PR Review Comment: https://git.openjdk.org/jfx/pull/1654#discussion_r1870280481 From kcr at openjdk.org Wed Dec 4 21:25:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 4 Dec 2024 21:25:47 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v9] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 21:10:24 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Address minor review observations Looks good. Since this is a very minor change, I am lowering the re-review requirement to 1. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2479933724 From angorya at openjdk.org Wed Dec 4 21:30:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 21:30:42 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: <5iIiOR2JxEk__7iGLh46DcPpa-Pd6Z9D6cacDPdp3yc=.3b9ed4ef-80ee-468d-9607-ddc5d97bc9ea@github.com> On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Created [JDK-8235989](https://bugs.openjdk.org/browse/JDK-8345536) for the a11y exception issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2518597833 From angorya at openjdk.org Wed Dec 4 23:18:11 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 4 Dec 2024 23:18:11 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v12] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 24 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: > > > /** > * Returns the shape for the strike-through in local coordinates. > * > * @param start the beginning character index for the range > * @param end the end character index (non-inclusive) for the range > * @return an array of {@code PathElement} which can be used to create a {@code Shape} > * @since 24 > */ > public final PathElement[] strikeThroughShape(int start, int end) > > > ## Discussion Points > > - it is unclear whether CaretInfo.getPartAt() should return a simple Rectangle2D or a more complex object similar to TextLineInfo, to be able to add more information, such as the nature of text, text direction, etc. > > > ## WARNING > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/Rich... Andy Goryachev 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 35 additional commits since the last revision: - Merge branch 'master' into ag.text.layout.api - segments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - coordinates - note - text layout test - text flow test - shorter array - line spacing - ... and 25 more: https://git.openjdk.org/jfx/compare/e3998333...1dd2b0cf ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/944bd0d3..1dd2b0cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=10-11 Stats: 2308 lines in 401 files changed: 760 ins; 433 del; 1115 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From duke at openjdk.org Thu Dec 5 04:08:52 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 5 Dec 2024 04:08:52 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v30] In-Reply-To: References: <4hmX9q5qKJqYc_G3cwyTAU9yosiRwzGHNPBaAiB9jIU=.aea8ad64-0ce2-409c-8352-43bc37af7448@github.com> Message-ID: On Wed, 4 Dec 2024 20:07:57 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Revert "Set IBUS_ENABLE_SYNC_MODE=1" >> >> This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > > Done (merged master) Hi @tsayao , Thanks for the patch about CJK IME. This is amazing! I compiled the branch: [tasyao/new_ime](https://github.com/tsayao/jfx/tree/new_ime), and used it for some tests. 1. used under `ibus`: it's worked well! 2. used under `fcitx`: it's actived, but the content was not able to input into `TextField`. [Screencast from 2024-12-05 12-03-13.webm](https://github.com/user-attachments/assets/b696fa64-8f5b-41f4-8985-685f977c824b) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1080#issuecomment-2519042497 From duke at openjdk.org Thu Dec 5 07:14:54 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 5 Dec 2024 07:14:54 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: Message-ID: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> On Wed, 4 Dec 2024 20:11:08 GMT, Thiago Milczarek Sayao wrote: >> This replaces obsolete XIM and uses gtk api for IME. >> Gtk uses [ibus](https://github.com/ibus/ibus) >> >> Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. >> >> [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) > > Thiago Milczarek Sayao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits: > > - Merge branch 'master' into new_ime > - Set IBUS_ENABLE_SYNC_MODE=1 > - Revert "Set IBUS_ENABLE_SYNC_MODE=1" > > This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. > - Set IBUS_ENABLE_SYNC_MODE=1 > - Merge branch 'master' into new_ime > - Merge branch 'master' into new_ime > - Revert "Fix for Polish AltGR combinations" > > This reverts commit 78e27e9deba2eda96b86186692da4f8dc2a3a1ff. > - Revert "Fix the case when IME filters key_press (Polish ALT Gr + C)" > > This reverts commit 112ed6f4306a42378255c858306f9625ea2b5fa8. > - Revert "Remove idea file" > > This reverts commit e56588baad42c07a5b872d27603a97e06be97649. > - Remove idea file > - ... and 104 more: https://git.openjdk.org/jfx/compare/67eed6d8...16b3eebe modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 100: > 98: > 99: void WindowContextBase::commitIME(gchar *str) { > 100: if (im_ctx.on_preedit) { Though `LOG0`/`LOG1`, I found that the value of `im_ctx.on_preedit` is `false` under `fcitx`. I removed this check, then tested under `fcitx` and `ibus`. All passed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1870775997 From lkostyra at openjdk.org Thu Dec 5 07:46:46 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Thu, 5 Dec 2024 07:46:46 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v9] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 21:10:24 GMT, Thiago Milczarek Sayao wrote: >> The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. >> >> The fix just uses the previous value for width/height if not set. >> >> The test class is designed to accept more test cases in the "mixed sizing" scenarios. > > Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision: > > Address minor review observations Marked as reviewed by lkostyra (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1654#pullrequestreview-2480800084 From mhanl at openjdk.org Thu Dec 5 09:21:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:21:45 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup In-Reply-To: References: Message-ID: <63IgvryK_8LPn8Gr9drG_QKe8k5JgsdX3wrSVU_D4EQ=.b02c8de3-1428-4243-994f-7f8ab1787fc6@github.com> On Wed, 4 Dec 2024 16:20:48 GMT, Andy Goryachev wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 323: > >> 321: >> 322: boolean isVisible = true; >> 323: if (getFixedCellSize() > 0) { > > `getFixedCellSize()` is getting called four times, also inside the `for` loop. > I'd suggest to add > > double fixedCellSize = getFixedCellSize(); > > before L318 (outside of the for loop) and use the local variable instead. Sure, can do that. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1870972167 From mhanl at openjdk.org Thu Dec 5 09:24:47 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:24:47 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 16:22:18 GMT, Andy Goryachev wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 432: > >> 430: } >> 431: >> 432: double getFixedCellSize() { > > should this method be `abstract`? We can do that, but then it should be `protected` as well, so custom code that extends from `TableRowSkinBase` can override this. If it is package private, custom code can not. This will require a CSR hovever, so I think it is better as a follow up (there might be some more occurrences that should be `protected abstract` in this class) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1870977422 From mhanl at openjdk.org Thu Dec 5 09:26:47 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:26:47 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> References: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> Message-ID: On Wed, 4 Dec 2024 19:59:37 GMT, Andy Goryachev wrote: >> Marius Hanl 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: >> >> 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 141: > >> 139: fixedCellSizeEnabled = fixedCellSize > 0.0; >> 140: >> 141: if (fixedCellSizeEnabled) { > > is this PR going to clash with #1645 ? Not clash, but there will be merge conflicts that are easy to solve > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 228: > >> 226: if (disclosureNodeDirty) { >> 227: updateDisclosureNodeAndGraphic(); >> 228: disclosureNodeDirty = false; > > shouldn't `disclosureNodeDirty = false;` be moved to `updateDisclosureNodeAndGraphic();` ? > here and in L257, L216 Could be an idea. I will check. I just tried to not make to many changes, but this might be an easy one. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1870979053 PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1870979872 From mhanl at openjdk.org Thu Dec 5 09:32:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:32:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> References: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> Message-ID: On Wed, 4 Dec 2024 20:13:31 GMT, Andy Goryachev wrote: > It feels like the horizontal scrolling has improved a bit, the vertical exhibits the same slight hiccups as with the master branch. Yes, especially if you try with many columns (> 100), scrolling up and down is much faster (especially when scrolled completely to the left). When you scroll completely to the right, it is just a little bit faster than master. I have also some ideas how to improve vertial scrolling with many items, but for another day. :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2519738904 From mhanl at openjdk.org Thu Dec 5 09:32:46 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:32:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: <9Dw8kFdPvsTfltoqaeDWUlahLz8rTXxVCaTqWnCd3c4=.62a6624e-9553-4891-b859-bb899156cef1@github.com> Message-ID: On Wed, 4 Dec 2024 09:18:41 GMT, Ambarish Rapte wrote: > I tested the PR changes with a few a11y scenarios, and did not observe any issues. Thank you for testing! Out of interesting, is it 'enough' to test with the `Narrator` application on Windows 11? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2519743269 From mhanl at openjdk.org Thu Dec 5 09:33:48 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 5 Dec 2024 09:33:48 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v6] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 12:27:54 GMT, Ambarish Rapte wrote: >> Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java >> # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix >> >> # Conflicts: >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java >> # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix >> >> # Conflicts: >> # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java >> - Improve test >> - 8218745: TableView: visual glitch at borders on horizontal scrolling > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3226: > >> 3224: clipRect.setLayoutY(snappedY); >> 3225: } >> 3226: > > The method names sound a little confusing to me. The methods only set the values for clip rect and clip view. > The hbar.getValue() represents the x value for the visible content of control. > I would recommend to rename these methods to something as, setClipLayoutX or setClipX.. I chose this name to be consistent with the `ScrollPaneSkin`, but I agree that this is not the best name. `setClipLayoutX` sounds good to me, will change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1462#discussion_r1870992107 From thiago.sayao at gmail.com Thu Dec 5 12:23:13 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 5 Dec 2024 09:23:13 -0300 Subject: MonkeyTester suggestion Message-ID: Hi, Pardon me if this suggestion is already there and I somehow missed it. It would be nice to have a "Window Operations" testing, including: - Opening a window in different states (Minimized, Maximized, FullScreen); - Changing the states after the window was opened; - Window/View with minimum and maximum size; - Setting the window position (before and after showing); - Modal / Application Modal; - Having a window that can be opened by view size, or setting the window size; - Having a window that can change sizes; - Test sizeToScene(); - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) - Owner / no Owner - Open Dialogs / Alerts I would also clean up the old manual tests and concentrate on this tool, which is nice. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Thu Dec 5 14:08:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 5 Dec 2024 14:08:52 GMT Subject: RFR: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' [v8] In-Reply-To: <9EZ0B7413m1evd-RCbpAeX1YT7Jex3LTogAJTK3oa4U=.b1ecec9f-9c91-4844-9a84-c68572756f88@github.com> References: <9EZ0B7413m1evd-RCbpAeX1YT7Jex3LTogAJTK3oa4U=.b1ecec9f-9c91-4844-9a84-c68572756f88@github.com> Message-ID: On Wed, 4 Dec 2024 13:23:25 GMT, Thiago Milczarek Sayao wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: >> >> - Move it to a Robot test >> - Fix test to fail without the fix > > I updated the tests to use Robot, using color validation. This ensures that the tests can verify whether the window has correctly shrunk as expected. @tsayao This is ready to integrate when you are ready. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1654#issuecomment-2520420028 From tsayao at openjdk.org Thu Dec 5 14:29:49 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Thu, 5 Dec 2024 14:29:49 GMT Subject: Integrated: 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' In-Reply-To: References: Message-ID: On Sat, 30 Nov 2024 14:56:44 GMT, Thiago Milczarek Sayao wrote: > The bug happened when setting only width or height (not both) on a Stage that was oriented by the view size. > > The fix just uses the previous value for width/height if not set. > > The test class is designed to accept more test cases in the "mixed sizing" scenarios. This pull request has now been integrated. Changeset: a431801c Author: Thiago Milczarek Sayao URL: https://git.openjdk.org/jfx/commit/a431801c3d1d76f03c54f7f3451eac4fa8024e8b Stats: 118 lines in 2 files changed: 118 ins; 0 del; 0 mod 8344372: Setting width for TRANSPARENT Stage -> gtk_window_resize: assertion 'height > 0' Reviewed-by: kcr, lkostyra ------------- PR: https://git.openjdk.org/jfx/pull/1654 From andy.goryachev at oracle.com Thu Dec 5 15:22:40 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 5 Dec 2024 15:22:40 +0000 Subject: MonkeyTester suggestion In-Reply-To: References: Message-ID: Thank you for suggestions, Thiago. That should be easy enough. -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Thursday, December 5, 2024 at 04:23 To: openjfx-dev Subject: MonkeyTester suggestion Hi, Pardon me if this suggestion is already there and I somehow missed it. It would be nice to have a "Window Operations" testing, including: - Opening a window in different states (Minimized, Maximized, FullScreen); - Changing the states after the window was opened; - Window/View with minimum and maximum size; - Setting the window position (before and after showing); - Modal / Application Modal; - Having a window that can be opened by view size, or setting the window size; - Having a window that can change sizes; - Test sizeToScene(); - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) - Owner / no Owner - Open Dialogs / Alerts I would also clean up the old manual tests and concentrate on this tool, which is nice. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Dec 5 15:34:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Dec 2024 15:34:48 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:45:36 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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: > > 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction By the way, a Tree/TableView with 500 columns is barely usable - locks up the UI giving me a macOS spinning beach ball quite often. Not that it's a reasonable use case. 200 is ok. May be the 500 case can be used for profiling? Speaking of the vertical scrolling - I could not use the idea implemented by the VirtualFlow in the RichTextArea as it won't work in the case of very large models. So instead it uses approximation, see https://github.com/openjdk/jfx/blob/7ed4e6ed1c20e9b32766c987b465a7c24dd0c8ad/modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/VFlow.java#L665 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2520640684 From angorya at openjdk.org Thu Dec 5 15:37:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Dec 2024 15:37:46 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup In-Reply-To: References: Message-ID: <52_9PQjrkkM5Pgp9lKqVM2j_A60V5YqxKjV5lBUqvpY=.dfa6875f-5fca-4c1d-a49b-b8a6caee13de@github.com> On Thu, 5 Dec 2024 09:22:34 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 432: >> >>> 430: } >>> 431: >>> 432: double getFixedCellSize() { >> >> should this method be `abstract`? > > We can do that, but then it should be `protected` as well, so custom code that extends from `TableRowSkinBase` can override this. If it is package private, custom code can not. > > This will require a CSR hovever, so I think it is better as a follow up (there might be some more occurrences that should be `protected abstract` in this class) good point. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1871602450 From andy.goryachev at oracle.com Thu Dec 5 20:02:32 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 5 Dec 2024 20:02:32 +0000 Subject: MonkeyTester suggestion In-Reply-To: References: Message-ID: I've added a StagePage for now, available in the dev repo https://github.com/andy-goryachev-oracle/MonkeyTest . Observed a couple of issues: - could not get TRANSPARENT stage to actually be transparent on macOS - UTILITY stage gets opened with maximized bit set Let me know what you think. -andy From: openjfx-dev on behalf of Thiago Milczarek Say?o Date: Thursday, December 5, 2024 at 04:23 To: openjfx-dev Subject: MonkeyTester suggestion Hi, Pardon me if this suggestion is already there and I somehow missed it. It would be nice to have a "Window Operations" testing, including: - Opening a window in different states (Minimized, Maximized, FullScreen); - Changing the states after the window was opened; - Window/View with minimum and maximum size; - Setting the window position (before and after showing); - Modal / Application Modal; - Having a window that can be opened by view size, or setting the window size; - Having a window that can change sizes; - Test sizeToScene(); - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) - Owner / no Owner - Open Dialogs / Alerts I would also clean up the old manual tests and concentrate on this tool, which is nice. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Thu Dec 5 20:24:51 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 5 Dec 2024 17:24:51 -0300 Subject: MonkeyTester suggestion In-Reply-To: References: Message-ID: Thanks for the addition. It?s great for testing. I usually end up with a /tmp folder full of testing samples. It?d be awesome to have a test menu in the opened window, where you could tweak things like resizing or adjusting content size, call sizeToScene(). No rush, though?just a thought for making it even handier! Em qui., 5 de dez. de 2024 ?s 17:02, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > I've added a StagePage for now, available in the dev repo > https://github.com/andy-goryachev-oracle/MonkeyTest . > > > > Observed a couple of issues: > > - could not get TRANSPARENT stage to actually be transparent on macOS > > - UTILITY stage gets opened with maximized bit set > > > > Let me know what you think. > > > > -andy > > > > *From: *openjfx-dev on behalf of Thiago > Milczarek Say?o > *Date: *Thursday, December 5, 2024 at 04:23 > *To: *openjfx-dev > *Subject: *MonkeyTester suggestion > > Hi, > > > > Pardon me if this suggestion is already there and I somehow missed it. > > > > It would be nice to have a "Window Operations" testing, including: > > > > - Opening a window in different states (Minimized, Maximized, FullScreen); > > - Changing the states after the window was opened; > > - Window/View with minimum and maximum size; > > - Setting the window position (before and after showing); > > - Modal / Application Modal; > > - Having a window that can be opened by view size, or setting the window > size; > > - Having a window that can change sizes; > > - Test sizeToScene(); > > - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) > > - Owner / no Owner > > - Open Dialogs / Alerts > > > > I would also clean up the old manual tests and concentrate on this tool, > which is nice. > > > > -- Thiago. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Dec 5 20:27:16 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 5 Dec 2024 20:27:16 +0000 Subject: [External] : Re: MonkeyTester suggestion In-Reply-To: References: Message-ID: right click on the stage content gives you some options. -andy From: Thiago Milczarek Say?o Date: Thursday, December 5, 2024 at 12:25 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: MonkeyTester suggestion Thanks for the addition. It?s great for testing. I usually end up with a /tmp folder full of testing samples. It?d be awesome to have a test menu in the opened window, where you could tweak things like resizing or adjusting content size, call sizeToScene(). No rush, though?just a thought for making it even handier! Em qui., 5 de dez. de 2024 ?s 17:02, Andy Goryachev > escreveu: I've added a StagePage for now, available in the dev repo https://github.com/andy-goryachev-oracle/MonkeyTest . Observed a couple of issues: - could not get TRANSPARENT stage to actually be transparent on macOS - UTILITY stage gets opened with maximized bit set Let me know what you think. -andy From: openjfx-dev > on behalf of Thiago Milczarek Say?o > Date: Thursday, December 5, 2024 at 04:23 To: openjfx-dev > Subject: MonkeyTester suggestion Hi, Pardon me if this suggestion is already there and I somehow missed it. It would be nice to have a "Window Operations" testing, including: - Opening a window in different states (Minimized, Maximized, FullScreen); - Changing the states after the window was opened; - Window/View with minimum and maximum size; - Setting the window position (before and after showing); - Modal / Application Modal; - Having a window that can be opened by view size, or setting the window size; - Having a window that can change sizes; - Test sizeToScene(); - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) - Owner / no Owner - Open Dialogs / Alerts I would also clean up the old manual tests and concentrate on this tool, which is nice. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.sayao at gmail.com Thu Dec 5 20:30:59 2024 From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=) Date: Thu, 5 Dec 2024 17:30:59 -0300 Subject: [External] : Re: MonkeyTester suggestion In-Reply-To: References: Message-ID: missed that, sorry :) Em qui., 5 de dez. de 2024 ?s 17:27, Andy Goryachev < andy.goryachev at oracle.com> escreveu: > right click on the stage content gives you some options. > > > > -andy > > > > > > > > *From: *Thiago Milczarek Say?o > *Date: *Thursday, December 5, 2024 at 12:25 > *To: *Andy Goryachev > *Cc: *openjfx-dev > *Subject: *[External] : Re: MonkeyTester suggestion > > Thanks for the addition. It?s great for testing. > > I usually end up with a /tmp folder full of testing samples. > > It?d be awesome to have a test menu in the opened window, where you could > tweak things like resizing or adjusting content size, call sizeToScene(). > > No rush, though?just a thought for making it even handier! > > > > Em qui., 5 de dez. de 2024 ?s 17:02, Andy Goryachev < > andy.goryachev at oracle.com> escreveu: > > I've added a StagePage for now, available in the dev repo > https://github.com/andy-goryachev-oracle/MonkeyTest > > . > > > > Observed a couple of issues: > > - could not get TRANSPARENT stage to actually be transparent on macOS > > - UTILITY stage gets opened with maximized bit set > > > > Let me know what you think. > > > > -andy > > > > *From: *openjfx-dev on behalf of Thiago > Milczarek Say?o > *Date: *Thursday, December 5, 2024 at 04:23 > *To: *openjfx-dev > *Subject: *MonkeyTester suggestion > > Hi, > > > > Pardon me if this suggestion is already there and I somehow missed it. > > > > It would be nice to have a "Window Operations" testing, including: > > > > - Opening a window in different states (Minimized, Maximized, FullScreen); > > - Changing the states after the window was opened; > > - Window/View with minimum and maximum size; > > - Setting the window position (before and after showing); > > - Modal / Application Modal; > > - Having a window that can be opened by view size, or setting the window > size; > > - Having a window that can change sizes; > > - Test sizeToScene(); > > - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) > > - Owner / no Owner > > - Open Dialogs / Alerts > > > > I would also clean up the old manual tests and concentrate on this tool, > which is nice. > > > > -- Thiago. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.goryachev at oracle.com Thu Dec 5 20:34:05 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Thu, 5 Dec 2024 20:34:05 +0000 Subject: [External] : Re: MonkeyTester suggestion In-Reply-To: References: Message-ID: Discoverability was not a priority. If it was difficult to write a program, it should be difficult to use it /jk. -andy From: Thiago Milczarek Say?o Date: Thursday, December 5, 2024 at 12:31 To: Andy Goryachev Cc: openjfx-dev Subject: Re: [External] : Re: MonkeyTester suggestion missed that, sorry :) Em qui., 5 de dez. de 2024 ?s 17:27, Andy Goryachev > escreveu: right click on the stage content gives you some options. -andy From: Thiago Milczarek Say?o > Date: Thursday, December 5, 2024 at 12:25 To: Andy Goryachev > Cc: openjfx-dev > Subject: [External] : Re: MonkeyTester suggestion Thanks for the addition. It?s great for testing. I usually end up with a /tmp folder full of testing samples. It?d be awesome to have a test menu in the opened window, where you could tweak things like resizing or adjusting content size, call sizeToScene(). No rush, though?just a thought for making it even handier! Em qui., 5 de dez. de 2024 ?s 17:02, Andy Goryachev > escreveu: I've added a StagePage for now, available in the dev repo https://github.com/andy-goryachev-oracle/MonkeyTest . Observed a couple of issues: - could not get TRANSPARENT stage to actually be transparent on macOS - UTILITY stage gets opened with maximized bit set Let me know what you think. -andy From: openjfx-dev > on behalf of Thiago Milczarek Say?o > Date: Thursday, December 5, 2024 at 04:23 To: openjfx-dev > Subject: MonkeyTester suggestion Hi, Pardon me if this suggestion is already there and I somehow missed it. It would be nice to have a "Window Operations" testing, including: - Opening a window in different states (Minimized, Maximized, FullScreen); - Changing the states after the window was opened; - Window/View with minimum and maximum size; - Setting the window position (before and after showing); - Modal / Application Modal; - Having a window that can be opened by view size, or setting the window size; - Having a window that can change sizes; - Test sizeToScene(); - Also vary the window initial style (DECORATED, TRANSPARENT, UNDECORATED) - Owner / no Owner - Open Dialogs / Alerts I would also clean up the old manual tests and concentrate on this tool, which is nice. -- Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: From angorya at openjdk.org Thu Dec 5 21:02:35 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 5 Dec 2024 21:02:35 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v56] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits: - clamp - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - review comments - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - whitespace - since 24 - ... and 67 more: https://git.openjdk.org/jfx/compare/a431801c...84cb0384 ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=55 Stats: 39865 lines in 208 files changed: 39855 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From mstrauss at openjdk.org Fri Dec 6 01:24:39 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Dec 2024 01:24:39 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v31] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java - Merge branch 'master' into feature/extended-window - macOS: double-click action + fullscreen toolbar - remove unneeded dll - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/test/addExports - Merge branch 'master' into feature/extended-window - Merge branch 'master' into feature/extended-window - add system menu documentation - WindowControlsOverlay snapping - HeaderBar javadoc change - ... and 29 more: https://git.openjdk.org/jfx/compare/a431801c...743626f2 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=30 Stats: 4915 lines in 61 files changed: 4403 ins; 409 del; 103 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mstrauss at openjdk.org Fri Dec 6 13:11:45 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Dec 2024 13:11:45 GMT Subject: RFR: 8344367: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 21:35:44 GMT, Nir Lisker wrote: > A batch of typo and grammar fixes that were found by the spellchecker. > > Integration can wait until RDP 1/2. cssref.html L2038: ` apples when the mnemonic affordance (typically an underscore)` ------------- PR Comment: https://git.openjdk.org/jfx/pull/1642#issuecomment-2523224610 From mstrauss at openjdk.org Fri Dec 6 16:28:08 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 6 Dec 2024 16:28:08 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v32] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - StyleableBooleanProperty -> BooleanProperty - Add HeaderBar.overlappingSystemInset property ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/743626f2..8649f917 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=31 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=30-31 Stats: 202 lines in 3 files changed: 152 ins; 23 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From michaelstrau2 at gmail.com Fri Dec 6 16:40:14 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Fri, 6 Dec 2024 17:40:14 +0100 Subject: JEP: JavaFX controls in the title bar In-Reply-To: References: <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com> Message-ID: Hi Martin, I've added the `HeaderBar.overlappingSystemInset` property, which controls whether the window buttons take up space in the layout. Setting this property effectively ignores the system inset for layout purposes. In your example, you could now place one layout container in the "leading" area, and another layout container in the "center" area, and assign different backgrounds to them. Does this solve your use case? On Fri, Nov 15, 2024 at 10:09?PM Martin Fox wrote: > > Michael, > > On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window? > > (I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.) > > In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized. > > The way Apple shoe-horned this into the older AppKit is a bit less elegant. There?s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn?t require any alterations to the HeaderBarBase class and it?s too specialized to be added to HeaderBar. > > Martin From lkostyra at openjdk.org Fri Dec 6 16:47:16 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 6 Dec 2024 16:47:16 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics Message-ID: This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. ------------- Commit messages: - Cleanup unused security-related functions Changes: https://git.openjdk.org/jfx/pull/1658/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344111 Stats: 148 lines in 12 files changed: 0 ins; 136 del; 12 mod Patch: https://git.openjdk.org/jfx/pull/1658.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1658/head:pull/1658 PR: https://git.openjdk.org/jfx/pull/1658 From lkostyra at openjdk.org Fri Dec 6 16:49:16 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Fri, 6 Dec 2024 16:49:16 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes Message-ID: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> This PR removes obsolete permission check methods and fields from Font-related classes. Verified the changes on Windows, did not see any regressions. ------------- Commit messages: - Cleanup unused security functions from Font classes Changes: https://git.openjdk.org/jfx/pull/1659/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1659&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344114 Stats: 56 lines in 5 files changed: 0 ins; 54 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1659.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1659/head:pull/1659 PR: https://git.openjdk.org/jfx/pull/1659 From kcr at openjdk.org Fri Dec 6 16:56:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Dec 2024 16:56:44 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes In-Reply-To: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: <9CX_VULuTHtvbF2LcEqdq9zqkiTuWVGMADeYc2L4NI8=.449af96d-2af7-41f3-9205-58b8015dd515@github.com> On Fri, 6 Dec 2024 16:40:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission check methods and fields from Font-related classes. > > Verified the changes on Windows, did not see any regressions. I spotted what looks like a bug in `loadEmbeddedFont`. The rest looks good. modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java line 1375: > 1373: if (FontFileWriter.hasTempPermission()) { > 1374: return loadEmbeddedFont0(name, fontStream, size, register, loadAll); > 1375: } This test always returns true today, so it looks like you removed the code path that was in use. Unless I'm missing something, I think that you should restore the "return loadEmbeddedFont0" call and remove everything else below this point from this method. ------------- PR Review: https://git.openjdk.org/jfx/pull/1659#pullrequestreview-2485392856 PR Review Comment: https://git.openjdk.org/jfx/pull/1659#discussion_r1873691186 From kcr at openjdk.org Fri Dec 6 17:00:52 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Dec 2024 17:00:52 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics In-Reply-To: References: Message-ID: <8UMbBsDXaZz65Ac6v2etXx7ThcVKjSSW6605Ic0SxLg=.c5010943-9dde-4ef3-a297-bb8bcb8e40dd@github.com> On Fri, 6 Dec 2024 16:38:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). > > The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. At first glance this looks fine. > The only part I did not remove from methods/fields listed in the issue is WindowStage.fullScreenFromUserEvent. This flag seems quite extensively used and did not seem to have anything to do with permission checks. I suspect that `WindowStage.fullScreenFromUserEvent` is now unused, but I'm not certain. It seems fine to leave it alone. @arapte Can you be the Reviewer for this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1658#issuecomment-2523738652 From angorya at openjdk.org Fri Dec 6 17:51:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Dec 2024 17:51:47 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 16:38:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). > > The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. code review only, I did not test it. modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 597: > 595: // event handler. > 596: // If not notify the stageListener to reset fullscreen to false. > 597: if (!fullScreenFromUserEvent) { is this correct? do I understand that the effective value for isTrusted is true, which makes the condition that the if tests false, so the (new) lines 598-599 would never execute. modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3080: > 3078: try { > 3079: tm = dndGesture.processTargetDrop(dragEvent); > 3080: } finally { try-finally is not necessary anymore modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3222: > 3220: fireEvent(target, detectedEvent); > 3221: } finally { > 3222: // Putting data to dragboard finished, restrict access to them try-finally can be removed modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3258: > 3256: fireEvent(target != null ? target : Scene.this, me); > 3257: } finally { > 3258: // Putting data to dragboard finished, restrict access to them try-finally modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 3530: > 3528: dndGesture.processDropEnd(dragEvent); > 3529: } finally { > 3530: DragboardHelper.setDataAccessRestriction(dndGesture.dragboard, true); try-finally ------------- PR Review: https://git.openjdk.org/jfx/pull/1658#pullrequestreview-2485530417 PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873777834 PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873778903 PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873779478 PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873779684 PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873780001 From kcr at openjdk.org Fri Dec 6 18:03:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 6 Dec 2024 18:03:46 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 17:47:07 GMT, Andy Goryachev wrote: >> This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). >> >> The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 597: > >> 595: // event handler. >> 596: // If not notify the stageListener to reset fullscreen to false. >> 597: if (!fullScreenFromUserEvent) { > > is this correct? > > do I understand that the effective value for isTrusted is true, which makes the condition that the if tests false, so the (new) lines 598-599 would never execute. Good catch. You are right. The entire block should be removed. As it is, this will incorrectly limit the set of keys that can be accessed in full-screen mode. This might be why Lukasz thought that `fullScreenFromUserEvent` was still needed. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1873793681 From angorya at openjdk.org Fri Dec 6 18:32:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 6 Dec 2024 18:32:44 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes In-Reply-To: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: On Fri, 6 Dec 2024 16:40:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission check methods and fields from Font-related classes. > > Verified the changes on Windows, did not see any regressions. apart from one spot with `loadEmbeddedFont0`, lgtm (code review only) ------------- PR Review: https://git.openjdk.org/jfx/pull/1659#pullrequestreview-2485604164 From andy.goryachev at oracle.com Fri Dec 6 19:16:17 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Fri, 6 Dec 2024 19:16:17 +0000 Subject: Focus delegation API In-Reply-To: References: Message-ID: Returning to this discussion. Consider the following scenario: a compound control such as ComboBox, which has an editable TextField control as a part of its skin. It might be expected that the ComboBox shows the focused border instead of its TextField even when the latter has the input focus. When the user presses and releases a key, the key events are first dispatched to the input focus owner which is the TextField. This part is correct. The issue we seem to be struggling with is that, unlike the case when TextField is used as a top level control, now it is a part of a ComboBox. Which means it should not handle some keys/events, instead delegating them to the top level control - there should be a single "controller" (in MVC parlance), instead of two fighting each other. This statement applies to built-in controls as well as the custom controls. One way to accomplish that is to register a bunch of event filters with the top level control, to prevent the events to arrive at the inner control, forwarding these events to the top level controller, which in JavaFX case is the behavior. The other way which I think will be easier, is to use the proposed InputMap to remove the undesired mappings from the inner control. Doing so does not involve subclassing of the inner controls, since the input map and the mappings will be a public API. With the mappings disabled (or remapped to the functions provided by the top level control), there is no contention between the two anymore. The top level control's controller is in full control, it can do anything that's required to the inner controls - setting pseudo styles, inserting text, etc. As an example - the right arrow key in the combo box's text field can be remapped to a function which checks if the caret is at the last position and then move the focus to the button, if so desired. And if the caret is not at the last position, the default function of text area is invoked - all that enabled by the InputMap. What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Wednesday, November 20, 2024 at 14:42 To: Cc: openjfx-dev Subject: Re: Focus delegation API I don't see how these problems are at all related. My proposal solves the focus delegation problem that is inherent with composite controls, which is not even addressed by the InputMap proposal. It also solves an artifact of the event system, namely that key events are delivered to the focused node, which cannot simultaneously be the Spinner and its TextField. The ugly hack to make this work is to duplicate the event entirely, so that if you'd observe Spinner and listen for key events, you will see duplicated key presses. This is also not solved in any meaningful way by InputMap. On Wed, Nov 13, 2024 at 8:33?PM Andy Goryachev wrote: > > I feel this is going in a wrong direction: the root cause of the issues we are observing, in my opinion, is that the top-level Control is fighting for control with the inner control, and the inner control's behaves as if it is a top-level control. > > What should happen instead is to provide a way for the top-level Control to disable those aspects of the inner control behavior (event handlers, key bindings) that are not needed anymore, and replace them with the new logic. > Continuing the Spinner example, it is ok for the TextField (Spinner.editor) to receive events, but the handling of certain key combinations should be disabled and instead bubbled up to the Spinner behavior. > > I propose to use the InputMap https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md for this purpose. > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Dec 7 03:15:08 2024 From: duke at openjdk.org (pe-3-6n) Date: Sat, 7 Dec 2024 03:15:08 GMT Subject: RFR: 8286831: WebView can't switch to Chinese input method in GTK3 Message-ID: This PR fixes a bug where the can't switch input method in GTK3. ------------- Commit messages: - 8286831: Fixed so that input method can be switched in GTK3 Changes: https://git.openjdk.org/jfx/pull/1660/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1660&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286831 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1660.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1660/head:pull/1660 PR: https://git.openjdk.org/jfx/pull/1660 From kcr at openjdk.org Sat Dec 7 14:51:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Sat, 7 Dec 2024 14:51:42 GMT Subject: RFR: 8286831: WebView can't switch to Chinese input method in GTK3 In-Reply-To: References: Message-ID: On Sat, 7 Dec 2024 03:10:28 GMT, pe-3-6n wrote: > This PR fixes a bug where the can't switch input method in GTK3. @pe-3-6n We need more information as to why this is the right fix. It isn't immediately obvious why this is needed. @tsayao Can you comment on this relative to your PR to replace the obsolete XIM input method editor? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1660#issuecomment-2525194477 From john.hendrikx at gmail.com Sun Dec 8 18:38:56 2024 From: john.hendrikx at gmail.com (John Hendrikx) Date: Sun, 8 Dec 2024 19:38:56 +0100 Subject: Focus delegation API In-Reply-To: References: Message-ID: On 06/12/2024 20:16, Andy Goryachev wrote: > > Returning to this discussion. > > ? > > Consider the following scenario: a compound control such as ComboBox, > which has an editable TextField control as a part of its skin.? It > might be expected that the ComboBox shows the focused border instead > of its TextField even when the latter has the input focus. > > ? > > When the user presses and releases a key, the key events are first > dispatched to the input focus owner which is the TextField.? This part > is correct. > No, this is incorrect.? The focus owner is the ComboBox, not some inner component of it, and so events are dispatched to the ComboBox.? The focused border is shown around the ComboBox, which is exactly what is expected.? As far as the user is concerned, ComboBox is a fully implemented native control without substructure; to make the implementation of such a control a bit easier (and less repetitive), JavaFX has elected to allow Controls to have children that can handle some of the tasks of a complicated control.? These children however are an implementation detail(as they must be as Skins provide them, and they are not mandated to follow specifics.? It also would have been perfectly acceptable to have created a ComboBox control that does not rely on any other controls and replicates all TextField functionality natively. > > ? > > The issue we seem to be struggling with is that, unlike the case when > TextField is used as a top level control, now it is a part of a > ComboBox.? Which means it should not handle some keys/events, instead > delegating them to the top level control - there should be a single > "controller" (in MVC parlance), instead of two fighting each other.? > This statement applies to built-in controls as well as the custom > controls. > I think you have this upside down. The single controller is the ComboBox.? Events arrive there first.? It encapsulates all its other functionality, including the TextField (if there is one at all, perhaps it is all "custom" drawn).? The ComboBox, fully in control,?can decide that it wants some events handled by its children if that is convenient.? This is done by internally forwarding the event at a child (you can even fire the event --directly-- at the child component, there is no hierarchy requirement here). The opposite is also true; all events an inner control may generate will have to pass scrutiny by the ComboBox, or the ComboBox is free to configure its children in such a way that they won't generate events (ie. by capturing triggering events before they reach the control, by replacing the event dispatcher or setting event handlers directly). Michael's proposal streamlines all of this, providing one solid implementation as it is easy to make mistakes in the event handling, or even use hacky work-arounds, like subclassing, refiring events at new targets, fake focuses... ? > > One way to accomplish that is to register a bunch of event *filters* > with the top level control, to prevent the events to arrive at the > inner control, forwarding these events to the top level controller, > which in JavaFX case is the behavior. > > ? > > The other way which I think will be easier, is to use the proposed > InputMap to remove the undesired mappings from the inner control.? > Doing so does not involve subclassing of the inner controls, since the > input map and the mappings will be a public API.? With the mappings > disabled (or remapped to the functions provided by the top level > control), there is no contention between the two anymore.? The top > level /control/'s /controller/ is in full /control/, it can do > anything that's required to the inner controls - setting pseudo > styles, inserting text, etc.? As an example - the right arrow key in > the combo box's text field can be remapped to a function which checks > if the caret is at the last position and then move the focus to the > button, if so desired.? And if the caret is not at the last position, > the default function of text area is invoked - all that enabled by the > InputMap. > There is no subclassing needed in the focus delegation API either; that's one of the hacks it will be removing.? InputMap does not need to be involved with this at all.? I mean, you are basically seeing exactly the intention (the top level control's controller is in full control) but then involve the InputMaps unnecessarily.? InputMaps are just event handlers backed by a Key to Action map. Adding focus concerns here is clearly overstepping their bounds, not to mention they would have to support arbitrary events. --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrin at pricemeier.ch Sun Dec 8 20:36:33 2024 From: andrin at pricemeier.ch (Andrin Meier) Date: Sun, 8 Dec 2024 20:36:33 +0000 Subject: Bug report Message-ID: Where can I submit a bug report? The official bug report website does not work. There is an error on submit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Dec 8 20:43:23 2024 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 8 Dec 2024 15:43:23 -0500 Subject: Bug report In-Reply-To: References: Message-ID: Hello Andrin, Yeah, it's a known issue. I have the same problem too on several of my bug reports. After 4-5 attempts, my bug finally submits. Alternatively, you can find the relevant mailing list, and they will take a look at it too. Personally, I recommend the mailing list option, as it gives you a faster response time. On Sun, Dec 8, 2024 at 3:36?PM Andrin Meier wrote: > Where can I submit a bug report? The official bug report website does not > work. There is an error on submit. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrin at pricemeier.ch Sun Dec 8 20:47:02 2024 From: andrin at pricemeier.ch (Andrin Meier) Date: Sun, 8 Dec 2024 20:47:02 +0000 Subject: Bug report In-Reply-To: References: Message-ID: The mailing list sounds like a good idea. Would this openjfx-dev mailing list be the place to post JavaFX bugs then? Or do you know which one is? Sent from Outlook for iOS ________________________________ From: David Alayachew Sent: Sunday, December 8, 2024 9:43:23 PM To: Andrin Meier Cc: openjfx-dev at openjdk.org Subject: Re: Bug report Hello Andrin, Yeah, it's a known issue. I have the same problem too on several of my bug reports. After 4-5 attempts, my bug finally submits. Alternatively, you can find the relevant mailing list, and they will take a look at it too. Personally, I recommend the mailing list option, as it gives you a faster response time. On Sun, Dec 8, 2024 at 3:36?PM Andrin Meier > wrote: Where can I submit a bug report? The official bug report website does not work. There is an error on submit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Dec 8 21:11:27 2024 From: philip.race at oracle.com (Philip Race) Date: Sun, 8 Dec 2024 13:11:27 -0800 Subject: Bug report In-Reply-To: References: Message-ID: I think we would MUCH prefer people to use the site : https://bugreport.java.com/bugreport/ I'd go so far as to say that even if you reported it here, we'd refer you back there to provide all the required information. If there are significant problems with that site it would affect a lot more than FX reports since it is used for the entire JDK too, but this is the first time I've ever heard of a problem. You should email about problems with the bug reporting to (I think) ops at openjdk.java.org. -phil. On 12/8/24 12:47 PM, Andrin Meier wrote: > The mailing list sounds like a good idea. Would this openjfx-dev > mailing list be the place to post JavaFX bugs then? Or do you know > which one is? > > Sent from Outlook for iOS > ------------------------------------------------------------------------ > *From:* David Alayachew > *Sent:* Sunday, December 8, 2024 9:43:23 PM > *To:* Andrin Meier > *Cc:* openjfx-dev at openjdk.org > *Subject:* Re: Bug report > Hello Andrin, > > Yeah, it's a known issue. I have the same problem too on several of my > bug reports. > > After 4-5 attempts, my bug finally submits. > > Alternatively, you can find the relevant mailing list, and they will > take a look at it too. Personally, I recommend the mailing list > option, as it gives you a faster response time. > > On Sun, Dec 8, 2024 at 3:36?PM Andrin Meier wrote: > > Where can I submit a bug report? The official bug report website > does not work. There is an error on submit. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Sun Dec 8 23:12:53 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 9 Dec 2024 00:12:53 +0100 Subject: Focus delegation API In-Reply-To: References: Message-ID: > Consider the following scenario: a compound control such as ComboBox, which has an editable TextField control as a part of its skin. It might be expected that the ComboBox shows the focused border instead of its TextField even when the latter has the input focus. > > When the user presses and releases a key, the key events are first dispatched to the input focus owner which is the TextField. This part is correct. The focus owner in your example is the ComboBox, not the TextField. The fact that the ComboBox skin uses a TextField in its implementation is not a part of the user model. From the user's perspective, it is a monolithic control with an unknown internal structure. Now, if you click on a ComboBox, the only logical thing that can happen is that the ComboBox receive the input focus. More precisely, the following things must be true: .focused == true Scene.focusOwner == This is how JavaFX is currently implemented. However, since JavaFX doesn't provide the necessary tools to support these semantics, the actual implementations are decidedly ad-hoc and held together by hacks. > The issue we seem to be struggling with is that, unlike the case when TextField is used as a top level control, now it is a part of a ComboBox. Which means it should not handle some keys/events, instead delegating them to the top level control - there should be a single "controller" (in MVC parlance), instead of two fighting each other. This statement applies to built-in controls as well as the custom controls. > > One way to accomplish that is to register a bunch of event filters with the top level control, to prevent the events to arrive at the inner control, forwarding these events to the top level controller, which in JavaFX case is the behavior. Since the FakeFocusTextField that is contained in the ComboBox is not the focus owner, it is not the target of input events. Delivering events to the text field in order to make it work currently requires the skin to fire a new event that is targeted at the text field. This can be observed externally, and is an obvious defect (user presses a single key, observers will see two key presses). > The other way which I think will be easier, is to use the proposed InputMap to remove the undesired mappings from the inner control. Doing so does not involve subclassing of the inner controls, since the input map and the mappings will be a public API. With the mappings disabled (or remapped to the functions provided by the top level control), there is no contention between the two anymore. The top level control's controller is in full control, it can do anything that's required to the inner controls - setting pseudo styles, inserting text, etc. As an example - the right arrow key in the combo box's text field can be remapped to a function which checks if the caret is at the last position and then move the focus to the button, if so desired. And if the caret is not at the last position, the default function of text area is invoked - all that enabled by the InputMap. InputMap is only tangentially related to focus handling. Focus delegation solves a whole array of problems that appear when you try to implement a multi-level focus system, such as is the case in JavaFX. In addition to that, focus delegation and InputMap are different levels of abstraction: Focus delegation is a core feature of the framework (just like focus is a core feature), while InputMap is one feature of one implementation of controls. There is nothing special about javafx.controls or its particular flavor of controls, skins, and behaviors. Missing building blocks in the core framework can't be solved in a controls library. From lkostyra at openjdk.org Mon Dec 9 12:42:49 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 9 Dec 2024 12:42:49 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics In-Reply-To: References: Message-ID: On Fri, 6 Dec 2024 18:01:05 GMT, Kevin Rushforth wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 597: >> >>> 595: // event handler. >>> 596: // If not notify the stageListener to reset fullscreen to false. >>> 597: if (!fullScreenFromUserEvent) { >> >> is this correct? >> >> do I understand that the effective value for isTrusted is true, which makes the condition that the if tests false, so the (new) lines 598-599 would never execute. > > Good catch. You are right. The entire block should be removed. As it is, this will incorrectly limit the set of keys that can be accessed in full-screen mode. > > This might be why Lukasz thought that `fullScreenFromUserEvent` was still needed. Indeed good catch. Monday brain now wonders what Friday brain was thinking ? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1658#discussion_r1875919220 From lkostyra at openjdk.org Mon Dec 9 12:48:47 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 9 Dec 2024 12:48:47 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes In-Reply-To: <9CX_VULuTHtvbF2LcEqdq9zqkiTuWVGMADeYc2L4NI8=.449af96d-2af7-41f3-9205-58b8015dd515@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> <9CX_VULuTHtvbF2LcEqdq9zqkiTuWVGMADeYc2L4NI8=.449af96d-2af7-41f3-9205-58b8015dd515@github.com> Message-ID: <_OO3ux3ftLuZNIzVkiawfo9m7gTkKXNhnsyCT7U1VXo=.079ff35c-a81f-489c-a017-bebe9eb17915@github.com> On Fri, 6 Dec 2024 16:51:48 GMT, Kevin Rushforth wrote: >> This PR removes obsolete permission check methods and fields from Font-related classes. >> >> Verified the changes on Windows, did not see any regressions. > > modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java line 1375: > >> 1373: if (FontFileWriter.hasTempPermission()) { >> 1374: return loadEmbeddedFont0(name, fontStream, size, register, loadAll); >> 1375: } > > This test always returns true today, so it looks like you removed the code path that was in use. Unless I'm missing something, I think that you should restore the "return loadEmbeddedFont0" call and remove everything else below this point from this method. Yes, this should always `return loadEmbeddedFont0`. Again, some Friday-related mishap. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1659#discussion_r1875926343 From lkostyra at openjdk.org Mon Dec 9 13:36:02 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 9 Dec 2024 13:36:02 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes [v2] In-Reply-To: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: > This PR removes obsolete permission check methods and fields from Font-related classes. > > Verified the changes on Windows, did not see any regressions. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Review fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1659/files - new: https://git.openjdk.org/jfx/pull/1659/files/a7281687..5e6bf0ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1659&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1659&range=00-01 Stats: 27 lines in 1 file changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1659.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1659/head:pull/1659 PR: https://git.openjdk.org/jfx/pull/1659 From lkostyra at openjdk.org Mon Dec 9 13:36:02 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 9 Dec 2024 13:36:02 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes [v2] In-Reply-To: <_OO3ux3ftLuZNIzVkiawfo9m7gTkKXNhnsyCT7U1VXo=.079ff35c-a81f-489c-a017-bebe9eb17915@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> <9CX_VULuTHtvbF2LcEqdq9zqkiTuWVGMADeYc2L4NI8=.449af96d-2af7-41f3-9205-58b8015dd515@github.com> <_OO3ux3ftLuZNIzVkiawfo9m7gTkKXNhnsyCT7U1VXo=.079ff35c-a81f-489c-a017-bebe9eb17915@github.com> Message-ID: <0c7txYaRmB6XVkcRoaVqDsShUbNEZZzDhqTzoRi4nSQ=.258104a3-de1d-4c33-8421-a6d8e171b56d@github.com> On Mon, 9 Dec 2024 12:45:56 GMT, Lukasz Kostyra wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java line 1375: >> >>> 1373: if (FontFileWriter.hasTempPermission()) { >>> 1374: return loadEmbeddedFont0(name, fontStream, size, register, loadAll); >>> 1375: } >> >> This test always returns true today, so it looks like you removed the code path that was in use. Unless I'm missing something, I think that you should restore the "return loadEmbeddedFont0" call and remove everything else below this point from this method. > > Yes, this should always `return loadEmbeddedFont0`. Again, some Friday-related mishap. I went a step further even - now with `loadEmbeddedFont` essentially only calling `loadEmbeddedFont0` this is the only place where `loadEmbeddedFont0` is used. I decided to remove this code altogether and rename `loadEmbeddedFont0` to appropriate `loadEmbeddedFont`. Tests seem to be all good after this change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1659#discussion_r1875988521 From lkostyra at openjdk.org Mon Dec 9 13:37:25 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Mon, 9 Dec 2024 13:37:25 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics [v2] In-Reply-To: References: Message-ID: > This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). > > The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: Review fixes ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1658/files - new: https://git.openjdk.org/jfx/pull/1658/files/5b89a0bc..7ad0f5b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1658&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1658&range=00-01 Stats: 172 lines in 3 files changed: 1 ins; 131 del; 40 mod Patch: https://git.openjdk.org/jfx/pull/1658.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1658/head:pull/1658 PR: https://git.openjdk.org/jfx/pull/1658 From kcr at openjdk.org Mon Dec 9 16:23:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Dec 2024 16:23:46 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics [v2] In-Reply-To: References: Message-ID: <2yUyw6ZVWR53QtF_gQDoG3mz6VAQhWBdJbsoPuBJFVo=.44701473-ec99-4875-baa2-d9cf5f16d830@github.com> On Mon, 9 Dec 2024 13:37:25 GMT, Lukasz Kostyra wrote: >> This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). >> >> The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review fixes Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1658#pullrequestreview-2489312032 From kcr at openjdk.org Mon Dec 9 16:27:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 9 Dec 2024 16:27:47 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes [v2] In-Reply-To: References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: On Mon, 9 Dec 2024 13:36:02 GMT, Lukasz Kostyra wrote: >> This PR removes obsolete permission check methods and fields from Font-related classes. >> >> Verified the changes on Windows, did not see any regressions. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review fixes Looks good. As a follow-up, we might consider whether `FontTracker` is still needed. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1659#pullrequestreview-2489323404 From angorya at openjdk.org Mon Dec 9 16:32:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Dec 2024 16:32:47 GMT Subject: RFR: 8344114: Remove obsolete permission check methods from Font classes [v2] In-Reply-To: References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: <1Bj-4kF6s2i7JU-9xtIzqsXpDhiYb_IcVPXzMD201-Y=.31d4e780-13a1-42d1-91b1-6dcfcd092745@github.com> On Mon, 9 Dec 2024 13:36:02 GMT, Lukasz Kostyra wrote: >> This PR removes obsolete permission check methods and fields from Font-related classes. >> >> Verified the changes on Windows, did not see any regressions. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review fixes looks good on macOS 15.1.1 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1659#pullrequestreview-2489339835 From angorya at openjdk.org Mon Dec 9 17:07:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 9 Dec 2024 17:07:46 GMT Subject: RFR: 8344111: Remove obsolete permission check methods from javafx.graphics [v2] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 13:37:25 GMT, Lukasz Kostyra wrote: >> This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). >> >> The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. > > Lukasz Kostyra has updated the pull request incrementally with one additional commit since the last revision: > > Review fixes tested various full screen scenarios with the monkey tester. looks good on macos 15.1.1 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1658#pullrequestreview-2489443330 From mfox at openjdk.org Mon Dec 9 17:28:57 2024 From: mfox at openjdk.org (Martin Fox) Date: Mon, 9 Dec 2024 17:28:57 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> Message-ID: <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> On Thu, 5 Dec 2024 07:12:20 GMT, Helly Guo wrote: >> 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 114 commits: >> >> - Merge branch 'master' into new_ime >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Revert "Set IBUS_ENABLE_SYNC_MODE=1" >> >> This reverts commit 8eccd9866b1e9931356557463997ccf53673fbfa. >> - Set IBUS_ENABLE_SYNC_MODE=1 >> - Merge branch 'master' into new_ime >> - Merge branch 'master' into new_ime >> - Revert "Fix for Polish AltGR combinations" >> >> This reverts commit 78e27e9deba2eda96b86186692da4f8dc2a3a1ff. >> - Revert "Fix the case when IME filters key_press (Polish ALT Gr + C)" >> >> This reverts commit 112ed6f4306a42378255c858306f9625ea2b5fa8. >> - Revert "Remove idea file" >> >> This reverts commit e56588baad42c07a5b872d27603a97e06be97649. >> - Remove idea file >> - ... and 104 more: https://git.openjdk.org/jfx/compare/67eed6d8...16b3eebe > > modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 100: > >> 98: >> 99: void WindowContextBase::commitIME(gchar *str) { >> 100: if (im_ctx.on_preedit) { > > Through `LOG0`/`LOG1`, I found that the value of `im_ctx.on_preedit` is `false` under `fcitx`. > I removed this check, then tested under `fcitx` and `ibus`. All passed. @hellyguo Could you provide more details on which Linux distribution, input method, and fcitx version you're using? I just tested this on Ubuntu 24.10. For Chinese I'm using Intelligent Pinyin and for Japanese I'm using Mozc. Everything worked under Ibus but when I switched to fcitx 4 both my Chinese and Japanese input methods stopped working for all apps, not just JavaFX. This makes me think that I'm not setting up fcitx correctly. I did reboot at each step as I changed the configuration. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1876389777 From martin at martinfox.com Mon Dec 9 18:16:00 2024 From: martin at martinfox.com (Martin Fox) Date: Mon, 9 Dec 2024 10:16:00 -0800 Subject: JEP: JavaFX controls in the title bar In-Reply-To: References: <125ccc21-75cc-468f-b333-cb89084197f5@oracle.com> Message-ID: Hi Michael, Yes, this works! I wrote up a quick test app and it worked fine on the Mac. I?ll try to write up a more comprehensive app but might not get around to it for a few weeks. Thanks, Martin > On Dec 6, 2024, at 8:40?AM, Michael Strau? wrote: > > Hi Martin, > > I've added the `HeaderBar.overlappingSystemInset` property, which > controls whether the window buttons take up space in the layout. > Setting this property effectively ignores the system inset for layout > purposes. > > In your example, you could now place one layout container in the > "leading" area, and another layout container in the "center" area, and > assign different backgrounds to them. > > Does this solve your use case? > > > > On Fri, Nov 15, 2024 at 10:09?PM Martin Fox wrote: >> >> Michael, >> >> On the Mac a common UI layout is to have a splitter view that extends to the top of the window with separate toolbars in each panel. Have you given any thought on supporting this layout in an EXTENDED window? >> >> (I realize this is a Mac thing; Apple loves their sidebars. Microsoft dabbled with this design language but it seems to be fading away. I have seen it in a few Windows apps like 1Password.) >> >> In UIKit Apple implements this using separate views. The equivalent in JavaFX would be to add a separate HeaderBarBase object to the top of each panel in a SplitPane. That would require supporting multiple HeaderBarBase instances and providing an API to tell one to ignore leftSystemInset or rightSystemInset (or both). I like this solution since it allows the background visuals for each header bar to be customized. >> >> The way Apple shoe-horned this into the older AppKit is a bit less elegant. There?s still one NSToolbar that spans the entire window. A developer can add special items to the toolbar that track the dividers in an NSSplitView. I would let developers roll their own solutions if they want that design. Replicating that in JavaFX wouldn?t require any alterations to the HeaderBarBase class and it?s too specialized to be added to HeaderBar. >> >> Martin From tsayao at openjdk.org Mon Dec 9 20:44:56 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Mon, 9 Dec 2024 20:44:56 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> Message-ID: On Mon, 9 Dec 2024 17:25:58 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 100: >> >>> 98: >>> 99: void WindowContextBase::commitIME(gchar *str) { >>> 100: if (im_ctx.on_preedit) { >> >> Through `LOG0`/`LOG1`, I found that the value of `im_ctx.on_preedit` is `false` under `fcitx`. >> I removed this check, then tested under `fcitx` and `ibus`. All passed. > > @hellyguo Could you provide more details on which Linux distribution, input method, and fcitx version you're using? > > I just tested this on Ubuntu 24.10. For Chinese I'm using Intelligent Pinyin and for Japanese I'm using Mozc. Everything worked under Ibus but when I switched to fcitx 4 both my Chinese and Japanese input methods stopped working for all apps, not just JavaFX. This makes me think that I'm not setting up fcitx correctly. I did reboot at each step as I changed the configuration. I did not test it with fcitx since gtk uses ibus. I think it's possible to use fcitx by installing a gtk im module. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1876727004 From andy.goryachev at oracle.com Mon Dec 9 21:27:26 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 9 Dec 2024 21:27:26 +0000 Subject: Focus delegation API In-Reply-To: References: Message-ID: OK, let's backtrack a bit. consider this example https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/ComboBox_Events.java it's a single combo box with application-level filters and handlers attached to scene, combo box, and the combo box editor. pressing and releasing a key, we get the following output: > user presses 'a' key 1. stage filter: KEY_PRESSED h=913 target=876 2. combobox filter: KEY_PRESSED h=457 target=876 3. stage filter: KEY_PRESSED h=487 target=553 4. combobox filter: KEY_PRESSED h=123 target=553 5. editor filter: KEY_PRESSED h=372 target=553 6. editor handler: KEY_PRESSED h=372 consumed! target=553 7. stage filter: KEY_TYPED h=424 target=876 8. combobox filter: KEY_TYPED h=271 target=876 9. stage filter: KEY_TYPED h=432 target=553 10. combobox filter: KEY_TYPED h=535 target=553 11. editor filter: KEY_TYPED h=208 target=553 12. editor handler: KEY_TYPED h=208 consumed! target=553 13. stage filter: KEY_RELEASED h=336 target=876 14. combobox filter: KEY_RELEASED h=242 target=876 15. stage filter: KEY_RELEASED h=740 target=553 16. combobox filter: KEY_RELEASED h=901 target=553 17. editor filter: KEY_RELEASED h=508 target=553 18. editor handler: KEY_RELEASED h=508 target=553 19. combobox handler: KEY_RELEASED h=955 target=553 20. stage handler: KEY_RELEASED h=232 target=553 ComboBox.onValueChanged: a This output is very puzzling, please help me understand it. - with the exception of events logged from the editor, the events being sent are all different instances (h= prints the event's hashCode) - where did the duplicate event in step 3 come from? step 9? step 15? - why a consumed event is being dispatched to the editor in line 6? line 12? Maybe we should ask the question why in this case the Scene.focusOwner is the ComboBox, and not its editor, the TextField? Having the actual component that receives the input events to be the focus owner would eliminate the need for hacks in the skin to send events, wouldn't it? Or, if we say that's the grand design of javafx - that the skins must forward event copies to the skin constituents, then adding a handler to the top level control (combo box in this case) should result in that handler to be called before the skin's one, right? This, I think, brings us again to the discussion of event handling priority. BTW, you never responded to my questions in https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050655.html Cheers, -andy From: Andy Goryachev Date: Friday, December 6, 2024 at 11:16 To: Michael Strau? Cc: openjfx-dev Subject: Re: Focus delegation API Returning to this discussion. Consider the following scenario: a compound control such as ComboBox, which has an editable TextField control as a part of its skin. It might be expected that the ComboBox shows the focused border instead of its TextField even when the latter has the input focus. When the user presses and releases a key, the key events are first dispatched to the input focus owner which is the TextField. This part is correct. The issue we seem to be struggling with is that, unlike the case when TextField is used as a top level control, now it is a part of a ComboBox. Which means it should not handle some keys/events, instead delegating them to the top level control - there should be a single "controller" (in MVC parlance), instead of two fighting each other. This statement applies to built-in controls as well as the custom controls. One way to accomplish that is to register a bunch of event filters with the top level control, to prevent the events to arrive at the inner control, forwarding these events to the top level controller, which in JavaFX case is the behavior. The other way which I think will be easier, is to use the proposed InputMap to remove the undesired mappings from the inner control. Doing so does not involve subclassing of the inner controls, since the input map and the mappings will be a public API. With the mappings disabled (or remapped to the functions provided by the top level control), there is no contention between the two anymore. The top level control's controller is in full control, it can do anything that's required to the inner controls - setting pseudo styles, inserting text, etc. As an example - the right arrow key in the combo box's text field can be remapped to a function which checks if the caret is at the last position and then move the focus to the button, if so desired. And if the caret is not at the last position, the default function of text area is invoked - all that enabled by the InputMap. What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Wednesday, November 20, 2024 at 14:42 To: Cc: openjfx-dev Subject: Re: Focus delegation API I don't see how these problems are at all related. My proposal solves the focus delegation problem that is inherent with composite controls, which is not even addressed by the InputMap proposal. It also solves an artifact of the event system, namely that key events are delivered to the focused node, which cannot simultaneously be the Spinner and its TextField. The ugly hack to make this work is to duplicate the event entirely, so that if you'd observe Spinner and listen for key events, you will see duplicated key presses. This is also not solved in any meaningful way by InputMap. On Wed, Nov 13, 2024 at 8:33?PM Andy Goryachev wrote: > > I feel this is going in a wrong direction: the root cause of the issues we are observing, in my opinion, is that the top-level Control is fighting for control with the inner control, and the inner control's behaves as if it is a top-level control. > > What should happen instead is to provide a way for the top-level Control to disable those aspects of the inner control behavior (event handlers, key bindings) that are not needed anymore, and replace them with the new logic. > Continuing the Spinner example, it is ok for the TextField (Spinner.editor) to receive events, but the handling of certain key combinations should be disabled and instead bubbled up to the Spinner behavior. > > I propose to use the InputMap https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md for this purpose. > > -andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Mon Dec 9 22:58:04 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Mon, 9 Dec 2024 23:58:04 +0100 Subject: Focus delegation API In-Reply-To: References: Message-ID: Hi Andy, your example highlights the observable defect that I've been trying to explain. Answers to your questions below. On Mon, Dec 9, 2024 at 10:27?PM Andy Goryachev wrote: > > OK, let's backtrack a bit. > > consider this example > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/ComboBox_Events.java > > it's a single combo box with application-level filters and handlers attached to scene, combo box, and the combo box editor. > > pressing and releasing a key, we get the following output: > > > user presses 'a' key > 1. stage filter: KEY_PRESSED h=913 target=876 > 2. combobox filter: KEY_PRESSED h=457 target=876 > 3. stage filter: KEY_PRESSED h=487 target=553 > 4. combobox filter: KEY_PRESSED h=123 target=553 > 5. editor filter: KEY_PRESSED h=372 target=553 > 6. editor handler: KEY_PRESSED h=372 consumed! target=553 > [...] > This output is very puzzling, please help me understand it. > > - with the exception of events logged from the editor, the events being sent are all different instances (h= prints the event's hashCode) Yes, each step of the event dispatch chain gets its own event instance. This is due to the immutable nature of the Event class, as on each step the source (and/or target) field must be changed; the way JavaFX does this is by copying the event instance and adjusting the fields in the process. > - where did the duplicate event in step 3 come from? step 9? step 15? That's the core of the issue. Here's what's happening, step by step: 1. ComboBox is the focus owner of the scene, so the KEY_PRESSED event is sent to the ComboBox. 2. ComboBox's skin has installed an event filter on ComboBox, and when it receives a key event, it consumes the event. This is why event dispatching stops after step 2 in your example. 3. However, it must forward the event to the TextField (as otherwise the TextField doesn't work), so it fires off a copy of the event targeted at TextField. The new event starts again at the root ("stage filter") and travels to the ComboBox ("combobox filter"). 4. When ComboBox receives the duplicate event, it inspects the target of the event, and realizes that it is targeted at the TextField. In this special case, the event is not consumed, but allowed to travel further. 5. Now the duplicate event reaches the TextField ("editor filter"), where nothing happens, and begins to bubble up ("editor handler"). This is where the event is consumed by the TextField I hope that you agree that the duplicated event, being visible to all listeners, is a defect. When a key is pressed once, a listener should not see two KEY_PRESSED events for the same key. > - why a consumed event is being dispatched to the editor in line 6? line 12? That's a bug. Consumed events are dispatched to all listeners on the same step of the event dispatch chain. I've often suggested that we finally fix this bug. > Maybe we should ask the question why in this case the Scene.focusOwner is the ComboBox, and not its editor, the TextField? Having the actual component that receives the input events to be the focus owner would eliminate the need for hacks in the skin to send events, wouldn't it? > > Or, if we say that's the grand design of javafx - that the skins must forward event copies to the skin constituents, then adding a handler to the top level control (combo box in this case) should result in that handler to be called before the skin's one, right? The core of JavaFX is just the scene graph, there's no concept of controls or skins (that's added by javafx.controls). I would say that a "skin", "shadow DOM", "internal/external" type of abstraction is a very useful abstraction, and JavaFX should support the creation of such abstractions. 1. When you have abstraction, you also want encapsulation. That means that the internal implementation of a control should not leak into its user model. Whether ComboBox contains a TextField, or whether it "custom draws" its text editor (for example, by writing pixels directly to a Canvas) shouldn't affect users of ComboBox. 2. From this it necessarily follows that the focus owner must always be the control, and not any part of its internal and opaque substructure. Users of ComboBox shouldn't have to change their code when they switch to a custom-drawing skin. 3. When the control is the focus owner, then it will receive all key events. We need a way to reconcile the JavaFX event system with the internal substructure, without exposing the internals to the outside world, and without changing the user model of the control. This is part of what focus delegation solves: it separates different levels of abstraction. It allows key events to be sent to the control, which is exactly what users of a control would expect. Every layer of abstraction will see exactly what it would expect to see: an event that is targeted at itself, not at some other thing. It also allows users to reason about events. For example, when a listener inspects a key event, it will see that the event is targeted at the ComboBox. If it was instead targeted at FakeFocusTextField, the listener couldn't reason about the event, as there is no such thing in the user model. > This, I think, brings us again to the discussion of event handling priority. BTW, you never responded to my questions in > https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050655.html I did: https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050753.html From andy.goryachev at oracle.com Mon Dec 9 23:22:39 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Mon, 9 Dec 2024 23:22:39 +0000 Subject: Prioritized event handlers In-Reply-To: References: Message-ID: Getting back to prioritized event handlers. > I think it would most likely be the latter, i.e. a separate "wave" for each priority where the event first tunnels down to the target, and then bubbles back up. Forgive me, this makes no sense. The point of adding priority to event handling is to resolve the problem of undefined order in which the handlers registered on one component are invoked. At least this is where we started. This is what I expect, really: scene filter (application) container filter (application) control filter (application) control filter (skin) control handler (application) control handler (skin) container handler (application) scene handler (application) This is not what is happening, as was described in https://mail.openjdk.org/pipermail/openjfx-dev/2024-December/051353.html I don't know whether any fx internals add event filters/handlers to the scene or various containers (Parents), but as we know the case of compound controls, as it is currently implemented, makes the whole picture more complicated: scene filter (application) container filter (application) control filter (application) control filter (skin) control forward an event to the skin constituent control filter? control handler (application) control handler (skin) control forward an event to the skin constituent control handler? container handler (application) scene handler (application) > Yes, once an event is consumed, further dispatching stops immediately. I wholeheartedly agree! However, this poses a problem: javafx sends out cascades of event copies, often without looking at whether one event was consumed or not. In my opinion, there is no need to create copies, meaning the target node should have never been made a part of the Event (or, if one really wants to keep this paradigm, all the involved events should have their isConsumed flag bidirectionally bound). Another thing is the public nature of the EventDispatcher. We spent some time already talking about it, my issue with it is that is creates two foot-guns: allows creating custom event dispatchers that can misbehave, and introduces a parallel mechanism for stopping the dispatch, replacing (or conflicting) with the existing Event.isConsumed(). I feel these three discussions (focus, EH priority, ifUnconsumed) are basically parts of the same discussion. It will be rather difficult to resolve all the issues at the same time, and we don't have to. I do want to move forward with the input map idea though - I think it brings benefit to application developers and the skin/custom component developers, so I want to agree at least on how we should fix the issue of prioritizing event handling between skins and application. If there are use cases where we might have undetermined order of handlers outside of controls, then we should think of adding the prioritization scheme as you proposed. If we only have this issue in controls, then we could use input map to resolve the issue. What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Wednesday, November 20, 2024 at 14:36 To: Cc: openjfx-dev Subject: Re: Prioritized event handlers Hi Andy! > 1. Does this proposal changes the way events are dispatched with respect to priority? In other words, does it first go through the list of all handlers registred on the leaf Node (high priority first, then lower, then lowest), then bubble up? Or do they propagate upwards looking for high priority handlers first, then the process restarts for lower priorities, as I saw in some previous emails? (I could be mistaken) I think it would most likely be the latter, i.e. a separate "wave" for each priority where the event first tunnels down to the target, and then bubbles back up. The downside of this is the increased implementation complexity: we probably don't want to increase the number of events five-fold, especially when most of the time, no one is listening anyway. So there would have to be quite a bit of optimization to make this work efficiently. > 2. Do you propose to abort event dispatching immediately after the event is consumed? This probably should be mentioned earlier in the Motivation (the problem statement) section. Yes, once an event is consumed, further dispatching stops immediately. We also need to fix the bug that is currently in FX where that's not the case for listeners on the same node. The rest of the questions are very specific for prioritized event handlers. But I now think that unconsumed event handlers are a much simpler solution to the problem, as it solves the same set of problems that are solved with prioritized event handlers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Mon Dec 9 23:23:59 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 9 Dec 2024 23:23:59 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v3] In-Reply-To: References: Message-ID: > This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. > > In order to do that, there are multiple things needed: > - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there > - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) > - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) > - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns > - As before, the `TableRow` adds or removes cells that are visible or not. > Note that this is only done when a fixed cell size is set. > The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later > - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: > - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells > Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself > - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org... Marius Hanl 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' of https://github.com/openjdk/jfx into 8185887-virtualization # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction ------------- Changes: https://git.openjdk.org/jfx/pull/1644/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=02 Stats: 1346 lines in 14 files changed: 1171 ins; 141 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/1644.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644 PR: https://git.openjdk.org/jfx/pull/1644 From mhanl at openjdk.org Mon Dec 9 23:24:00 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 9 Dec 2024 23:24:00 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: <4HkljtjF6VOFqX6I3GSd27Sid_OP9MV03Z-eEal_gOI=.57e04e23-dd06-472d-b27c-f02929ea3adc@github.com> Message-ID: On Thu, 5 Dec 2024 09:24:13 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 228: >> >>> 226: if (disclosureNodeDirty) { >>> 227: updateDisclosureNodeAndGraphic(); >>> 228: disclosureNodeDirty = false; >> >> shouldn't `disclosureNodeDirty = false;` be moved to `updateDisclosureNodeAndGraphic();` ? >> here and in L257, L216 > > Could be an idea. I will check. I just tried to not make to many changes, but this might be an easy one. Checked the code, that is a safe improvement, so will do. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1644#discussion_r1876896331 From mhanl at openjdk.org Mon Dec 9 23:49:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 9 Dec 2024 23:49:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v2] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 15:32:33 GMT, Andy Goryachev wrote: > By the way, a Tree/TableView with 500 columns is barely usable - locks up the UI giving me a macOS spinning beach ball quite often. Not that it's a reasonable use case. 200 is ok. May be the 500 case can be used for profiling? With fixed cell size, it seems okay to me. How is your table configured? > Speaking of the vertical scrolling - I could not use the idea implemented by the VirtualFlow in the RichTextArea as it won't work in the case of very large models. There is a lot of stuff that can improved in the `VirtualFlow`. Most of the modern table components all use fixed cells or have some kind of dynamic height calculation logic. They only rely on calculating the size themself when it really needs to (e.g. the developer turning it on). You can for example check AG-Grid, which is a pretty nicely implemented table that is very fast and has a nice API design: https://www.ag-grid.com/javascript-data-grid/row-height/ They also do not recommend setting the auto height, and also explain the side effects (cells and scroll bar jumping). We only have the fixed cell size implemented, but it is not the default (and too late to change). This helps a lot since the math is very easy then. For something like the `RichTextArea`, this might be more complex, so I can see why the `VirtualFlow` does not fit. It is more complex as a Table, where you most likely know the height in advance. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2529815614 From mhanl at openjdk.org Mon Dec 9 23:53:54 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 9 Dec 2024 23:53:54 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v7] In-Reply-To: References: Message-ID: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appear... Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java - Rename setContent to setClipLayout - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java - Improve test - 8218745: TableView: visual glitch at borders on horizontal scrolling ------------- Changes: https://git.openjdk.org/jfx/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1462&range=06 Stats: 238 lines in 11 files changed: 163 ins; 56 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1462.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1462/head:pull/1462 PR: https://git.openjdk.org/jfx/pull/1462 From mhanl at openjdk.org Mon Dec 9 23:55:01 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 9 Dec 2024 23:55:01 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: Message-ID: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> > This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. > > While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. > > It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). > Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. Marius Hanl 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 three additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup - Call getFixedCellSize() once - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1645/files - new: https://git.openjdk.org/jfx/pull/1645/files/8206f821..5d5c0c3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1645&range=00-01 Stats: 2436 lines in 402 files changed: 879 ins; 435 del; 1122 mod Patch: https://git.openjdk.org/jfx/pull/1645.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/jfx/pull/1645 From andy.goryachev at oracle.com Tue Dec 10 00:21:17 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 10 Dec 2024 00:21:17 +0000 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: > Yes, each step of the event dispatch chain gets its own event instance. Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. > 2. ComboBox's skin has installed an event filter on ComboBox So we have another scenario where different priorities are needed: adding event filters. > 3. However, it must forward the event to the TextField (as otherwise the TextField doesn't work), so it fires off a copy of the event targeted at TextField. Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. > Consumed events are dispatched to all listeners on the same step of the event dispatch chain. I've often suggested that we finally fix this bug. Agree. Moving to the second part: > 1. When you have abstraction, you also want encapsulation. Agree. Swing does not do it (combo box's text field is a top level component, being the to "focusOwner"), but I buy the idea of encapsulation of controls. > 2. From this it necessarily follows that the focus owner must always be the control, and not any part of its internal and opaque substructure. Agree. > 3. When the control is the focus owner, then it will receive all key events. We need a way to reconcile the JavaFX event system with the internal substructure, without exposing the internals to the outside world, and without changing the user model of the control. Agree. > This is part of what focus delegation solves: it separates different levels of abstraction. It allows key events to be sent to the control, which is exactly what users of a control would expect. Every layer of abstraction will see exactly what it would expect to see: an event that is targeted at itself, not at some other thing. > It also allows users to reason about events. For example, when a listener inspects a key event, it will see that the event is targeted at the ComboBox. If it was instead targeted at FakeFocusTextField, the listener couldn't reason about the event, as there is no such thing in the user model. Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. What do you think? -andy From: Michael Strau? Date: Monday, December 9, 2024 at 14:59 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: Focus delegation API Hi Andy, your example highlights the observable defect that I've been trying to explain. Answers to your questions below. On Mon, Dec 9, 2024 at 10:27?PM Andy Goryachev wrote: > > OK, let's backtrack a bit. > > consider this example > https://urldefense.com/v3/__https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/ComboBox_Events.java__;!!ACWV5N9M2RV99hQ!LKECD0WK6vtwHmtgrjyLZtP8ewEdwKDErX57HgvozbPNhmM-FGxTjzFchI_2JaLjjbmfjDLtbAPuQ-n2C5uFsQa3hx6M$ > > it's a single combo box with application-level filters and handlers attached to scene, combo box, and the combo box editor. > > pressing and releasing a key, we get the following output: > > > user presses 'a' key > 1. stage filter: KEY_PRESSED h=913 target=876 > 2. combobox filter: KEY_PRESSED h=457 target=876 > 3. stage filter: KEY_PRESSED h=487 target=553 > 4. combobox filter: KEY_PRESSED h=123 target=553 > 5. editor filter: KEY_PRESSED h=372 target=553 > 6. editor handler: KEY_PRESSED h=372 consumed! target=553 > [...] > This output is very puzzling, please help me understand it. > > - with the exception of events logged from the editor, the events being sent are all different instances (h= prints the event's hashCode) Yes, each step of the event dispatch chain gets its own event instance. This is due to the immutable nature of the Event class, as on each step the source (and/or target) field must be changed; the way JavaFX does this is by copying the event instance and adjusting the fields in the process. > - where did the duplicate event in step 3 come from? step 9? step 15? That's the core of the issue. Here's what's happening, step by step: 1. ComboBox is the focus owner of the scene, so the KEY_PRESSED event is sent to the ComboBox. 2. ComboBox's skin has installed an event filter on ComboBox, and when it receives a key event, it consumes the event. This is why event dispatching stops after step 2 in your example. 3. However, it must forward the event to the TextField (as otherwise the TextField doesn't work), so it fires off a copy of the event targeted at TextField. The new event starts again at the root ("stage filter") and travels to the ComboBox ("combobox filter"). 4. When ComboBox receives the duplicate event, it inspects the target of the event, and realizes that it is targeted at the TextField. In this special case, the event is not consumed, but allowed to travel further. 5. Now the duplicate event reaches the TextField ("editor filter"), where nothing happens, and begins to bubble up ("editor handler"). This is where the event is consumed by the TextField I hope that you agree that the duplicated event, being visible to all listeners, is a defect. When a key is pressed once, a listener should not see two KEY_PRESSED events for the same key. > - why a consumed event is being dispatched to the editor in line 6? line 12? That's a bug. Consumed events are dispatched to all listeners on the same step of the event dispatch chain. I've often suggested that we finally fix this bug. > Maybe we should ask the question why in this case the Scene.focusOwner is the ComboBox, and not its editor, the TextField? Having the actual component that receives the input events to be the focus owner would eliminate the need for hacks in the skin to send events, wouldn't it? > > Or, if we say that's the grand design of javafx - that the skins must forward event copies to the skin constituents, then adding a handler to the top level control (combo box in this case) should result in that handler to be called before the skin's one, right? The core of JavaFX is just the scene graph, there's no concept of controls or skins (that's added by javafx.controls). I would say that a "skin", "shadow DOM", "internal/external" type of abstraction is a very useful abstraction, and JavaFX should support the creation of such abstractions. 1. When you have abstraction, you also want encapsulation. That means that the internal implementation of a control should not leak into its user model. Whether ComboBox contains a TextField, or whether it "custom draws" its text editor (for example, by writing pixels directly to a Canvas) shouldn't affect users of ComboBox. 2. From this it necessarily follows that the focus owner must always be the control, and not any part of its internal and opaque substructure. Users of ComboBox shouldn't have to change their code when they switch to a custom-drawing skin. 3. When the control is the focus owner, then it will receive all key events. We need a way to reconcile the JavaFX event system with the internal substructure, without exposing the internals to the outside world, and without changing the user model of the control. This is part of what focus delegation solves: it separates different levels of abstraction. It allows key events to be sent to the control, which is exactly what users of a control would expect. Every layer of abstraction will see exactly what it would expect to see: an event that is targeted at itself, not at some other thing. It also allows users to reason about events. For example, when a listener inspects a key event, it will see that the event is targeted at the ComboBox. If it was instead targeted at FakeFocusTextField, the listener couldn't reason about the event, as there is no such thing in the user model. > This, I think, brings us again to the discussion of event handling priority. BTW, you never responded to my questions in > https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050655.html I did: https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050753.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelstrau2 at gmail.com Tue Dec 10 02:16:45 2024 From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=) Date: Tue, 10 Dec 2024 03:16:45 +0100 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. I can't image that we would ever do this, considering that events have been there almost from the beginning. We'd break half of the JavaFX world if we changed the API of events. In addition to that, this would remove functionality. As of now, you can add a listener to Scene, and inspect which node is being targeted by an event. > > 2. ComboBox's skin has installed an event filter on ComboBox > > So we have another scenario where different priorities are needed: adding event filters. Maybe, but that's a different problem than what's being solved by focus delegation. Focus delegation is all about removing defective ad-hoc implementations, and offering a pre-made building block for composite controls. > > 3. However, it must forward the event to the TextField (as otherwise > the TextField doesn't work), so it fires off a copy of the event > targeted at TextField. > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. Sure, that would be an option. But it's not my preferred solution for the following reasons: 1. It's gratuitously different. Instead of using events like they normally work, control skins would punch a hole through the scene graph, and deliver the event directly to the delegation target. That means that the skin's scene graph works differently as the outside scene graph, as you can't observe events traveling through it. 2. It requires the skin to implement a complex protocol (register an event handler, copy the event, punch a hole through to the delegation target, send off the event), whereas the focus delegation proposal requires no additional implementation inside of the skin (aside from selecting the delegation target). The advantage of focus delegation is that it just works, even recursively, across arbitrary levels of abstractions (a skin might contain another control, which itself has a skin, and so on). No matter where you listen to events, you will always see exactly what you'd expect to see: an event that is targeted at the next focused node. This is another aspect of focus delegation, unrelated to events: it formalizes the notion of multi-level focus without resorting to hacks (like FakeFocusTextField). You'll need to solve this no matter what, as users can click on the TextField. As we discussed, the ComboBox must be the focus owner even when a user clicks on the TextField. > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. First of all, it's only one property (Node.hoistFocus), not a bunch. And this is not related to events at all, it is a way for skins to indicate that clicking on an internal node will focus the outside control. The part of focus delegation that fixes the delivery of events in a scene graph with potentially nested abstractions is done without any new properties. From duke at openjdk.org Tue Dec 10 03:55:44 2024 From: duke at openjdk.org (pe-3-6n) Date: Tue, 10 Dec 2024 03:55:44 GMT Subject: RFR: 8286831: WebView can't switch to Chinese input method in GTK3 In-Reply-To: References: Message-ID: On Sat, 7 Dec 2024 03:10:28 GMT, pe-3-6n wrote: > This PR fixes a bug where the can't switch input method in GTK3. Thank you for your comment. I read the PR to replace the obsolete XIM input method editor. I will close my PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1660#issuecomment-2530206970 From duke at openjdk.org Tue Dec 10 04:07:46 2024 From: duke at openjdk.org (pe-3-6n) Date: Tue, 10 Dec 2024 04:07:46 GMT Subject: Withdrawn: 8286831: WebView can't switch to Chinese input method in GTK3 In-Reply-To: References: Message-ID: <0279_xSlqbGIAYR6w64Fjjtf5it6h-RRnRyiNqKB5sk=.8e287074-cc8c-43a8-a9ed-c49e1f971afc@github.com> On Sat, 7 Dec 2024 03:10:28 GMT, pe-3-6n wrote: > This PR fixes a bug where the can't switch input method in GTK3. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1660 From jvos at openjdk.org Tue Dec 10 07:26:46 2024 From: jvos at openjdk.org (Johan Vos) Date: Tue, 10 Dec 2024 07:26:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v3] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 23:23:59 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction I checked the changes in VirtualFlow and those are ok. In general, we need a better approach to test and quantify performance, but realistically that should not be done as part of this PR. There are some tests in ListViewTest and TableViewTest that are based on the number of invocations of updateItem() (which is in most cases a good indication of performance), but they are mainly ad-hoc. In absence of those tests, I believe this PR is a good step in the good direction. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2530642219 From lkostyra at openjdk.org Tue Dec 10 08:55:44 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 10 Dec 2024 08:55:44 GMT Subject: Integrated: 8344114: Remove obsolete permission check methods from Font classes In-Reply-To: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> References: <_Yy154jGmev0StNL-vAqIa1blaLkSPGymcIl55obPZk=.86942d4d-2bda-420b-9af8-8b50ec00a8b7@github.com> Message-ID: On Fri, 6 Dec 2024 16:40:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission check methods and fields from Font-related classes. > > Verified the changes on Windows, did not see any regressions. This pull request has now been integrated. Changeset: ebeee751 Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/ebeee75191b14f0a9945f15e5ccc5fb5e9744817 Stats: 81 lines in 5 files changed: 0 ins; 81 del; 0 mod 8344114: Remove obsolete permission check methods from Font classes Reviewed-by: kcr, angorya ------------- PR: https://git.openjdk.org/jfx/pull/1659 From lkostyra at openjdk.org Tue Dec 10 08:56:45 2024 From: lkostyra at openjdk.org (Lukasz Kostyra) Date: Tue, 10 Dec 2024 08:56:45 GMT Subject: Integrated: 8344111: Remove obsolete permission check methods from javafx.graphics In-Reply-To: References: Message-ID: <4rkqeB1Xgc0cFuSHbcVdJx2TmE4lPfMZJ4WadLf0OUA=.4964aefc-07b7-41ef-bf95-7bd0a7ac1985@github.com> On Fri, 6 Dec 2024 16:38:14 GMT, Lukasz Kostyra wrote: > This PR removes obsolete permission checks from javafx.graphics _minus_ Font classes (handled by a separate PR). > > The only part I did not remove from methods/fields listed in the issue is `WindowStage.fullScreenFromUserEvent`. This flag seems quite extensively used and did not seem to have anything to do with permission checks. This pull request has now been integrated. Changeset: 8ae268fb Author: Lukasz Kostyra URL: https://git.openjdk.org/jfx/commit/8ae268fbe7b08c20a9c68d5f74389698e5e6ecf0 Stats: 319 lines in 12 files changed: 1 ins; 267 del; 51 mod 8344111: Remove obsolete permission check methods from javafx.graphics Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1658 From schernyshev at openjdk.org Tue Dec 10 09:34:03 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 10 Dec 2024 09:34:03 GMT Subject: [jfx17u] RFR: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 Message-ID: Hi, this PR fixes the build failure after backporting JDK-8336798 [1]. The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. [1] https://bugs.openjdk.org/browse/JDK-8336798 ------------- Commit messages: - 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 Changes: https://git.openjdk.org/jfx17u/pull/221/files Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=221&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345870 Stats: 48 lines in 1 file changed: 0 ins; 3 del; 45 mod Patch: https://git.openjdk.org/jfx17u/pull/221.diff Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/221/head:pull/221 PR: https://git.openjdk.org/jfx17u/pull/221 From duke at openjdk.org Tue Dec 10 09:56:00 2024 From: duke at openjdk.org (Helly Guo) Date: Tue, 10 Dec 2024 09:56:00 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> Message-ID: <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> On Mon, 9 Dec 2024 17:25:58 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/native-glass/gtk/glass_window_ime.cpp line 100: >> >>> 98: >>> 99: void WindowContextBase::commitIME(gchar *str) { >>> 100: if (im_ctx.on_preedit) { >> >> Through `LOG0`/`LOG1`, I found that the value of `im_ctx.on_preedit` is `false` under `fcitx`. >> I removed this check, then tested under `fcitx` and `ibus`. All passed. > > @hellyguo Could you provide more details on which Linux distribution, input method, and fcitx version you're using? > > I just tested this on Ubuntu 24.10. For Chinese I'm using Intelligent Pinyin and for Japanese I'm using Mozc. Everything worked under Ibus but when I switched to fcitx 4 both my Chinese and Japanese input methods stopped working for all apps, not just JavaFX. This makes me think that I'm not setting up fcitx correctly. I did reboot at each step as I changed the configuration. hi @beldenfox / @tsayao , thanks for response. here is my env. # uname -a Linux workdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux # cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" # fcitx5 -v 5.0.21 ![Screenshot from 2024-12-10 17-50-02](https://github.com/user-attachments/assets/c3b6139c-34d1-4422-9a6c-b8d06e4988bc) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1877751761 From kevin.rushforth at oracle.com Tue Dec 10 13:37:05 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Dec 2024 05:37:05 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: <0233d1d5-7fba-4f27-87d6-42e769e84e28@oracle.com> On 12/9/2024 6:16 PM, Michael Strau? wrote: >> Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. > I can't image that we would ever do this, considering that events have > been there almost from the beginning. We'd break half of the JavaFX > world if we changed the API of events. > In addition to that, this would remove functionality. As of now, you > can add a listener to Scene, and inspect which node is being targeted > by an event. I also don't see this ever happening. The rest of the discussion is a good one to continue, since there are multiple ways we might (compatibly) solve the problem at hand. -- Kevin >>> 2. ComboBox's skin has installed an event filter on ComboBox >> So we have another scenario where different priorities are needed: adding event filters. > Maybe, but that's a different problem than what's being solved by > focus delegation. Focus delegation is all about removing defective > ad-hoc implementations, and offering a pre-made building block for > composite controls. > > >>> 3. However, it must forward the event to the TextField (as otherwise >> the TextField doesn't work), so it fires off a copy of the event >> targeted at TextField. >> >> Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. > Sure, that would be an option. But it's not my preferred solution for > the following reasons: > 1. It's gratuitously different. Instead of using events like they > normally work, control skins would punch a hole through the scene > graph, and deliver the event directly to the delegation target. That > means that the skin's scene graph works differently as the outside > scene graph, as you can't observe events traveling through it. > 2. It requires the skin to implement a complex protocol (register an > event handler, copy the event, punch a hole through to the delegation > target, send off the event), whereas the focus delegation proposal > requires no additional implementation inside of the skin (aside from > selecting the delegation target). > > The advantage of focus delegation is that it just works, even > recursively, across arbitrary levels of abstractions (a skin might > contain another control, which itself has a skin, and so on). No > matter where you listen to events, you will always see exactly what > you'd expect to see: an event that is targeted at the next focused > node. This is another aspect of focus delegation, unrelated to events: > it formalizes the notion of multi-level focus without resorting to > hacks (like FakeFocusTextField). You'll need to solve this no matter > what, as users can click on the TextField. As we discussed, the > ComboBox must be the focus owner even when a user clicks on the > TextField. > > > >> Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. > First of all, it's only one property (Node.hoistFocus), not a bunch. > And this is not related to events at all, it is a way for skins to > indicate that clicking on an internal node will focus the outside > control. > > The part of focus delegation that fixes the delivery of events in a > scene graph with potentially nested abstractions is done without any > new properties. From azvegint at openjdk.org Tue Dec 10 16:26:57 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 10 Dec 2024 16:26:57 GMT Subject: RFR: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland Message-ID: This PR enables several previously disabled test cases for Wayland, as the required fixes are already in the promoted build. ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469), [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468)) ------------- Commit messages: - check JDK version - 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland Changes: https://git.openjdk.org/jfx/pull/1661/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1661&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335470 Stats: 22 lines in 3 files changed: 13 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1661.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1661/head:pull/1661 PR: https://git.openjdk.org/jfx/pull/1661 From kcr at openjdk.org Tue Dec 10 16:26:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Dec 2024 16:26:57 GMT Subject: RFR: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland In-Reply-To: References: Message-ID: <8pKOPoNO01nvRwqAQnceicRasTrtUVpASOSTAdi2-ng=.88bc4584-d480-44b1-aab0-35c3ddab8617@github.com> On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev wrote: > This PR enables several previously disabled test cases for Wayland, as the required fixes are already in the promoted build. ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469), [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468)) tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 59: > 57: @BeforeAll > 58: public static void init() throws Exception { > 59: Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470 You need to replace this with a version check for JDK >= 24 rather than just removing it or else this will fail (probably hang) when the tests are run on JDK 23. See [this JBS comment](https://bugs.openjdk.org/browse/JDK-8335470?focusedId=14722937&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14722937). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1661#discussion_r1878241310 From azvegint at openjdk.org Tue Dec 10 16:26:57 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Tue, 10 Dec 2024 16:26:57 GMT Subject: RFR: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland In-Reply-To: <8pKOPoNO01nvRwqAQnceicRasTrtUVpASOSTAdi2-ng=.88bc4584-d480-44b1-aab0-35c3ddab8617@github.com> References: <8pKOPoNO01nvRwqAQnceicRasTrtUVpASOSTAdi2-ng=.88bc4584-d480-44b1-aab0-35c3ddab8617@github.com> Message-ID: On Tue, 10 Dec 2024 14:49:34 GMT, Kevin Rushforth wrote: >> This PR enables several previously disabled test cases for Wayland, as the required fixes are already in the promoted build. ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469), [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468)) > > tests/system/src/test/java/test/robot/javafx/embed/swing/LinuxScreencastHangCrashTest.java line 59: > >> 57: @BeforeAll >> 58: public static void init() throws Exception { >> 59: Assumptions.assumeTrue(!Util.isOnWayland()); // JDK-8335470 > > You need to replace this with a version check for JDK >= 24 rather than just removing it or else this will fail (probably hang) when the tests are run on JDK 23. See [this JBS comment](https://bugs.openjdk.org/browse/JDK-8335470?focusedId=14722937&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14722937). Updated. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1661#discussion_r1878306642 From andy.goryachev at oracle.com Tue Dec 10 16:32:25 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 10 Dec 2024 16:32:25 +0000 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: Michael: Please help me understand. How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control? For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors. How would that work? In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on. Will the proposed design still work? If we presume the model in which the control is a monolithic entity, then we must accept the fact that there is a separate mechanism for the top level control to manipulate its skin constituents. How it is done is not that important - events, or direct method calls, not important. Since we don't often have direct methods, using the events is probably the easiest. My point is that the mechanism of isolating the parts of skin from the usual event handling is **necessary**, especially when it comes to bubbling of events up the hierarchy. Adding a bunch of methods trying to simulate that seems to be less optimal and more complicated. What do you think? -andy From: openjfx-dev on behalf of Michael Strau? Date: Monday, December 9, 2024 at 18:17 To: Cc: openjfx-dev Subject: Re: [External] : Re: Focus delegation API > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. I can't image that we would ever do this, considering that events have been there almost from the beginning. We'd break half of the JavaFX world if we changed the API of events. In addition to that, this would remove functionality. As of now, you can add a listener to Scene, and inspect which node is being targeted by an event. > > 2. ComboBox's skin has installed an event filter on ComboBox > > So we have another scenario where different priorities are needed: adding event filters. Maybe, but that's a different problem than what's being solved by focus delegation. Focus delegation is all about removing defective ad-hoc implementations, and offering a pre-made building block for composite controls. > > 3. However, it must forward the event to the TextField (as otherwise > the TextField doesn't work), so it fires off a copy of the event > targeted at TextField. > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. Sure, that would be an option. But it's not my preferred solution for the following reasons: 1. It's gratuitously different. Instead of using events like they normally work, control skins would punch a hole through the scene graph, and deliver the event directly to the delegation target. That means that the skin's scene graph works differently as the outside scene graph, as you can't observe events traveling through it. 2. It requires the skin to implement a complex protocol (register an event handler, copy the event, punch a hole through to the delegation target, send off the event), whereas the focus delegation proposal requires no additional implementation inside of the skin (aside from selecting the delegation target). The advantage of focus delegation is that it just works, even recursively, across arbitrary levels of abstractions (a skin might contain another control, which itself has a skin, and so on). No matter where you listen to events, you will always see exactly what you'd expect to see: an event that is targeted at the next focused node. This is another aspect of focus delegation, unrelated to events: it formalizes the notion of multi-level focus without resorting to hacks (like FakeFocusTextField). You'll need to solve this no matter what, as users can click on the TextField. As we discussed, the ComboBox must be the focus owner even when a user clicks on the TextField. > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. First of all, it's only one property (Node.hoistFocus), not a bunch. And this is not related to events at all, it is a way for skins to indicate that clicking on an internal node will focus the outside control. The part of focus delegation that fixes the delivery of events in a scene graph with potentially nested abstractions is done without any new properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstrauss at openjdk.org Tue Dec 10 17:49:04 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Dec 2024 17:49:04 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v33] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits: - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java - StyleableBooleanProperty -> BooleanProperty - Add HeaderBar.overlappingSystemInset property - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/TKScene.java # modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java - Merge branch 'master' into feature/extended-window - macOS: double-click action + fullscreen toolbar - remove unneeded dll - Merge branch 'master' into feature/extended-window # Conflicts: # modules/javafx.graphics/src/test/addExports - Merge branch 'master' into feature/extended-window - Merge branch 'master' into feature/extended-window - ... and 32 more: https://git.openjdk.org/jfx/compare/8ae268fb...af35dce8 ------------- Changes: https://git.openjdk.org/jfx/pull/1605/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=32 Stats: 5043 lines in 61 files changed: 4532 ins; 409 del; 102 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mhanl at openjdk.org Tue Dec 10 18:11:55 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 10 Dec 2024 18:11:55 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version Message-ID: The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. That is from `5.8.1` to `5.11.3`. Affected dependencies: - `junit.jupiter` - `junit.platform` - `opentest4j` Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ Note: I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. ------------- Commit messages: - Update JUnit Platform to newest version Changes: https://git.openjdk.org/jfx/pull/1662/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1662&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345937 Stats: 54 lines in 2 files changed: 0 ins; 0 del; 54 mod Patch: https://git.openjdk.org/jfx/pull/1662.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1662/head:pull/1662 PR: https://git.openjdk.org/jfx/pull/1662 From kcr at openjdk.org Tue Dec 10 18:22:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Dec 2024 18:22:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v56] In-Reply-To: References: Message-ID: On Thu, 5 Dec 2024 21:02:35 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 77 commits: > > - clamp > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - review comments > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - whitespace > - since 24 > - ... and 67 more: https://git.openjdk.org/jfx/compare/a431801c...84cb0384 Several public classes under the following directory tree are missing `@since` javadoc tags: modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/ Here is s list of classes with missing `@since` tags: CodeArea.java LineNumberDecorator.java Marker.java SelectionModel.java SelectionSegment.java SideDecorator.java SingleSelectionModel.java StyleAttributeHandler.java StyleHandlerRegistry.java StyleResolver.java SyntaxDecorator.java TextPos.java model/BasicTextModel.java model/CodeTextModel.java model/DataFormatHandler.java model/HtmlExportFormatHandler.java model/ParagraphDirection.java model/PlainTextFormatHandler.java model/RichParagraph.java model/RichTextFormatHandler.java model/RichTextModel.java model/RtfFormatHandler.java model/SimpleViewOnlyStyledModel.java model/StyleAttribute.java model/StyleAttributeMap.java model/StyledInput.java model/StyledOutput.java model/StyledSegment.java model/StyledTextModelViewOnlyBase.java skin/CellContext.java skin/CodeAreaSkin.java skin/RichTextAreaSkin.java Additional related comments are inline. apps/samples/RichTextAreaDemo/src/com/oracle/demo/richtext/editor/settings/EndKey.java line 6: > 4: * > 5: * This code is free software; you can redistribute it and/or modify it > 6: * under the terms of the GNU General Public License version 2 only, as Since this is under `apps/samples` it should have a BSD license. apps/samples/RichTextAreaDemo/src/com/oracle/demo/richtext/util/HasDisplayText.java line 6: > 4: * > 5: * This code is free software; you can redistribute it and/or modify it > 6: * under the terms of the GNU General Public License version 2 only, as Since this is under `apps/samples` it should have a BSD license. modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/BehaviorBase.java line 65: > 63: * > 64: * @param the type of the control > 65: * @since 24 Remove the `@since` tag since this is not public API. modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/EventCriteria.java line 34: > 32: * > 33: * @param the type of the event > 34: * @since 24 Remove the `@since` tag since this is not public API. modules/jfx.incubator.input/src/main/java/com/sun/jfx/incubator/scene/control/input/SkinInputMap.java line 50: > 48: * could use a Stateless variant obtained with the {@link #createStateless()} method. > 49: * > 50: * @since 24 Remove the `@since` tag since this is not public API. modules/jfx.incubator.input/src/main/java/module-info.java line 34: > 32: * > 33: * @moduleGraph > 34: * @since 999 s/999/24/ modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/rtf/charsets/NeXT.txt line 1: > 1: /* the character set used for the \ansi control word in NeXT-rtf mode */ This file should be moved to: modules/jfx.incubator.richtext/src/main/resources/com/sun/jfx/incubator/scene/control/richtext/rtf/charsets/ along with the other `.txt` resource files. modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/ImgUtil.java line 69: > 67: * @return an {@code Image} object representing a snapshot of the > 68: * current pixels in the {@code BufferedImage}. > 69: * @since JavaFX 2.2 Remove the `@since` tag since this is not public API. modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/util/ImgUtil.java line 240: > 238: * @return a {@code BufferedImage} containing a snapshot of the JavaFX > 239: * {@code Image}, or null if the {@code Image} is not readable. > 240: * @since JavaFX 2.2 Remove the `@since` tag since this is not public API. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java line 83: > 81: * > 82: */ > 83: public class CodeArea extends RichTextArea { This class is missing an `@since 24` tag, along with several other classes. I'll provide a list in my review comment. modules/jfx.incubator.richtext/src/main/java/module-info.java line 33: > 31: * > 32: * @moduleGraph > 33: * @since 999 s/999/24/ ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2493162022 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878598349 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878599896 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878585381 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878586046 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878586928 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878580097 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878605431 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878589267 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878590433 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878595562 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878580815 From mstrauss at openjdk.org Tue Dec 10 18:48:05 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Dec 2024 18:48:05 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v34] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix system menu for non-resizeable extended window ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/af35dce8..65230730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=33 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=32-33 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From angorya at openjdk.org Tue Dec 10 18:59:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 18:59:31 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v57] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - clamp - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - review comments - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - ... and 69 more: https://git.openjdk.org/jfx/compare/8ae268fb...7b66cdac ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=56 Stats: 39936 lines in 208 files changed: 39926 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From mstrauss at openjdk.org Tue Dec 10 19:13:09 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Dec 2024 19:13:09 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v35] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: add StageStyle.EXTENDED_UTILITY ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/65230730..8d5d7b87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=34 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=33-34 Stats: 77 lines in 9 files changed: 55 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From angorya at openjdk.org Tue Dec 10 19:46:13 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 19:46:13 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v58] In-Reply-To: References: Message-ID: <8Dg9-TaCcEEvuEMCv71GPPSsNisrakX1QvngXngKrdg=.c313e3ab-1978-4830-b2fb-fb1f3354b651@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: add handler ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/7b66cdac..db428962 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=57 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=56-57 Stats: 145 lines in 4 files changed: 0 ins; 130 del; 15 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Dec 10 20:00:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 20:00:47 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v59] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: unicode license ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/db428962..5ad1eebe Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=58 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=57-58 Stats: 268 lines in 1 file changed: 268 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Dec 10 20:41:19 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 20:41:19 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v60] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: legal ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/5ad1eebe..29154372 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=59 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=58-59 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Dec 10 20:53:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 20:53:45 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v3] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 23:23:59 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl 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' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction looks good, thanks! scrolling performance is not an issue: the horizontal one has improved, and the vertical one is on par with the master. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1644#pullrequestreview-2493575747 From kcr at openjdk.org Tue Dec 10 21:11:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 10 Dec 2024 21:11:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v60] In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 20:41:19 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > legal The updates look good. And thanks for adding the missing Unicode third-party readme file as discussed offline. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2532896950 From angorya at openjdk.org Tue Dec 10 21:13:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 21:13:45 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Mon, 9 Dec 2024 23:55:01 GMT, Marius Hanl wrote: >> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners. >> >> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set. >> >> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745). >> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect. > > Marius Hanl 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 three additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup > - Call getFixedCellSize() once > - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 421: > 419: } else { > 420: width = tableCell.prefWidth(height); > 421: // we only add/remove to the scenegraph if the fixed cell are you sure this is correct? the tableCell is added in L343 only if `fixedCellSize > 0` the removal in L424 misses that logic ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1878861083 From mhanl at openjdk.org Tue Dec 10 21:58:43 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 10 Dec 2024 21:58:43 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Tue, 10 Dec 2024 21:10:54 GMT, Andy Goryachev wrote: >> Marius Hanl 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 three additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jfx into 8277000-tree-table-row-skin-live-lookup >> - Call getFixedCellSize() once >> - 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup > > modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 421: > >> 419: } else { >> 420: width = tableCell.prefWidth(height); >> 421: // we only add/remove to the scenegraph if the fixed cell > > are you sure this is correct? > the tableCell is added in L343 only if `fixedCellSize > 0` > the removal in L424 misses that logic Yes, IntelliJ actually gave me the hint. `isVisible` can only be `false`, when a `fixedCellSize` is set. So the else branch can only ever be executed when `fixedCellSize > 0` ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1878932051 From angorya at openjdk.org Tue Dec 10 22:05:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 22:05:43 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Tue, 10 Dec 2024 21:56:07 GMT, Marius Hanl wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java line 421: >> >>> 419: } else { >>> 420: width = tableCell.prefWidth(height); >>> 421: // we only add/remove to the scenegraph if the fixed cell >> >> are you sure this is correct? >> the tableCell is added in L343 only if `fixedCellSize > 0` >> the removal in L424 misses that logic > > Yes, IntelliJ actually gave me the hint. > `isVisible` can only be `false`, when a `fixedCellSize` is set. So the else branch can only ever be executed when `fixedCellSize > 0` it's hard to tell (for me): there are just too many conditions: isColumnParticallyOrFullVisible(), if parent == null... ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1878954208 From mstrauss at openjdk.org Tue Dec 10 22:12:29 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 10 Dec 2024 22:12:29 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v36] In-Reply-To: References: Message-ID: > Implementation of [`EXTENDED` stage style](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09). Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: fix resizable states for GTK windows ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1605/files - new: https://git.openjdk.org/jfx/pull/1605/files/8d5d7b87..eaafd9f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=35 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=34-35 Stats: 62 lines in 4 files changed: 23 ins; 20 del; 19 mod Patch: https://git.openjdk.org/jfx/pull/1605.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605 PR: https://git.openjdk.org/jfx/pull/1605 From mhanl at openjdk.org Tue Dec 10 22:31:47 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 10 Dec 2024 22:31:47 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Tue, 10 Dec 2024 22:03:04 GMT, Andy Goryachev wrote: >> Yes, IntelliJ actually gave me the hint. >> `isVisible` can only be `false`, when a `fixedCellSize` is set. So the else branch can only ever be executed when `fixedCellSize > 0` > > it's hard to tell (for me): there are just too many conditions: isColumnParticallyOrFullVisible(), if parent == null... It will be much better after https://github.com/openjdk/jfx/pull/1644 :) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1879003014 From angorya at openjdk.org Tue Dec 10 23:30:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 23:30:46 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Tue, 10 Dec 2024 22:28:46 GMT, Marius Hanl wrote: >> it's hard to tell (for me): there are just too many conditions: isColumnParticallyOrFullVisible(), if parent == null... > > It will be much better after https://github.com/openjdk/jfx/pull/1644 :) can you apply the same treatment as in #1644? there at least it makes sense. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1879067415 From angorya at openjdk.org Tue Dec 10 23:36:30 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 10 Dec 2024 23:36:30 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v13] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 24 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: > > > /** > * Returns the shape for the strike-through in local coordinates. > * > * @param start the beginning character index for the range > * @param end the end character index (non-inclusive) for the range > * @return an array of {@code PathElement} which can be used to create a {@code Shape} > * @since 24 > */ > public final PathElement[] strikeThroughShape(int start, int end) > > > ## Discussion Points > > - it is unclear whether CaretInfo.getPartAt() should return a simple Rectangle2D or a more complex object similar to TextLineInfo, to be able to add more information, such as the nature of text, text direction, etc. > > > ## WARNING > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/Rich... Andy Goryachev 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 36 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge branch 'master' into ag.text.layout.api - segments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - coordinates - note - text layout test - text flow test - shorter array - ... and 26 more: https://git.openjdk.org/jfx/compare/b106b0da...2a3a754a ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/1dd2b0cf..2a3a754a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=12 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=11-12 Stats: 518 lines in 19 files changed: 119 ins; 348 del; 51 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From kcr at openjdk.org Wed Dec 11 00:30:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Dec 2024 00:30:44 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. Because this has third-party and build implications, I need to review it. Since it is a test-only usage (we don't distribute anything from it), we don't need to get new approval as long as the license is unchanged (I'll double-check). Reviewers: @kevinrushforth @arapte > got a test failure once in ServiceLifecycleTest. Not sure yet if related to the update or not. I doubt it. There is at least one test there that is prone to intermittent failures on some (usually slower) systems. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2533343033 PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2533343804 From kcr at openjdk.org Wed Dec 11 00:32:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Dec 2024 00:32:45 GMT Subject: RFR: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev wrote: > This PR enables several previously disabled test cases for Wayland, as the required fixes are already in the promoted build. ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469), [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468)) Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1661#pullrequestreview-2494014163 From azvegint at openjdk.org Wed Dec 11 13:55:46 2024 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Wed, 11 Dec 2024 13:55:46 GMT Subject: Integrated: 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 14:10:23 GMT, Alexander Zvegintsev wrote: > This PR enables several previously disabled test cases for Wayland, as the required fixes are already in the promoted build. ([JDK-8335469](https://bugs.openjdk.org/browse/JDK-8335469), [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468)) This pull request has now been integrated. Changeset: b76c05b9 Author: Alexander Zvegintsev URL: https://git.openjdk.org/jfx/commit/b76c05b9356656c1bd6a4a7026b858d3a935a51f Stats: 22 lines in 3 files changed: 13 ins; 8 del; 1 mod 8335470: [XWayland] JavaFX tests that use AWT Robot fail on Wayland Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1661 From angorya at openjdk.org Wed Dec 11 16:07:18 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 16:07:18 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: On Wed, 4 Dec 2024 15:55:20 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactor macOS PlatformSupport Does not seem to work on macOS 15.1.1 M1: ![Screenshot 2024-12-11 at 08 00 31](https://github.com/user-attachments/assets/a0087e53-e577-4818-af94-47dc4b43ab7e) ![Screenshot 2024-12-11 at 08 04 13](https://github.com/user-attachments/assets/79333a7d-96ac-426d-af4e-3676670ef990) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536406715 PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536413085 From mstrauss at openjdk.org Wed Dec 11 16:20:16 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 16:20:16 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 16:02:27 GMT, Andy Goryachev wrote: > Does not seem to work on macOS 15.1.1 M1: It works on my 14.6 machine. Let me try upgrading and testing again... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536440408 From angorya at openjdk.org Wed Dec 11 16:20:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 16:20:17 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: <370I_gUa2E254EfBxNXs4anWsNDagCg0UCUbD2DdjEY=.f0598b57-2294-4103-8864-dc3ca199dba8@github.com> On Wed, 4 Dec 2024 15:55:20 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > refactor macOS PlatformSupport I might suggest adding the instructions on how to control the platform settings as comments somewhere in the implementation. Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection (I've merged the latest master prior to testing) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536445211 PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536446875 From mstrauss at openjdk.org Wed Dec 11 16:31:06 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 16:31:06 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? 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 seven additional commits since the last revision: - Merge branch 'master' into feature/reduced-data - refactor macOS PlatformSupport - javadoc change - error message tweak - add macOS implementation - add linux implementation - Implementation of reducedData ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/8b8b1bdb..455613f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=02-03 Stats: 704 lines in 26 files changed: 292 ins; 356 del; 56 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mfox at openjdk.org Wed Dec 11 16:48:26 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 11 Dec 2024 16:48:26 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> Message-ID: On Tue, 10 Dec 2024 09:52:38 GMT, Helly Guo wrote: >> @hellyguo Could you provide more details on which Linux distribution, input method, and fcitx version you're using? >> >> I just tested this on Ubuntu 24.10. For Chinese I'm using Intelligent Pinyin and for Japanese I'm using Mozc. Everything worked under Ibus but when I switched to fcitx 4 both my Chinese and Japanese input methods stopped working for all apps, not just JavaFX. This makes me think that I'm not setting up fcitx correctly. I did reboot at each step as I changed the configuration. > > hi @beldenfox / @tsayao , thanks for response. > > here is my env. > > > # uname -a > Linux workdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux > > # cat /etc/os-release > PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" > NAME="Debian GNU/Linux" > VERSION_ID="12" > VERSION="12 (bookworm)" > VERSION_CODENAME=bookworm > ID=debian > HOME_URL="https://www.debian.org/" > SUPPORT_URL="https://www.debian.org/support" > BUG_REPORT_URL="https://bugs.debian.org/" > > # fcitx5 -v > 5.0.21 > > > ![Screenshot from 2024-12-10 17-50-02](https://github.com/user-attachments/assets/c3b6139c-34d1-4422-9a6c-b8d06e4988bc) @hellyguo I can't reproduce the problem you're seeing. I configured a Debian Bookworm system with Fcitx5 and Pinyin and tested this PR and everything worked. The Linux and Fcitx version numbers are the same as yours. I also installed fcitx5 on my existing Ubuntu 24.10 system and it worked there, also. The behavior seems a little odd but it matches the behavior of other Linux apps (I see Roman letters inserted into the JavaFX TextField until I select Chinese text in the IM). In your screen capture the input method window was clearly in the wrong location but in my testing it was correctly positioned near the JavaFX caret. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1880546240 From mstrauss at openjdk.org Wed Dec 11 17:47:21 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 17:47:21 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 16:15:05 GMT, Michael Strau? wrote: > Does not seem to work on macOS 15.1.1 M1: It also works on 15.1.1 on my machine. Just to check the obvious: did you close the WiFi Details window? The settings are only applied when you click OK. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536683607 From mfox at openjdk.org Wed Dec 11 17:50:27 2024 From: mfox at openjdk.org (Martin Fox) Date: Wed, 11 Dec 2024 17:50:27 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: <8oAJ-g8KBGK8YxA27qC31oPQz6YxlZYZ6ZNllCZ22is=.9b46f035-8d88-4a2a-a17f-69fc6879517d@github.com> On Wed, 4 Dec 2024 14:39:55 GMT, Martin Fox wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/InputMethodStateManager.java line 48: >> >>> 46: * PopupWindow. >>> 47: */ >>> 48: public class InputMethodStateManager { >> >> All this feels overly complicated - >> >> Why do we need to keep a list of scenes? Can't we get this information indirectly `from Window.getWindows()` ? >> >> Since the `PopupWindow` has the `ownerWindowProperty`, could we simply listen to the focusOwner property and get the "root" window and its scene by traversing the hierarchy? Do we really need to maintain derived lists when the InputMethodRequests is only needed during the handling of a specific event? > > I don't like trying to maintain derived lists either. What you're proposing is an interesting idea but I won't have time to work out the details until next week. > Why do we need to keep a list of scenes? Can't we get this information indirectly `from Window.getWindows()` ? We need to recalculate the IM state whenever a PopupWindow is shown or hidden (because the set of focusOwners changes). In this PR I'm relying on the existing logic in the PopupWindow class to track when scenes are added or removed so I can match when the PopupWindow starts and stops event monitoring. This is done via the addScene and removeScene calls in the InputMethodStateManager. In theory I could track the coming and going of scenes by monitoring window ownership lists. This would be complicated since it's recursive. The root scene's window only owns the first popup. If another popup is shown it's owned by the popup below it. I would have to attach change listeners to the root scene's window list, scan the list for popups, and then recursively add change listeners to their window lists. I would much rather track what the PopupWindow class is already doing rather than try to implement an entirely separate mechanism. Given that I rely on the PopupWindow code to tell me when scenes come and go it's expedient to just keep a list of the scenes around. I suppose I could remove that list and instead work my way recursively through the window ownership lists but I don't think there's much to be gained by that. > Since the `PopupWindow` has the `ownerWindowProperty`, could we simply listen to the focusOwner property and get the "root" window and its scene by traversing the hierarchy? The listeners attached to the focusOwner property are triggered too late in the process. The current system updates the OS state (via finishInputMethodComposition and enableInputMethodEvents) at very specific points in time and I don't want to disturb that. In particular all of this happens before we trigger the change listeners on the focusOwner property. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1880650779 From angorya at openjdk.org Wed Dec 11 18:00:25 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 18:00:25 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: <2uWciC-EmFCclTg5dIj0NaC3dJNAvMn_0YE6mMcwUmc=.abdda9c7-1acb-438c-8255-db73fb98dd8b@github.com> On Wed, 11 Dec 2024 16:31:06 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 seven additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - refactor macOS PlatformSupport > - javadoc change > - error message tweak > - add macOS implementation > - add linux implementation > - Implementation of reducedData Update: I was getting interference from the VPN application. Getting off the VPN helped - I see the property and `macOS.*.currentPathConstrained` key being toggled. (`macOS.*.currentPathExpensive` remains false). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536710762 From mstrauss at openjdk.org Wed Dec 11 18:13:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 18:13:17 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: <2uWciC-EmFCclTg5dIj0NaC3dJNAvMn_0YE6mMcwUmc=.abdda9c7-1acb-438c-8255-db73fb98dd8b@github.com> References: <2uWciC-EmFCclTg5dIj0NaC3dJNAvMn_0YE6mMcwUmc=.abdda9c7-1acb-438c-8255-db73fb98dd8b@github.com> Message-ID: On Wed, 11 Dec 2024 17:58:01 GMT, Andy Goryachev wrote: > Update: I was getting interference from the VPN application. Getting off the VPN helped - I see the property and `macOS.*.currentPathConstrained` key being toggled. > > (`macOS.*.currentPathExpensive` remains false). That's the expected result. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536736463 From mstrauss at openjdk.org Wed Dec 11 18:17:17 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 18:17:17 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: <370I_gUa2E254EfBxNXs4anWsNDagCg0UCUbD2DdjEY=.f0598b57-2294-4103-8864-dc3ca199dba8@github.com> References: <370I_gUa2E254EfBxNXs4anWsNDagCg0UCUbD2DdjEY=.f0598b57-2294-4103-8864-dc3ca199dba8@github.com> Message-ID: On Wed, 11 Dec 2024 16:17:04 GMT, Andy Goryachev wrote: > I might suggest adding the instructions on how to control the platform settings as comments somewhere in the implementation. > > ``` > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > ``` I feel this wouldn't age well, considering that the particular UI used by the different operating systems has often changed over the years. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2536762542 From angorya at openjdk.org Wed Dec 11 18:40:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 18:40:16 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 16:31:06 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 seven additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - refactor macOS PlatformSupport > - javadoc change > - error message tweak > - add macOS implementation > - add linux implementation > - Implementation of reducedData It looks like the scope of this change goes far beyond adding a few properties. It looks like a non-trivial refactoring that might also impact other platform preferences. I did check that switching between light/dark modes on macOS results in proper updates, but the native code needs to be re-reviewed. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 190: > 188: { > 189: // unblock main thread. Glass is started at this point. > 190: self->platformSupport = [[PlatformSupport alloc] initWithEnv:env application:jApplication]; should we check for failure here? (alloc) ------------- PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2496523969 PR Review Comment: https://git.openjdk.org/jfx/pull/1656#discussion_r1880713286 From mstrauss at openjdk.org Wed Dec 11 19:23:07 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 19:23:07 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: <1n7LZGANPgjXRXeMKCstJn3hot67VvpGEIpdZbr3AKY=.c814697e-ffbd-42e3-90cf-4b9c367a841b@github.com> On Wed, 11 Dec 2024 18:33:10 GMT, Andy Goryachev wrote: >> Michael Strau? 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 seven additional commits since the last revision: >> >> - Merge branch 'master' into feature/reduced-data >> - refactor macOS PlatformSupport >> - javadoc change >> - error message tweak >> - add macOS implementation >> - add linux implementation >> - Implementation of reducedData > > modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 190: > >> 188: { >> 189: // unblock main thread. Glass is started at this point. >> 190: self->platformSupport = [[PlatformSupport alloc] initWithEnv:env application:jApplication]; > > should we check for failure here? (alloc) We never do that in obj-c native code, so this probably wouldn't be the place to start. In any case, a failure at this point wouldn't lead to a crash, as the only access of `platformSupport` checks for `nil`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1656#discussion_r1880762924 From angorya at openjdk.org Wed Dec 11 20:11:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 20:11:46 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: <370I_gUa2E254EfBxNXs4anWsNDagCg0UCUbD2DdjEY=.f0598b57-2294-4103-8864-dc3ca199dba8@github.com> Message-ID: On Wed, 11 Dec 2024 18:14:40 GMT, Michael Strau? wrote: > I feel this wouldn't age well, considering that the particular UI used by the different operating systems has often changed over the years. I think it has merit. Now that we need to re-test the functionality, it would have helped. Even when something changes, it will be easier to look up a few missing pieces than dig through the PRs... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2537006251 From kcr at openjdk.org Wed Dec 11 20:29:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Dec 2024 20:29:42 GMT Subject: RFR: 8343398: Add reducedData preference [v3] In-Reply-To: References: <370I_gUa2E254EfBxNXs4anWsNDagCg0UCUbD2DdjEY=.f0598b57-2294-4103-8864-dc3ca199dba8@github.com> Message-ID: On Wed, 11 Dec 2024 20:08:50 GMT, Andy Goryachev wrote: > > I feel this wouldn't age well, considering that the particular UI used by the different operating systems has often changed over the years. > > I think it has merit. Now that we need to re-test the functionality, it would have helped. Even when something changes, it will be easier to look up a few missing pieces than dig through the PRs... I think this sort of information is better suited for a Wiki. Btw, I can review the native code changes. Just not for a couple days. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2537061868 From angorya at openjdk.org Wed Dec 11 20:36:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 20:36:44 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 16:31:06 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 seven additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - refactor macOS PlatformSupport > - javadoc change > - error message tweak > - add macOS implementation > - add linux implementation > - Implementation of reducedData tested macOS behavior, all is well. BTW, I've updated the Monkey Tester to highlight changes in Tools -> Platform Preferences Monitor. https://github.com/andy-goryachev-oracle/MonkeyTest ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2537079089 From angorya at openjdk.org Wed Dec 11 20:41:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 20:41:42 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 16:31:06 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 seven additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - refactor macOS PlatformSupport > - javadoc change > - error message tweak > - add macOS implementation > - add linux implementation > - Implementation of reducedData tested on macOS. needs testing on linux and windows. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2496861928 From kcr at openjdk.org Wed Dec 11 20:41:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 11 Dec 2024 20:41:43 GMT Subject: RFR: 8343398: Add reducedData preference [v4] In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 20:33:43 GMT, Andy Goryachev wrote: > BTW, I've updated the Monkey Tester to highlight changes in Tools -> Platform Preferences Monitor. > > https://github.com/andy-goryachev-oracle/MonkeyTest That seems useful. Thanks. > tested on macOS. needs testing on linux and windows. I can test Windows and Linux (I'll skip macOS since you've already done that). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2537094984 From angorya at openjdk.org Wed Dec 11 21:34:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 11 Dec 2024 21:34:49 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: Message-ID: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - legal - unicode license - add handler - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - clamp - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - review comments - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=60 Stats: 40075 lines in 209 files changed: 40065 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From mstrauss at openjdk.org Wed Dec 11 22:04:34 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 11 Dec 2024 22:04:34 GMT Subject: RFR: 8343398: Add reducedData preference [v5] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: changed formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/455613f0..4bfcb337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=04 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=03-04 Stats: 17 lines in 1 file changed: 3 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Thu Dec 12 01:03:26 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Dec 2024 01:03:26 GMT Subject: RFR: 8343398: Add reducedData preference [v6] In-Reply-To: References: Message-ID: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/4bfcb337..cbd3cb63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=05 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Thu Dec 12 01:11:51 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Dec 2024 01:11:51 GMT Subject: RFR: 8313424: JavaFX controls in the title bar [v36] In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 22:12:29 GMT, Michael Strau? wrote: >> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > fix resizable states for GTK windows I've added the `EXTENDED_UTILITY` stage style, which is basically the same as `EXTENDED`, but presented as a utility window (like `UTILITY`). Both stage styles should go in the same PR, as they are merely two facets of the same underlying implementation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2537525783 From duke at openjdk.org Thu Dec 12 01:20:44 2024 From: duke at openjdk.org (duke) Date: Thu, 12 Dec 2024 01:20:44 GMT Subject: Withdrawn: 8301761: The sorting of the SortedList can become invalid In-Reply-To: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> References: <1iwxjULvCm-S5rJ8NRWCI2WbWsgvVnX7-cUpv371tlE=.ab1dcee5-1df5-417b-ad8f-76f89d41e50a@github.com> Message-ID: On Sun, 28 Jul 2024 04:13:30 GMT, Loay Ghreeb wrote: > Fix an issue in `SortedList` where the sorting became incorrect when adding new items that are equal to existing items according to the comparator. The `SortedList` should consider the insertion index of these items to maintain the correct order. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1519 From craigraw at gmail.com Thu Dec 12 09:51:35 2024 From: craigraw at gmail.com (Craig Raw) Date: Thu, 12 Dec 2024 11:51:35 +0200 Subject: test SDKs for headless builds In-Reply-To: References: Message-ID: Hi Johan, I managed to solve this - I forgot (again) that javafx.graphics.jar does not contain the native libraries, and you have to repackage the jar to include them manually. Once I did this, everything worked successfully. I'm hoping the headless glass platform makes it into the JavaFX 24 release! Craig On Thu, Nov 21, 2024 at 2:11?PM Craig Raw wrote: > Thanks Johan, great to see this moving forward. > > I tested the mac-aarch64 and linux-x86_64 SDKs, and had no problems when > running the application using a Gradle build. > > When I jpackaged the application however, I got the following on launch. > I'm a little uncertain if there was anything else I was doing when this > worked in April, but I am setting -Dglass.platform=Headless as a JVM arg. > > Graphics Device initialization failed for : es2, sw > Error initializing QuantumRenderer: no suitable pipeline found > java.lang.RuntimeException: java.lang.RuntimeException: Error initializing > QuantumRenderer: no suitable pipeline found > at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumToolkit.init(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.tk.Toolkit.getToolkit(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.application.PlatformImpl.startup(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.application.PlatformImpl.startup(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.startToolkit(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$0(Unknown > Source) > at java.base/java.lang.Thread.run(Unknown Source) > Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: > no suitable pipeline found > at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(Unknown > Source) > at javafx.graphics at 24-headless/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(Unknown > Source) > ... 1 more > > Craig > > > On Wed, Nov 20, 2024 at 8:59?PM Johan Vos wrote: > >> Hi, >> >> Now that JDK-8343196 [1] (Add build property to identify experimental >> builds of JavaFX) is integrated, I added a jfx.experimental.feature.name >> property in the headless branch of the sandbox [2] and set that to >> "headless" >> >> Based on that commit, we created builds, and the SDKs containing the >> headless glass platform are available at those urls: >> >> >> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-aarch64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_linux-x86_64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-aarch64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_mac-x86_64_bin-sdk.zip >> >> https://download2.gluonhq.com/openjfx/forks/johan/headless/openjfx-24+77_headless_windows-x86_64_bin-sdk.zip >> >> The system property "javafx.version" returns "24-headless" and >> "javafx.runtime.version" returns "24-headless+844-2024-11-20-125652" on my >> linux-x86_64. >> >> Especially developers who currently use monocle to do headless work are >> recommended to give those test SDKs a try and to report. >> >> Thanks, >> >> - Johan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8343196 >> [2] https://github.com/openjdk/jfx-sandbox/commits/johanvos-headless/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Dec 12 10:17:53 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 12 Dec 2024 10:17:53 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> Message-ID: On Wed, 11 Dec 2024 16:46:02 GMT, Martin Fox wrote: >> hi @beldenfox / @tsayao , thanks for response. >> >> here is my env. >> >> >> # uname -a >> Linux workdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux >> >> # cat /etc/os-release >> PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" >> NAME="Debian GNU/Linux" >> VERSION_ID="12" >> VERSION="12 (bookworm)" >> VERSION_CODENAME=bookworm >> ID=debian >> HOME_URL="https://www.debian.org/" >> SUPPORT_URL="https://www.debian.org/support" >> BUG_REPORT_URL="https://bugs.debian.org/" >> >> # fcitx5 -v >> 5.0.21 >> >> >> ![Screenshot from 2024-12-10 17-50-02](https://github.com/user-attachments/assets/c3b6139c-34d1-4422-9a6c-b8d06e4988bc) > > @hellyguo I can't reproduce the problem you're seeing. I configured a Debian Bookworm system with Fcitx5 and Pinyin and tested this PR and everything worked. The Linux and Fcitx version numbers are the same as yours. I also installed fcitx5 on my existing Ubuntu 24.10 system and it worked there, also. > > The behavior seems a little odd but it matches the behavior of other Linux apps (I see Roman letters inserted into the JavaFX TextField until I select Chinese text in the IM). In your screen capture the input method window was clearly in the wrong location but in my testing it was correctly positioned near the JavaFX caret. @beldenfox , you are right. I created a brand new env in virt-manager: virt at virtdeb:~$ uname -a Linux virtdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux virt at virtdeb:~$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" virt at virtdeb:~$ java -version openjdk version "23.0.1" 2024-10-15 OpenJDK Runtime Environment (build 23.0.1+11-39) OpenJDK 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing) virt at virtdeb:~$ fcitx5 -v 5.0.21 After tested, I found that what you said is true. Forgot what I said, go ahead. Thanks again for your(@tsayao / @beldenfox ) amazing working. [Screencast from 2024-12-12 17-55-44.webm](https://github.com/user-attachments/assets/d2935d8a-9a5a-4603-a9d0-23f59b2b8f4d) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1881781253 From duke at openjdk.org Thu Dec 12 11:43:55 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 12 Dec 2024 11:43:55 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> Message-ID: On Thu, 12 Dec 2024 11:38:37 GMT, Helly Guo wrote: >> @beldenfox , you are right. >> I created a brand new env in virt-manager: >> >> >> virt at virtdeb:~$ uname -a >> Linux virtdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux >> >> virt at virtdeb:~$ cat /etc/os-release >> PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" >> NAME="Debian GNU/Linux" >> VERSION_ID="12" >> VERSION="12 (bookworm)" >> VERSION_CODENAME=bookworm >> ID=debian >> HOME_URL="https://www.debian.org/" >> SUPPORT_URL="https://www.debian.org/support" >> BUG_REPORT_URL="https://bugs.debian.org/" >> >> virt at virtdeb:~$ java -version >> openjdk version "23.0.1" 2024-10-15 >> OpenJDK Runtime Environment (build 23.0.1+11-39) >> OpenJDK 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing) >> >> virt at virtdeb:~$ fcitx5 -v >> 5.0.21 >> >> >> After tested, I found that what you said is true. Forgot what I said, go ahead. >> >> Thanks again for your(@tsayao / @beldenfox ) amazing working. >> [Screencast from 2024-12-12 17-55-44.webm](https://github.com/user-attachments/assets/d2935d8a-9a5a-4603-a9d0-23f59b2b8f4d) > > Finally, I got the point. Fcitx5 has a setting entry: `Show preedit in application`. If this is on, it works well. If this is off, the value `im_ctx.on_preedit` will get `false` when im(`fcitx5`) finished input-action. Then, the input will not show in the TextField. > > ![wechat_2024-12-12_193021_345](https://github.com/user-attachments/assets/9cab3844-8166-43fe-b69d-bda00f422e90) ![pic_20241212193112](https://github.com/user-attachments/assets/7b9233f9-3af5-42d5-89f9-9f85248d68dd) The option is surrounded by a red box. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1881906512 From duke at openjdk.org Thu Dec 12 11:43:55 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 12 Dec 2024 11:43:55 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> Message-ID: On Thu, 12 Dec 2024 10:15:19 GMT, Helly Guo wrote: >> @hellyguo I can't reproduce the problem you're seeing. I configured a Debian Bookworm system with Fcitx5 and Pinyin and tested this PR and everything worked. The Linux and Fcitx version numbers are the same as yours. I also installed fcitx5 on my existing Ubuntu 24.10 system and it worked there, also. >> >> The behavior seems a little odd but it matches the behavior of other Linux apps (I see Roman letters inserted into the JavaFX TextField until I select Chinese text in the IM). In your screen capture the input method window was clearly in the wrong location but in my testing it was correctly positioned near the JavaFX caret. > > @beldenfox , you are right. > I created a brand new env in virt-manager: > > > virt at virtdeb:~$ uname -a > Linux virtdeb 6.1.0-28-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) x86_64 GNU/Linux > > virt at virtdeb:~$ cat /etc/os-release > PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" > NAME="Debian GNU/Linux" > VERSION_ID="12" > VERSION="12 (bookworm)" > VERSION_CODENAME=bookworm > ID=debian > HOME_URL="https://www.debian.org/" > SUPPORT_URL="https://www.debian.org/support" > BUG_REPORT_URL="https://bugs.debian.org/" > > virt at virtdeb:~$ java -version > openjdk version "23.0.1" 2024-10-15 > OpenJDK Runtime Environment (build 23.0.1+11-39) > OpenJDK 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing) > > virt at virtdeb:~$ fcitx5 -v > 5.0.21 > > > After tested, I found that what you said is true. Forgot what I said, go ahead. > > Thanks again for your(@tsayao / @beldenfox ) amazing working. > [Screencast from 2024-12-12 17-55-44.webm](https://github.com/user-attachments/assets/d2935d8a-9a5a-4603-a9d0-23f59b2b8f4d) Finally, I got the point. Fcitx5 has a setting entry: `Show preedit in application`. If this is on, it works well. If this is off, the value `im_ctx.on_preedit` will get `false` when im(`fcitx5`) finished input-action. Then, the input will not show in the TextField. ![wechat_2024-12-12_193021_345](https://github.com/user-attachments/assets/9cab3844-8166-43fe-b69d-bda00f422e90) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1881903187 From mfox at openjdk.org Thu Dec 12 15:28:00 2024 From: mfox at openjdk.org (Martin Fox) Date: Thu, 12 Dec 2024 15:28:00 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> Message-ID: <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> On Thu, 12 Dec 2024 11:41:20 GMT, Helly Guo wrote: >> Finally, I got the point. Fcitx5 has a setting entry: `Show preedit in application`. If this is on, it works well. If this is off, the value `im_ctx.on_preedit` will get `false` when im(`fcitx5`) finished input-action. Then, the input will not show in the TextField. >> >> ![wechat_2024-12-12_193021_345](https://github.com/user-attachments/assets/9cab3844-8166-43fe-b69d-bda00f422e90) > > ![pic_20241212193112](https://github.com/user-attachments/assets/7b9233f9-3af5-42d5-89f9-9f85248d68dd) > > The option is surrounded by a red box. @hellyguo Thanks so much for tracking this down and providing all the details. I would like to better understand what that checkbox does but I might not be able to get to that until next week. JavaFX handles keyboard entry using two mechanisms, KeyEvents and InputMethodEvents. This corresponds to the way Windows works. On Mac and Linux the OS only uses one channel (basically InputMethodEvents) and we have to apply a simple heuristic to map this to JavaFX's two-channel approach. This checkbox seems to be upsetting that logic. (I work on the Mac side of this and @tsayao works on the Linux side. I just do testing on Linux because it's easy for me to create new virtual machines.) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1882371128 From mstrauss at openjdk.org Thu Dec 12 16:46:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 12 Dec 2024 16:46:42 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. Work as expected. ------------- Marked as reviewed by mstrauss (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1662#pullrequestreview-2500217749 From angorya at openjdk.org Thu Dec 12 19:52:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 19:52:44 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v3] In-Reply-To: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> References: <2fr1qZsiK-jNudr6J-yYcTOqXT0A9jQXlxulK4jWJbA=.43754b35-5b34-42a6-9e86-f68e9cc9ce61@github.com> Message-ID: On Tue, 12 Nov 2024 15:08:11 GMT, Martin Fox wrote: >> Input methods don?t work for text controls inside Popups. This PR fixes that. >> >> Some background: >> >> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. >> >> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. >> >> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. >> >> There are several reasons why Input Methods aren?t currently working for Popups. >> >> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. >> >> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. >> >> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. >> >> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. >> >> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha... > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Tweak to satisfy system test. This PR does fix the issue at hand (merged the latest master and tested on macOS 15.1.1) It still feels a bit heavy (re: ordered scene list), but I don't have a good suggestion, so I am ok with this approach. left some minor comments - will re-approve if you decide to make changes. modules/javafx.graphics/src/main/java/com/sun/javafx/scene/InputMethodStateManager.java line 95: > 93: public void addScene(Scene scene) { > 94: if (scenes.contains(scene)) { > 95: System.err.println("Popup scene already present"); what is the point of outputting this message? is user supposed to do anything in response to it? modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 563: > 561: > 562: startMonitorOwnerEvents(ownerWindowValue); > 563: Scene scene = getScene(); very minor: this code and L577 can be moved before L548 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1634#pullrequestreview-2500497302 PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1882697050 PR Review Comment: https://git.openjdk.org/jfx/pull/1634#discussion_r1882699944 From angorya at openjdk.org Thu Dec 12 19:55:47 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 19:55:47 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v7] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 23:53:54 GMT, Marius Hanl wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of Java... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Rename setContent to setClipLayout > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling please address the merge conflict. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2539886300 From kcr at openjdk.org Thu Dec 12 20:03:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Dec 2024 20:03:04 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Wed, 11 Dec 2024 21:34:49 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: > > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - legal > - unicode license > - add handler > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - clamp > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - review comments > - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 Here are some more API doc comments, and a few API naming suggestions. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 71: > 69: * When such a mapping exists, the found function tag is matched to a function registered either by > 70: * the application or by the skin. > 71: * This mechanism allows for customizing the key mappings and the underlying functions independently and separately. Additionally, the `register(KeyBinding,Runnable)` method allows mapping to a function directly, bypassing the function tag. You probably want to document this. You might also say that a `KeyBinding` is only mapped to a single value: either a FunctionTag or a Runnable (last one wins). modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 102: > 100: > 101: /** > 102: * Adds an event handler for the specified event type, at the control level. Minor: The phrase "at the control level" seems redundant (and a little awkward), since this is the input map for the control. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 279: > 277: > 278: /** > 279: * Unbinds the specified key binding. There is a lack of symmetry in the name (also, we generally use "unbind" when talking about property bindings). Since "register" is used to create a mapping from a `KeyBinding` to a `FunctionTag` or `Runnable`, maybe rename this to "unregister"? For that matter, what is the practical difference between this and `restoreDefaultKeyBinding(KeyBinding)`? modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 363: > 361: */ > 362: // TODO this should not affect the skin input map, but perhaps place NULL for each found KeyBinding > 363: public void unbind(FunctionTag tag) { This needs a different name than the other "unbind" method since the semantics are quite different. Since this removes all key bindings for a given function tag, I recommend renaming it to `removeKeyBindingsFor`, which goes nicely with `getKeyBindingsFor`. And shouldn't there be an `unregisterFunction(FunctionTag)` method that is the inverse of `registerFunction(FunctionTag, Runnable)`? Or is that what `restoreDefaultFunction(FunctionTag)` does already? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 168: > 166: * {@link InputMap#register(jfx.incubator.scene.control.input.KeyBinding, FunctionHandler)}. > 167: */ > 168: public static class Tags { Should this be `Tag` instead of `Tags`? Each instance is a single `FunctionTag`. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 523: > 521: > 522: /** > 523: * Indicates whether this RichTextArea can be edited by the user, provided the model is also editable. Minor: "model is also _writable_ ..." modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 1114: > 1112: * possibly breaking up the grapheme clusters. > 1113: *

    > 1114: * This method does nothing if either the control or the model is not editable, Minor: "does nothing if the control is not editable or the model is not writable" (here and in other places in this file) modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/ContentChange.java line 108: > 106: /** > 107: * Determines whether the change is an edit (true) or affects styling only (false). > 108: * @return true if change affects stylint only This is backwards. Also, you spelled "styling" wrong, but since you need to remove it anyway, that problem will go away. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 216: > 214: * @return this {@code Builder} instance > 215: */ > 216: public Builder addSquiggly(int start, int length, Color color) { We need a better name. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichTextModel.java line 132: > 130: @Override > 131: protected void insertParagraph(int index, Supplier generator) { > 132: // TODO What is the implication of not having implemented this yet? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichTextModel.java line 182: > 180: // TODO remove later > 181: @Deprecated > 182: public static void dump(StyledTextModel model, PrintStream out) { It's time to remove this. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RtfFormatHandler.java line 48: > 46: public class RtfFormatHandler extends DataFormatHandler { > 47: /** The singleton instance of {@code RtfFormatHandler}. */ > 48: public static final RtfFormatHandler INSTANCE = new RtfFormatHandler(); A better pattern is to provide a static `getInstance()` getter rather than making the singleton field itself public. That's what we do elsewhere in the API. This applies to the other subclasses as well. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 63: > 61: > 62: /** > 63: * Creates the model from the supplied text string by breaking it down into individual text segments. Breaking it down, how? Splitting on newline characters? If so, then say that. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 68: > 66: * @throws IOException if an I/O error occurs > 67: */ > 68: public static SimpleViewOnlyStyledModel from(String text) throws IOException { Would "of" be a better method name? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 96: > 94: /** > 95: * Appends a text segment to the last paragraph. > 96: * The {@code text} cannot contain newline ({@code \n}) symbols. What if it does contain newline chars? Does it throw an Exception? is the newline ignored? Something else? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 194: > 192: * @return this model instance > 193: */ > 194: public SimpleViewOnlyStyledModel squiggly(int start, int length, Color c) { We need a netter name than "squiggly". CSS uses "wavy", so maybe "wavyUnderline"? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 414: > 412: * @param color the background color > 413: */ > 414: void addSquiggly(int start, int length, Color color) { Need a better name. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 119: > 117: * {@code undo()}, > 118: * {@code redo()} > 119: * methods, i.e. editing via UI. Either spell out the `i.e` as "`that is,`" or change it to a parenthetical comment. As it is, the first sentence is truncated after the "i.e". modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 124: > 122: * and fire the change events as a response, for example, to changes in its backing data storage. > 123: * > 124: * @return true if the model supports content modifications via the UI It isn't just UI operations that cannot be done here, right? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 138: > 136: * Returns the plain text string for the specified paragraph. The returned text string cannot be null > 137: * and must not contain any control characters other than TAB. > 138: * The caller should never attempt to ask for a paragraph outside of the valid range. Would it be better to specify an IOOBE? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 150: > 148: * > 149: * @param index paragraph index in the range (0...{@link #size()}) > 150: * @return a new instance of TextCell created Typo: this doesn't return a TextCell. Also, does it really always create a "new instance"? The description implies that it may or may not return a new instance. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 223: > 221: /** > 222: * Returns the {@link StyleAttributeMap} of the first character at the specified position. > 223: * When at the end of the document, returns the attributes of the last character. I don't know what you mean by "first" in "the first character at the specified position". Shouldn't this just be "the character at the specified position"? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 370: > 368: * @return supported formats > 369: */ > 370: public final DataFormat[] getSupportedDataFormats(boolean forExport) { Would a List be better here? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 443: > 441: /** > 442: * Exports the stream of {@code StyledSegment}s in the given range to the specified > 443: * {@code StyledOutput}. Does it close the stream? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 841: > 839: * @throws UnsupportedOperationException if the model is not {@link #isWritable() writable} > 840: */ > 841: public final TextPos[] undo(StyleResolver resolver) { Should this be a List? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModelViewOnlyBase.java line 46: > 44: > 45: @Override > 46: public final boolean isWritable() { Consider adding a javadoc comment saying that this always returns false. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2493615952 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882471175 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882445317 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882491871 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882504267 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882592809 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882610654 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882612646 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882802145 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882713468 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882771077 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882769846 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882790081 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882660242 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882719757 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882662445 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882704457 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882712259 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882646685 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882734264 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882730692 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882727781 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882738554 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882742703 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882745332 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882752787 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882652057 From kcr at openjdk.org Thu Dec 12 20:03:04 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Dec 2024 20:03:04 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v59] In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 20:00:47 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > unicode license modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 521: > 519: * > 520: * @return this Builder > 521: */ So you decided that the builders don't need the ability to clear a modifier key? That seems fine (it could be added later if needed, but seems unlikely). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1878862994 From angorya at openjdk.org Thu Dec 12 20:13:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 20:13:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v59] In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 21:11:51 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> unicode license > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/KeyBinding.java line 521: > >> 519: * >> 520: * @return this Builder >> 521: */ > > So you decided that the builders don't need the ability to clear a modifier key? That seems fine (it could be added later if needed, but seems unlikely). not needed. the (only?) use case is to create a KeyBinding in one step. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882820663 From angorya at openjdk.org Thu Dec 12 20:36:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 20:36:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 16:21:04 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 71: > >> 69: * When such a mapping exists, the found function tag is matched to a function registered either by >> 70: * the application or by the skin. >> 71: * This mechanism allows for customizing the key mappings and the underlying functions independently and separately. > > Additionally, the `register(KeyBinding,Runnable)` method allows mapping to a function directly, bypassing the function tag. You probably want to document this. You might also say that a `KeyBinding` is only mapped to a single value: either a FunctionTag or a Runnable (last one wins). good point! it's a bit more complex - the mapping done via the InputMap takes precedence over skin mappings (which typically use FunctionTags), this fact is documented in `register(KeyBinding k, Runnable function)` method. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882849221 From angorya at openjdk.org Thu Dec 12 20:51:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 20:51:53 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 16:40:27 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 363: > >> 361: */ >> 362: // TODO this should not affect the skin input map, but perhaps place NULL for each found KeyBinding >> 363: public void unbind(FunctionTag tag) { > > This needs a different name than the other "unbind" method since the semantics are quite different. Since this removes all key bindings for a given function tag, I recommend renaming it to `removeKeyBindingsFor`, which goes nicely with `getKeyBindingsFor`. > > And shouldn't there be an `unregisterFunction(FunctionTag)` method that is the inverse of `registerFunction(FunctionTag, Runnable)`? Or is that what `restoreDefaultFunction(FunctionTag)` does already? you are right - no need for a separate `unregister(FunctionTag)`, the `restoreDefaultFunction(FunctionTag)` does the job. > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java line 168: > >> 166: * {@link InputMap#register(jfx.incubator.scene.control.input.KeyBinding, FunctionHandler)}. >> 167: */ >> 168: public static class Tags { > > Should this be `Tag` instead of `Tags`? Each instance is a single `FunctionTag`. Isn't it a collection of tags? But you are right, it looks better in the behavior code. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882864930 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882866282 From mhanl at openjdk.org Thu Dec 12 21:21:45 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 12 Dec 2024 21:21:45 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v7] In-Reply-To: References: Message-ID: On Thu, 12 Dec 2024 19:52:53 GMT, Andy Goryachev wrote: > please address the merge conflict. ? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2540033618 From angorya at openjdk.org Thu Dec 12 21:25:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 21:25:43 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v7] In-Reply-To: References: Message-ID: <5MJ4QGEa3pkHh0a4sIOUGTz8jEOiicMbnmReB2XXFFg=.c368a66d-9cdf-446a-97de-f16cc77c4ee5@github.com> On Mon, 9 Dec 2024 23:53:54 GMT, Marius Hanl wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of Java... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Rename setContent to setClipLayout > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling Marked as reviewed by angorya (Reviewer). sorry, please disregard. had the window open where the merge conflict label was still there. ------------- PR Review: https://git.openjdk.org/jfx/pull/1462#pullrequestreview-2500805851 PR Comment: https://git.openjdk.org/jfx/pull/1462#issuecomment-2540037494 From angorya at openjdk.org Thu Dec 12 22:08:56 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 22:08:56 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 18:49:13 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 216: > >> 214: * @return this {@code Builder} instance >> 215: */ >> 216: public Builder addSquiggly(int start, int length, Color color) { > > We need a better name. this is an internal method. > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 96: > >> 94: /** >> 95: * Appends a text segment to the last paragraph. >> 96: * The {@code text} cannot contain newline ({@code \n}) symbols. > > What if it does contain newline chars? Does it throw an Exception? is the newline ignored? Something else? `The caller must ensure that the {@code text} does not contain newline symbols.` I would rather not add checking to this method. > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 194: > >> 192: * @return this model instance >> 193: */ >> 194: public SimpleViewOnlyStyledModel squiggly(int start, int length, Color c) { > > We need a netter name than "squiggly". CSS uses "wavy", so maybe "wavyUnderline"? mein squiggly! ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882952087 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882949116 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882951652 From angorya at openjdk.org Thu Dec 12 22:14:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 22:14:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 19:04:53 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 124: > >> 122: * and fire the change events as a response, for example, to changes in its backing data storage. >> 123: * >> 124: * @return true if the model supports content modifications via the UI > > It isn't just UI operations that cannot be done here, right? right, re-phrased. > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 138: > >> 136: * Returns the plain text string for the specified paragraph. The returned text string cannot be null >> 137: * and must not contain any control characters other than TAB. >> 138: * The caller should never attempt to ask for a paragraph outside of the valid range. > > Would it be better to specify an IOOBE? This is an abstract method, so the functionality is delegated to the model. If the model decides to throw an exception, so be it. Not sure what to say here. "The return value is undefined if the index falls outside the valid range"? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882958253 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882957723 From angorya at openjdk.org Thu Dec 12 22:34:54 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 22:34:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 19:19:00 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 841: > >> 839: * @throws UnsupportedOperationException if the model is not {@link #isWritable() writable} >> 840: */ >> 841: public final TextPos[] undo(StyleResolver resolver) { > > Should this be a List? no, the two-element array [start, end] should be sufficient. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882977311 From angorya at openjdk.org Thu Dec 12 22:40:53 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 22:40:53 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 19:33:34 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits: >> >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - legal >> - unicode license >> - add handler >> - review comments >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - clamp >> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea >> - review comments >> - review comments >> - ... and 73 more: https://git.openjdk.org/jfx/compare/b76c05b9...e5814b21 > > modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichTextModel.java line 132: > >> 130: @Override >> 131: protected void insertParagraph(int index, Supplier generator) { >> 132: // TODO > > What is the implication of not having implemented this yet? For now, the RichTextModel does not support arbitrary Regions only text. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1882984087 From angorya at openjdk.org Thu Dec 12 23:05:32 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 12 Dec 2024 23:05:32 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v62] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/e5814b21..b49e9d6d Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=61 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=60-61 Stats: 442 lines in 21 files changed: 50 ins; 52 del; 340 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From kcr at openjdk.org Thu Dec 12 23:38:55 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 12 Dec 2024 23:38:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v61] In-Reply-To: References: <9J3sgJGttoQI9KAxKsIFcvAMgyW1R-q75Qe6f6BOo94=.2e8129c4-1f24-48cc-9c67-9c5e513703ba@github.com> Message-ID: On Thu, 12 Dec 2024 22:05:48 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 216: >> >>> 214: * @return this {@code Builder} instance >>> 215: */ >>> 216: public Builder addSquiggly(int start, int length, Color color) { >> >> We need a better name. > > this is an internal method. Nope. It's a public method in the public class, and it shows up in the javadocs. >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichTextModel.java line 132: >> >>> 130: @Override >>> 131: protected void insertParagraph(int index, Supplier generator) { >>> 132: // TODO >> >> What is the implication of not having implemented this yet? > > For now, the RichTextModel does not support arbitrary Regions only text. Then should this throw an UnsupportedOperationException? >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 96: >> >>> 94: /** >>> 95: * Appends a text segment to the last paragraph. >>> 96: * The {@code text} cannot contain newline ({@code \n}) symbols. >> >> What if it does contain newline chars? Does it throw an Exception? is the newline ignored? Something else? > > `The caller must ensure that the {@code text} does not contain newline symbols.` > > I would rather not add checking to this method. OK. We might want to say that the behavior is undefined if the string contains a newline. >> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 138: >> >>> 136: * Returns the plain text string for the specified paragraph. The returned text string cannot be null >>> 137: * and must not contain any control characters other than TAB. >>> 138: * The caller should never attempt to ask for a paragraph outside of the valid range. >> >> Would it be better to specify an IOOBE? > > This is an abstract method, so the functionality is delegated to the model. > If the model decides to throw an exception, so be it. > > Not sure what to say here. "The return value is undefined if the index falls outside the valid range"? We could still specify it, but I can see why you'd rather not. In that case, maybe add a comment like "...might result in an IndexOutOfBoundsException"? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1883022781 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1883031840 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1883028631 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1883031130 From duke at openjdk.org Thu Dec 12 23:56:50 2024 From: duke at openjdk.org (Helly Guo) Date: Thu, 12 Dec 2024 23:56:50 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> Message-ID: On Thu, 12 Dec 2024 15:25:29 GMT, Martin Fox wrote: >> ![pic_20241212193112](https://github.com/user-attachments/assets/7b9233f9-3af5-42d5-89f9-9f85248d68dd) >> >> The option is surrounded by a red box. > > @hellyguo Thanks so much for tracking this down and providing all the details. I would like to better understand what that checkbox does but I might not be able to get to that until next week. > > JavaFX handles keyboard entry using two mechanisms, KeyEvents and InputMethodEvents. This corresponds to the way Windows works. On Mac and Linux the OS only uses one channel (basically InputMethodEvents) and we have to apply a simple heuristic to map this to JavaFX's two-channel approach. This checkbox seems to be upsetting that logic. > > (I work on the Mac side of this and @tsayao works on the Linux side. I just do testing on Linux because it's easy for me to create new virtual machines.) Anyway, current solution without checking `im_ctx.on_preedit` can work well. I backported it to `jfx22` and it worked well. Thanks again. And hope for the final solution. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1883045965 From angorya at openjdk.org Fri Dec 13 00:08:09 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 13 Dec 2024 00:08:09 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/b49e9d6d..df00c2b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=62 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=61-62 Stats: 11 lines in 6 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From kcr at openjdk.org Fri Dec 13 14:40:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 14:40:57 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs Message-ID: Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. Both the GHA build and our CI build are successful. ------------- Commit messages: - Move loading of build.properties earlier in build.gradle - 8345136: Update JDK_DOCS property to point to JDK 23 docs Changes: https://git.openjdk.org/jfx/pull/1663/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1663&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345136 Stats: 13 lines in 3 files changed: 7 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1663.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1663/head:pull/1663 PR: https://git.openjdk.org/jfx/pull/1663 From kcr at openjdk.org Fri Dec 13 14:40:57 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 14:40:57 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:52:00 GMT, Kevin Rushforth wrote: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. Reviewers: @arapte or @andy-goryachev-oracle AND @tiainen or @johanvos ------------- PR Comment: https://git.openjdk.org/jfx/pull/1663#issuecomment-2541597884 From martinfox656 at gmail.com Fri Dec 13 16:03:34 2024 From: martinfox656 at gmail.com (Martin Fox) Date: Fri, 13 Dec 2024 08:03:34 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> Hi Andy, I?m trying to understand the use case you?ve outlined here since it doesn?t correspond to anything currently in JavaFX. > On Dec 10, 2024, at 8:32?AM, Andy Goryachev wrote: > How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control? For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors. How would that work? > > In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on. Will the proposed design still work? Are you proposing a control which delegates events to one inner node that changes over time OR a control which delegates a single key event to multiple inner nodes at once? If the latter, would all of those inner nodes have the focused flag set? Neither of these correspond to a control design I?m familiar with. Can you point to an example? I can?t picture how such a control would appear to the user. In either case would the delegate nodes be accessible via an API like a Spinner?s editor or hidden like a Spinner?s buttons? In the unlikely event that we wanted to deliver key events to a Spinner?s buttons I could imagine using an internal mechanism but that doesn?t make much sense for the publicly accessible editor. Perhaps in your use-case we need two separate mechanisms for delivering key events, this PR and a different one for delegate nodes that aren?t advertised via the control?s API. Martin > > From: openjfx-dev > on behalf of Michael Strau? > > Date: Monday, December 9, 2024 at 18:17 > To: > Cc: openjfx-dev > Subject: Re: [External] : Re: Focus delegation API > > > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. > > I can't image that we would ever do this, considering that events have > been there almost from the beginning. We'd break half of the JavaFX > world if we changed the API of events. > In addition to that, this would remove functionality. As of now, you > can add a listener to Scene, and inspect which node is being targeted > by an event. > > > > > 2. ComboBox's skin has installed an event filter on ComboBox > > > > So we have another scenario where different priorities are needed: adding event filters. > > Maybe, but that's a different problem than what's being solved by > focus delegation. Focus delegation is all about removing defective > ad-hoc implementations, and offering a pre-made building block for > composite controls. > > > > > 3. However, it must forward the event to the TextField (as otherwise > > the TextField doesn't work), so it fires off a copy of the event > > targeted at TextField. > > > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. > > Sure, that would be an option. But it's not my preferred solution for > the following reasons: > 1. It's gratuitously different. Instead of using events like they > normally work, control skins would punch a hole through the scene > graph, and deliver the event directly to the delegation target. That > means that the skin's scene graph works differently as the outside > scene graph, as you can't observe events traveling through it. > 2. It requires the skin to implement a complex protocol (register an > event handler, copy the event, punch a hole through to the delegation > target, send off the event), whereas the focus delegation proposal > requires no additional implementation inside of the skin (aside from > selecting the delegation target). > > The advantage of focus delegation is that it just works, even > recursively, across arbitrary levels of abstractions (a skin might > contain another control, which itself has a skin, and so on). No > matter where you listen to events, you will always see exactly what > you'd expect to see: an event that is targeted at the next focused > node. This is another aspect of focus delegation, unrelated to events: > it formalizes the notion of multi-level focus without resorting to > hacks (like FakeFocusTextField). You'll need to solve this no matter > what, as users can click on the TextField. As we discussed, the > ComboBox must be the focus owner even when a user clicks on the > TextField. > > > > > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. > > First of all, it's only one property (Node.hoistFocus), not a bunch. > And this is not related to events at all, it is a way for skins to > indicate that clicking on an internal node will focus the outside > control. > > The part of focus delegation that fixes the delivery of events in a > scene graph with potentially nested abstractions is done without any > new properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinfox656 at gmail.com Fri Dec 13 16:03:34 2024 From: martinfox656 at gmail.com (Martin Fox) Date: Fri, 13 Dec 2024 08:03:34 -0800 Subject: [External] : Re: Focus delegation API In-Reply-To: References: Message-ID: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> Hi Andy, I?m trying to understand the use case you?ve outlined here since it doesn?t correspond to anything currently in JavaFX. > On Dec 10, 2024, at 8:32?AM, Andy Goryachev wrote: > How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control? For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors. How would that work? > > In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on. Will the proposed design still work? Are you proposing a control which delegates events to one inner node that changes over time OR a control which delegates a single key event to multiple inner nodes at once? If the latter, would all of those inner nodes have the focused flag set? Neither of these correspond to a control design I?m familiar with. Can you point to an example? I can?t picture how such a control would appear to the user. In either case would the delegate nodes be accessible via an API like a Spinner?s editor or hidden like a Spinner?s buttons? In the unlikely event that we wanted to deliver key events to a Spinner?s buttons I could imagine using an internal mechanism but that doesn?t make much sense for the publicly accessible editor. Perhaps in your use-case we need two separate mechanisms for delivering key events, this PR and a different one for delegate nodes that aren?t advertised via the control?s API. Martin > > From: openjfx-dev > on behalf of Michael Strau? > > Date: Monday, December 9, 2024 at 18:17 > To: > Cc: openjfx-dev > Subject: Re: [External] : Re: Focus delegation API > > > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. > > I can't image that we would ever do this, considering that events have > been there almost from the beginning. We'd break half of the JavaFX > world if we changed the API of events. > In addition to that, this would remove functionality. As of now, you > can add a listener to Scene, and inspect which node is being targeted > by an event. > > > > > 2. ComboBox's skin has installed an event filter on ComboBox > > > > So we have another scenario where different priorities are needed: adding event filters. > > Maybe, but that's a different problem than what's being solved by > focus delegation. Focus delegation is all about removing defective > ad-hoc implementations, and offering a pre-made building block for > composite controls. > > > > > 3. However, it must forward the event to the TextField (as otherwise > > the TextField doesn't work), so it fires off a copy of the event > > targeted at TextField. > > > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. > > Sure, that would be an option. But it's not my preferred solution for > the following reasons: > 1. It's gratuitously different. Instead of using events like they > normally work, control skins would punch a hole through the scene > graph, and deliver the event directly to the delegation target. That > means that the skin's scene graph works differently as the outside > scene graph, as you can't observe events traveling through it. > 2. It requires the skin to implement a complex protocol (register an > event handler, copy the event, punch a hole through to the delegation > target, send off the event), whereas the focus delegation proposal > requires no additional implementation inside of the skin (aside from > selecting the delegation target). > > The advantage of focus delegation is that it just works, even > recursively, across arbitrary levels of abstractions (a skin might > contain another control, which itself has a skin, and so on). No > matter where you listen to events, you will always see exactly what > you'd expect to see: an event that is targeted at the next focused > node. This is another aspect of focus delegation, unrelated to events: > it formalizes the notion of multi-level focus without resorting to > hacks (like FakeFocusTextField). You'll need to solve this no matter > what, as users can click on the TextField. As we discussed, the > ComboBox must be the focus owner even when a user clicks on the > TextField. > > > > > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. > > First of all, it's only one property (Node.hoistFocus), not a bunch. > And this is not related to events at all, it is a way for skins to > indicate that clicking on an internal node will focus the outside > control. > > The part of focus delegation that fixes the delivery of events in a > scene graph with potentially nested abstractions is done without any > new properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Fri Dec 13 16:21:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 16:21:10 GMT Subject: RFR: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed Message-ID: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. ------------- Commit messages: - Pass option only for JDK 24 or later - Merge branch 'master' into 8345127-allow-unsafe - 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed Changes: https://git.openjdk.org/jfx/pull/1650/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1650&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345127 Stats: 64 lines in 3 files changed: 56 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1650.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1650/head:pull/1650 PR: https://git.openjdk.org/jfx/pull/1650 From kcr at openjdk.org Fri Dec 13 16:21:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 16:21:10 GMT Subject: RFR: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed In-Reply-To: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> References: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Message-ID: On Wed, 27 Nov 2024 19:27:55 GMT, Kevin Rushforth wrote: > Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. > > I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. > > Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. build.gradle line 771: > 769: > 770: ext.jdk23OrLater = jdkVersionInfo.feature() >= 23 > 771: ext.jdk24OrLater = jdkVersionInfo.feature() >= 24 We really only need to add `--sun-misc-unsafe-memory-access=allow` when running with JDK 24 or later ("allow" is the default in JDK 23). I want to do initial testing on JDK 23 with this flag, but will likely change all of the checks to `jdk24OrLater` for the final version, in which case we won't need the `jdk23OrLater` flag. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1650#discussion_r1861162515 From kcr at openjdk.org Fri Dec 13 16:21:10 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 16:21:10 GMT Subject: RFR: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed In-Reply-To: References: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Message-ID: On Wed, 27 Nov 2024 19:31:20 GMT, Kevin Rushforth wrote: >> Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. >> >> I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. >> >> Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. > > build.gradle line 771: > >> 769: >> 770: ext.jdk23OrLater = jdkVersionInfo.feature() >= 23 >> 771: ext.jdk24OrLater = jdkVersionInfo.feature() >= 24 > > We really only need to add `--sun-misc-unsafe-memory-access=allow` when running with JDK 24 or later ("allow" is the default in JDK 23). I want to do initial testing on JDK 23 with this flag, but will likely change all of the checks to `jdk24OrLater` for the final version, in which case we won't need the `jdk23OrLater` flag. I made the above change. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1650#discussion_r1884003765 From mfox at openjdk.org Fri Dec 13 16:26:54 2024 From: mfox at openjdk.org (Martin Fox) Date: Fri, 13 Dec 2024 16:26:54 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v4] In-Reply-To: References: Message-ID: > Input methods don?t work for text controls inside Popups. This PR fixes that. > > Some background: > > A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. > > Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. > > The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. > > There are several reasons why Input Methods aren?t currently working for Popups. > > - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. > > - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. > > - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. > > In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. > > This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the change. In this PR the InputMethodStateManage... Martin Fox has updated the pull request incrementally with one additional commit since the last revision: Removed debug printlns, tidied up some code ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1634/files - new: https://git.openjdk.org/jfx/pull/1634/files/ce980548..31ebdcf4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1634&range=03 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1634&range=02-03 Stats: 10 lines in 2 files changed: 1 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1634.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1634/head:pull/1634 PR: https://git.openjdk.org/jfx/pull/1634 From kcr at openjdk.org Fri Dec 13 18:04:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 18:04:43 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Wed, 11 Dec 2024 00:27:44 GMT, Kevin Rushforth wrote: > Because this has third-party and build implications, I need to review it. Since it is a test-only usage (we don't distribute anything from it), we don't need to get new approval as long as the license is unchanged (I'll double-check). All looks good so far. I fired off a CI test job. Once finished, I'll approve and you can integrate. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2541980589 From kcr at openjdk.org Fri Dec 13 18:45:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 18:45:41 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. The following test consistently fails on macOS and Linux (I haven't tried it on Windows) with JUnit 5.13.1 in our CI and on my local macOS system: $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest ... SwingNodePlatformExitCrashTest > executionError FAILED org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec at app//test.util.Util.runAndWait(Util.java:168) at app//test.util.Util.runAndWait(Util.java:139) at app//test.util.Util.shutdown(Util.java:316) at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) at java.base at 23/java.lang.reflect.Method.invoke(Method.java:580) at java.base at 23/java.util.ArrayList.forEach(ArrayList.java:1597) at java.base at 23/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1117) at java.base at 23/java.util.ArrayList.forEach(ArrayList.java:1597) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2542043612 From kcr at openjdk.org Fri Dec 13 19:02:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 19:02:42 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. Update: I think this is a test bug. @Maran23 Can you confirm a theory I have? We have a situation where an abstract base class of a test has a static `tearDownOnce` method, annotated with `@AfterAll`. A concrete test class extends the base class and attempts to "override" the static method in the base calss with an `@AfterAll` annotation on a static method of the same name in the subclass. My suspicion is that this used to accidentally work by hiding the method in the parent class in JUnit 5.8 and no longer does. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2542068187 From kcr at openjdk.org Fri Dec 13 19:08:46 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 19:08:46 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: <_B_X14jNlCMLF6DyW8nLOL_Xg1i9yot5fFHfU950bOU=.155b434b-12d4-4521-a601-d561e06ae00d@github.com> On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. I'm almost sure that this is the case, given this: > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) For the test in question, the `Utils::shutDown` method called by `SwingNodeBase.teardownOnce` must be skipped. It will be an easy test fix. I'll file a follow-up bug for it. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2542077359 From kcr at openjdk.org Fri Dec 13 19:50:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 19:50:51 GMT Subject: RFR: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 Message-ID: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. I discovered this while testing PR #1662 which updates JUnit to 5.11.3. $ gradle sdk shims $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest ... SwingNodePlatformExitCrashTest > executionError FAILED org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec at app//test.util.Util.runAndWait(Util.java:168) at app//test.util.Util.runAndWait(Util.java:139) at app//test.util.Util.shutdown(Util.java:316) at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) ... The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an @AfterAll annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. ------------- Commit messages: - 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 Changes: https://git.openjdk.org/jfx/pull/1664/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1664&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346222 Stats: 11 lines in 2 files changed: 4 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1664.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1664/head:pull/1664 PR: https://git.openjdk.org/jfx/pull/1664 From kcr at openjdk.org Fri Dec 13 19:50:51 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 19:50:51 GMT Subject: RFR: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 In-Reply-To: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> References: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> Message-ID: On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote: > This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. > > I discovered this while testing PR #1662 which updates JUnit to 5.11.3. > > > $ gradle sdk shims > $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest > ... > SwingNodePlatformExitCrashTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//test.util.Util.runAndWait(Util.java:168) > at app//test.util.Util.runAndWait(Util.java:139) > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) > ... > > > The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an @AfterAll annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. > > The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. @prsadhuk Please review @Maran23 Can you also take a look at this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1664#issuecomment-2542172931 From kcr at openjdk.org Fri Dec 13 19:55:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 19:55:41 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: <0NOA-EkTjrVg1IW_HAaEkJfLwq5v-xocvKP-IrUSgb4=.b64dda4b-dec5-4e46-b10c-600cdd7af25d@github.com> On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. I confirmed my theory about why that test is now failing, and filed a new bug, [JDK-8346222](https://bugs.openjdk.org/browse/JDK-8346222), to track this. PR #1664 is out for review. I have a CI build out with the patches from both PRs. Once that completes, I'll approve this. It would probably be best to wait until Monday, unless I'm able to integrate PR #1664 is integrated sooner than that (as a simple testbug I will integrate that one without waiting 24 hours if it is approved sooner). One more thing: I updated the title of the JBS bug to match our usual pattern for third-party updates. Please update the title of your PR to match. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2542189326 From mstrauss at openjdk.org Fri Dec 13 21:25:46 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Dec 2024 21:25:46 GMT Subject: Integrated: 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D In-Reply-To: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> References: <5cY1ZLCuObrEVjoZhf2Ricug4Kh2fIsABoDcPF2PTf4=.af393558-6fd9-40e6-8282-3b903417536e@github.com> Message-ID: On Thu, 5 Sep 2024 12:01:23 GMT, Michael Strau? wrote: > None of these classes can be extended by user code, and any attempt to do so will fail at runtime with an exception. For this reason, we can seal the class hierarchy and remove the run-time checks to turn this into a compile-time error instead. > > In some cases, `Node` and `Shape` are extended by JavaFX classes in other modules, preventing those derived classes from being permitted subclasses. A non-exported `AbstractNode` and `AbstractShape` class is provided just for these scenarios. Note that introducing a new superclass is a source- and binary-compatible change (see [JLS ch. 13](https://docs.oracle.com/javase/specs/jls/se22/html/jls-13.html)). > > I'm not sure if this change requires a CSR, as it doesn't change the specification in any meaningful way. There can be no valid JavaFX program that is affected by this change. This pull request has now been integrated. Changeset: c5a98395 Author: Michael Strau? URL: https://git.openjdk.org/jfx/commit/c5a983952ee62ffa56a55a840b57a357fe204bcc Stats: 215 lines in 46 files changed: 93 ins; 41 del; 81 mod 8339603: Seal the class hierarchy of Node, Camera, LightBase, Shape, Shape3D Reviewed-by: angorya, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1556 From kcr at openjdk.org Fri Dec 13 21:28:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 21:28:47 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. All good. The combined patch from this PR and #1664 passes in our CI. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1662#pullrequestreview-2503271037 From kcr at openjdk.org Fri Dec 13 21:35:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 21:35:41 GMT Subject: RFR: 8345937: Update JUnit Platform to newest version In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. As an FYI, the behavior change that exposed the bug in our test was a deliberate change in JUnit 5.11. https://github.com/junit-team/junit5/issues/3553 Indeed it was the case that before 5.11, a static method annotated with `@BeforeAll` or `@AfterAll` in a subclass would hide the same named method in the superclass, and starting in 5.11, it no longer does. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2542416585 From kcr at openjdk.org Fri Dec 13 21:36:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 13 Dec 2024 21:36:41 GMT Subject: RFR: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 In-Reply-To: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> References: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> Message-ID: On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote: > This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. > > I discovered this while testing PR #1662 which updates JUnit to 5.11.3. > > > $ gradle sdk shims > $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest > ... > SwingNodePlatformExitCrashTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//test.util.Util.runAndWait(Util.java:168) > at app//test.util.Util.runAndWait(Util.java:139) > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) > ... > > > The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an @AfterAll annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. > > The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. As an FYI, the behavior change that exposed this latent bug in our test was a deliberate change in JUnit 5.11. https://github.com/junit-team/junit5/issues/3553 Indeed it was the case that before 5.11, a static method annotated with `@BeforeAll` or `@AfterAll` in a subclass would hide the same named method in the superclass, and starting in 5.11, it no longer does. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1664#issuecomment-2542417832 From mstrauss at openjdk.org Fri Dec 13 23:37:50 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 13 Dec 2024 23:37:50 GMT Subject: RFR: 8346227: Seal Paint and Material Message-ID: The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. ------------- Commit messages: - Seal Paint and Material Changes: https://git.openjdk.org/jfx/pull/1665/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1665&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346227 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1665.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1665/head:pull/1665 PR: https://git.openjdk.org/jfx/pull/1665 From mstrauss at openjdk.org Sat Dec 14 17:16:20 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Sat, 14 Dec 2024 17:16:20 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: > The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: use exhaustive switch pattern ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1665/files - new: https://git.openjdk.org/jfx/pull/1665/files/5c4b42c8..f0a39b16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1665&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1665&range=00-01 Stats: 18 lines in 2 files changed: 0 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1665.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1665/head:pull/1665 PR: https://git.openjdk.org/jfx/pull/1665 From mhanl at openjdk.org Sat Dec 14 23:05:39 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Sat, 14 Dec 2024 23:05:39 GMT Subject: RFR: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 In-Reply-To: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> References: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> Message-ID: On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote: > This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. > > I discovered this while testing PR #1662 which updates JUnit to 5.11.3. > > > $ gradle sdk shims > $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest > ... > SwingNodePlatformExitCrashTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//test.util.Util.runAndWait(Util.java:168) > at app//test.util.Util.runAndWait(Util.java:139) > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) > ... > > > The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an `@AfterAll` annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. > > The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. Marked as reviewed by mhanl (Committer). Thanks for investigating this in https://github.com/openjdk/jfx/pull/1662. I have read all comments and can confirm your investigation! Funny enough, I found a similar problem when updating another project to the latest JUnit version. So it seems like a good idea to update JUnit so that we can no longer write tests that violate this behavior, only to find out later. ------------- PR Review: https://git.openjdk.org/jfx/pull/1664#pullrequestreview-2504266624 PR Comment: https://git.openjdk.org/jfx/pull/1664#issuecomment-2543369358 From tsayao at openjdk.org Sun Dec 15 19:11:49 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Dec 2024 19:11:49 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> Message-ID: On Thu, 12 Dec 2024 23:53:55 GMT, Helly Guo wrote: >> @hellyguo Thanks so much for tracking this down and providing all the details. I would like to better understand what that checkbox does but I might not be able to get to that until next week. >> >> JavaFX handles keyboard entry using two mechanisms, KeyEvents and InputMethodEvents. This corresponds to the way Windows works. On Mac and Linux the OS only uses one channel (basically InputMethodEvents) and we have to apply a simple heuristic to map this to JavaFX's two-channel approach. This checkbox seems to be upsetting that logic. >> >> (I work on the Mac side of this and @tsayao works on the Linux side. I just do testing on Linux because it's easy for me to create new virtual machines.) > > Anyway, current solution without checking `im_ctx.on_preedit` can work well. I backported it to `jfx22` and it worked well. Thanks again. And hope for the final solution. This option sets if editing happens on the application or in the IME window. Application: ![image](https://github.com/user-attachments/assets/d44364ad-4090-4e1d-9fcf-5fa7fbd8a306) IME Window: ![image](https://github.com/user-attachments/assets/692536bf-e8d2-467d-9332-0a6f04f1eb9a) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1885813314 From tsayao at openjdk.org Sun Dec 15 20:19:06 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Dec 2024 20:19:06 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v32] In-Reply-To: References: Message-ID: <_o7yIQF5b3Dsz0n-2vqC1uOBLLM07mGlYiu3GCsQIgU=.7677e657-b989-466a-8806-87535a49dda1@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with two additional commits since the last revision: - Fixes for fcitx - Fixes for fcitx ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/16b3eebe..6cd1d32a Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=31 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=30-31 Stats: 52 lines in 2 files changed: 11 ins; 35 del; 6 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Dec 15 20:28:51 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Dec 2024 20:28:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> Message-ID: On Sun, 15 Dec 2024 19:09:29 GMT, Thiago Milczarek Sayao wrote: >> Anyway, current solution without checking `im_ctx.on_preedit` can work well. I backported it to `jfx22` and it worked well. Thanks again. And hope for the final solution. > > This option sets if editing happens on the application or in the IME window. > > Application: > ![image](https://github.com/user-attachments/assets/d44364ad-4090-4e1d-9fcf-5fa7fbd8a306) > > > IME Window: > ![image](https://github.com/user-attachments/assets/692536bf-e8d2-467d-9332-0a6f04f1eb9a) I modified it to no longer rely on pre-edit calls, but I'm not sure if it's working as expected yet. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1885846316 From mfox at openjdk.org Sun Dec 15 20:59:51 2024 From: mfox at openjdk.org (Martin Fox) Date: Sun, 15 Dec 2024 20:59:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> Message-ID: On Sun, 15 Dec 2024 20:26:22 GMT, Thiago Milczarek Sayao wrote: >> This option sets if editing happens on the application or in the IME window. >> >> Application: >> ![image](https://github.com/user-attachments/assets/d44364ad-4090-4e1d-9fcf-5fa7fbd8a306) >> >> >> IME Window: >> ![image](https://github.com/user-attachments/assets/692536bf-e8d2-467d-9332-0a6f04f1eb9a) > > I modified it to no longer rely on pre-edit calls, but I'm not sure if it's working as expected yet. When fcitx is configured this way we never receive pre-editing signals AND we're not filtering a key event when the commit comes in. The best way to test this is to use the mouse to click on a choice in the IM window. You'll see a commit arrive even though no key was pressed (which is expected) and no pre-edit signals were sent (which is unexpected). On the one hand according to the GTK documentation this set of conditions should never happen. On the other hand this is Linux. I'll look at this code in more detail but I think you're comparing the commit text with the keyval of the previous key event which may be unrelated. The simplest solution is to add a flag that's only set while a key event is being filtered. If a commit message arrives during pre-edit OR when no key event is being filtered it should be processed as an InputMethod event. I did a quick test of this logic and it seems to work but I did very little testing. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1885860305 From tsayao at openjdk.org Sun Dec 15 22:11:30 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Dec 2024 22:11:30 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v33] In-Reply-To: References: Message-ID: <2hnd8cohA6wC2jORmNbIt833ALLLcNZRi8ejB2skAno=.dfd7251c-f64f-4d0a-9d55-aa9f44bd86a0@github.com> > This replaces obsolete XIM and uses gtk api for IME. > Gtk uses [ibus](https://github.com/ibus/ibus) > > Gtk3+ uses relative positioning (as Wayland does), so I've added a Relative positioning on `InputMethodRequest`. > > [Screencast from 17-09-2023 21:59:04.webm](https://github.com/openjdk/jfx/assets/30704286/6c398e39-55a3-4420-86a2-beff07b549d3) Thiago Milczarek Sayao has updated the pull request incrementally with three additional commits since the last revision: - Better solution for fcitx - Revert "Fixes for fcitx" This reverts commit d8b38ea8f1379f9783d9186e462b0652ae7fd98b. - Revert "Fixes for fcitx" This reverts commit 6cd1d32a51149df2cbe36f0b348a464173422201. ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1080/files - new: https://git.openjdk.org/jfx/pull/1080/files/6cd1d32a..0c0c23bd Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=32 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1080&range=31-32 Stats: 48 lines in 2 files changed: 32 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jfx/pull/1080.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1080/head:pull/1080 PR: https://git.openjdk.org/jfx/pull/1080 From tsayao at openjdk.org Sun Dec 15 22:15:51 2024 From: tsayao at openjdk.org (Thiago Milczarek Sayao) Date: Sun, 15 Dec 2024 22:15:51 GMT Subject: RFR: 8305418: [Linux] Replace obsolete XIM as Input Method Editor [v31] In-Reply-To: References: <9BS4y41_ObmAnZvoK8SX1C7L1pF8co0fGM6OwVzVVv4=.275dcc37-0362-4c4d-9986-e50676ef0968@github.com> <-UJ8HAx_YcxcD1mwWQjtJ2W8UBEweJf0lGhI5QUV82o=.d9f071af-3253-4e52-953d-a051afbe14ea@github.com> <-FOEXkoC6xQmDpEDDPLczGtt-Uy92WmAIGIgCQYi5Ho=.6580238f-e3c5-4ef5-8b2b-f622ba3e31b7@github.com> <7CvsZPmIWBeJQ6aZJvrXGUMcrW4pR6h2ZrPic23smu0=.8d3dda60-f026-4a66-9b35-54f71467e3f6@github.com> Message-ID: On Sun, 15 Dec 2024 20:57:14 GMT, Martin Fox wrote: >> I modified it to no longer rely on pre-edit calls, but I'm not sure if it's working as expected yet. > > When fcitx is configured this way we never receive pre-editing signals AND we're not filtering a key event when the commit comes in. The best way to test this is to use the mouse to click on a choice in the IM window. You'll see a commit arrive even though no key was pressed (which is expected) and no pre-edit signals were sent (which is unexpected). > > On the one hand according to the GTK documentation this set of conditions should never happen. On the other hand this is Linux. > > I'll look at this code in more detail but I think you're comparing the commit text with the keyval of the previous key event which may be unrelated. The simplest solution is to add a flag that's only set while a key event is being filtered. If a commit message arrives during pre-edit OR when no key event is being filtered it should be processed as an InputMethod event. I did a quick test of this logic and it seems to work but I did very little testing. I reverted and did the way @beldenfox explained above. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1080#discussion_r1885902898 From arapte at openjdk.org Mon Dec 16 06:07:46 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Dec 2024 06:07:46 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:52:00 GMT, Kevin Rushforth wrote: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. LGTM, tested with a local build. Having a separate property offers flexibility if ever we require it to be different than `jfx-build.jdk.version`, otherwise we could reuse property `jfx-build.jdk.version`. ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1663#pullrequestreview-2505226654 From psadhukhan at openjdk.org Mon Dec 16 10:45:46 2024 From: psadhukhan at openjdk.org (Prasanta Sadhukhan) Date: Mon, 16 Dec 2024 10:45:46 GMT Subject: RFR: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 In-Reply-To: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> References: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> Message-ID: On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote: > This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. > > I discovered this while testing PR #1662 which updates JUnit to 5.11.3. > > > $ gradle sdk shims > $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest > ... > SwingNodePlatformExitCrashTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//test.util.Util.runAndWait(Util.java:168) > at app//test.util.Util.runAndWait(Util.java:139) > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) > ... > > > The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an `@AfterAll` annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. > > The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. Though not failing in windows, but I understand why it can fail.. looks good. ------------- Marked as reviewed by psadhukhan (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1664#pullrequestreview-2505802465 From aghaisas at openjdk.org Mon Dec 16 11:09:55 2024 From: aghaisas at openjdk.org (Ajit Ghaisas) Date: Mon, 16 Dec 2024 11:09:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:08:09 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Reviewed files under - com.sun.jfx.incubator.scene.control.richtext Done some sanity testing. Overall this is looking good now. ------------- Marked as reviewed by aghaisas (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2505872498 From kcr at openjdk.org Mon Dec 16 13:05:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Dec 2024 13:05:41 GMT Subject: Integrated: 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 In-Reply-To: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> References: <8aLt8Oee4PMgIK3ashZWwDnq-2qd1Mv7arRqjEc0syc=.f58133bb-8d02-4b7e-8e42-2a18006b086c@github.com> Message-ID: <5kEPzEiJTEGle9E2-zQbX-uWTAZw7SkfEO14YDsv8HI=.801251ac-e20b-4cbd-b215-9b6081d5637f@github.com> On Fri, 13 Dec 2024 19:46:54 GMT, Kevin Rushforth wrote: > This PR fixes a latent test bug in test bug in `SwingNodePlatformExitCrashTest` by setting a flag to skip shutdown rather than relying on a quirk of JUnit 5.8.1. > > I discovered this while testing PR #1662 which updates JUnit to 5.11.3. > > > $ gradle sdk shims > $ gradle -PTEST_ONLY=true -PFULL_TEST=true -PUSE_ROBOT=true :systemTests:test --tests SwingNodePlatformExitCrashTest > ... > SwingNodePlatformExitCrashTest > executionError FAILED > org.opentest4j.AssertionFailedError: Exceeded timeout limit of 10000 msec > at app//test.util.Util.runAndWait(Util.java:168) > at app//test.util.Util.runAndWait(Util.java:139) > at app//test.util.Util.shutdown(Util.java:316) > at app//test.robot.javafx.embed.swing.SwingNodeBase.teardownOnce(SwingNodeBase.java:81) > ... > > > The abstract `SwingNodeBase` base class calls `Util::shutdown` from its static `tearDownOnce` method, annotated with `@AfterAll`. The `SwingNodePlatformExitCrashTest` shuts down the FX toolkit as part of the test so must not call shutdown a second time. The current test logic attempts to "override" the static method in the base class with an `@AfterAll` annotation on a static method of the same name in the subclass. This accidentally works in JUnit 5.8 by hiding the method in the parent class, but no longer does in JUnit 5.11. > > The right fix is for the subclass to set a flag such that the superclass will skip the call to `Util::shutdown`. This pull request has now been integrated. Changeset: 56175f40 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/56175f40037a6a03f65a99d26b74c7b110d29b70 Stats: 11 lines in 2 files changed: 4 ins; 1 del; 6 mod 8346222: SwingNodePlatformExitCrashTest fails with JUnit 5.11.3 Reviewed-by: mhanl, psadhukhan ------------- PR: https://git.openjdk.org/jfx/pull/1664 From kcr at openjdk.org Mon Dec 16 13:14:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Dec 2024 13:14:42 GMT Subject: RFR: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed In-Reply-To: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> References: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Message-ID: On Wed, 27 Nov 2024 19:27:55 GMT, Kevin Rushforth wrote: > Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. > > I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. > > Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. @arapte can you review this? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1650#issuecomment-2545597658 From arapte at openjdk.org Mon Dec 16 15:00:53 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Mon, 16 Dec 2024 15:00:53 GMT Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal scrolling [v7] In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 23:53:54 GMT, Marius Hanl wrote: >> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. >> >> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. >> Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. >> >> So the following code is effectively doing the same: >> >> Old: >> >> BaseBounds newClip = clipNode.getShape().getBounds(); >> if (!clipNode.getTransform().isIdentity()) { >> newClip = clipNode.getTransform().transform(newClip, newClip); >> } >> final BaseTransform curXform = g.getTransformNoClone(); >> final Rectangle curClip = g.getClipRectNoClone(); >> newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning >> newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> Rectangle clipRect = new Rectangle(newClip) >> >> >> New: >> >> BaseTransform curXform = g.getTransformNoClone(); >> BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); >> Rectangle clipRect = new Rectangle(clipBounds); >> clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); >> >> >> As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. >> I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. >> >> I checked several scenarios and code and could not find any regressions. >> Still, since this is change affects all nodes with rectangular clips, we should be careful. >> Performance wise I could not spot any difference, I do not expect any difference. >> **So I would like to have at least 2 reviewers.** >> Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. >> >> --- >> >> As written in the other PR, I have some interesting findings on this particular problem. >> >> Copy&Paste from the other PR: >> -- >> >> Ok, so I found out the following: >> When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. >> This happens at the low level (`NGNode`) side of Java... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Rename setContent to setClipLayout > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > # modules/javafx.graphics/src/test/java/test/com/sun/javafx/sg/prism/NGNodeTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java > # modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableViewTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8218745-tableview-glitch-clipping-fix > > # Conflicts: > # modules/javafx.graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java > - Improve test > - 8218745: TableView: visual glitch at borders on horizontal scrolling Marked as reviewed by arapte (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1462#pullrequestreview-2506433786 From kcr at openjdk.org Mon Dec 16 15:51:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 16 Dec 2024 15:51:43 GMT Subject: RFR: 8345937: Update JUnit to 5.11.3 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. @Maran23 I integrated the fix for #1664 so you can integrate this now. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1662#issuecomment-2545986806 From mhanl at openjdk.org Mon Dec 16 18:41:46 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Mon, 16 Dec 2024 18:41:46 GMT Subject: Integrated: 8345937: Update JUnit to 5.11.3 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 18:07:44 GMT, Marius Hanl wrote: > The JUnit Platform got some updates over the last years, so it is a good idea to update it to the newest version. > > That is from `5.8.1` to `5.11.3`. > Affected dependencies: > - `junit.jupiter` > - `junit.platform` > - `opentest4j` > > Release notes: https://junit.org/junit5/docs/5.11.3/release-notes/ > > Note: > I did a handful of CI runs and got a test failure once in `ServiceLifecycleTest`. Not sure yet if related to the update or not. This pull request has now been integrated. Changeset: 0c9d4eeb Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/0c9d4eebbc53b54f91387c2b5ec6c01cd647381b Stats: 54 lines in 2 files changed: 0 ins; 0 del; 54 mod 8345937: Update JUnit to 5.11.3 Reviewed-by: mstrauss, kcr ------------- PR: https://git.openjdk.org/jfx/pull/1662 From nlisker at openjdk.org Tue Dec 17 12:18:49 2024 From: nlisker at openjdk.org (Nir Lisker) Date: Tue, 17 Dec 2024 12:18:49 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: On Sat, 14 Dec 2024 17:16:20 GMT, Michael Strau? wrote: >> The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use exhaustive switch pattern Marked as reviewed by nlisker (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1665#pullrequestreview-2508717719 From arapte at openjdk.org Tue Dec 17 17:07:47 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Tue, 17 Dec 2024 17:07:47 GMT Subject: RFR: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed In-Reply-To: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> References: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Message-ID: On Wed, 27 Nov 2024 19:27:55 GMT, Kevin Rushforth wrote: > Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. > > I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. > > Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. LGTM, verified with 24 ea build28 ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1650#pullrequestreview-2509532749 From angorya at openjdk.org Tue Dec 17 17:26:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 17:26:45 GMT Subject: RFR: 8343398: Add reducedData preference [v6] In-Reply-To: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> References: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> Message-ID: On Thu, 12 Dec 2024 01:03:26 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > formatting Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2509581552 From angorya at openjdk.org Tue Dec 17 18:10:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 18:10:45 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: On Sat, 14 Dec 2024 17:16:20 GMT, Michael Strau? wrote: >> The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use exhaustive switch pattern modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 597: > 595: > 596: public Object getPaint(Paint paint) { > 597: return switch (paint) { standard warning: not equivalent change (in the case of null `paint`). it's ok in this case, since it looks like this method is never called with a null argument thanks to guards like this replicated across the code base: peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); would it have been easier to allow null argument and return null from `getPaint()` instead? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1888982459 From mstrauss at openjdk.org Tue Dec 17 18:15:47 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Tue, 17 Dec 2024 18:15:47 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 18:01:57 GMT, Andy Goryachev wrote: >> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: >> >> use exhaustive switch pattern > > modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 597: > >> 595: >> 596: public Object getPaint(Paint paint) { >> 597: return switch (paint) { > > standard warning: not equivalent change (in the case of null `paint`). > it's ok in this case, since it looks like this method is never called with a null argument thanks to guards like this replicated across the code base: > > > peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); > > > would it have been easier to allow null argument and return null from `getPaint()` instead? `null` is not a valid argument for this method, and has never been. `acc_getPlatformPaint()` previously asserted that the return value is not `null`. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1888999112 From angorya at openjdk.org Tue Dec 17 18:20:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 18:20:45 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: <67K0HnFgaCiR4U4gSSYMjcoSQ1s-ycxrn9lN4JU47M4=.f6eda424-6997-406e-bab5-8050ee94eff9@github.com> On Tue, 17 Dec 2024 18:13:28 GMT, Michael Strau? wrote: >> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/Toolkit.java line 597: >> >>> 595: >>> 596: public Object getPaint(Paint paint) { >>> 597: return switch (paint) { >> >> standard warning: not equivalent change (in the case of null `paint`). >> it's ok in this case, since it looks like this method is never called with a null argument thanks to guards like this replicated across the code base: >> >> >> peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); >> >> >> would it have been easier to allow null argument and return null from `getPaint()` instead? > > `null` is not a valid argument for this method, and has never been. `acc_getPlatformPaint()` previously asserted that the return value is not `null`. this is not what I am asking though: in more than one place we have _callers_ like this peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); it could be changed to peer.setFillPaint(tk.getPaint(getFill())); ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1889005859 From angorya at openjdk.org Tue Dec 17 18:29:44 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 18:29:44 GMT Subject: RFR: 8288893: Popup and its subclasses cannot input text from InputMethod [v4] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 16:26:54 GMT, Martin Fox wrote: >> Input methods don?t work for text controls inside Popups. This PR fixes that. >> >> Some background: >> >> A PopupWindow always has an owner. The owner of the first Popup is a standard Window; I?ll refer to that as the root window. But a popup can show another popup (for example, a popup may contain a ComboBox which opens a menu which is also a Popup) resulting in a stack of PopupWindows. >> >> Under the hood each PopupWindow has its own scene (this is not visible in the API). So if there?s a stack of PopupWindows there?s also a stack of scenes with the root window?s scene at the bottom. >> >> The OS focus always stays with the root window (in part because JavaFX can?t move the OS focus when it?s embedded). This means a KeyEvent is initially fired at the focusOwner in the root window?s scene. Each PopupWindow in the stack uses an EventRedirector to refire that key event at its own focusOwner. In effect KeyEvents start processing at the top-most scene in the stack and work their way down to the root scene. >> >> There are several reasons why Input Methods aren?t currently working for Popups. >> >> - InputMethodEvents are not being redirected. This PR extends the EventRedirector to refire InputMethod events in the same way it refires KeyEvents. >> >> - If a PopupWindow contains a TextInput control it will enable input method events on its scene which has no effect since that scene doesn?t have OS focus. If a PopupWindow wants to enable IM events it needs to do so on the root window?s scene. Put another way IM events should be enabled on the root scene if and only if one of the focusOwners in the scene stack requires IM events. >> >> - The OS always retrieves the InputMethodRequests from the root window?s scene. InputMethodRequests should be retrieved from whichever focusOwner in the scene stack is processing InputMethodEvents. >> >> In this PR the root scene creates an InputMethodStateManager object and shares it with all of the Popup scenes in the stack. Any time the focusOwner changes in a scene it tells the InputMethodStateManager so it can determine whether IM events should be enabled on the root scene. The root scene also calls on the InputMethodStateManager to retrieve InputMethodRequests so it can grab them from the appropriate Node in the scene stack. >> >> This PR also fixes JDK-8334586. Currently the scene only enabled or disables IM events when the focusOwner changes. If a node?s skin is installed after it becomes focusOwner the scene won?t notice the cha... > > Martin Fox has updated the pull request incrementally with one additional commit since the last revision: > > Removed debug printlns, tidied up some code thank you for making the changes! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1634#pullrequestreview-2509743848 From mhanl at openjdk.org Tue Dec 17 18:50:46 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Tue, 17 Dec 2024 18:50:46 GMT Subject: Integrated: 8218745: TableView: visual glitch at borders on horizontal scrolling In-Reply-To: References: Message-ID: On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote: > Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not modify the layout of `VirtualFlow`. > > This PR fixes the glitching by removing the code in `NGNode.renderRectClip`, which made many calculations leading to floating point errors. > Interestingly I found out, that `getClippedBounds(..)` is already returning the correct bounds that just need to be intersected with the clip of the `Graphics` object. > > So the following code is effectively doing the same: > > Old: > > BaseBounds newClip = clipNode.getShape().getBounds(); > if (!clipNode.getTransform().isIdentity()) { > newClip = clipNode.getTransform().transform(newClip, newClip); > } > final BaseTransform curXform = g.getTransformNoClone(); > final Rectangle curClip = g.getClipRectNoClone(); > newClip = curXform.transform(newClip, newClip); // <- The value of newClip after the transform is what getClippedBounds(..) is returning > newClip.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > Rectangle clipRect = new Rectangle(newClip) > > > New: > > BaseTransform curXform = g.getTransformNoClone(); > BaseBounds clipBounds = getClippedBounds(new RectBounds(), curXform); > Rectangle clipRect = new Rectangle(clipBounds); > clipRect.intersectWith(PrEffectHelper.getGraphicsClipNoClone(g)); > > > As you can see, there are very similar, but `getClippedBounds` does a much better job in calculating the bounds. > I also wrote a tests proving the bug. I took 100% of the setup and values from a debugging session I did when reproducing this bug. > > I checked several scenarios and code and could not find any regressions. > Still, since this is change affects all nodes with rectangular clips, we should be careful. > Performance wise I could not spot any difference, I do not expect any difference. > **So I would like to have at least 2 reviewers.** > Note that I will do more testing as well soon on all JavaFX applications I have access to. -> DONE: Could not spot any problem or difference. > > --- > > As written in the other PR, I have some interesting findings on this particular problem. > > Copy&Paste from the other PR: > -- > > Ok, so I found out the following: > When a Rectangle is used as clip without any effect or opacity modification, the rendering goes another (probably faster) route with rendering the clip. That's why setting the `opacity` to `0.99` fixes the issue - another route will be used for the rendering. > This happens at the low level (`NGNode`) side of JavaFX. > ... > I could track it down to be a typical floating point problem > ... > The bug always appear... This pull request has now been integrated. Changeset: ec8c032e Author: Marius Hanl URL: https://git.openjdk.org/jfx/commit/ec8c032e95f376d154978af4b7e92bfd5fd48ea6 Stats: 238 lines in 11 files changed: 163 ins; 56 del; 19 mod 8218745: TableView: visual glitch at borders on horizontal scrolling Reviewed-by: angorya, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1462 From kcr at openjdk.org Tue Dec 17 19:03:03 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 19:03:03 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:08:09 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > review comments Most of the changes look good. I left a few comments. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 287: > 285: * {@link #register(KeyBinding, Runnable)}, > 286: * {@link #registerKey(KeyBinding, FunctionTag)}, > 287: * or registered by the skin. The "or registered by the skin" part seems doesn't seem right to me. Is that really what happens? And if so, why is it the right thing to do? modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 292: > 290: */ > 291: public void unregister(KeyBinding k) { > 292: map.put(k, NULL); Why does this add a `NULL` rather than remove the mapping? I'm trying to understand the difference between this method and `resetKeyBindings` (maybe this is related to my earlier question above?). One thing to consider is that allowing `NULL` values means that there is no way to tell the difference between a key with a `NULL` value and a key that isn't in the map without calling `map.contains`, which you don't expose. modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 371: > 369: */ > 370: // TODO this should not affect the skin input map, but perhaps place NULL for each found KeyBinding > 371: public void unregister(FunctionTag tag) { For symmetry (and better clarity), I still think the name should have `KeyBindingsFor` in the name, perhaps `removeKeyBindingsFor` or `unregisgterKeyBindingsFor`. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 210: > 208: > 209: /** > 210: * Adds a wave underline (typically used as a spell checker indicator) with the given color. Minor: "wave" --> "wavy" modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichParagraph.java line 216: > 214: * @return this {@code Builder} instance > 215: */ > 216: public Builder wavyUnderline(int start, int length, Color color) { Should the name start with "add" (e.g., to match `addHighlight`)? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/RichTextModel.java line 132: > 130: @Override > 131: protected void insertParagraph(int index, Supplier generator) { > 132: throw new UnsupportedOperationException(); Should this be documented? modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 99: > 97: * Appends a text segment to the last paragraph. > 98: * The caller must ensure that the {@code text} does not contain newline symbols, as the behavior might be > 99: * undefined. Minor: I would say "is undefined" (instead of "might be") meaning that we don't define or specify the behavior. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/SimpleViewOnlyStyledModel.java line 191: > 189: > 190: /** > 191: * Adds a wave underline (typically used as a spell checker indicator) to the specified range within the last paragraph. Minor: "wave" --> "wavy" modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 140: > 138: * Returns the plain text string for the specified paragraph. The returned text string cannot be null > 139: * and must not contain any control characters other than TAB. > 140: * The caller must not attempt to ask for a paragraph outside of the valid range. It might be worth adding the note about "doing otherwise might result in an exception..." as you mentioned below. modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/model/StyledTextModel.java line 150: > 148: * Returns a {@link RichParagraph} at the given model index. > 149: * The callers must ensure that the value of {@code index} is within the valid document range, > 150: * since doing otherwise might result in an exception or undetermied behavior. Typo: "undetermied" --> "undetermined" ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2509752650 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889030681 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889046058 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889034881 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889053342 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889055776 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889057083 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889058306 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889059447 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889061153 PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889061933 From angorya at openjdk.org Tue Dec 17 19:09:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 19:09:43 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:52:00 GMT, Kevin Rushforth wrote: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. Marked as reviewed by angorya (Reviewer). build.properties line 92: > 90: jfx.build.jdk.version=23 > 91: jfx.build.jdk.buildnum=37 > 92: jdk.docs.version=23 very, very minor: maybe move this var to L95 so as not to break `jfx.build.jdk` block? (and also text in L76) ------------- PR Review: https://git.openjdk.org/jfx/pull/1663#pullrequestreview-2509848239 PR Review Comment: https://git.openjdk.org/jfx/pull/1663#discussion_r1889076646 From kcr at openjdk.org Tue Dec 17 19:29:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 19:29:17 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs [v2] In-Reply-To: References: Message-ID: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: Move jdk.docs.version before jfx.build.jdk.version ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1663/files - new: https://git.openjdk.org/jfx/pull/1663/files/795ed9aa..5a86fde8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1663&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1663&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1663.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1663/head:pull/1663 PR: https://git.openjdk.org/jfx/pull/1663 From angorya at openjdk.org Tue Dec 17 19:29:17 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 19:29:17 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 19:26:36 GMT, Kevin Rushforth wrote: >> Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). >> >> I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. >> >> As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. >> >> Both the GHA build and our CI build are successful. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Move jdk.docs.version before jfx.build.jdk.version thanks! ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1663#pullrequestreview-2509890261 From kcr at openjdk.org Tue Dec 17 19:29:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 19:29:17 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs In-Reply-To: References: Message-ID: <4nM68zuJCANvrQp9-c_ehtN5nirix3fw1nz364nYjJo=.37a42ff7-ce4e-4e19-b155-3033c9ec9e63@github.com> On Fri, 13 Dec 2024 00:52:00 GMT, Kevin Rushforth wrote: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. @tiainen Have you had a chance to see whether this works for you? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1663#issuecomment-2549417242 From kcr at openjdk.org Tue Dec 17 19:29:17 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 19:29:17 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 19:06:29 GMT, Andy Goryachev wrote: >> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: >> >> Move jdk.docs.version before jfx.build.jdk.version > > build.properties line 92: > >> 90: jfx.build.jdk.version=23 >> 91: jfx.build.jdk.buildnum=37 >> 92: jdk.docs.version=23 > > very, very minor: maybe move this var to L95 so as not to break `jfx.build.jdk` block? > > (and also text in L76) Good idea. Done. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1663#discussion_r1889097514 From angorya at openjdk.org Tue Dec 17 19:36:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 19:36:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 18:30:57 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 287: > >> 285: * {@link #register(KeyBinding, Runnable)}, >> 286: * {@link #registerKey(KeyBinding, FunctionTag)}, >> 287: * or registered by the skin. > > The "or registered by the skin" part seems doesn't seem right to me. Is that really what happens? And if so, why is it the right thing to do? this call disables the key binding, regardless of who registered it. the use case example is Eclipse's "Unbind Command": ![Screenshot 2024-12-17 at 11 32 33](https://github.com/user-attachments/assets/cb39eb4c-969b-4967-9c10-9acd133c33b9) ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889109521 From angorya at openjdk.org Tue Dec 17 20:03:55 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 20:03:55 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 18:42:45 GMT, Kevin Rushforth wrote: >> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments > > modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 292: > >> 290: */ >> 291: public void unregister(KeyBinding k) { >> 292: map.put(k, NULL); > > Why does this add a `NULL` rather than remove the mapping? I'm trying to understand the difference between this method and `resetKeyBindings` (maybe this is related to my earlier question above?). One thing to consider is that allowing `NULL` values means that there is no way to tell the difference between a key with a `NULL` value and a key that isn't in the map without calling `map.contains`, which you don't expose. see my previous comment for the use case. this method disables the key binding, regardless of whether it's done programmatically by the application (as in constructor of the custom RTA), or the skin. if we are talking about implementation, the NULL basically blocks subsequent lookup in the skin input map. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889141226 From kcr at openjdk.org Tue Dec 17 20:24:54 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 20:24:54 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v63] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 20:01:14 GMT, Andy Goryachev wrote: >> modules/jfx.incubator.input/src/main/java/jfx/incubator/scene/control/input/InputMap.java line 292: >> >>> 290: */ >>> 291: public void unregister(KeyBinding k) { >>> 292: map.put(k, NULL); >> >> Why does this add a `NULL` rather than remove the mapping? I'm trying to understand the difference between this method and `resetKeyBindings` (maybe this is related to my earlier question above?). One thing to consider is that allowing `NULL` values means that there is no way to tell the difference between a key with a `NULL` value and a key that isn't in the map without calling `map.contains`, which you don't expose. > > see my previous comment for the use case. > > this method disables the key binding, regardless of whether it's done programmatically by the application (as in constructor of the custom RTA), or the skin. > > if we are talking about implementation, the NULL basically blocks subsequent lookup in the skin input map. I see. In that case, unregister is not a good name, since it is _not_ the inverse of register. What it is really doing is registering a no-op binding. In which case... why is it needed at all? The application can just as easily do this: register(keyBinding, () -> {}); If there really is a compelling reason to keep this method, then we need to think of a better name. Maybe "disable" or "disableKeyBinding"? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1524#discussion_r1889167616 From angorya at openjdk.org Tue Dec 17 20:50:50 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 20:50:50 GMT Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional Scale [v5] In-Reply-To: <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com> References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com> <4hnTnYWWqWvjceSwdZ7VudM3TZEkyiicujy_Hb-iirk=.f2ba41e5-249e-423b-adad-cd16a32fb3ac@github.com> Message-ID: On Mon, 4 Nov 2024 17:21:57 GMT, Andy Goryachev wrote: >> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to @hjohn and @mstr2 . >> >> Removed earlier manual tester in favor of the monkey tester. >> >> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display. This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale). > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: > > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - in case of hitting min max > - Merge branch 'master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge branch 'master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - Merge remote-tracking branch 'origin/master' into 8299753.resize > - ... and 28 more: https://git.openjdk.org/jfx/compare/5bf02be0...7c947083 keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2549594948 From angorya at openjdk.org Tue Dec 17 20:53:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 20:53:31 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v64] In-Reply-To: References: Message-ID: > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 87 commits: - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - review comments - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - legal - unicode license - add handler - review comments - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea - ... and 77 more: https://git.openjdk.org/jfx/compare/ec8c032e...71a8017b ------------- Changes: https://git.openjdk.org/jfx/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=63 Stats: 40085 lines in 209 files changed: 40075 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From angorya at openjdk.org Tue Dec 17 21:06:16 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 21:06:16 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: References: Message-ID: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> > Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. > > This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. > > Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. > > Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. > > **References** > > - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md > - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md > - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc > - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 > - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md > - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html > - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: added html charset ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1524/files - new: https://git.openjdk.org/jfx/pull/1524/files/71a8017b..d43acd58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=64 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1524&range=63-64 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1524.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/jfx/pull/1524 From kcr at openjdk.org Tue Dec 17 22:01:59 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 17 Dec 2024 22:01:59 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v64] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 20:53:31 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 87 commits: > > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - review comments > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - legal > - unicode license > - add handler > - review comments > - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea > - ... and 77 more: https://git.openjdk.org/jfx/compare/ec8c032e...71a8017b The latest doc changes (and one method renaming) look good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2510233044 From angorya at openjdk.org Tue Dec 17 22:15:58 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Tue, 17 Dec 2024 22:15:58 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: <3tikqSoyXSj47F8GqWQEqrZPvml7X-0r1qhPmq9X_Dg=.7a49f251-6ee6-4b91-a1af-e8b4f41660eb@github.com> On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Refreshed the javadoc/apidiff attachments in the CSR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2549752831 From andy.goryachev at oracle.com Tue Dec 17 23:29:39 2024 From: andy.goryachev at oracle.com (Andy Goryachev) Date: Tue, 17 Dec 2024 23:29:39 +0000 Subject: [External] : Re: Focus delegation API In-Reply-To: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> References: <0A74984F-E1D7-42BC-9709-D3BDE47DFCED@gmail.com> Message-ID: Martin: I guess I am trying to say that I find the focus delegation idea as unnecessary - it feels to me like a band-aid on a broken event dispatching system. It might be the case that the current design was there from the beginning, and so probably all the other issues we have encountered so far due to that design: - the order of events is undefined - the events are copied willy nilly and their isConsumed flag is ignored - a parallel isConsumed mechanism gets invented - it is possible for the application to create a misbehaving event dispatcher - events that are intended for an inner component bubble up to the scene graph unnecessarily - consumed events continue being dispatched - multiple controls show input focus and handle input events simultaneously I am trying to find an alternative that will be easy for everyone to understand and use. Does not mean we should drop everything and re-write the whole thing, but I do want to continue the conversation. -andy From: Martin Fox Date: Friday, December 13, 2024 at 08:03 To: Andy Goryachev Cc: OpenJFX Subject: Re: [External] : Re: Focus delegation API Hi Andy, I?m trying to understand the use case you?ve outlined here since it doesn?t correspond to anything currently in JavaFX. On Dec 10, 2024, at 8:32?AM, Andy Goryachev wrote: How does the idea of focus delegation works with multiple inner nodes that are supposed to handle different aspects of a complex control? For example, a custom combo box-like control may contain an editor (possibly created dynamically), may be a couple of buttons, may be even two editors. How would that work? In this example, the buttons need focus to respond to ENTER or SPACE key presses, the editors should respond to key typed and maybe LEFT/RIGHT arrow keys to switch between the two, and so on. Will the proposed design still work? Are you proposing a control which delegates events to one inner node that changes over time OR a control which delegates a single key event to multiple inner nodes at once? If the latter, would all of those inner nodes have the focused flag set? Neither of these correspond to a control design I?m familiar with. Can you point to an example? I can?t picture how such a control would appear to the user. In either case would the delegate nodes be accessible via an API like a Spinner?s editor or hidden like a Spinner?s buttons? In the unlikely event that we wanted to deliver key events to a Spinner?s buttons I could imagine using an internal mechanism but that doesn?t make much sense for the publicly accessible editor. Perhaps in your use-case we need two separate mechanisms for delivering key events, this PR and a different one for delegate nodes that aren?t advertised via the control?s API. Martin From: openjfx-dev > on behalf of Michael Strau? > Date: Monday, December 9, 2024 at 18:17 To: Cc: openjfx-dev Subject: Re: [External] : Re: Focus delegation API > Yep, this seems unnecessary and counterproductive to me. All we need is to drop the target field from the event. I can't image that we would ever do this, considering that events have been there almost from the beginning. We'd break half of the JavaFX world if we changed the API of events. In addition to that, this would remove functionality. As of now, you can add a listener to Scene, and inspect which node is being targeted by an event. > > 2. ComboBox's skin has installed an event filter on ComboBox > > So we have another scenario where different priorities are needed: adding event filters. Maybe, but that's a different problem than what's being solved by focus delegation. Focus delegation is all about removing defective ad-hoc implementations, and offering a pre-made building block for composite controls. > > 3. However, it must forward the event to the TextField (as otherwise > the TextField doesn't work), so it fires off a copy of the event > targeted at TextField. > > Maybe instead, there should be a way to send the event to a Node directly, without bubbling up. These internal events should never propagate outside of the skin's internals. Sure, that would be an option. But it's not my preferred solution for the following reasons: 1. It's gratuitously different. Instead of using events like they normally work, control skins would punch a hole through the scene graph, and deliver the event directly to the delegation target. That means that the skin's scene graph works differently as the outside scene graph, as you can't observe events traveling through it. 2. It requires the skin to implement a complex protocol (register an event handler, copy the event, punch a hole through to the delegation target, send off the event), whereas the focus delegation proposal requires no additional implementation inside of the skin (aside from selecting the delegation target). The advantage of focus delegation is that it just works, even recursively, across arbitrary levels of abstractions (a skin might contain another control, which itself has a skin, and so on). No matter where you listen to events, you will always see exactly what you'd expect to see: an event that is targeted at the next focused node. This is another aspect of focus delegation, unrelated to events: it formalizes the notion of multi-level focus without resorting to hacks (like FakeFocusTextField). You'll need to solve this no matter what, as users can click on the TextField. As we discussed, the ComboBox must be the focus owner even when a user clicks on the TextField. > Well, we don't need to add a bunch of weird properties for that (the first part). Just send the events to the skin's components directly, preventing the bubbling up part. There is no need for Event.target because there is no extraneous events being bubbled up, and both CB and TF can process the events as they come in. First of all, it's only one property (Node.hoistFocus), not a bunch. And this is not related to events at all, it is a way for skins to indicate that clicking on an internal node will focus the outside control. The part of focus delegation that fixes the delivery of events in a scene graph with potentially nested abstractions is done without any new properties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sykora at openjdk.org Wed Dec 18 07:40:44 2024 From: sykora at openjdk.org (Joeri Sykora) Date: Wed, 18 Dec 2024 07:40:44 GMT Subject: RFR: 8345136: Update JDK_DOCS property to point to JDK 23 docs [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 19:29:17 GMT, Kevin Rushforth wrote: >> Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). >> >> I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. >> >> As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. >> >> Both the GHA build and our CI build are successful. > > Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision: > > Move jdk.docs.version before jfx.build.jdk.version This is looking fine for us. ------------- Marked as reviewed by sykora (Author). PR Review: https://git.openjdk.org/jfx/pull/1663#pullrequestreview-2511028766 From kcr at openjdk.org Wed Dec 18 13:51:47 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 13:51:47 GMT Subject: Integrated: 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed In-Reply-To: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> References: <8MgyBfft4BKQ74Nr711cOIKT9xPT3TNWi0T3kUuEvRc=.feecd7a0-6e25-4d29-ae12-a8cffaea8a0c@github.com> Message-ID: On Wed, 27 Nov 2024 19:27:55 GMT, Kevin Rushforth wrote: > Add the `--sun-misc-unsafe-memory-access=allow` flag until [JDK-8334137](https://bugs.openjdk.org/browse/JDK-8334137) is fixed to avoid warnings when running tests (automated and manual) with JDK 24. > > I've tested this using a boot JDK of JDK 22.0.2, JDK 23 (the boot JDK we use in production), and in our CI with the latest promoted build of JDK 24, which now warns by default when a deprecated method in `sun.misc.Unsafe` is called. > > Without this fix, we see a warning when running our automated or manual tests with JDK 24. With this fix, we see no warnings. This pull request has now been integrated. Changeset: 5279be65 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/5279be658350392e080d358ba7bdd1edb7310f07 Stats: 64 lines in 3 files changed: 56 ins; 2 del; 6 mod 8345127: Add --sun-misc-unsafe-memory-access=allow when running tests until JDK-8334137 is fixed Reviewed-by: arapte ------------- PR: https://git.openjdk.org/jfx/pull/1650 From kcr at openjdk.org Wed Dec 18 13:51:48 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 13:51:48 GMT Subject: Integrated: 8345136: Update JDK_DOCS property to point to JDK 23 docs In-Reply-To: References: Message-ID: On Fri, 13 Dec 2024 00:52:00 GMT, Kevin Rushforth wrote: > Update the docs bundle to point to the JDK 23 docs (we're currently pointing to JDK 21). > > I will need to also download and host a zip bundle and add its checksum to gradle/verification-metadata.xml to avoid breaking our internal CI build. > > As mentioned in [JDK-8325873](https://bugs.openjdk.org/browse/JDK-8325873) when we updated the docs to use JDK 21, we should do this as a part of updating the boot JDK. To facilitate this, and to move more version number properties to a common place, I will create a new `jdk.docs.version` property in `build.properties` and put it near the `jfx.build.jdk.version` property. > > Both the GHA build and our CI build are successful. This pull request has now been integrated. Changeset: e30d0d54 Author: Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/e30d0d54f4269ffe3a9293fc9604f5467c3b5e37 Stats: 13 lines in 3 files changed: 7 ins; 2 del; 4 mod 8345136: Update JDK_DOCS property to point to JDK 23 docs Reviewed-by: angorya, sykora, arapte ------------- PR: https://git.openjdk.org/jfx/pull/1663 From mstrauss at openjdk.org Wed Dec 18 17:57:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 18 Dec 2024 17:57:42 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: <67K0HnFgaCiR4U4gSSYMjcoSQ1s-ycxrn9lN4JU47M4=.f6eda424-6997-406e-bab5-8050ee94eff9@github.com> References: <67K0HnFgaCiR4U4gSSYMjcoSQ1s-ycxrn9lN4JU47M4=.f6eda424-6997-406e-bab5-8050ee94eff9@github.com> Message-ID: On Tue, 17 Dec 2024 18:18:00 GMT, Andy Goryachev wrote: >> `null` is not a valid argument for this method, and has never been. `acc_getPlatformPaint()` previously asserted that the return value is not `null`. > > this is not what I am asking though: in more than one place we have _callers_ like this > > peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); > > > it could be changed to > > peer.setFillPaint(tk.getPaint(getFill())); Yes, that would make the callsite a bit easier. However, from an API perspective, I think it's not the best approach to handle nulls in the toolkit layer. A system that channels nulls thorugh various layers tends to become harder to reason about over time. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1890631899 From angorya at openjdk.org Wed Dec 18 18:06:48 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Dec 2024 18:06:48 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: <9eXy_slQ3euO6AZnH_GFbJ8AGs0Imof69YUkf11RCHA=.c46f863d-c721-41d1-92c7-1fdd339f5b5e@github.com> On Sat, 14 Dec 2024 17:16:20 GMT, Michael Strau? wrote: >> The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use exhaustive switch pattern Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1665#pullrequestreview-2512524999 From angorya at openjdk.org Wed Dec 18 18:06:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Dec 2024 18:06:49 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: <67K0HnFgaCiR4U4gSSYMjcoSQ1s-ycxrn9lN4JU47M4=.f6eda424-6997-406e-bab5-8050ee94eff9@github.com> Message-ID: <_QSdwM1oSGD0qb5AFOtoKMnYtkp0EAa5oIbGkQbc8Z4=.65c9aacb-491b-424b-8878-b9eed03b9d83@github.com> On Wed, 18 Dec 2024 17:55:12 GMT, Michael Strau? wrote: >> this is not what I am asking though: in more than one place we have _callers_ like this >> >> peer.setFillPaint(getFill() == null ? null : tk.getPaint(getFill())); >> >> >> it could be changed to >> >> peer.setFillPaint(tk.getPaint(getFill())); > > Yes, that would make the callsite a bit easier. However, from an API perspective, I think it's not the best approach to handle nulls in the toolkit layer. A system that channels nulls thorugh various layers tends to become harder to reason about over time. I disagree: it makes it more resilient by doing what the caller has to do anyway. However, the answer is acceptable. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1890641976 From kcr at openjdk.org Wed Dec 18 19:28:41 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 19:28:41 GMT Subject: RFR: 8343398: Add reducedData preference [v6] In-Reply-To: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> References: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> Message-ID: On Thu, 12 Dec 2024 01:03:26 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > formatting I ran a CI build and noticed a crash in two test methods in one of our headful tests on macOS. Both of them use AWT as well as JavaFX, and given the error, I suspect that is relevant. *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[ApplicationDelegate getPlatformPreferences]: unrecognized selector sent to instance 0x6000030c0880' *** First throw call stack: ( 0 CoreFoundation 0x0000000182730570 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x0000000182221eb4 objc_exception_throw + 60 2 CoreFoundation 0x00000001827e212c -[NSObject(NSObject) __retain_OA] + 0 3 CoreFoundation 0x000000018269a7d4 ___forwarding___ + 1572 4 CoreFoundation 0x000000018269a0f0 _CF_forwarding_prep_0 + 96 5 ??? 0x00000001125fcfd4 0x0 + 4603236308 6 ??? 0x00000001125f8ea0 0x0 + 4603219616 7 ??? 0x00000001125f9110 0x0 + 4603220240 8 ??? 0x00000001125f9110 0x0 + 4603220240 9 ??? 0x00000001125f96b0 0x0 + 4603221680 10 ??? 0x00000001125f9110 0x0 + 4603220240 11 ??? 0x00000001125f96b0 0x0 + 4603221680 12 ??? 0x00000001125f9110 0x0 + 4603220240 13 ??? 0x00000001125f4114 0x0 + 4603199764 14 libjvm.dylib 0x0000000101e34e24 _ZN9JavaCalls11call_helperEP9JavaValueRK12methodHandleP17JavaCallArgumentsP10JavaThread + 984 15 libjvm.dylib 0x0000000101ea5e1c _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP10JavaThread + 992 16 libjvm.dylib 0x0000000101eaa844 jni_CallVoidMethod + 284 17 libglass.dylib 0x000000013570164c JNI_OnLoad + 1036 18 libglass.dylib 0x00000001357031ac JNI_OnLoad + 8044 19 Foundation 0x00000001837e1298 __NSThreadPerformPerform + 264 20 CoreFoundation 0x00000001826bba4c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 21 CoreFoundation 0x00000001826bb9e0 __CFRunLoopDoSource0 + 176 22 CoreFoundation 0x00000001826bb750 __CFRunLoopDoSources0 + 244 23 CoreFoundation 0x00000001826ba340 __CFRunLoopRun + 828 24 CoreFoundation 0x00000001826b99ac CFRunLoopRunSpecific + 608 25 HIToolbox 0x000000018cc68448 RunCurrentEventLoopInMode + 292 26 HIToolbox 0x000000018cc68284 ReceiveNextEventCommon + 648 27 HIToolbox 0x000000018cc67fdc _BlockUntilNextEventMatchingListInModeWithFilter + 76 28 AppKit 0x0000000185e968a4 _DPSNextEvent + 660 29 AppKit 0x0000000186670980 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716 30 libosxapp.dylib 0x00000001007ab748 -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 136 31 AppKit 0x0000000185e89d50 -[NSApplication run] + 476 32 libosxapp.dylib 0x00000001007ab568 +[NSApplicationAWT runAWTLoopWithApp:] + 132 33 libawt_lwawt.dylib 0x0000000131062f5c +[AWTStarter starter:headless:] + 376 34 libosxapp.dylib 0x00000001007acd88 +[ThreadUtilities invokeBlockCopy:] + 28 35 Foundation 0x00000001837e1298 __NSThreadPerformPerform + 264 36 CoreFoundation 0x00000001826bba4c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 37 CoreFoundation 0x00000001826bb9e0 __CFRunLoopDoSource0 + 176 38 CoreFoundation 0x00000001826bb750 __CFRunLoopDoSources0 + 244 39 CoreFoundation 0x00000001826ba340 __CFRunLoopRun + 828 40 CoreFoundation 0x00000001826b99ac CFRunLoopRunSpecific + 608 41 libjli.dylib 0x00000001008a0e84 CreateExecutionEnvironment + 404 42 libjli.dylib 0x000000010089c984 JLI_Launch + 1152 43 java 0x000000010040fbb4 main + 404 44 dyld 0x000000018225d0e0 start + 2360 ) libc++abi: terminating due to uncaught exception of type NSException > Task :systemTests:test MainLauncherTest > testMainLauncher(TestData) > [7] test.launchertest.MainLauncherTest$TestData at 63fbfaeb FAILED org.opentest4j.AssertionFailedError: test.launchertest.TestStartupJFXPanel: Unexpected error exit: 134 at app//org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at app//org.junit.jupiter.api.Assertions.fail(Assertions.java:138) at app//test.launchertest.MainLauncherTest.testMainLauncher(MainLauncherTest.java:231) I'm also seeing some failures (color mismatches) in other tests, but I don't know if those are related your to your PR or not -- it seems unlikely that they would be, but I need to check. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2552104844 From kcr at openjdk.org Wed Dec 18 19:33:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 19:33:42 GMT Subject: RFR: 8343398: Add reducedData preference [v6] In-Reply-To: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> References: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> Message-ID: On Thu, 12 Dec 2024 01:03:26 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > formatting The changes to GlassApplication where you assume that `[NSApp delegate]` is a `GlassApplication` won't work in the case where the AWT toolkit is initialized first (e.g., a JFXPanel app). modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 1271: > 1269: { > 1270: GlassApplication* app = (GlassApplication*)[NSApp delegate]; > 1271: return [app getPlatformPreferences]; I think this is the cause of the crash. You cannot assume that `[NSApp delegate]` is a `GlassApplication`. In the case where AWT initializes the toolkit first, it won't be. ------------- Changes requested by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2512700869 PR Review Comment: https://git.openjdk.org/jfx/pull/1656#discussion_r1890737991 From kcr at openjdk.org Wed Dec 18 20:44:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 20:44:42 GMT Subject: RFR: 8343398: Add reducedData preference [v6] In-Reply-To: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> References: <5bOreIwa-096C_oL1LYGE58gsvES8Qq6O_Qx0UT2Q9w=.0d362267-0b40-43d8-a389-30c0025c42cf@github.com> Message-ID: On Thu, 12 Dec 2024 01:03:26 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > formatting I can reproduce this locally. Any app that initializes the AWT toolkit and then uses FX will hit this, including `HelloJFXPanel` (in `apps/toys/Hello`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2552231672 From mstrauss at openjdk.org Wed Dec 18 20:52:59 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 18 Dec 2024 20:52:59 GMT Subject: RFR: 8343398: Add reducedData preference [v7] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - typo - store the app delegate reference in MacApplication ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/cbd3cb63..fd4846a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=06 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=05-06 Stats: 62 lines in 2 files changed: 34 ins; 3 del; 25 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Wed Dec 18 20:56:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Wed, 18 Dec 2024 20:56:42 GMT Subject: RFR: 8343398: Add reducedData preference [v7] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 20:52:59 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - store the app delegate reference in MacApplication It seems that there's no reliable way to retreive the `GlassApplication` instance outside of the `_runLoop()` method where it is created. I've decided to split the method into `_initDelegate()` and `_runLoop()`, and store the app delegate reference in the `MacApplication` class on the Java side. Then the reference can be passed down into the native toolkit for methods that require it (like `_getPlatformPreferences()`). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2552248753 From kcr at openjdk.org Wed Dec 18 21:28:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 21:28:42 GMT Subject: RFR: 8343398: Add reducedData preference [v7] In-Reply-To: References: Message-ID: On Wed, 18 Dec 2024 20:52:59 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - store the app delegate reference in MacApplication I'll take a closer look later, but the changes to solve the problem with GlassApplication look good to me. I'll also fire off another headful test run and report the results. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 995: > 993: NSAutoreleasePool *glasspool = [[NSAutoreleasePool alloc] init]; > 994: { > 995: GlassApplication* glass = (GlassApplication*)appDelegate; This looks like a clean split to me. modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 1026: > 1024: > 1025: if (appDelegate) { > 1026: [(GlassApplication*)appDelegate release]; This is needed because you moved the allocation of GlassApplication outside (before) the auto-release pool in runLoop, so looks good. ------------- PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2512892606 PR Review Comment: https://git.openjdk.org/jfx/pull/1656#discussion_r1890855088 PR Review Comment: https://git.openjdk.org/jfx/pull/1656#discussion_r1890855283 From angorya at openjdk.org Wed Dec 18 21:53:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Wed, 18 Dec 2024 21:53:41 GMT Subject: RFR: 8343398: Add reducedData preference [v7] In-Reply-To: References: Message-ID: <0WMQkFNUAv9hj8hfupEQ0kG3xkogTt8EHRQbncrd8us=.139aacfd-91f0-430e-a7e3-33eae33d9ab3@github.com> On Wed, 18 Dec 2024 20:52:59 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - store the app delegate reference in MacApplication - HelloJFXPanel does not fail anymore - for completeness sake, ran swing/fx interop tools in the monkey tester - no problems before and after the latest changes (can't really reproduce the HelloJFXPanel use case with the MT) - see the property events for light/dark mode and reduced data on macOS 15.1.1 ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2512931609 From kcr at openjdk.org Wed Dec 18 22:50:45 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 18 Dec 2024 22:50:45 GMT Subject: RFR: 8343398: Add reducedData preference [v7] In-Reply-To: References: Message-ID: <13RP6tMUzLt7fQwqh4P1zVrqy1gbR0USRHHolAsbeVI=.89b92739-3954-4186-972f-346121988376@github.com> On Wed, 18 Dec 2024 20:52:59 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - typo > - store the app delegate reference in MacApplication Our CI headful test build passed on macOS and Linux (I'll need to run Windows manually later), so the problem is fixed (the other Robot color mismatch test failures were unrelated, and fixed by rebooting the macOS systems in question). I don't have access to Windows or Linux system where I can turn on the metering option, so I can't test if the notification works. Maybe someone else can? I'll review the code tomorrow. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2552415742 From mstrauss at openjdk.org Thu Dec 19 04:19:27 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 Dec 2024 04:19:27 GMT Subject: RFR: 8343398: Add reducedData preference [v8] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: - method name - smaller diff ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/fd4846a9..7feba0bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=07 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=06-07 Stats: 25 lines in 1 file changed: 12 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From arapte at openjdk.org Thu Dec 19 06:48:58 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Thu, 19 Dec 2024 06:48:58 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v65] In-Reply-To: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> References: <30Kh14YFUvB9TweXzjsz5fI0EUQGQong_Z0SqvFF1zU=.b4fc4c32-e7d1-4543-85fe-fa9300b53e9f@github.com> Message-ID: On Tue, 17 Dec 2024 21:06:16 GMT, Andy Goryachev wrote: >> Incubating a new feature - rich text control, **RichTextArea**, intended to bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The main design goal is to provide a control that is complete enough to be useful out-of-the box, as well as open to extension by the application developers. >> >> This is a complex feature with a large API surface that would be nearly impossible to get right the first time, even after an extensive review. We are, therefore, introducing this in an incubating module, **jfx.incubator.richtext**. This will allow us to evolve the API in future releases without the strict compatibility constraints that other JavaFX modules have. >> >> Please check out two manual test applications - one for RichTextArea (**RichTextAreaDemoApp**) and one for the CodeArea (**CodeAreaDemoApp**). Also, a small example provides a standalone rich text editor, see **RichEditorDemoApp**. >> >> Because it's an incubating module, please focus on the public APIs rather than implementation. There **will be** changes to the implementation once/if the module is promoted to the core by popular demand. The goal of the incubator is to let the app developers try the new feature out. >> >> **References** >> >> - Proposal: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextArea.md >> - Discussion points: https://github.com/andy-goryachev-oracle/Test/blob/main/doc/RichTextArea/RichTextAreaDiscussion.md >> - API specification (javadoc): https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> - RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> - Behavior doc: https://github.com/andy-goryachev-oracle/jfx/blob/8301121.RichTextArea/doc-files/behavior/RichTextAreaBehavior.md >> - CSS Reference: https://cr.openjdk.org/~angorya/RichTextArea/javadoc/javafx.graphics/javafx/scene/doc-files/cssref.html >> - InputMap (v3): https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md >> - Previous Draft PR: https://github.com/openjdk/jfx/pull/1374 > > Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision: > > added html charset Great work @andy-goryachev-oracle ------------- Marked as reviewed by arapte (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1524#pullrequestreview-2513481651 From johan.vos at gluonhq.com Thu Dec 19 12:27:42 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 19 Dec 2024 13:27:42 +0100 Subject: Binding.dispose Message-ID: Hi, I believe the javadoc in Binding.dispose() is misleading. Before creating an issue for this, it would be good to know if others have other interpretation, or suggestions for improvements. I recently ran into a memory leak that was caused by this binding: ``` someDoubleProperty.bind(Bindings.when(someBooleanProperty).then(cell.layoutYProperty()).otherwise(0)); ... someDoubleProperty.unbind(); ``` This flow creates a memoryleak as the NumberBinding created in the then clause is not using a WeakInvalidationListener, hence it has to be disposed manually. However, the javadoc for Binding.dispose() says: ``` All bindings in our implementation use instances of WeakInvalidationListener, which means usually a binding does not need to be disposed. ``` I think this is incorrect and should be fixed. In general, I believe the javadoc about Binding needs to be revisited. There are too many occurrences like "in general", "usually", "optional", which contributes to the idea that bindings are fuzzy logic. - Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhanl at openjdk.org Thu Dec 19 15:57:52 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 19 Dec 2024 15:57:52 GMT Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to fixedCellSize by live lookup [v2] In-Reply-To: References: <2FwU_9vR1LlN9SGqkfhAwny9yMvBl8kSpdmlDkApCbA=.58c9ba1e-91e6-425d-befa-d59097a55f4d@github.com> Message-ID: On Tue, 10 Dec 2024 23:28:05 GMT, Andy Goryachev wrote: >> It will be much better after https://github.com/openjdk/jfx/pull/1644 :) > > can you apply the same treatment as in #1644? there at least it makes sense. I would say, lets merge https://github.com/openjdk/jfx/pull/1644 first and then it is automatically there when the conflict is solved ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1645#discussion_r1892574916 From mhanl at openjdk.org Thu Dec 19 16:03:02 2024 From: mhanl at openjdk.org (Marius Hanl) Date: Thu, 19 Dec 2024 16:03:02 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: > This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. > > In order to do that, there are multiple things needed: > - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there > - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) > - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) > - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns > - As before, the `TableRow` adds or removes cells that are visible or not. > Note that this is only done when a fixed cell size is set. > The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later > - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: > - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells > Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself > - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-8276326](https://bugs.openjdk.org... Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization # Conflicts: # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization # Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction ------------- Changes: https://git.openjdk.org/jfx/pull/1644/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1644&range=03 Stats: 1346 lines in 14 files changed: 1171 ins; 141 del; 34 mod Patch: https://git.openjdk.org/jfx/pull/1644.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1644/head:pull/1644 PR: https://git.openjdk.org/jfx/pull/1644 From angorya at openjdk.org Thu Dec 19 16:03:02 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Dec 2024 16:03:02 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v3] In-Reply-To: References: Message-ID: <5X7VB-s_j74Z4g8jo74RLVn5S0vLlhfXuoOSQ7jeJm0=.6f5508cc-a9ac-4c8c-8dfa-71a98ed943eb@github.com> On Tue, 10 Dec 2024 07:23:38 GMT, Johan Vos wrote: > I believe this PR is a good step in the good direction. @johanvos would you approve this PR then? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2554779265 From angorya at openjdk.org Thu Dec 19 17:14:04 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Dec 2024 17:14:04 GMT Subject: RFR: 8301121: RichTextArea Control (Incubator) [v18] In-Reply-To: References: <5j9aLgil_oufAlaDflX9eWKUJRCPXP9Hiq_eCjzh7JY=.7240f3ae-503c-4ccb-9aad-f2bc0f1cb19b@github.com> <2ss6IfWyTbKwhsMlug9KB1GI6hlcI9OucWLFKkqi-dc=.80284c64-7f68-474f-b972-f4ef28efa8de@github.com> Message-ID: <-MxrWCdxm4jvpBBpa8TRnFI8m5YEqh76GmC0_-G0ats=.65f3ee57-c4cd-468f-a557-55ce5e82018a@github.com> On Fri, 4 Oct 2024 07:48:50 GMT, Ambarish Rapte wrote: >>> I observed an NPE with RichTextAreaDemoApp: >> >> I can't reproduce this... >> >> Are you on mac or windows? Are you testing the latest code (can you tell me the git commit hash?) >> Also, could you take a screenshot when this happens, I'd like to see the settings on the right pane. > >> Are you on mac or windows? Are you testing the latest code (can you tell me the git commit hash?) Also, could you take a screenshot when this happens, I'd like to see the settings on the right pane. > > Tested it on Mac by fetching this PR using the command: > `git fetch origin pull/1524/head:1524` > HEAD commit: de3947b9f72e934acb2de4247cb851f40d7017e1 (HEAD -> 1524) > Attaching a video : > > https://github.com/user-attachments/assets/65f2b5fd-4638-4f00-996a-02d1cf851969 Thank you, @arapte ! ------------- PR Comment: https://git.openjdk.org/jfx/pull/1524#issuecomment-2555173647 From kcr at openjdk.org Thu Dec 19 18:10:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Dec 2024 18:10:43 GMT Subject: RFR: 8343398: Add reducedData preference [v8] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 04:19:27 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with two additional commits since the last revision: > > - method name > - smaller diff The headful test run passed on Windows. While doing manual testing of other settings (since the notification logic has changed), I discovered a reproducible crash on Windows 11: 1. Run the manual `PlatformPreferencesChangedTest` app (or any other JavaFX app) 2. Toggle Settings --> Accessibility --> Visual effects --> Animation effects JavaFX will crash, likely in response to the notification of a change in animation effect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2555476391 From jvos at openjdk.org Thu Dec 19 19:14:44 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 19 Dec 2024 19:14:44 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v3] In-Reply-To: <5X7VB-s_j74Z4g8jo74RLVn5S0vLlhfXuoOSQ7jeJm0=.6f5508cc-a9ac-4c8c-8dfa-71a98ed943eb@github.com> References: <5X7VB-s_j74Z4g8jo74RLVn5S0vLlhfXuoOSQ7jeJm0=.6f5508cc-a9ac-4c8c-8dfa-71a98ed943eb@github.com> Message-ID: <0wkanflTK34_3npRz7CqpMAdshqBovVMb-NNOcYKg7c=.1fd90db1-00fb-4922-b00a-f0d640f499e2@github.com> On Thu, 19 Dec 2024 15:57:14 GMT, Andy Goryachev wrote: > > I believe this PR is a good step in the good direction. > > @johanvos would you approve this PR then? I only looked into the changes in VirtualFlow, so I can't say anything about the other changes -- and approving a PR means the whole PR has been reviewed. I can do a review later, but tbh, the TableRowSkin is a beast I never managed to tame :) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2555589055 From angorya at openjdk.org Thu Dec 19 19:19:46 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Thu, 19 Dec 2024 19:19:46 GMT Subject: RFR: 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction [v4] In-Reply-To: References: Message-ID: <5Zyc1xEDes2XawLvvXbHvzYu-NmHm_IAUeo_cBR0Itc=.453979d3-c04d-42c0-b937-e7d5779c0dd8@github.com> On Thu, 19 Dec 2024 16:03:02 GMT, Marius Hanl wrote: >> This PR fixes the horizontal virtualization performed in the `TableRowSkinBase`, which significantly improves performance with many columns (and thus many cells). Scrolling up and down as well as scrolling left and right feels much more snappy. >> >> In order to do that, there are multiple things needed: >> - the `isColumnPartiallyOrFullyVisible` needs to be fixed to take the `VirtualFlow` into account, not the `TableView`. Since rows are inside the `VirtualFlow`, we need to use the width from there >> - The wrong implementation right now leads to [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326), where if you scroll to the right with many columns, cells on the left start to be empty (since they are removed when they should'nt be) >> - It also does not help performance when scrolled to the left, as the right cells are not removed (only when scrolling to the right, cells on the left are removed) >> - To improve performance, `isColumnPartiallyOrFullyVisible` was refactored to take in everything that is needed directly, without reiterating through all columns >> - As before, the `TableRow` adds or removes cells that are visible or not. >> Note that this is only done when a fixed cell size is set. >> The reason for that is that we always know the row height. If not set, we need all cells so we can iterate over them to get the max height. I'm not sure if this can be improved, but this is not the goal of this PR and can be checked later >> - The other issue mentioned in [JDK-8276326](https://bugs.openjdk.org/browse/JDK-8276326) happens only when a fixed cell size is set (empty rows). This is related and also fixed: >> - Cells start to be empty when scolling around a lot. This is because cells that are in the pile (ready to be reused) will not receive any layout requests (`requestLayout`) while all cells in the viewport will receive them. As soon as they are reused, they are visually outdated and not updated, leading to empty cells >> Fix is to request layout to those cells as well, and as soon as they are reused, they will layout themself >> - This has revealed another error: Cells that are not used anymore (added to the pile and invisible) are STILL inside the `VirtualFlow` sheet (as children). This will cause them to actually do the layout when requested, and especially when the height of the `TableView` changed drastically (e.g. from 50 visible cells to just 10), we have 40 cells laying around, receiving the layout request I added to fix [JDK-82763... > > Marius Hanl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/VirtualFlowTest.java > - Merge branch 'master' of https://github.com/openjdk/jfx into 8185887-virtualization > > # Conflicts: > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkinBase.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java > # modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java > - 8185887: Reset disclosureNodeDirty in updateDisclosureNodeAndGraphic() > - 8185887: TableRowSkinBase fails to correctly virtualize cells in horizontal direction Thank you for the partial review nevertheless! Every little bit helps... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1644#issuecomment-2555598227 From mstrauss at openjdk.org Thu Dec 19 19:34:58 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 Dec 2024 19:34:58 GMT Subject: RFR: 8343398: Add reducedData preference [v9] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: only update preferences that may have changed ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/7feba0bf..f8384925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=08 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=07-08 Stats: 49 lines in 2 files changed: 22 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Thu Dec 19 21:03:58 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 Dec 2024 21:03:58 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: change enum constant names ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/f8384925..b7840bd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=09 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=08-09 Stats: 29 lines in 4 files changed: 1 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Thu Dec 19 21:10:42 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Thu, 19 Dec 2024 21:10:42 GMT Subject: RFR: 8343398: Add reducedData preference [v8] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 18:07:45 GMT, Kevin Rushforth wrote: > The headful test run passed on Windows. While doing manual testing of other settings (since the notification logic has changed), I discovered a reproducible crash on Windows 11: > > 1. Run the manual `PlatformPreferencesChangedTest` app (or any other JavaFX app) > 2. Toggle Settings --> Accessibility --> Visual effects --> Animation effects > > JavaFX will crash, likely in response to the notification of a change in animation effect. This is a weird one. I've narrowed it down to `INetworkInformation::GetInternetConnectionProfile` returning `null`, and then crashing the app. Now, this method is specified to return `null` if there's no connection profile, so a null-check is obviously in order. What is strange is that at least on my machine, `GetInternetConnectionProfile` always returns a non-null value _except_ when the method is called in response to receiving `WM_SETCLIENTAREAANIMATION`. Note that the method doesn't fail with an error, it simply returns `null`. I've checked all "obvious" things that might go wrong, such as calling the method on a wrong thread (not the case, it's always the same thread, regardless of whether we react to a window message or a WinRT callback). The quick fix in this case is simply not calling the API in question in response to the unrelated `WM_SETCLIENTAREAANIMATION` message. I've added a parameter to `collectPreferences()` that indicates what type of preferences we're going to collect. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2555776513 From kevin.rushforth at oracle.com Fri Dec 20 00:05:35 2024 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Dec 2024 16:05:35 -0800 Subject: Proposed schedule for JavaFX 24 In-Reply-To: References: Message-ID: As a reminder, Rampdown Phase 1 (RDP1) for JavaFX 24 starts on Thursday, January 16, 2025 at 16:00 UTC (08:00 US/Pacific time). Given the upcoming holidays, that's a little over 2 working weeks from now. During rampdown of JavaFX 24, the "master" branch of the jfx repo will be open for JavaFX 25 fixes. Please allow sufficient time for any feature that needs a CSR. New features should be far enough along in the review process that you can finalize the CSR no later than Thursday, January 9, or it is likely to miss the window for this release, in which case it can be targeted for JavaFX 25. We will follow the same process as in previous releases for getting fixes into JavaFX 24 during rampdown. I'll send a message with detailed information when we fork, but candidates for fixing during RDP1 are P1-P3 bugs (as long as they are not risky) and test or doc bugs of any priority. Some small enhancements might be considered during RDP1, but they require explicit approval; the bar will be high for such requests. -- Kevin On 10/25/2024 11:34 AM, Kevin Rushforth wrote: > Here is the proposed schedule for JavaFX 24: > > RDP1: Jan 16, 2025 (aka ?feature freeze?) > RDP2: Feb 6, 2025 > Freeze: Feb 27, 2025 > GA: Mar 18, 2025 > > We plan to fork a jfx24 stabilization branch at RDP1. > > The start of RDP1, the start of RDP2, and the code freeze will be > 16:00 UTC on the respective dates. > > This schedule moves the RDP1 and RDP2 start dates back one week to > better avoid running into the holidays like we usually do. This will > give one extra week before RDP1 starts and one less week during RDP2 > (we historically have few fixes coming in during RDP2). We intend to > use this as the new formula for computing the release schedule going > forward. > > Please let Johan or me know if you have any questions. > > -- Kevin > From arapte at openjdk.org Fri Dec 20 09:17:01 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Dec 2024 09:17:01 GMT Subject: RFR: 8346693: Update copyright header for files modified in 2024 Message-ID: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Update copyright year in files updated in the year 2024, as we reach end of the year. ------------- Commit messages: - 8346693: Update copyright header for files modified in 2024 Changes: https://git.openjdk.org/jfx/pull/1666/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346693 Stats: 470 lines in 470 files changed: 0 ins; 0 del; 470 mod Patch: https://git.openjdk.org/jfx/pull/1666.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1666/head:pull/1666 PR: https://git.openjdk.org/jfx/pull/1666 From kcr at openjdk.org Fri Dec 20 13:22:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 13:22:42 GMT Subject: RFR: 8346693: Update copyright header for files modified in 2024 In-Reply-To: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> References: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Message-ID: On Fri, 20 Dec 2024 09:12:46 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2024, as we reach end of the year. Looks good except for two files that need to be reverted. modules/javafx.media/src/main/legal/libffi.md line 38: > 36: Copyright (C) 2002-2007 Bo Thorsen > 37: Copyright (C) 2021 Microsoft, Inc. > 38: Copyright (c) 2022, 2024, Oracle and/or its affiliates. Revert this change. The copyright years should not be modified in a third-party README. modules/javafx.media/src/main/native/gstreamer/3rd_party/libffi/src/prep_cif.c line 4: > 2: prep_cif.c - Copyright (c) 2011, 2012, 2021 Anthony Green > 3: Copyright (c) 1996, 1998, 2007 Red Hat, Inc. > 4: Copyright (c) 2022, 2024, Oracle and/or its affiliates. Revert this change. The copyright years should not be modified in a third-party file. ------------- PR Review: https://git.openjdk.org/jfx/pull/1666#pullrequestreview-2517529916 PR Review Comment: https://git.openjdk.org/jfx/pull/1666#discussion_r1893926133 PR Review Comment: https://git.openjdk.org/jfx/pull/1666#discussion_r1893929258 From arapte at openjdk.org Fri Dec 20 13:34:29 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Dec 2024 13:34:29 GMT Subject: RFR: 8346693: Update copyright header for files modified in 2024 [v2] In-Reply-To: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> References: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Message-ID: > Update copyright year in files updated in the year 2024, as we reach end of the year. Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: revert third party files ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1666/files - new: https://git.openjdk.org/jfx/pull/1666/files/b127cb4b..13d62cd2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1666&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1666&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jfx/pull/1666.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1666/head:pull/1666 PR: https://git.openjdk.org/jfx/pull/1666 From kcr at openjdk.org Fri Dec 20 13:34:30 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 13:34:30 GMT Subject: RFR: 8346693: Update copyright header for files modified in 2024 [v2] In-Reply-To: References: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Message-ID: <1KyHnGwOUaMPxv_KqbkioRdBwBXPPckCn8qYzYZmFgQ=.7b9b410e-cf15-4de9-9cd8-7206d91269cf@github.com> On Fri, 20 Dec 2024 13:31:34 GMT, Ambarish Rapte wrote: >> Update copyright year in files updated in the year 2024, as we reach end of the year. > > Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision: > > revert third party files Marked as reviewed by kcr (Lead). ------------- PR Review: https://git.openjdk.org/jfx/pull/1666#pullrequestreview-2517559637 From arapte at openjdk.org Fri Dec 20 13:34:31 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Dec 2024 13:34:31 GMT Subject: RFR: 8346693: Update copyright header for files modified in 2024 [v2] In-Reply-To: References: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Message-ID: On Fri, 20 Dec 2024 13:20:31 GMT, Kevin Rushforth wrote: > two files that need to be reverted. Thanks Kevin, The two files are now reverted. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1666#issuecomment-2557025386 From arapte at openjdk.org Fri Dec 20 14:04:42 2024 From: arapte at openjdk.org (Ambarish Rapte) Date: Fri, 20 Dec 2024 14:04:42 GMT Subject: Integrated: 8346693: Update copyright header for files modified in 2024 In-Reply-To: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> References: <9QnXVqBota2hYP3cMmRKU6UfrQlFySMqgfehmGff2tk=.6aff43b2-0b2f-4642-8b3a-5d2e3d469b19@github.com> Message-ID: On Fri, 20 Dec 2024 09:12:46 GMT, Ambarish Rapte wrote: > Update copyright year in files updated in the year 2024, as we reach end of the year. This pull request has now been integrated. Changeset: f06b15b6 Author: Ambarish Rapte URL: https://git.openjdk.org/jfx/commit/f06b15b6e6c60fba18b6452464e75b89cc7054f9 Stats: 468 lines in 468 files changed: 0 ins; 0 del; 468 mod 8346693: Update copyright header for files modified in 2024 Reviewed-by: kcr ------------- PR: https://git.openjdk.org/jfx/pull/1666 From kcr at openjdk.org Fri Dec 20 14:50:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 14:50:42 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 21:03:58 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > change enum constant names The changes all look good now. I did notice one thing in macOS while reviewing the changes in `PlatformSupport.m`. The PlatformSupport object stays around after the GlassApplication is terminated via finishTerminating. It will continue to process platform events, including making Java upcalls even after the FX toolkit is stopped. You would only see this with a Swing interop app that initializes FX and then later terminates it while keeping AWT alive. I think it is preexisting, and doesn't seem to be causing any problems. It might be worth a P4 follow-up issue to investigate. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2517714143 From kcr at openjdk.org Fri Dec 20 15:03:56 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 15:03:56 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 14:48:05 GMT, Kevin Rushforth wrote: > I did notice one thing in macOS while reviewing the changes in `PlatformSupport.m`. The PlatformSupport object stays around after the GlassApplication is terminated via finishTerminating. It will continue to process platform events, including making Java upcalls even after the FX toolkit is stopped. Correction: the listeners no longer get notified after the FX toolkit is stopped, perhaps due to the fix for[JDK-8335630](https://bugs.openjdk.org/browse/JDK-8335630). Needs more investigation. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557174418 From angorya at openjdk.org Fri Dec 20 15:50:43 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 15:50:43 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: On Thu, 19 Dec 2024 21:03:58 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > change enum constant names Marked as reviewed by angorya (Reviewer). ------------- PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2517827037 From kcr at openjdk.org Fri Dec 20 16:55:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 16:55:44 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 15:01:00 GMT, Kevin Rushforth wrote: > Correction: the listeners no longer get notified after the FX toolkit is stopped, perhaps due to the fix for[JDK-8335630](https://bugs.openjdk.org/browse/JDK-8335630). Needs more investigation. This is not related to JDK-8335630. The notification does get delivered, but ends up going through the "else" block in the following code in `PlatformImpl::updatePreferences`: if (isFxApplicationThread()) { checkHighContrastThemeChanged(preferences); platformPreferences.update(preferences); } else { // Make a defensive copy in case the caller of this method decides to re-use or // modify its preferences map after the method returns. Don't use Map.copyOf // because the preferences map may contain null values. Map preferencesCopy = new HashMap<>(preferences); runLater(() -> updatePreferences(preferencesCopy)); } This happens because `isFxApplicationThread()` returns false after the toolkit is stopped (see `Application::finishTerminating`). The `runLater` at the end of the else block never runs and the runnable is discarded, so the else block ends up being a no-op. So I think my recommendation of "maybe file a P4 bug to look at later" is the most that is needed here. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557378425 From mstrauss at openjdk.org Fri Dec 20 18:01:56 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 20 Dec 2024 18:01:56 GMT Subject: RFR: 8343398: Add reducedData preference [v11] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: release macOS PlatformSupport instance ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/b7840bd6..6f015a47 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=10 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=09-10 Stats: 23 lines in 3 files changed: 22 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From mstrauss at openjdk.org Fri Dec 20 18:05:44 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 20 Dec 2024 18:05:44 GMT Subject: RFR: 8343398: Add reducedData preference [v10] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 14:48:05 GMT, Kevin Rushforth wrote: > The changes all look good now. > > I did notice one thing in macOS while reviewing the changes in `PlatformSupport.m`. The PlatformSupport object stays around after the GlassApplication is terminated via finishTerminating. It will continue to process platform events, including making Java upcalls even after the FX toolkit is stopped. You would only see this with a Swing interop app that initializes FX and then later terminates it while keeping AWT alive. I think it is preexisting, and doesn't seem to be causing any problems. It might be worth a P4 follow-up issue to investigate. I've added some code that ensures that the `PlatformSupport` instance stops event processing and is released when `GlassApplication` shuts down. I've verified this by logging whether `dealloc` is called, which it is. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557478491 From mstrauss at openjdk.org Fri Dec 20 18:24:29 2024 From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=) Date: Fri, 20 Dec 2024 18:24:29 GMT Subject: RFR: 8343398: Add reducedData preference [v12] In-Reply-To: References: Message-ID: > The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. > > This corresponds to the following OS settings: > > Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection > macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode > Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection > > Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. Michael Strau? 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 17 additional commits since the last revision: - Merge branch 'master' into feature/reduced-data - release macOS PlatformSupport instance - change enum constant names - only update preferences that may have changed - method name - smaller diff - typo - store the app delegate reference in MacApplication - formatting - changed formatting - ... and 7 more: https://git.openjdk.org/jfx/compare/8b2016bd...b1635719 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1656/files - new: https://git.openjdk.org/jfx/pull/1656/files/6f015a47..b1635719 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=11 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1656&range=10-11 Stats: 1063 lines in 531 files changed: 323 ins; 102 del; 638 mod Patch: https://git.openjdk.org/jfx/pull/1656.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1656/head:pull/1656 PR: https://git.openjdk.org/jfx/pull/1656 From angorya at openjdk.org Fri Dec 20 18:24:31 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 18:24:31 GMT Subject: RFR: 8343398: Add reducedData preference [v11] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:01:56 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > release macOS PlatformSupport instance I highly recommend syncing up with the latest master once the PR branch is out for a prolonged period. This will ensure that the new changes do not interfere with the latest updates, and it also saves the reviewer's time as they need to merge in order to do a good review (times N reviewers). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557504420 From kcr at openjdk.org Fri Dec 20 18:25:43 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 18:25:43 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: References: Message-ID: On Sat, 14 Dec 2024 17:16:20 GMT, Michael Strau? wrote: >> The `Paint` and `Material` classes can't be extended by user code, because their implementations require special support in internal JavaFX code. The classes should be sealed. > > Michael Strau? has updated the pull request incrementally with one additional commit since the last revision: > > use exhaustive switch pattern Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1665#pullrequestreview-2512524567 From kcr at openjdk.org Fri Dec 20 18:25:44 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 18:25:44 GMT Subject: RFR: 8346227: Seal Paint and Material [v2] In-Reply-To: <_QSdwM1oSGD0qb5AFOtoKMnYtkp0EAa5oIbGkQbc8Z4=.65c9aacb-491b-424b-8878-b9eed03b9d83@github.com> References: <67K0HnFgaCiR4U4gSSYMjcoSQ1s-ycxrn9lN4JU47M4=.f6eda424-6997-406e-bab5-8050ee94eff9@github.com> <_QSdwM1oSGD0qb5AFOtoKMnYtkp0EAa5oIbGkQbc8Z4=.65c9aacb-491b-424b-8878-b9eed03b9d83@github.com> Message-ID: On Wed, 18 Dec 2024 18:03:59 GMT, Andy Goryachev wrote: >> Yes, that would make the callsite a bit easier. However, from an API perspective, I think it's not the best approach to handle nulls in the toolkit layer. A system that channels nulls thorugh various layers tends to become harder to reason about over time. > > I disagree: it makes it more resilient by doing what the caller has to do anyway. > However, the answer is acceptable. Btw, even if we did decide to change it in the future, we wouldn't do it as part of this PR. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1665#discussion_r1890642221 From angorya at openjdk.org Fri Dec 20 19:03:49 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 19:03:49 GMT Subject: RFR: 8343398: Add reducedData preference [v12] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:24:29 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 17 additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - release macOS PlatformSupport instance > - change enum constant names > - only update preferences that may have changed > - method name > - smaller diff > - typo > - store the app delegate reference in MacApplication > - formatting > - changed formatting > - ... and 7 more: https://git.openjdk.org/jfx/compare/52c2e2a0...b1635719 Looks good (macOS). An observation: when running `HelloJFXPanel`, noticed that the FX animation restarts each time the appearance preference gets changed between light and dark modes. This might be an existing issue since it can also be observed in the master branch. I am not entirely sure this is expected, since neither the color of the animated rectangle nor the background color changes. It's unrelated to the changes in this PR (but might be related to the way the platform notifications are being processed). Another observation related to the same animation, and also can be observed with the master branch: when one runs the `HelloJFXPanel` app, the initial animation is smooth and is not affected by mouse over. Once the platform light/dark mode preference gets changed, however, the movement becomes jerky on mouse over. ------------- Marked as reviewed by angorya (Reviewer). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2518158802 From kcr at openjdk.org Fri Dec 20 19:08:49 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 19:08:49 GMT Subject: RFR: 8343398: Add reducedData preference [v12] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:24:29 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 17 additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - release macOS PlatformSupport instance > - change enum constant names > - only update preferences that may have changed > - method name > - smaller diff > - typo > - store the app delegate reference in MacApplication > - formatting > - changed formatting > - ... and 7 more: https://git.openjdk.org/jfx/compare/358645c9...b1635719 Looks good. ------------- Marked as reviewed by kcr (Lead). PR Review: https://git.openjdk.org/jfx/pull/1656#pullrequestreview-2518174263 From kcr at openjdk.org Fri Dec 20 19:18:42 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 20 Dec 2024 19:18:42 GMT Subject: RFR: 8343398: Add reducedData preference [v12] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 19:01:14 GMT, Andy Goryachev wrote: > An observation: when running `HelloJFXPanel`, noticed that the FX animation restarts each time the appearance preference gets changed between light and dark modes. This might be an existing issue since it can also be observed in the master branch. > I am not entirely sure this is expected, since neither the color of the animated rectangle nor the background color changes. It's unrelated to the changes in this PR (but might be related to the way the platform notifications are being processed). When I run it, it doesn't reset, it seems to jump -- often, but not always, to the beginning or end. In any case, it's completely unrelated to platform notifications: I just checked and it behaves the same way on JDK 8, which has no platform preference support. > Another observation related to the same animation, and also can be observed with the master branch: when one runs the `HelloJFXPanel` app, the initial animation is smooth and is not affected by mouse over. Once the platform light/dark mode preference gets changed, however, the movement becomes jerky on mouse over. I can't reproduce this on my system. If you can characterize this, please file a new bug. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557582598 From angorya at openjdk.org Fri Dec 20 19:46:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 19:46:42 GMT Subject: RFR: 8343398: Add reducedData preference [v12] In-Reply-To: References: Message-ID: On Fri, 20 Dec 2024 18:24:29 GMT, Michael Strau? wrote: >> The `reducedData` preference instructs applications to minimize internet traffic, as users might be on a metered network or a limited data plan. >> >> This corresponds to the following OS settings: >> >> Windows: Settings -> Network and Internet -> Ethernet/WiFi -> Metered connection >> macOS: Settings -> Network -> Ethernet/WiFi -> Network Settings -> Low data mode >> Ubuntu: Settings -> Network -> Wired/WiFi -> Metered connection >> >> Change notifications work consistently on Windows and macOS. On my Ubuntu 24 system, the GIO `network-changed` signal is not sent when I only toggle the "metered connection" flag in network settings (and there's no signal specifically for low-data mode). The new value is only picked up when the connection changes by coming offline or going online. > > Michael Strau? 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 17 additional commits since the last revision: > > - Merge branch 'master' into feature/reduced-data > - release macOS PlatformSupport instance > - change enum constant names > - only update preferences that may have changed > - method name > - smaller diff > - typo > - store the app delegate reference in MacApplication > - formatting > - changed formatting > - ... and 7 more: https://git.openjdk.org/jfx/compare/cccc3ba6...b1635719 More on jerky animation: it's unrelated to the platform preferences change (which is good, for this PR anyway). It seems the jerky movement appears after HelloJFXPanel loses focus to some other window. Switch back, mouse over and the jerkiness starts. Happens even with the second external monitor disconnected. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1656#issuecomment-2557622302 From crschnick at xpipe.io Fri Dec 20 20:48:10 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 20 Dec 2024 21:48:10 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> Message-ID: <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> So as a follow-up to this, this is a general JavaFX issue and not related to a certain application. You can find references to this on reddit: https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ and on GitHub with some verbose and debugfonts output: https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 . It also seems related to this issue: https://bugs.openjdk.org/browse/JDK-8242617 On 04/12/2024 18:43, Christopher Schnick wrote: > > I'm not able to reproduce it, but some of my users are. If anyone who > knows the font renderer maybe wants additional information or has some > ideas on what the users can try to either fix or diagnose the root > cause, I can relay that request to them. > > I can ask them to try other JavaFX applications, but either way how > that goes, it doesn't show the cause. > > On 04/12/2024 18:37, Andy Goryachev wrote: >> >> I might suggest trying to run some other JavaFX application using the >> same setup.? Or better yet, if you can come up with a short >> reproducer, please file a bug. >> >> Thanks! >> >> -andy >> >> *From: *openjfx-dev on behalf of Andy >> Goryachev >> *Date: *Wednesday, December 4, 2024 at 09:20 >> *To: *Christopher Schnick , >> openjfx-dev at openjdk.org >> *Subject: *Re: Windows default font glyphs are rendered wrong on some >> systems >> >> I've never seen this...? what is the font that causes the issue? >> >> -andy >> >> *From: *openjfx-dev on behalf of >> Christopher Schnick >> *Date: *Monday, November 25, 2024 at 02:44 >> *To: *openjfx-dev at openjdk.org >> *Subject: *Windows default font glyphs are rendered wrong on some systems >> >> Hello, >> >> for some of our users, the font glyphs of the default Windows font >> are wrong by an offset of +2. E.g. the letter D is rendered as F, the >> symbol - is rendered as /, and so on ... However, the glyph spacings >> and kernings are using the correct values for the original letter, >> only the actual glyph itself is wrong. This is happening on the >> latest 24-ea build on Windows 11, but also occurred on version 21 a >> while ago. I wasn't able to reproduce it myself, only some users were. >> >> This has happened now for multiple users of our application, so I >> figured to report it (Didn't find this in the bug tracker). >> >> Here is there issue, next to how it should look like: >> >> (It is in danish because the user played around with the language >> settings to troubleshoot) >> >> There was no explicit -fx-font set, so the application uses the >> default one. When the users change to using -fx-font: Roboto, which >> is bundled with our application, the glyphs are rendered normally. So >> this issue is specific to certain fonts. >> >> If there's any additional information required, I can relay that >> request to our affected users. >> >> >> Best >> Christopher Schnick >> >> (I resent this mail as it got stuck in the moderation queue for being >> too big due to me accidentally pasting the screenshot as a .bmp) >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From philip.race at oracle.com Fri Dec 20 21:02:44 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Dec 2024 13:02:44 -0800 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> Message-ID: <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> Very odd. Possibilities : - font mixup :? the glyph ID is for a different font. - cmap bug : the incorrect glyph ID is used for the codepoint. - the font is a unicode variable font something goes wrong as a result - I doubt this one as the IDs should be the same. - something else? :-) Is the D3D pipeline being used ? What's the user locale as shown by windows ? To get some idea of what fonts are being used they could run with -Dprism.debugfonts=true -phil. On 12/20/24 12:48 PM, Christopher Schnick wrote: > > So as a follow-up to this, this is a general JavaFX issue and not > related to a certain application. You can find references to this on > reddit: > https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ > and on GitHub with some verbose and debugfonts output: > https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 > . It also seems related to this issue: > https://bugs.openjdk.org/browse/JDK-8242617 > > On 04/12/2024 18:43, Christopher Schnick wrote: >> >> I'm not able to reproduce it, but some of my users are. If anyone who >> knows the font renderer maybe wants additional information or has >> some ideas on what the users can try to either fix or diagnose the >> root cause, I can relay that request to them. >> >> I can ask them to try other JavaFX applications, but either way how >> that goes, it doesn't show the cause. >> >> On 04/12/2024 18:37, Andy Goryachev wrote: >>> >>> I might suggest trying to run some other JavaFX application using >>> the same setup.? Or better yet, if you can come up with a short >>> reproducer, please file a bug. >>> >>> Thanks! >>> >>> -andy >>> >>> *From: *openjfx-dev on behalf of Andy >>> Goryachev >>> *Date: *Wednesday, December 4, 2024 at 09:20 >>> *To: *Christopher Schnick , >>> openjfx-dev at openjdk.org >>> *Subject: *Re: Windows default font glyphs are rendered wrong on >>> some systems >>> >>> I've never seen this...? what is the font that causes the issue? >>> >>> -andy >>> >>> *From: *openjfx-dev on behalf of >>> Christopher Schnick >>> *Date: *Monday, November 25, 2024 at 02:44 >>> *To: *openjfx-dev at openjdk.org >>> *Subject: *Windows default font glyphs are rendered wrong on some >>> systems >>> >>> Hello, >>> >>> for some of our users, the font glyphs of the default Windows font >>> are wrong by an offset of +2. E.g. the letter D is rendered as F, >>> the symbol - is rendered as /, and so on ... However, the glyph >>> spacings and kernings are using the correct values for the original >>> letter, only the actual glyph itself is wrong. This is happening on >>> the latest 24-ea build on Windows 11, but also occurred on version >>> 21 a while ago. I wasn't able to reproduce it myself, only some >>> users were. >>> >>> This has happened now for multiple users of our application, so I >>> figured to report it (Didn't find this in the bug tracker). >>> >>> Here is there issue, next to how it should look like: >>> >>> (It is in danish because the user played around with the language >>> settings to troubleshoot) >>> >>> There was no explicit -fx-font set, so the application uses the >>> default one. When the users change to using -fx-font: Roboto, which >>> is bundled with our application, the glyphs are rendered normally. >>> So this issue is specific to certain fonts. >>> >>> If there's any additional information required, I can relay that >>> request to our affected users. >>> >>> >>> Best >>> Christopher Schnick >>> >>> (I resent this mail as it got stuck in the moderation queue for >>> being too big due to me accidentally pasting the screenshot as a .bmp) >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From crschnick at xpipe.io Fri Dec 20 21:08:08 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 20 Dec 2024 22:08:08 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> Message-ID: <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> Hey Phil, the linked GitHub comment has debugfonts output hidden in the comment. It looks like this: Prism pipeline init order: d3d sw Using Double Precision Marlin Rasterizer Using dirty region optimizations Not using texture mask for primitives Not forcing power of 2 sizes for textures Using hardware CLAMP_TO_ZERO mode Opting in for HiDPI pixel scaling Prism pipeline name = com.sun.prism.d3d.D3DPipeline Loading D3D native library ... ??????? succeeded. D3DPipelineManager: Created D3D9Ex device Direct3D initialization succeeded (X) Got class = class com.sun.prism.d3d.D3DPipeline Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline Maximum supported texture size: 16384 Maximum texture size clamped to 4096 OS Information: ??????? Windows version 10.0 build 22631 D3D Driver Information: ??????? Intel(R) Iris(R) Xe Graphics ??????? \\.\DISPLAY1 ??????? Driver igd10iumd64.dll, version 30.0.101.3118 ??????? Pixel Shader version 3.0 ??????? Device : ven_8086, dev_46A8, subsys_00631414 ??????? Max Multisamples supported: 4 ?vsync: true vpipe: true Loading FontFactory com.sun.javafx.font.directwrite.DWFactory Subpixel: enabled No match for name null in C:\WINDOWS\Fonts\segoeui.ttf No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf new alphas with length = 16384 new alphas with length = 20480 new alphas with length = 61440 The comment also contains information about the system and fonts. On 20/12/2024 22:02, Philip Race wrote: > Very odd. Possibilities : > - font mixup :? the glyph ID is for a different font. > - cmap bug : the incorrect glyph ID is used for the codepoint. > - the font is a unicode variable font something goes wrong as a result > - I doubt this one as the IDs should be the same. > - something else? :-) > > Is the D3D pipeline being used ? > What's the user locale as shown by windows ? > > To get some idea of what fonts are being used they could run with > -Dprism.debugfonts=true > > -phil. > > > On 12/20/24 12:48 PM, Christopher Schnick wrote: >> >> So as a follow-up to this, this is a general JavaFX issue and not >> related to a certain application. You can find references to this on >> reddit: >> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >> and on GitHub with some verbose and debugfonts output: >> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >> . It also seems related to this issue: >> https://bugs.openjdk.org/browse/JDK-8242617 >> >> On 04/12/2024 18:43, Christopher Schnick wrote: >>> >>> I'm not able to reproduce it, but some of my users are. If anyone >>> who knows the font renderer maybe wants additional information or >>> has some ideas on what the users can try to either fix or diagnose >>> the root cause, I can relay that request to them. >>> >>> I can ask them to try other JavaFX applications, but either way how >>> that goes, it doesn't show the cause. >>> >>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>> >>>> I might suggest trying to run some other JavaFX application using >>>> the same setup.? Or better yet, if you can come up with a short >>>> reproducer, please file a bug. >>>> >>>> Thanks! >>>> >>>> -andy >>>> >>>> *From: *openjfx-dev on behalf of >>>> Andy Goryachev >>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>> *To: *Christopher Schnick , >>>> openjfx-dev at openjdk.org >>>> *Subject: *Re: Windows default font glyphs are rendered wrong on >>>> some systems >>>> >>>> I've never seen this...? what is the font that causes the issue? >>>> >>>> -andy >>>> >>>> *From: *openjfx-dev on behalf of >>>> Christopher Schnick >>>> *Date: *Monday, November 25, 2024 at 02:44 >>>> *To: *openjfx-dev at openjdk.org >>>> *Subject: *Windows default font glyphs are rendered wrong on some >>>> systems >>>> >>>> Hello, >>>> >>>> for some of our users, the font glyphs of the default Windows font >>>> are wrong by an offset of +2. E.g. the letter D is rendered as F, >>>> the symbol - is rendered as /, and so on ... However, the glyph >>>> spacings and kernings are using the correct values for the original >>>> letter, only the actual glyph itself is wrong. This is happening on >>>> the latest 24-ea build on Windows 11, but also occurred on version >>>> 21 a while ago. I wasn't able to reproduce it myself, only some >>>> users were. >>>> >>>> This has happened now for multiple users of our application, so I >>>> figured to report it (Didn't find this in the bug tracker). >>>> >>>> Here is there issue, next to how it should look like: >>>> >>>> (It is in danish because the user played around with the language >>>> settings to troubleshoot) >>>> >>>> There was no explicit -fx-font set, so the application uses the >>>> default one. When the users change to using -fx-font: Roboto, which >>>> is bundled with our application, the glyphs are rendered normally. >>>> So this issue is specific to certain fonts. >>>> >>>> If there's any additional information required, I can relay that >>>> request to our affected users. >>>> >>>> >>>> Best >>>> Christopher Schnick >>>> >>>> (I resent this mail as it got stuck in the moderation queue for >>>> being too big due to me accidentally pasting the screenshot as a .bmp) >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From philip.race at oracle.com Fri Dec 20 21:12:53 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Dec 2024 13:12:53 -0800 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> Message-ID: That just looks like prism.verbose output I see someone suggested prism.debugfonts but I don't see that any results were ever provided. -phil. On 12/20/24 1:08 PM, Christopher Schnick wrote: > > Hey Phil, > > the linked GitHub comment has debugfonts output hidden in the comment. > It looks like this: > > Prism pipeline init order: d3d sw > Using Double Precision Marlin Rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures > Using hardware CLAMP_TO_ZERO mode > Opting in for HiDPI pixel scaling > Prism pipeline name = com.sun.prism.d3d.D3DPipeline > Loading D3D native library ... > ??????? succeeded. > D3DPipelineManager: Created D3D9Ex device > Direct3D initialization succeeded > (X) Got class = class com.sun.prism.d3d.D3DPipeline > Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline > Maximum supported texture size: 16384 > Maximum texture size clamped to 4096 > OS Information: > ??????? Windows version 10.0 build 22631 > D3D Driver Information: > ??????? Intel(R) Iris(R) Xe Graphics > ??????? \\.\DISPLAY1 > ??????? Driver igd10iumd64.dll, version 30.0.101.3118 > ??????? Pixel Shader version 3.0 > ??????? Device : ven_8086, dev_46A8, subsys_00631414 > ??????? Max Multisamples supported: 4 > ?vsync: true vpipe: true > Loading FontFactory com.sun.javafx.font.directwrite.DWFactory > Subpixel: enabled > No match for name null in C:\WINDOWS\Fonts\segoeui.ttf > No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf > new alphas with length = 16384 > new alphas with length = 20480 > new alphas with length = 61440 > > The comment also contains information about the system and fonts. > > On 20/12/2024 22:02, Philip Race wrote: >> Very odd. Possibilities : >> - font mixup :? the glyph ID is for a different font. >> - cmap bug : the incorrect glyph ID is used for the codepoint. >> - the font is a unicode variable font something goes wrong as a >> result - I doubt this one as the IDs should be the same. >> - something else? :-) >> >> Is the D3D pipeline being used ? >> What's the user locale as shown by windows ? >> >> To get some idea of what fonts are being used they could run with >> -Dprism.debugfonts=true >> >> -phil. >> >> >> On 12/20/24 12:48 PM, Christopher Schnick wrote: >>> >>> So as a follow-up to this, this is a general JavaFX issue and not >>> related to a certain application. You can find references to this on >>> reddit: >>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >>> and on GitHub with some verbose and debugfonts output: >>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >>> . It also seems related to this issue: >>> https://bugs.openjdk.org/browse/JDK-8242617 >>> >>> On 04/12/2024 18:43, Christopher Schnick wrote: >>>> >>>> I'm not able to reproduce it, but some of my users are. If anyone >>>> who knows the font renderer maybe wants additional information or >>>> has some ideas on what the users can try to either fix or diagnose >>>> the root cause, I can relay that request to them. >>>> >>>> I can ask them to try other JavaFX applications, but either way how >>>> that goes, it doesn't show the cause. >>>> >>>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>>> >>>>> I might suggest trying to run some other JavaFX application using >>>>> the same setup.? Or better yet, if you can come up with a short >>>>> reproducer, please file a bug. >>>>> >>>>> Thanks! >>>>> >>>>> -andy >>>>> >>>>> *From: *openjfx-dev on behalf of >>>>> Andy Goryachev >>>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>>> *To: *Christopher Schnick , >>>>> openjfx-dev at openjdk.org >>>>> *Subject: *Re: Windows default font glyphs are rendered wrong on >>>>> some systems >>>>> >>>>> I've never seen this...? what is the font that causes the issue? >>>>> >>>>> -andy >>>>> >>>>> *From: *openjfx-dev on behalf of >>>>> Christopher Schnick >>>>> *Date: *Monday, November 25, 2024 at 02:44 >>>>> *To: *openjfx-dev at openjdk.org >>>>> *Subject: *Windows default font glyphs are rendered wrong on some >>>>> systems >>>>> >>>>> Hello, >>>>> >>>>> for some of our users, the font glyphs of the default Windows font >>>>> are wrong by an offset of +2. E.g. the letter D is rendered as F, >>>>> the symbol - is rendered as /, and so on ... However, the glyph >>>>> spacings and kernings are using the correct values for the >>>>> original letter, only the actual glyph itself is wrong. This is >>>>> happening on the latest 24-ea build on Windows 11, but also >>>>> occurred on version 21 a while ago. I wasn't able to reproduce it >>>>> myself, only some users were. >>>>> >>>>> This has happened now for multiple users of our application, so I >>>>> figured to report it (Didn't find this in the bug tracker). >>>>> >>>>> Here is there issue, next to how it should look like: >>>>> >>>>> (It is in danish because the user played around with the language >>>>> settings to troubleshoot) >>>>> >>>>> There was no explicit -fx-font set, so the application uses the >>>>> default one. When the users change to using -fx-font: Roboto, >>>>> which is bundled with our application, the glyphs are rendered >>>>> normally. So this issue is specific to certain fonts. >>>>> >>>>> If there's any additional information required, I can relay that >>>>> request to our affected users. >>>>> >>>>> >>>>> Best >>>>> Christopher Schnick >>>>> >>>>> (I resent this mail as it got stuck in the moderation queue for >>>>> being too big due to me accidentally pasting the screenshot as a .bmp) >>>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From philip.race at oracle.com Fri Dec 20 21:18:20 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Dec 2024 13:18:20 -0800 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> Message-ID: On 12/20/24 1:12 PM, Philip Race wrote: > That just looks like prism.verbose output > I see someone suggested prism.debugfonts but I don't see that any > results were ever provided. > I take that back .. I see No match for name null in C:\WINDOWS\Fonts\segoeui.ttf No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf which would be from debugfonts. But that's less information than I was hoping for. -phil. From philip.race at oracle.com Fri Dec 20 21:24:45 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Dec 2024 13:24:45 -0800 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> Message-ID: <8909aa3d-ddf4-419a-91a2-65ac0936f625@oracle.com> There's some hard-coding of names to files in WindowsFontMap.java Maybe that's part of it, but its very much a guess. It would be interesting to try a build which excludes using that pure "optimization" -phil. On 12/20/24 1:12 PM, Philip Race wrote: > That just looks like prism.verbose output > I see someone suggested prism.debugfonts but I don't see that any > results were ever provided. > > -phil. > > > On 12/20/24 1:08 PM, Christopher Schnick wrote: >> >> Hey Phil, >> >> the linked GitHub comment has debugfonts output hidden in the >> comment. It looks like this: >> >> Prism pipeline init order: d3d sw >> Using Double Precision Marlin Rasterizer >> Using dirty region optimizations >> Not using texture mask for primitives >> Not forcing power of 2 sizes for textures >> Using hardware CLAMP_TO_ZERO mode >> Opting in for HiDPI pixel scaling >> Prism pipeline name = com.sun.prism.d3d.D3DPipeline >> Loading D3D native library ... >> ??????? succeeded. >> D3DPipelineManager: Created D3D9Ex device >> Direct3D initialization succeeded >> (X) Got class = class com.sun.prism.d3d.D3DPipeline >> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline >> Maximum supported texture size: 16384 >> Maximum texture size clamped to 4096 >> OS Information: >> ??????? Windows version 10.0 build 22631 >> D3D Driver Information: >> ??????? Intel(R) Iris(R) Xe Graphics >> ??????? \\.\DISPLAY1 >> ??????? Driver igd10iumd64.dll, version 30.0.101.3118 >> ??????? Pixel Shader version 3.0 >> ??????? Device : ven_8086, dev_46A8, subsys_00631414 >> ??????? Max Multisamples supported: 4 >> ?vsync: true vpipe: true >> Loading FontFactory com.sun.javafx.font.directwrite.DWFactory >> Subpixel: enabled >> No match for name null in C:\WINDOWS\Fonts\segoeui.ttf >> No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf >> new alphas with length = 16384 >> new alphas with length = 20480 >> new alphas with length = 61440 >> >> The comment also contains information about the system and fonts. >> >> On 20/12/2024 22:02, Philip Race wrote: >>> Very odd. Possibilities : >>> - font mixup :? the glyph ID is for a different font. >>> - cmap bug : the incorrect glyph ID is used for the codepoint. >>> - the font is a unicode variable font something goes wrong as a >>> result - I doubt this one as the IDs should be the same. >>> - something else? :-) >>> >>> Is the D3D pipeline being used ? >>> What's the user locale as shown by windows ? >>> >>> To get some idea of what fonts are being used they could run with >>> -Dprism.debugfonts=true >>> >>> -phil. >>> >>> >>> On 12/20/24 12:48 PM, Christopher Schnick wrote: >>>> >>>> So as a follow-up to this, this is a general JavaFX issue and not >>>> related to a certain application. You can find references to this >>>> on reddit: >>>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >>>> and on GitHub with some verbose and debugfonts output: >>>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >>>> . It also seems related to this issue: >>>> https://bugs.openjdk.org/browse/JDK-8242617 >>>> >>>> On 04/12/2024 18:43, Christopher Schnick wrote: >>>>> >>>>> I'm not able to reproduce it, but some of my users are. If anyone >>>>> who knows the font renderer maybe wants additional information or >>>>> has some ideas on what the users can try to either fix or diagnose >>>>> the root cause, I can relay that request to them. >>>>> >>>>> I can ask them to try other JavaFX applications, but either way >>>>> how that goes, it doesn't show the cause. >>>>> >>>>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>>>> >>>>>> I might suggest trying to run some other JavaFX application using >>>>>> the same setup.? Or better yet, if you can come up with a short >>>>>> reproducer, please file a bug. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> -andy >>>>>> >>>>>> *From: *openjfx-dev on behalf of >>>>>> Andy Goryachev >>>>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>>>> *To: *Christopher Schnick , >>>>>> openjfx-dev at openjdk.org >>>>>> *Subject: *Re: Windows default font glyphs are rendered wrong on >>>>>> some systems >>>>>> >>>>>> I've never seen this...? what is the font that causes the issue? >>>>>> >>>>>> -andy >>>>>> >>>>>> *From: *openjfx-dev on behalf of >>>>>> Christopher Schnick >>>>>> *Date: *Monday, November 25, 2024 at 02:44 >>>>>> *To: *openjfx-dev at openjdk.org >>>>>> *Subject: *Windows default font glyphs are rendered wrong on some >>>>>> systems >>>>>> >>>>>> Hello, >>>>>> >>>>>> for some of our users, the font glyphs of the default Windows >>>>>> font are wrong by an offset of +2. E.g. the letter D is rendered >>>>>> as F, the symbol - is rendered as /, and so on ... However, the >>>>>> glyph spacings and kernings are using the correct values for the >>>>>> original letter, only the actual glyph itself is wrong. This is >>>>>> happening on the latest 24-ea build on Windows 11, but also >>>>>> occurred on version 21 a while ago. I wasn't able to reproduce it >>>>>> myself, only some users were. >>>>>> >>>>>> This has happened now for multiple users of our application, so I >>>>>> figured to report it (Didn't find this in the bug tracker). >>>>>> >>>>>> Here is there issue, next to how it should look like: >>>>>> >>>>>> (It is in danish because the user played around with the language >>>>>> settings to troubleshoot) >>>>>> >>>>>> There was no explicit -fx-font set, so the application uses the >>>>>> default one. When the users change to using -fx-font: Roboto, >>>>>> which is bundled with our application, the glyphs are rendered >>>>>> normally. So this issue is specific to certain fonts. >>>>>> >>>>>> If there's any additional information required, I can relay that >>>>>> request to our affected users. >>>>>> >>>>>> >>>>>> Best >>>>>> Christopher Schnick >>>>>> >>>>>> (I resent this mail as it got stuck in the moderation queue for >>>>>> being too big due to me accidentally pasting the screenshot as a >>>>>> .bmp) >>>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From crschnick at xpipe.io Fri Dec 20 21:34:27 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 20 Dec 2024 22:34:27 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <8909aa3d-ddf4-419a-91a2-65ac0936f625@oracle.com> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> <8909aa3d-ddf4-419a-91a2-65ac0936f625@oracle.com> Message-ID: <777abb08-0a5a-40b0-82e4-eb084e1661ef@xpipe.io> I'm not a font wizard, the only a consistent thing about this issue is that the glyph indices are always off by 2. The linked otf bug tracker issue has that same issue, and that is using a completely different font. If I had to debug this, I would probably think of something where some rare condition is true for the affected systems where some part of the code does a +1 on the glyph index to adjust for something but should instead do a -1. And since that condition seems to be very rare, normal testing doesn't catch that. On 20/12/2024 22:24, Philip Race wrote: > There's some hard-coding of names to files in WindowsFontMap.java > Maybe that's part of it, but its very much a guess. > It would be interesting to try a build which excludes using that pure > "optimization" > > -phil. > > > On 12/20/24 1:12 PM, Philip Race wrote: >> That just looks like prism.verbose output >> I see someone suggested prism.debugfonts but I don't see that any >> results were ever provided. >> >> -phil. >> >> >> On 12/20/24 1:08 PM, Christopher Schnick wrote: >>> >>> Hey Phil, >>> >>> the linked GitHub comment has debugfonts output hidden in the >>> comment. It looks like this: >>> >>> Prism pipeline init order: d3d sw >>> Using Double Precision Marlin Rasterizer >>> Using dirty region optimizations >>> Not using texture mask for primitives >>> Not forcing power of 2 sizes for textures >>> Using hardware CLAMP_TO_ZERO mode >>> Opting in for HiDPI pixel scaling >>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline >>> Loading D3D native library ... >>> ??????? succeeded. >>> D3DPipelineManager: Created D3D9Ex device >>> Direct3D initialization succeeded >>> (X) Got class = class com.sun.prism.d3d.D3DPipeline >>> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline >>> Maximum supported texture size: 16384 >>> Maximum texture size clamped to 4096 >>> OS Information: >>> ??????? Windows version 10.0 build 22631 >>> D3D Driver Information: >>> ??????? Intel(R) Iris(R) Xe Graphics >>> ??????? \\.\DISPLAY1 >>> ??????? Driver igd10iumd64.dll, version 30.0.101.3118 >>> ??????? Pixel Shader version 3.0 >>> ??????? Device : ven_8086, dev_46A8, subsys_00631414 >>> ??????? Max Multisamples supported: 4 >>> ?vsync: true vpipe: true >>> Loading FontFactory com.sun.javafx.font.directwrite.DWFactory >>> Subpixel: enabled >>> No match for name null in C:\WINDOWS\Fonts\segoeui.ttf >>> No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf >>> new alphas with length = 16384 >>> new alphas with length = 20480 >>> new alphas with length = 61440 >>> >>> The comment also contains information about the system and fonts. >>> >>> On 20/12/2024 22:02, Philip Race wrote: >>>> Very odd. Possibilities : >>>> - font mixup :? the glyph ID is for a different font. >>>> - cmap bug : the incorrect glyph ID is used for the codepoint. >>>> - the font is a unicode variable font something goes wrong as a >>>> result - I doubt this one as the IDs should be the same. >>>> - something else? :-) >>>> >>>> Is the D3D pipeline being used ? >>>> What's the user locale as shown by windows ? >>>> >>>> To get some idea of what fonts are being used they could run with >>>> -Dprism.debugfonts=true >>>> >>>> -phil. >>>> >>>> >>>> On 12/20/24 12:48 PM, Christopher Schnick wrote: >>>>> >>>>> So as a follow-up to this, this is a general JavaFX issue and not >>>>> related to a certain application. You can find references to this >>>>> on reddit: >>>>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >>>>> and on GitHub with some verbose and debugfonts output: >>>>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >>>>> . It also seems related to this issue: >>>>> https://bugs.openjdk.org/browse/JDK-8242617 >>>>> >>>>> On 04/12/2024 18:43, Christopher Schnick wrote: >>>>>> >>>>>> I'm not able to reproduce it, but some of my users are. If anyone >>>>>> who knows the font renderer maybe wants additional information or >>>>>> has some ideas on what the users can try to either fix or >>>>>> diagnose the root cause, I can relay that request to them. >>>>>> >>>>>> I can ask them to try other JavaFX applications, but either way >>>>>> how that goes, it doesn't show the cause. >>>>>> >>>>>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>>>>> >>>>>>> I might suggest trying to run some other JavaFX application >>>>>>> using the same setup.? Or better yet, if you can come up with a >>>>>>> short reproducer, please file a bug. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -andy >>>>>>> >>>>>>> *From: *openjfx-dev on behalf of >>>>>>> Andy Goryachev >>>>>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>>>>> *To: *Christopher Schnick , >>>>>>> openjfx-dev at openjdk.org >>>>>>> *Subject: *Re: Windows default font glyphs are rendered wrong on >>>>>>> some systems >>>>>>> >>>>>>> I've never seen this...? what is the font that causes the issue? >>>>>>> >>>>>>> -andy >>>>>>> >>>>>>> *From: *openjfx-dev on behalf of >>>>>>> Christopher Schnick >>>>>>> *Date: *Monday, November 25, 2024 at 02:44 >>>>>>> *To: *openjfx-dev at openjdk.org >>>>>>> *Subject: *Windows default font glyphs are rendered wrong on >>>>>>> some systems >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> for some of our users, the font glyphs of the default Windows >>>>>>> font are wrong by an offset of +2. E.g. the letter D is rendered >>>>>>> as F, the symbol - is rendered as /, and so on ... However, the >>>>>>> glyph spacings and kernings are using the correct values for the >>>>>>> original letter, only the actual glyph itself is wrong. This is >>>>>>> happening on the latest 24-ea build on Windows 11, but also >>>>>>> occurred on version 21 a while ago. I wasn't able to reproduce >>>>>>> it myself, only some users were. >>>>>>> >>>>>>> This has happened now for multiple users of our application, so >>>>>>> I figured to report it (Didn't find this in the bug tracker). >>>>>>> >>>>>>> Here is there issue, next to how it should look like: >>>>>>> >>>>>>> (It is in danish because the user played around with the >>>>>>> language settings to troubleshoot) >>>>>>> >>>>>>> There was no explicit -fx-font set, so the application uses the >>>>>>> default one. When the users change to using -fx-font: Roboto, >>>>>>> which is bundled with our application, the glyphs are rendered >>>>>>> normally. So this issue is specific to certain fonts. >>>>>>> >>>>>>> If there's any additional information required, I can relay that >>>>>>> request to our affected users. >>>>>>> >>>>>>> >>>>>>> Best >>>>>>> Christopher Schnick >>>>>>> >>>>>>> (I resent this mail as it got stuck in the moderation queue for >>>>>>> being too big due to me accidentally pasting the screenshot as a >>>>>>> .bmp) >>>>>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From philip.race at oracle.com Fri Dec 20 21:43:31 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 20 Dec 2024 13:43:31 -0800 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: <777abb08-0a5a-40b0-82e4-eb084e1661ef@xpipe.io> References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> <8909aa3d-ddf4-419a-91a2-65ac0936f625@oracle.com> <777abb08-0a5a-40b0-82e4-eb084e1661ef@xpipe.io> Message-ID: The OTF bug is about printing. Disregard that. It is a case where the printer font is not the same as the font used on screen. I hear what you say but I can't imagine what code would add any value to a glyph id. There's no use case for that. Glyph ids need to be obtained by mapping via the font cmap. They are just an opaque value you then use to then map into a table to get the image/outline. You can't assume ANYTHING about the relationship between glyph ids. Glyph ID for 'A' could be 23 .. id for 'B' could be 17 .. etc -phil. On 12/20/24 1:34 PM, Christopher Schnick wrote: > > I'm not a font wizard, the only a consistent thing about this issue is > that the glyph indices are always off by 2. The linked otf bug tracker > issue has that same issue, and that is using a completely different font. > > If I had to debug this, I would probably think of something where some > rare condition is true for the affected systems where some part of the > code does a +1 on the glyph index to adjust for something but should > instead do a -1. And since that condition seems to be very rare, > normal testing doesn't catch that. > > On 20/12/2024 22:24, Philip Race wrote: >> There's some hard-coding of names to files in WindowsFontMap.java >> Maybe that's part of it, but its very much a guess. >> It would be interesting to try a build which excludes using that pure >> "optimization" >> >> -phil. >> >> >> On 12/20/24 1:12 PM, Philip Race wrote: >>> That just looks like prism.verbose output >>> I see someone suggested prism.debugfonts but I don't see that any >>> results were ever provided. >>> >>> -phil. >>> >>> >>> On 12/20/24 1:08 PM, Christopher Schnick wrote: >>>> >>>> Hey Phil, >>>> >>>> the linked GitHub comment has debugfonts output hidden in the >>>> comment. It looks like this: >>>> >>>> Prism pipeline init order: d3d sw >>>> Using Double Precision Marlin Rasterizer >>>> Using dirty region optimizations >>>> Not using texture mask for primitives >>>> Not forcing power of 2 sizes for textures >>>> Using hardware CLAMP_TO_ZERO mode >>>> Opting in for HiDPI pixel scaling >>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline >>>> Loading D3D native library ... >>>> ??????? succeeded. >>>> D3DPipelineManager: Created D3D9Ex device >>>> Direct3D initialization succeeded >>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline >>>> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline >>>> Maximum supported texture size: 16384 >>>> Maximum texture size clamped to 4096 >>>> OS Information: >>>> ??????? Windows version 10.0 build 22631 >>>> D3D Driver Information: >>>> ??????? Intel(R) Iris(R) Xe Graphics >>>> ??????? \\.\DISPLAY1 >>>> ??????? Driver igd10iumd64.dll, version 30.0.101.3118 >>>> ??????? Pixel Shader version 3.0 >>>> ??????? Device : ven_8086, dev_46A8, subsys_00631414 >>>> ??????? Max Multisamples supported: 4 >>>> ?vsync: true vpipe: true >>>> Loading FontFactory com.sun.javafx.font.directwrite.DWFactory >>>> Subpixel: enabled >>>> No match for name null in C:\WINDOWS\Fonts\segoeui.ttf >>>> No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf >>>> new alphas with length = 16384 >>>> new alphas with length = 20480 >>>> new alphas with length = 61440 >>>> >>>> The comment also contains information about the system and fonts. >>>> >>>> On 20/12/2024 22:02, Philip Race wrote: >>>>> Very odd. Possibilities : >>>>> - font mixup :? the glyph ID is for a different font. >>>>> - cmap bug : the incorrect glyph ID is used for the codepoint. >>>>> - the font is a unicode variable font something goes wrong as a >>>>> result - I doubt this one as the IDs should be the same. >>>>> - something else? :-) >>>>> >>>>> Is the D3D pipeline being used ? >>>>> What's the user locale as shown by windows ? >>>>> >>>>> To get some idea of what fonts are being used they could run with >>>>> -Dprism.debugfonts=true >>>>> >>>>> -phil. >>>>> >>>>> >>>>> On 12/20/24 12:48 PM, Christopher Schnick wrote: >>>>>> >>>>>> So as a follow-up to this, this is a general JavaFX issue and not >>>>>> related to a certain application. You can find references to this >>>>>> on reddit: >>>>>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >>>>>> and on GitHub with some verbose and debugfonts output: >>>>>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >>>>>> . It also seems related to this issue: >>>>>> https://bugs.openjdk.org/browse/JDK-8242617 >>>>>> >>>>>> On 04/12/2024 18:43, Christopher Schnick wrote: >>>>>>> >>>>>>> I'm not able to reproduce it, but some of my users are. If >>>>>>> anyone who knows the font renderer maybe wants additional >>>>>>> information or has some ideas on what the users can try to >>>>>>> either fix or diagnose the root cause, I can relay that request >>>>>>> to them. >>>>>>> >>>>>>> I can ask them to try other JavaFX applications, but either way >>>>>>> how that goes, it doesn't show the cause. >>>>>>> >>>>>>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>>>>>> >>>>>>>> I might suggest trying to run some other JavaFX application >>>>>>>> using the same setup.? Or better yet, if you can come up with a >>>>>>>> short reproducer, please file a bug. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> -andy >>>>>>>> >>>>>>>> *From: *openjfx-dev on behalf of >>>>>>>> Andy Goryachev >>>>>>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>>>>>> *To: *Christopher Schnick , >>>>>>>> openjfx-dev at openjdk.org >>>>>>>> *Subject: *Re: Windows default font glyphs are rendered wrong >>>>>>>> on some systems >>>>>>>> >>>>>>>> I've never seen this...? what is the font that causes the issue? >>>>>>>> >>>>>>>> -andy >>>>>>>> >>>>>>>> *From: *openjfx-dev on behalf of >>>>>>>> Christopher Schnick >>>>>>>> *Date: *Monday, November 25, 2024 at 02:44 >>>>>>>> *To: *openjfx-dev at openjdk.org >>>>>>>> *Subject: *Windows default font glyphs are rendered wrong on >>>>>>>> some systems >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> for some of our users, the font glyphs of the default Windows >>>>>>>> font are wrong by an offset of +2. E.g. the letter D is >>>>>>>> rendered as F, the symbol - is rendered as /, and so on ... >>>>>>>> However, the glyph spacings and kernings are using the correct >>>>>>>> values for the original letter, only the actual glyph itself is >>>>>>>> wrong. This is happening on the latest 24-ea build on Windows >>>>>>>> 11, but also occurred on version 21 a while ago. I wasn't able >>>>>>>> to reproduce it myself, only some users were. >>>>>>>> >>>>>>>> This has happened now for multiple users of our application, so >>>>>>>> I figured to report it (Didn't find this in the bug tracker). >>>>>>>> >>>>>>>> Here is there issue, next to how it should look like: >>>>>>>> >>>>>>>> (It is in danish because the user played around with the >>>>>>>> language settings to troubleshoot) >>>>>>>> >>>>>>>> There was no explicit -fx-font set, so the application uses the >>>>>>>> default one. When the users change to using -fx-font: Roboto, >>>>>>>> which is bundled with our application, the glyphs are rendered >>>>>>>> normally. So this issue is specific to certain fonts. >>>>>>>> >>>>>>>> If there's any additional information required, I can relay >>>>>>>> that request to our affected users. >>>>>>>> >>>>>>>> >>>>>>>> Best >>>>>>>> Christopher Schnick >>>>>>>> >>>>>>>> (I resent this mail as it got stuck in the moderation queue for >>>>>>>> being too big due to me accidentally pasting the screenshot as >>>>>>>> a .bmp) >>>>>>>> >>>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From crschnick at xpipe.io Fri Dec 20 21:53:37 2024 From: crschnick at xpipe.io (Christopher Schnick) Date: Fri, 20 Dec 2024 22:53:37 +0100 Subject: Windows default font glyphs are rendered wrong on some systems In-Reply-To: References: <4f1cb655-d412-425a-a75b-a67d3368138c@xpipe.io> <5572a0e6-43e4-4dee-a333-a4d0bd59ee1a@xpipe.io> <46a73c76-38e7-4ef2-899e-37d50eeea3f4@xpipe.io> <8d78c99f-1360-4695-a933-8159531baf2e@oracle.com> <0e15e82e-24e3-4548-82a4-d79ff210a053@xpipe.io> <8909aa3d-ddf4-419a-91a2-65ac0936f625@oracle.com> <777abb08-0a5a-40b0-82e4-eb084e1661ef@xpipe.io> Message-ID: <9b7b6511-eaeb-4710-bb19-a7387c2a7c93@xpipe.io> Yeah I am out of my element here, I can just add my thoughts. Since the kerning / glyph spacing is using the correct glyph info (but rendering the wrong glyph), this might be a pure display issue. You can see that if you take a closer look at the screenshots, the glyphs are aligned as if they were rendering the correct glyph. So it definitely knows the correct cmap for the glyph info, it just uses the wrong graphics. About the printer issue, wouldn't that even be more peculiar if installing and using some otf font would break the display (in this case when printed) of another font? The issue states that installing the otf font is causing that. If it was printing the otf font, then it would be the same off-by-2 issue. If it uses a different font to print, then the otf font is somehow still interfering with it because without the otf font, this issue doesn't happen. On 20/12/2024 22:43, Philip Race wrote: > The OTF bug is about printing. Disregard that. It is a case where the > printer font is not the same as the font used on screen. > > I hear what you say but I can't imagine what code would add any value > to a glyph id. There's no use case for that. > Glyph ids need to be obtained by mapping via the font cmap. They are > just an opaque value you then use to then > map into a table to get the image/outline. > You can't assume ANYTHING about the relationship between glyph ids. > Glyph ID for 'A' could be 23 .. id for 'B' could be 17 .. etc > > -phil. > > > On 12/20/24 1:34 PM, Christopher Schnick wrote: >> >> I'm not a font wizard, the only a consistent thing about this issue >> is that the glyph indices are always off by 2. The linked otf bug >> tracker issue has that same issue, and that is using a completely >> different font. >> >> If I had to debug this, I would probably think of something where >> some rare condition is true for the affected systems where some part >> of the code does a +1 on the glyph index to adjust for something but >> should instead do a -1. And since that condition seems to be very >> rare, normal testing doesn't catch that. >> >> On 20/12/2024 22:24, Philip Race wrote: >>> There's some hard-coding of names to files in WindowsFontMap.java >>> Maybe that's part of it, but its very much a guess. >>> It would be interesting to try a build which excludes using that >>> pure "optimization" >>> >>> -phil. >>> >>> >>> On 12/20/24 1:12 PM, Philip Race wrote: >>>> That just looks like prism.verbose output >>>> I see someone suggested prism.debugfonts but I don't see that any >>>> results were ever provided. >>>> >>>> -phil. >>>> >>>> >>>> On 12/20/24 1:08 PM, Christopher Schnick wrote: >>>>> >>>>> Hey Phil, >>>>> >>>>> the linked GitHub comment has debugfonts output hidden in the >>>>> comment. It looks like this: >>>>> >>>>> Prism pipeline init order: d3d sw >>>>> Using Double Precision Marlin Rasterizer >>>>> Using dirty region optimizations >>>>> Not using texture mask for primitives >>>>> Not forcing power of 2 sizes for textures >>>>> Using hardware CLAMP_TO_ZERO mode >>>>> Opting in for HiDPI pixel scaling >>>>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline >>>>> Loading D3D native library ... >>>>> ??????? succeeded. >>>>> D3DPipelineManager: Created D3D9Ex device >>>>> Direct3D initialization succeeded >>>>> (X) Got class = class com.sun.prism.d3d.D3DPipeline >>>>> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline >>>>> Maximum supported texture size: 16384 >>>>> Maximum texture size clamped to 4096 >>>>> OS Information: >>>>> ??????? Windows version 10.0 build 22631 >>>>> D3D Driver Information: >>>>> ??????? Intel(R) Iris(R) Xe Graphics >>>>> ??????? \\.\DISPLAY1 >>>>> ??????? Driver igd10iumd64.dll, version 30.0.101.3118 >>>>> ??????? Pixel Shader version 3.0 >>>>> ??????? Device : ven_8086, dev_46A8, subsys_00631414 >>>>> ??????? Max Multisamples supported: 4 >>>>> ?vsync: true vpipe: true >>>>> Loading FontFactory com.sun.javafx.font.directwrite.DWFactory >>>>> Subpixel: enabled >>>>> No match for name null in C:\WINDOWS\Fonts\segoeui.ttf >>>>> No match for name null in C:\WINDOWS\Fonts\segoeuib.ttf >>>>> new alphas with length = 16384 >>>>> new alphas with length = 20480 >>>>> new alphas with length = 61440 >>>>> >>>>> The comment also contains information about the system and fonts. >>>>> >>>>> On 20/12/2024 22:02, Philip Race wrote: >>>>>> Very odd. Possibilities : >>>>>> - font mixup :? the glyph ID is for a different font. >>>>>> - cmap bug : the incorrect glyph ID is used for the codepoint. >>>>>> - the font is a unicode variable font something goes wrong as a >>>>>> result - I doubt this one as the IDs should be the same. >>>>>> - something else? :-) >>>>>> >>>>>> Is the D3D pipeline being used ? >>>>>> What's the user locale as shown by windows ? >>>>>> >>>>>> To get some idea of what fonts are being used they could run with >>>>>> -Dprism.debugfonts=true >>>>>> >>>>>> -phil. >>>>>> >>>>>> >>>>>> On 12/20/24 12:48 PM, Christopher Schnick wrote: >>>>>>> >>>>>>> So as a follow-up to this, this is a general JavaFX issue and >>>>>>> not related to a certain application. You can find references to >>>>>>> this on reddit: >>>>>>> https://www.reddit.com/r/JavaFX/comments/1hhu0d5/bugs_with_scene_builder_v_2400/ >>>>>>> and on GitHub with some verbose and debugfonts output: >>>>>>> https://github.com/JabRef/jabref/issues/11755#issuecomment-2403606223 >>>>>>> . It also seems related to this issue: >>>>>>> https://bugs.openjdk.org/browse/JDK-8242617 >>>>>>> >>>>>>> On 04/12/2024 18:43, Christopher Schnick wrote: >>>>>>>> >>>>>>>> I'm not able to reproduce it, but some of my users are. If >>>>>>>> anyone who knows the font renderer maybe wants additional >>>>>>>> information or has some ideas on what the users can try to >>>>>>>> either fix or diagnose the root cause, I can relay that request >>>>>>>> to them. >>>>>>>> >>>>>>>> I can ask them to try other JavaFX applications, but either way >>>>>>>> how that goes, it doesn't show the cause. >>>>>>>> >>>>>>>> On 04/12/2024 18:37, Andy Goryachev wrote: >>>>>>>>> >>>>>>>>> I might suggest trying to run some other JavaFX application >>>>>>>>> using the same setup.? Or better yet, if you can come up with >>>>>>>>> a short reproducer, please file a bug. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> -andy >>>>>>>>> >>>>>>>>> *From: *openjfx-dev on behalf >>>>>>>>> of Andy Goryachev >>>>>>>>> *Date: *Wednesday, December 4, 2024 at 09:20 >>>>>>>>> *To: *Christopher Schnick , >>>>>>>>> openjfx-dev at openjdk.org >>>>>>>>> *Subject: *Re: Windows default font glyphs are rendered wrong >>>>>>>>> on some systems >>>>>>>>> >>>>>>>>> I've never seen this...? what is the font that causes the issue? >>>>>>>>> >>>>>>>>> -andy >>>>>>>>> >>>>>>>>> *From: *openjfx-dev on behalf >>>>>>>>> of Christopher Schnick >>>>>>>>> *Date: *Monday, November 25, 2024 at 02:44 >>>>>>>>> *To: *openjfx-dev at openjdk.org >>>>>>>>> *Subject: *Windows default font glyphs are rendered wrong on >>>>>>>>> some systems >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> for some of our users, the font glyphs of the default Windows >>>>>>>>> font are wrong by an offset of +2. E.g. the letter D is >>>>>>>>> rendered as F, the symbol - is rendered as /, and so on ... >>>>>>>>> However, the glyph spacings and kernings are using the correct >>>>>>>>> values for the original letter, only the actual glyph itself >>>>>>>>> is wrong. This is happening on the latest 24-ea build on >>>>>>>>> Windows 11, but also occurred on version 21 a while ago. I >>>>>>>>> wasn't able to reproduce it myself, only some users were. >>>>>>>>> >>>>>>>>> This has happened now for multiple users of our application, >>>>>>>>> so I figured to report it (Didn't find this in the bug tracker). >>>>>>>>> >>>>>>>>> Here is there issue, next to how it should look like: >>>>>>>>> >>>>>>>>> (It is in danish because the user played around with the >>>>>>>>> language settings to troubleshoot) >>>>>>>>> >>>>>>>>> There was no explicit -fx-font set, so the application uses >>>>>>>>> the default one. When the users change to using -fx-font: >>>>>>>>> Roboto, which is bundled with our application, the glyphs are >>>>>>>>> rendered normally. So this issue is specific to certain fonts. >>>>>>>>> >>>>>>>>> If there's any additional information required, I can relay >>>>>>>>> that request to our affected users. >>>>>>>>> >>>>>>>>> >>>>>>>>> Best >>>>>>>>> Christopher Schnick >>>>>>>>> >>>>>>>>> (I resent this mail as it got stuck in the moderation queue >>>>>>>>> for being too big due to me accidentally pasting the >>>>>>>>> screenshot as a .bmp) >>>>>>>>> >>>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s.png Type: image/png Size: 81374 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ls6xRvPGaI1BL10B.png Type: image/png Size: 69609 bytes Desc: not available URL: From angorya at openjdk.org Fri Dec 20 22:11:45 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 22:11:45 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v13] In-Reply-To: References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: On Tue, 10 Dec 2024 23:36:30 GMT, Andy Goryachev wrote: >> Please refer to >> >> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md >> >> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. >> >> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: >> >> >> /** >> * Obtains the snapshot of the current text layout information. >> * @return the layout information >> * @since 24 >> */ >> public final LayoutInfo getLayoutInfo() >> >> >> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: >> >> - caret information >> - text lines: offsets and bounds >> - overall layout bounds >> - text selection geometry >> - strike-through geometry >> - underline geometry >> >> >> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: >> >> >> /** >> * Returns the shape for the strike-through in local coordinates. >> * >> * @param start the beginning character index for the range >> * @param end the end character index (non-inclusive) for the range >> * @return an array of {@code PathElement} which can be used to create a {@code Shape} >> * @since 24 >> */ >> public final PathElement[] strikeThroughShape(int start, int end) >> >> >> >> >> ## WARNING >> >> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). >> >> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). >> >> >> >> ## Testing >> >> The new APIs can be visually tested using the Monkey Tester on this branch: >> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api >> >> in the Text and TextFlow pages: >> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) >> >> Two very basic headful tests have been added. >> >> >> ## See Also >> >> https://github.com/FXMisc/RichTextFX/pull/1246 > > Andy Goryachev 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 36 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - Merge branch 'master' into ag.text.layout.api > - segments > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - Merge remote-tracking branch 'origin/master' into ag.text.layout.api > - coordinates > - note > - text layout test > - text flow test > - shorter array > - ... and 26 more: https://git.openjdk.org/jfx/compare/69afda8b...2a3a754a keep-alive ------------- PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2557779671 From angorya at openjdk.org Fri Dec 20 22:27:24 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 20 Dec 2024 22:27:24 GMT Subject: RFR: 8341670: [Text, TextFlow] Public API for Text Layout Info [v14] In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com> Message-ID: > Please refer to > > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md > > The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout. > > This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.: > > > /** > * Obtains the snapshot of the current text layout information. > * @return the layout information > * @since 24 > */ > public final LayoutInfo getLayoutInfo() > > > The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as: > > - caret information > - text lines: offsets and bounds > - overall layout bounds > - text selection geometry > - strike-through geometry > - underline geometry > > > This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake: > > > /** > * Returns the shape for the strike-through in local coordinates. > * > * @param start the beginning character index for the range > * @param end the end character index (non-inclusive) for the range > * @return an array of {@code PathElement} which can be used to create a {@code Shape} > * @since 24 > */ > public final PathElement[] strikeThroughShape(int start, int end) > > > > > ## WARNING > > Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438). > > This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ). > > > > ## Testing > > The new APIs can be visually tested using the Monkey Tester on this branch: > https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api > > in the Text and TextFlow pages: > ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72) > > Two very basic headful tests have been added. > > > ## See Also > > https://github.com/FXMisc/RichTextFX/pull/1246 Andy Goryachev 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 37 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge branch 'master' into ag.text.layout.api - segments - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - Merge remote-tracking branch 'origin/master' into ag.text.layout.api - coordinates - note - text layout test - text flow test - ... and 27 more: https://git.openjdk.org/jfx/compare/4c86be72...c1c46ab6 ------------- Changes: - all: https://git.openjdk.org/jfx/pull/1596/files - new: https://git.openjdk.org/jfx/pull/1596/files/2a3a754a..c1c46ab6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=13 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=12-13 Stats: 617 lines in 67 files changed: 336 ins; 110 del; 171 mod Patch: https://git.openjdk.org/jfx/pull/1596.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596 PR: https://git.openjdk.org/jfx/pull/1596 From jpereda at openjdk.org Mon Dec 23 10:56:11 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 23 Dec 2024 10:56:11 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes Message-ID: This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. ------------- Commit messages: - Notify window and screen when dpi changes Changes: https://git.openjdk.org/jfx/pull/1668/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1668&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8346281 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1668.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1668/head:pull/1668 PR: https://git.openjdk.org/jfx/pull/1668 From angorya at openjdk.org Mon Dec 23 15:55:42 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 15:55:42 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. modules/javafx.graphics/src/main/native-glass/win/GlassWindow.cpp line 213: > 211: > 212: #ifndef USER_DEFAULT_SCREEN_DPI > 213: #define USER_DEFAULT_SCREEN_DPI 96 shouldn't this value come from some windows header? ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1668#discussion_r1895898710 From angorya at openjdk.org Mon Dec 23 20:12:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 20:12:38 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. please add the test case to https://bugs.openjdk.org/browse/JDK-8346281 ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560243002 From angorya at openjdk.org Mon Dec 23 21:10:41 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 21:10:41 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: <_xpswqgakFTuwVNQN5kpeCVDmhPbtX1LbBE8q0mbBi4=.1a75e6c8-0f5c-422d-ae9b-dc03482fb0eb@github.com> On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. Does not seem to work. Here is my scenario: 1. win11 with two monitors, the built-in laptop screen at scale 100%, the external monitor at 225% (located "above" the build-in one). 2. the monkey tester opens up on the external monitor (since it remembers its position between launches) 3. when the user clicks on the menu, the menu pops up in the wrong location (way outside of the main window in fact) 4. change resolution to 200% 5. click on the menu, the menu also appears in the wrong location 6. it's only after I drag the window to the main monitor the menus start appearing at the right location. drag it back to the external monitor, the menu appears at the correct location again. 7. change external scale back to 225%, the menu opens up at the right location. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560298271 From jpereda at openjdk.org Mon Dec 23 21:18:42 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 23 Dec 2024 21:18:42 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. I've added the test case to the JBS issue (sorry about that, I thought I did when I created it). About the test case scenario: - you have a JavaFX application already running in a given monitor - without changing resolution, the label shows the current output scale, and the menu popup shows up in the correct position (if it doesn't, this is a different issue than this one). - Then, after showing the menu at least once, you change the screen resolution (the screen that has the app, that is) With this PR you should see: - the label showing the correct output scale once you change the resolution (this doesn't happen without the PR), - and the menu popup showing up at the correct position (this doesn't happen without the PR). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560305657 From angorya at openjdk.org Mon Dec 23 21:24:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 21:24:38 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. hmm, not sure where the disconnect is. - before I launch the monkey tester, there is no fx app running anywhere - the monkey tester appears on the external monitor, it's status bar shows scale 2.25 - the menu appears in the wrong location let me try attaching the screenshot: ![Screenshot 2024-12-23 132020](https://github.com/user-attachments/assets/ccdc4117-aef5-4498-83fd-678d04b6acb3) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560308802 From jpereda at openjdk.org Mon Dec 23 21:32:40 2024 From: jpereda at openjdk.org (Jose Pereda) Date: Mon, 23 Dec 2024 21:32:40 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. Do you have the same issue (unexpected offset for the popup) as well without this PR? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560317552 From angorya at openjdk.org Mon Dec 23 21:32:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 21:32:40 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. I think the difference between your scenario and mine is that the monkey tester appears on the external monitor instead of the main one. If I close the monkey tester while it is on the primary laptop screen and restart it, the menu shows up at the right location from the start. Maybe you can change your test app to open one window on each screen? ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560317772 From angorya at openjdk.org Mon Dec 23 21:44:38 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 21:44:38 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 21:30:01 GMT, Jose Pereda wrote: > Do you have the same issue (unexpected offset for the popup) as well without this PR? The behavior is different. With the MT showing up on the external monitor, the initial location of the menus is correct. Once I change the scale, the menus pop up in two wrong location *above and to the left* (the change in scale was 2.25 -> 1.5) ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560327923 From angorya at openjdk.org Mon Dec 23 22:09:40 2024 From: angorya at openjdk.org (Andy Goryachev) Date: Mon, 23 Dec 2024 22:09:40 GMT Subject: RFR: 8346281: [Windows] RenderScale doesn't update to HiDPI changes In-Reply-To: References: Message-ID: On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda wrote: > This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running. > > When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well. > > There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. > > There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case. attached an updated SCCE to the ticket. the initial scale value seems to be incorrect in this PR. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1668#issuecomment-2560364978 From duke at openjdk.org Mon Dec 23 22:40:50 2024 From: duke at openjdk.org (duke) Date: Mon, 23 Dec 2024 22:40:50 GMT Subject: Withdrawn: 8342703: CSS transition is not started when initial value was not specified In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 15:32:28 GMT, Michael Strau? wrote: > When the initial value of a styleable property is not specified in a stylesheet, no transition is started: > > .button { > transition: -fx-opacity 1s; > } > > .button:hover { > -fx-opacity: 0.5; > } > > The expected behavior is that a transition is started in this case, since the default value of `-fx-opacity` is 1. > > The reason for this bug is that `StyleableProperty` implementations do not start a CSS transition when the value is applied for the first time. The intention behind this is that a node that is added to the scene graph should not start transitions. CSS transitions should only be started _after_ the node has been shown for the first time. > > The logic to detect this situation is currently as follows: > > // If this.origin == null, we're setting the value for the first time. > // No transition should be started in this case. > TransitionDefinition transition = this.origin != null && getBean() instanceof Node node ? > NodeHelper.findTransitionDefinition(node, getCssMetaData()) : null; > > > However, this does not work. When no initial style is specified in the stylesheet, `this.origin` will not be set, and thus no transition will be started even after the node has been shown. The new logic works like this: > > A `Node.initialCssState` flag is added. Initially, this is `true`. Manually calling `applyCss` or similar methods will not clear this flag, as we consider all manual CSS processing to be part of the "initial CSS state". Only at the end of `Scene.doCSSPass` will this flag be cleared on all nodes that have expressed their interest. This mechanism ensures that a node will be eligible for CSS transitions only after the following conditions have been satisfied: > 1. The node was added to a scene graph > 2. CSS processing was completed for a scene pulse This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1607 From schernyshev at openjdk.org Wed Dec 25 08:21:43 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 25 Dec 2024 08:21:43 GMT Subject: [jfx17u] RFR: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 09:29:51 GMT, Sergey Chernyshev wrote: > Hi, > > this PR fixes the build failure after backporting JDK-8336798 [1]. > The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. > > > [1] https://bugs.openjdk.org/browse/JDK-8336798 @johanvos Could you please take a look? ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/221#issuecomment-2561709586 From jvos at openjdk.org Wed Dec 25 11:29:43 2024 From: jvos at openjdk.org (Johan Vos) Date: Wed, 25 Dec 2024 11:29:43 GMT Subject: [jfx17u] RFR: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 In-Reply-To: References: Message-ID: On Wed, 25 Dec 2024 08:19:31 GMT, Sergey Chernyshev wrote: >> Hi, >> >> this PR fixes the build failure after backporting JDK-8336798 [1]. >> The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8336798 > > @johanvos Could you please take a look? @sercher Thanks for spotting this -- makes sense indeed. I'll do a deeper review + tests later this week. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/221#issuecomment-2561847990 From jvos at openjdk.org Thu Dec 26 10:37:43 2024 From: jvos at openjdk.org (Johan Vos) Date: Thu, 26 Dec 2024 10:37:43 GMT Subject: [jfx17u] RFR: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 09:29:51 GMT, Sergey Chernyshev wrote: > Hi, > > this PR fixes the build failure after backporting JDK-8336798 [1]. > The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. > > > [1] https://bugs.openjdk.org/browse/JDK-8336798 tested, works fine now. ------------- Marked as reviewed by jvos (Reviewer). PR Review: https://git.openjdk.org/jfx17u/pull/221#pullrequestreview-2523066351 From duke at openjdk.org Thu Dec 26 15:33:44 2024 From: duke at openjdk.org (duke) Date: Thu, 26 Dec 2024 15:33:44 GMT Subject: [jfx17u] RFR: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 09:29:51 GMT, Sergey Chernyshev wrote: > Hi, > > this PR fixes the build failure after backporting JDK-8336798 [1]. > The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. > > > [1] https://bugs.openjdk.org/browse/JDK-8336798 @sercher Your change (at version 92c8ee437853bc34edb12e13a106068bc7e6a43b) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jfx17u/pull/221#issuecomment-2562889746 From schernyshev at openjdk.org Thu Dec 26 19:25:40 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 26 Dec 2024 19:25:40 GMT Subject: [jfx17u] Integrated: 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 In-Reply-To: References: Message-ID: On Tue, 10 Dec 2024 09:29:51 GMT, Sergey Chernyshev wrote: > Hi, > > this PR fixes the build failure after backporting JDK-8336798 [1]. > The test CSSRoundingTest.java uses multiline string literals, that are not supported with -source 11. > > > [1] https://bugs.openjdk.org/browse/JDK-8336798 This pull request has now been integrated. Changeset: f965b610 Author: Sergey Chernyshev Committer: Johan Vos URL: https://git.openjdk.org/jfx17u/commit/f965b6102a648d697236c8f9a1f0e63287b6026f Stats: 48 lines in 1 file changed: 0 ins; 3 del; 45 mod 8345870: Failed to compile test/javafx/scene/web/CSSRoundingTest.java after 8336798 Reviewed-by: jvos ------------- PR: https://git.openjdk.org/jfx17u/pull/221 From pavelturk2000 at gmail.com Fri Dec 27 14:29:51 2024 From: pavelturk2000 at gmail.com (PavelTurk) Date: Fri, 27 Dec 2024 16:29:51 +0200 Subject: Is it not possible to create a JavaFX bug because site doesn't work Message-ID: <41c26005-4632-4823-9085-bacc080ac75e@gmail.com> Hello everyone, Unfortunately https://bugreport.java.com/ doesn't work. On submitting a bug the site returns a blank page with: Request method 'POST' not supported Best regards, Pavel From philip.race at oracle.com Fri Dec 27 19:55:35 2024 From: philip.race at oracle.com (Philip Race) Date: Fri, 27 Dec 2024 19:55:35 +0000 Subject: Is it not possible to create a JavaFX bug because site doesn't work In-Reply-To: <41c26005-4632-4823-9085-bacc080ac75e@gmail.com> References: <41c26005-4632-4823-9085-bacc080ac75e@gmail.com> Message-ID: I see that. I will report it. -phil ________________________________ From: openjfx-dev on behalf of PavelTurk Sent: Friday, December 27, 2024 6:29:51 AM To: openjfx-dev at openjdk.org Subject: Is it not possible to create a JavaFX bug because site doesn't work Hello everyone, Unfortunately https://bugreport.java.com/ doesn't work. On submitting a bug the site returns a blank page with: Request method 'POST' not supported Best regards, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: