On 4/25/2016 10:33 PM, Phil Race wrote:
You will need to convince me of the appropriateness of opening these
methods.
It seems to me that are for the focus system, not for applications.
Why should an application be allowed to say "I would like component X" to
receive focus and tell it the reason is a mouse event" when in fact it
is nothing of the kind.
This is a continuation of the 8080395. I think it would be mostly
interesting for framework developers not for applications.
In applications one may need to know the reason why focus is requested
to the component before the focus is set to it.
As I heard from Anton (that was his task initially) opening the cause
was requested by some client, but, unfortunately, I don't have any
references.
--Semyon
I would like to hear from others if they see a valid use case and that
there are no
down-sides to mis-use.
-phil.
On 04/19/2016 02:30 AM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8154434
webrev: http://cr.openjdk.java.net/~ssadetsky/8154434/webrev.00/
To support the new FocusEvent cause concept introduced by JDK-8080395
the next package-private methods of the java.awt.Component class are
opened in the fix:
boolean requestFocus(FocusEvent.Cause cause) -> public void
requestFocus(FocusEvent.Cause cause)
boolean requestFocus(boolean temporary, FocusEvent.Cause cause) ->
protected boolean requestFocus(boolean temporary, FocusEvent.Cause cause)
boolean requestFocusInWindow(FocusEvent.Cause cause) -> public
boolean requestFocusInWindow(FocusEvent.Cause cause)
The methods are changed to be symmetric with the focus request
methods of the same class which do not accept the cause parameter.
The method requestFocus(FocusEvent.Cause cause) was changed to return
no value similarly to the requestFocus() because the returning
boolean true cannot guarantee the focus gain.
--Semyon
