Hi Frank,
I approve.
Thanks,
SAM
On 23.01.2013 7:00, Frank Ding wrote:
Hi Alexandr.
Thanks.
To swing-dev, seems I still need anther member review before
committing. Is there anybody who would like to review it?
Best regards,
Frank
On 1/22/2013 10:54 PM, Alexander Scherbatiy wrote:
On 1/22/2013 9:21 AM, Frank Ding wrote:
Hi Alexandr,
Thanks for your information. I have created a new webrev review @
http://cr.openjdk.java.net/~dingxmin/8000326/webrev.03/
Pls take a look.
The fix looks good for me.
By the way, please let me know once 2401619 is migrated to the bug
system.
I will let you know.
Thanks,
Alexandr.
Best regards,
Frank
On 1/21/2013 6:02 PM, Alexander Scherbatiy wrote:
On 1/18/2013 10:53 AM, Frank Ding wrote:
Hi Alexandr,
Could you please let me know if there is any update on review
result? I did not receive any review information of 2401619 which
means it's still not public/reviewed yet, right?
I got answers from the javadoc team:
8000326
The JMenuBar javadoc could be updated to
-------------------------
By default, pressing the Tab key does not transfer focus from
a <code>JMenuBar</code> which is added to a container together with
other Swing components, because the
<code>focusTraversalKeysEnabled</code> property of
<code>JMenuBar</code> is set to <code>false</code>. To resolve this,
you should call the
<code>JMenuBar.setFocusTraversalKeysEnabled(true)</code> method.
-------------------------
2401619
Yes, there should be "will return" expression instead of the
"with return"?
The 2401619 java incident has not been migrated yet to the
bug system.
Thanks,
Alexandr.
Best regards,
Frank
On 12/18/2012 2:36 PM, Frank Ding wrote:
Thanks, Alexandr.
On 12/14/2012 8:40 PM, Alexander Scherbatiy wrote:
On 12/13/2012 1:01 PM, Frank Ding wrote:
Hi Alexandr,
I made another change according to your comment @
http://cr.openjdk.java.net/~dingxmin/8000326/webrev.02 . Please
review it.
I submitted a bug whose internal review ID is 2401619 about
one wording mistake in ContainerOrderFocusTraversalPolicy. But
since the bug system transition, newly submitted bugs cannot
pass review and get publicly available. Can you help me to have
somebody review it?
I resent the both issues 8000326 and 2401619 to the JDK doc
team to review.
Thanks,
Alexandr.
Thanks and Best regards,
Frank
On 12/12/2012 10:07 PM, Alexander Scherbatiy wrote:
On 12/10/2012 11:08 AM, Frank Ding wrote:
Hi Pavel,
I think pointing out the special behavior in javadoc makes
more sense. Could you please take a look at my draft below?
http://cr.openjdk.java.net/~dingxmin/8000326/webrev.01
I think that It has more sense to point this special
behavior in the JMenuBar class itself.
It looks more naturally to read about the JMenuBar focus
traversal behaviour from the JMenuBar javadoc.
Note that I think in the sentence "By default, methods of
this class with return a Component only if it is" it should be
"will" not "with", shouldn't it?
Thank you that you point it out. Could you create an issue
on it?
Thanks,
Alexandr.
Expecting your reply.
Best regards,
Frank
On 10/8/2012 7:47 PM, pavel porvatov wrote:
Hi Jonathan,
Hi Pavel,
On 10/02/2012 11:31 PM, Pavel Porvatov wrote:
Hi Jonathan,
Hi Pavel,
I've filed bug 7198816 for this problem,
Regards, Pavel
http://bugs.sun.com/view_bug.do?bug_id=7198816
This bug was not ported to jira, so I created another bug:
https://jbs.oracle.com/bugs/browse/JDK-8000326
Thanks for porting, but I have trouble with opening that link.
Sorry, use the following link:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000326
but the bug is not available yet... It contains the same
description as the original bug.
Any comments on the patch?
The fix looks dangerous for me. After the fix the
setFocusTraversalKeysEnabled method doesn't work for JMenuBar
(when ContainerOrderFocusTraversalPolicy is used) - it
ignores this property...
Regards, Pavel
best regards
Jonathan
Regards, Pavel
On 11/09/2011 07:25 PM, Pavel Porvatov wrote:
Hi Jing,
Thanks Pavel,
It seems fine to me, if no other
suggestions/opinions, I guess we can move on with this?
Yes, we can. Could you please file a bug for the problem
as well?
Thanks, Pavel
On 2011/11/2 19:58, Pavel Porvatov wrote:
Hi Jing,
Hello Anton,
Thanks for the review. I am still trying to figure
out some real case and provide more detail the
customer may fail.
Anyway, I agree we'd better update the java spec
to make it clear for the customers. I'd like to know
if anyone can help with that?
I'm not sure that javadoc changing is a good decision
in this case. ContainerOrderFocusTraversalPolicy is
designed for AWT, but I don't know why that policy
cannot be used for Swing components as well. I see
several problems:
1. We cannot change javadoc of
ContainerOrderFocusTraversalPolicy because of backward
compatibility
2. We cannot remove setFocusTraversalKeysEnabled(false)
from the JMenuBar#JMenuBar() constructor because of
backward compatibility
May be the best decision is to specify, that JMenuBar
creates menu with the focusTraversalKeysEnabled = false
Did you mean that for the new menu
setFocusTraversalKeysEnabled(false) ? I've tried, but it
does not seem to work for this problem.
if my understanding is incorrect, please help to fix me.
Regards, Pavel
On 2011/10/12 20:54, Anton Tarasov wrote:
Hi Neil,
On 10/10/2011 7:01 PM, Neil Richards wrote:
On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote:
Hi Neil and Jing,
I'm afraid that it's wrong to use
ContainerOrderFocusTraversalPolicy
for swing components. This policy is designed for AWT.
JMenuBar calls setFocusTraversalKeysEnabled(false)
in its ctor which
means that it "swallows" focus traversal keys (like
TAB/SHIFT-TAB
etc.)
and so it can't be a member of a focus traversal
chain. Swing's
default traversal policy
(LayoutFocusTraversalPolicy) excludes
JMenuBar
from a focus traversal cycle.
ContainerOrderFocusTraversalPolicy is
not "aware" about JMenuBar and so it allows it.
So, either a default Swing policy should be used,
or a custom policy.
At worst, ContainerOrderFocusTraversalPolicy should
be overriden
to exclude JMenuBar from a cycle (override its
accept(Component)
method).
I agree that backward compatibility should not be broken
by the fix, so here's a patch from me for the worst case,
could you please help to take a look?
http://cr.openjdk.java.net/~luchsh/7198816/
Thanks
Jonathan
Thanks,
Anton.
Hi Anton,
Thanks for reviewing the suggestion, and for your
insights into this
scenario.
> From the Javadoc, it seems that
setFocusTraversalKeysEnabled() is mainly
concerned with choosing whether focus traversal key
presses (normally
TAB and SHIFT-TAB) are processed "automatically"
(when 'true') or are
delivered to the Component as key events (for the
component's code to
process "manually").
(In the case of JMenuBar, it makes them come through
as key events, but
doesn't do anything special to process these events,
which is why they
get discarded.)
That is right, though it doesn't directly relate to
the issue we're talking about =)
Your description above, though, seems to suggest
that it is generally
undesirable for the JMenuBar to be given the focus,
as all the
Swing-aware focus traversal policies make a point of
not giving focus to
JMenuBar items.
If this is so, then wouldn't it make sense to call
setFocusable(false)
from its constructor (too), to ensure it doesn't get
focus ?
Or, to put it another way, could you explain a
little of the reasoning
or scenario behind why it is desirable for JMenuBar
items to be
generally focusable, even though they aren't
focus-traversable ?
I think such an explanation would be really helpful
in clearing up my
confusion on this point.
Thanks, Neil
Well, I suspect that the core of the problem is that
adding JMenuBar as JComponent to a swing
container doesn't make much sense. Though it is not
directly prohibited, doing so may cause
side effects like the one you've discovered. When
JMenuBar is set properly onto a JFrame its focus
is managed by JRootPane and its focusability just
isn't taken into account. That's may be the reason
it's not declared unfocusable. Honestly, I can't tell
you exactly.
If you do it, you probably won't make any harm, but I
personally don't think this is a vital fix
(unless you have a good use case of the scenario
you've provided). Anyway, this is a swing question
(I'm, as an AWT dev member, leaving the decision to
swing guys).
Thanks,
Anton.
