JDK-8116555 : Node Orientation - API issue: Should isAutomaticallyMirrored() be protected?
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Priority: P2
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2012-11-08
  • Updated: 2015-06-17
  • Resolved: 2012-11-12
Related Reports
Blocks :  
JDK-8100124 - Create API for determining the layout direction of a component
Relates :  
JDK-8102424 - Node Orientation - API issue: Is isAutomaticallyMirrored() named properly?
Relates :  
JDK-8100148 - Add RTL support to Text node
Relates :  
JDK-8099289 - Support component orientation in common UI controls
Description
> I am not a fan of protected.  Other than indicating explicitly that subclasses are supposed to override this method, are there any other benefits?

I believe it is a good approach not to publish things that don't need to be public. It is a node implementation thing, it should not confuse users in the list of publicly accessible methods. Other than you not being a fan, are there any concrete reasons for it to be public? (the fan thing doesn't leave much room for discussion) 

<rant>
Steve says: "Protected is a waste of time.  There is only API in the world.  API is something people see.  Non-API is your implementation.  Every time I have defined a method to be protected in the past, I have always later wanted it to be public.  The advantage of protected is that it indicates that you should override it but we have @Override for that now."
</rant>
Comments
Not when just moving the caret, but when holding the shift key down and extending a selection across bidi boundaries. If mainly LTR text contains an RTL part, the direction will be reversed when selecting across it.
13-11-2012
Ok then, I didn't realize that there are users who want the cursor to move left when they press right arrow - I naively thought arrow points the same way in all countries :-) Thaks.
13-11-2012
>I think it would be cleaner if the mirrored node itself handled the arrow keys instead of doing it from outside (encapsulation). >Could you please show me an example of a node which doesn't know how to handle arrows keys (so it needs user to do that)? 1) Text - caret can move visually or logically 2) Forms - where input fields are embedded in the text content and the arrows need to move the cursor to the next input field according to the reading direction.
13-11-2012
I think it would be cleaner if the mirrored node itself handled the arrow keys instead of doing it from outside (encapsulation). Could you please show me an example of a node which doesn't know how to handle arrows keys (so it needs user to do that)?
13-11-2012
Good point Felipe. The API has to be public for this case. It already is public so we can close this issue.
12-11-2012
I think it has to be protected (or public) since Text (which is in a different package as Node) has to see it. Note: I think it should be public, in general no user should need this information during layout but there are some cases (i.e. handling key events to different arrow keys) when the application needs to know that.
12-11-2012
Raising prioirty to indicate that we cannot ship with this unresolved.
12-11-2012