From duke at openjdk.org Tue Oct 1 00:15:43 2024 From: duke at openjdk.org (duke) Date: Tue, 1 Oct 2024 00:15:43 GMT Subject: Withdrawn: 8330559: Trailing space not rendering correctly in TextFlow in RTL mode In-Reply-To: References: Message-ID: On Fri, 31 May 2024 14:39:00 GMT, Karthik P K wrote: > The issue is specific to Mac. The glyph positions returned from native side for complex text is not handled in the text render logic. This issue is observed only when trailing spaces are present along with LTR text mixed with RTL text (Example: "Arabic: ???????"). > > Made changes in `getPosX` of `TextRun` class to handle negative values. > > Tested the changes manually with the sample code present in the bug and using the MonkeyTester. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jfx/pull/1468 From jhendrikx at openjdk.org Tue Oct 1 10:11:45 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Oct 2024 10:11:45 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: <-W96PWvracccoMDZ1LzRywA2vJPB9Ix9Oc9Z06gaQk4=.bf764b84-75fb-4554-b4a4-3ce64f1395db@github.com> On Mon, 30 Sep 2024 16:27:50 GMT, Andy Goryachev wrote: > I do not see much behavioral difference between controls inside a regular VBox and VBox inside a ScrollPane > > https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/FocusPolicyResearch.java > > Am I doing things wrong? Yeah, as I explained, FX provided controls, like `ToggleButton` will capture navigation keys **before** they bubble up to `ScrollPane`. See here in `ToggleButtonBehavior`: new KeyMapping(RIGHT, e -> traverse(e, "ToggleNext-Right")), new KeyMapping(LEFT, e -> traverse(e, "TogglePrevious-Left")), new KeyMapping(DOWN, e -> traverse(e, "ToggleNext-Down")), new KeyMapping(UP, e -> traverse(e, "TogglePrevious-Up")) So, with FX provided controls, this issue is being worked around. The controls themselves handle navigation, and so `ScrollPane` won't interfere. `ToggleButton` however is not a good example, as it has special needs for its navigation (which I hope are documented) and so is correct to override how navigation works. Using a regular `Button` instead for your tests would be better, however this also won't work as FX provided controls are all providing their own navigation to avoid letting events bubble up to `ScrollPane`. To make a real comparison, you need to either: 1. Remove the navigation behavior from one of the FX controls, ie. in `ButtonBehavior`, remove the line: // add focus traversal mappings addDefaultMapping(buttonInputMap, FocusTraversalInputMap.getFocusTraversalMappings()); 2. Set a different skin on `Button` (which will also kill its standard behavior). I'll provide an example. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2385376542 From jhendrikx at openjdk.org Tue Oct 1 10:33:44 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Oct 2024 10:33:44 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Mon, 30 Sep 2024 15:31:52 GMT, Andy Goryachev wrote: > SCCE = Self-contained code example, or "complete code sample" in https://wiki.openjdk.org/display/OpenJFX/Submitting+a+Bug+Report Ah, thank you, I hadn't seen this before. > I am not entirely convinced that the proposed solution addresses compatibility concerns, unless this can be demonstrated. I would imagine the idea behind SP handling these keys might have been a desire to be able to scroll the content in the view without changing the currently focused node within possibly? That would be counter to how all scrollable views in almost all UI's work. Generally, a ScrollPane only scrolls when it has the focus itself. As an example, in Eclipse, use the Package Explorer and ensure it has a horizonal scroll bar. Now use the mouse to scroll to the right. Now press the left arrow key to go "up the tree" and close nodes. You'll notice that when you are at a root item, and pressing left again will not "bubble" up to the ScrollPane and it starts scrolling left. At the risk of repeating myself, this is not a matter of what the original programmers may have thought (it is highly likely an oversight, considering how bubbling works and how you don't need to worry about with this in "normal" controls), but what people expect from UI's. The focused component deals with key presses, and nothing else does. The only exceptions to these are well understood: - Menu Hotkeys (usually with a specific kind of menu modifier key as it would otherwise be very confusing) - Underscored keys to change focus (also only with a modifier, and made visual to the user) - Navigation > Alternatively, should we use a different set of key bindings instead of simple arrow keys, like for instance alt-ctrl-LEFT/RIGHT/UP/DOWN (option-command-LEFT/RIGHT/UP/DOWN) key bindings, similarly to #1393 ? That's certainly possible, if that's considered normal for such a control on a given platform. AFAIK, FX is still doing its best to emulate how controls work on the platforms it supports (as evidenced by specific mac/linux/windows bindings in many behaviors). On Windows however, I'm not aware of any such bindings. I've also looked into the Mac platform, and I could not find any combinations that would make the container scroll while another control within it has focus (like an edit box for example). ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2385419806 From jhendrikx at openjdk.org Tue Oct 1 10:52:40 2024 From: jhendrikx at openjdk.org (John Hendrikx) Date: Tue, 1 Oct 2024 10:52:40 GMT Subject: RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus In-Reply-To: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> References: <9M82aLtxDlix7vZcFZou-uwnydew2qFoBz45HBbWrVA=.dfb8aa75-c4de-4985-b351-e74c985a33d9@github.com> Message-ID: On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote: > This change modifies `ScrollPaneBehavior` to only consume keys that are targetted at it. As `KeyEvent`s are in almost all cases only intended for the targetted node (as visually that's where the user expects the keyboard input to go, as per normal UI rules) consuming key events that bubble up is simply incorrect. When the `ScrollPane` is focused directly (it has the focused border) then it is fine for it to respond to all kinds of keys. > > In FX controls normally there is no need to check if a `Control` is focused (although they probably should **all** do this) as they do not have children that could have received the Key Events involved, and Key Events are always sent to the focused Node. When `ScrollPane` was developed this was not taken into account, leading to it consuming keys not intended for it. > > This fixes several unexpected problems for custom control builders. A custom control normally benefits from standard navigation out of the box (TAB/shift+TAB) and directional keys. However, this breaks down as soon as this custom control is positioned within a `ScrollPane`, which is very surprising behavior and not at all expected. This makes it harder than needed for custom control developers to get the standard navigation for the directional keys, as they would have to specifically capture those keys before they reach the `ScrollPane` and trigger the correct navigation action themselves (for which as of this writing there is no public API). > > The same goes for all the other keys captured by `ScrollPane` when it does not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys. Here is a minimal working example that demonstrates the issue when people create a custom control. Note that the standard controls and the custom control all have directional navigation working, except in the case where the custom control is embedded inside a `ScrollPane`. This creates a big burden on custom control developers as to make their control work when used in a scroll pane, they now need to implement their own navigation... package app; import javafx.application.Application; import javafx.scene.Node; import javafx.scene.Scene; import javafx.scene.control.Button; import javafx.scene.control.Label; import javafx.scene.control.ScrollPane; import javafx.scene.control.Skin; import javafx.scene.layout.GridPane; import javafx.scene.layout.HBox; import javafx.scene.layout.StackPane; import javafx.scene.layout.VBox; import javafx.stage.Stage; public class App extends Application { @Override public void start(Stage primaryStage) { GridPane gp = new GridPane(10, 10); gp.add(new VBox(new Label("Standard Buttons in normal container"), new HBox(5, new Button("A"), new Button("B"), new Button("C"))), 0, 0); gp.add(new VBox(new Label("Standard Buttons in ScrollPane"), new ScrollPane(new HBox(5, new Button("A"), new Button("B"), new Button("C")))), 1, 0); gp.add(new VBox(new Label("Custom Buttons in normal container"), new HBox(5, new CustomButton("A"), new CustomButton("B"), new CustomButton("C"))), 0, 1); gp.add(new VBox(new Label("Custom Buttons in ScrollPane"), new ScrollPane(new HBox(5, new CustomButton("A"), new CustomButton("B"), new CustomButton("C")))), 1, 1); Scene scene = new Scene(gp); primaryStage.setScene(scene); primaryStage.show(); } static class CustomButton extends Button { CustomButton(String title) { super(title); setSkin(new CustomButtonSkin(this)); } } static class CustomButtonSkin implements Skin