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.
