JDK-8099289 : Support component orientation in common UI controls
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2008-06-19
  • Updated: 2015-06-16
  • Resolved: 2013-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8100124 :  
JDK-8100125 :  
JDK-8100126 :  
JDK-8100127 :  
JDK-8100128 :  
JDK-8100129 :  
JDK-8100130 :  
JDK-8100131 :  
JDK-8100132 :  
JDK-8100133 :  
JDK-8100134 :  
JDK-8100135 :  
JDK-8100136 :  
JDK-8100137 :  
JDK-8100138 :  
JDK-8100139 :  
JDK-8100140 :  
JDK-8100141 :  
JDK-8100142 :  
JDK-8100143 :  
JDK-8100144 :  
JDK-8100145 :  
JDK-8100146 :  
JDK-8100147 :  
JDK-8100148 :  
JDK-8100149 :  
Description
The common UI controls need to support component orientation in order to be usable by non left-to-right languages (Arabic, Hebrew, Urdu ...)  This feature allows controls to lay themselves out in the expected manner for a given writing system.
Comments
Verified on 8.0b88
06-05-2013

Initial support is now in the 8.0 controls repo. There are still some gaps in the implementation and notable bugs include clipping issues in ScrollPane, SplitPane, TextArea, TreeView, etc. Note that this is especially severe when running with the Prism SW pipeline (use J2D as a workaround). New JIRA issues will be filed and linked here. Developers would typically call setNodeOrientation(NodeOrientation) on the Scene to have it automatically inherited by all children. The property can be overridden on any Node and will be inherited by default for any children of that Node. There is still a need for an application wide property to set the default orientation for all scenes. An interim solution is available in the form of a system property, but please note that this is likely to be removed if/when an application based property becomes available. To enable RTL as the Scene default, add "-Djavafx.scene.nodeOrientation.RTL=true" to the command line.
06-11-2012

Ok, I will assign the bug to Leif. I have asked Anthony to review the C code. We should aim to get this code in by the end of this week.
30-10-2012

Patch seems generally ok, however I would like to review it again when applied to the repo and I can more easily play with the behavior code modifications (my only real area of concern - from an approach point of view, not a loss of functionality or buggy point of view). I've asked Leif to review this patch and he will be the main point of contact on this feature from a UI controls point of view, but I will be watching changes on this jira issue closely so am happy to be involved when necessary.
29-10-2012

Suspected Problems: - TextArea (and other controls) may not change orientation dynamically when inheriting and the parent orientation changes - any control that sets properties based on effecitive orientation will be in trouble when the parent orientation changes - if a control opts out of mirroring, when orientation changes, we update the transformation (will the control redraw with the new orientation) - it seems effective orientation needs to be a property
26-10-2012

The attatched patches are a first cut at Node Orientation with a minimal API. The easiest way to see RTL behavior is to set node orientation in a scene. For most nodes, it is automatically inherited. Missing Features: - Canvas mirroring has not been implemented Known Bugs: - ScrollPane doesn't scroll right (could be a bug in scroll pane, I have a stand alone example that uses transfomrations that fails) - TextArea doesn't scroll right. If you hold down a key, when the characters hit the left edge, the text scrolls to the right (bad clipping) - in the main "grid" view of Ensemble when RTL, the arrow keys go the wrong way (but they work everywhere else, for example in tool bar) - the drop down list for a combo box is clipped and not positioned properly - the SearchBox in Ensemble is quite broken (might be hard coded offsets that don't work for RTL) Suspicious Code: - look for //TODO's in the code - the code that positions a stage (popup or regular) is suspicious and contains instanceof - table has some arrow key behavior that is not accounted for and appropriately flipped - text field skin getAlignment() may not account for all alignment combinations that can occur Once the patch is accepted (or some flavour of orientation is implemented), I will enter JIRA with example code for each of the problems mentioned and anything else I find or know about. The good news is that most thing work.
26-10-2012

Docs/OK
03-10-2012

G11N/OK
03-10-2012

SQE/OK for baselining
13-09-2012

Implements A360 Feature http://oracleplan.oracle.com/gotoEntity?entityType=FEATURE&entityId=751242 Implements A360 Feature http://oracleplan.oracle.com/goto?ra_=entity&entityType=FEATURE&entityId=766113
07-09-2012

True, CSS does not deal directly with layout, but styleable properties such as shadows, margins, etc, may depend on orientation.
15-08-2012

This is still in brainstorming phase, but current idea is to provide some client property per each node. The reason behind it is that in some controls, orientation has to be settable depending on its content context. As to CSS, my understanding is that it does not deal with layout by design, doesn't it?
15-08-2012

Will the orientation property be settable on an individual Control basis, or is it only per Scene or per Application? I think this decision affects how we load styles from CSS. If the property is set for the whole Scene, then we can load separate stylesheets (possibly having one for RTL that is loaded on top of the main stylesheet when needed). If it is per Control, then we will need some kind of CSS selector for those cases where the styling differs. Does CSS3 already have mechanisms defined for this?
15-08-2012

This feature comprises a small amount of API work and the upgrading of all controls and layouts. Once the API and the visual design are done, the implementation for each control/layout can be done pretty much independently from the rest. Estimate starting the work in early October after the performance projects are complete. We will make controls and layouts available for test as they are completed. While the exact ordering of controls isn't decided yet, the sub tasks are roughly grouped into 3 milestones: Milestone 1: Nov 7th - Button / Hyperlink - Label / Labeled - CheckBox - Tooltip - Menu / MenuItem / RadioMenuItem / CheckMenuItem / ContextMenu / MenuBar - ScrollBar / Scrollpane - Slider - ListView / ListCell Milestone 2: Dec 12th - Pagination - SplitPane - ColorPicker - ComboBox / ComboBoxBase - MenuButton / SplitMenuButton - TextField / TextArea / PasswordField - TreeView / TreeItem / CheckBoxTreeItem - layouts Milestone 3: Jan 30th - Accordion - TabPane / Tab - TableView / TableRow / TableCell - TitledPane - ToolBar
14-08-2012

sorry for mis-oparation that changed assignee.
26-04-2011

This RFE was originally concerned about component orientation in the Reprise controls. I've re-written to make it pertain to the common controls. For the record, the original description of this request follows: Moved from internal bug database (6708277): Looks like the component orientation attribute is missing in javafx.gui, while it's in javafx.ui. http://openjfx.java.sun.com/current-build/doc/api/javafx.ui/javafx.ui.Widget.html#componentOrientation Note that there are some inconsistencies in the javafx.ui component orientation constants, like LEFT-RIGHT, WEST-EAST, LEADING-TRAILING. Reprise should have consistent and component-orientation friendly constant names.
07-08-2009