Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Where is the actual menu key processing in Swing or the LaF?
7 views
Skip to first unread message
Message has been deleted
Jeff Higgins
May 25, 2012, 10:18:42 AM5/25/12
to
On 05/25/2012 08:21 AM, Stefan Ram wrote:
> When there are two menus with two entries each (no
> sub-menus) and one menu is visible and the right-arrow
> (right-cursor) key is being pressed, the next menu will be
> opened. But (even using the Windows LaF) the first entry of
> the menu just opened will /not/ be selected, while I want in
> /to be/ selected.
>
> So, I got the idea that I might overwrite some Swing class
> or or some such. But where in Swing or in the LaF is this
> actually implemented that the right-arrow key does close the
> current menu and does open the next menu (in the case
> described above)?
>
> I have been looking in JMenu.java, JMenuItem.java and some
> of the LaF-specific classes, but was not able to find that
> spot. One gets lost in many delegations. One class delegates
> to the other, but I do not find the spot where the actual
> connection of right-arrow to next-menu operation is done.
Have you looked about Focus Traversal Policy?
>
> ----------------------------------------
> File Edit
> > New
> Open ...
> Save
> Save As ...
> Exit
>
> Above, »New« is selected. Now, assume that the user pressed
> [-->], then I want to see
>
> ----------------------------------------
> File Edit
> > Undo
> Redo
> Cut
> Copy
> Paste
>
> with »Undo« selected. But instead, all I get is:
>
> ----------------------------------------
> File Edit
> Undo
> Redo
> Cut
> Copy
> Paste
>
> with »Undo« /not/ selected. (One can select this
> with the down-arrow key, then.)
>
> When there are two menus with two entries each (no
> sub-menus) and one menu is visible and the right-arrow
> (right-cursor) key is being pressed, the next menu will be
> opened. But (even using the Windows LaF) the first entry of
> the menu just opened will /not/ be selected, while I want in
> /to be/ selected.
>
> So, I got the idea that I might overwrite some Swing class
> or or some such. But where in Swing or in the LaF is this
> actually implemented that the right-arrow key does close the
> current menu and does open the next menu (in the case
> described above)?
>
> I have been looking in JMenu.java, JMenuItem.java and some
> of the LaF-specific classes, but was not able to find that
> spot. One gets lost in many delegations. One class delegates
> to the other, but I do not find the spot where the actual
> connection of right-arrow to next-menu operation is done.
Have you looked about Focus Traversal Policy?
>
> ----------------------------------------
> File Edit
> > New
> Open ...
> Save
> Save As ...
> Exit
>
> Above, »New« is selected. Now, assume that the user pressed
> [-->], then I want to see
>
> ----------------------------------------
> File Edit
> > Undo
> Redo
> Cut
> Copy
> Paste
>
> with »Undo« selected. But instead, all I get is:
>
> ----------------------------------------
> File Edit
> Undo
> Redo
> Cut
> Copy
> Paste
>
> with »Undo« /not/ selected. (One can select this
> with the down-arrow key, then.)
>
Message has been deleted
John B. Matthews
May 25, 2012, 1:56:48 PM5/25/12
to
In article <menu-2012...@ram.dialup.fu-berlin.de>,
never tried to override it.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> I have been looking in JMenu.java, JMenuItem.java and some of the
> LaF-specific classes, but was not able to find that spot. One gets
> lost in many delegations. One class delegates to the other, but I
> do not find the spot where the actual connection of right-arrow to
> next-menu operation is done.
MenuSelectionManager#processKeyEvent() appears to regulate this. I've
> I have been looking in JMenu.java, JMenuItem.java and some of the
> LaF-specific classes, but was not able to find that spot. One gets
> lost in many delegations. One class delegates to the other, but I
> do not find the spot where the actual connection of right-arrow to
> next-menu operation is done.
never tried to override it.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Jeff Higgins
May 27, 2012, 6:12:49 PM5/27/12
to
On 05/25/2012 12:21 PM, Stefan Ram wrote:
> the method selectParentChild(boolean), and at the end of
> this method, there is a new menu path selected that ends with
> the popup menu.
>
> It seems as if I need to overwrite this and extend the path
> so as to also include the first popup menu entry, but only
> if this selectParentChild(boolean) is called in response to
> an arrow key (not in the case of a mouse action).
>
> »Overwriting« something in a LaF also is not obvious: I want
> my program to use a new LaF that is just a copy of Oracle's
> Windows LaF but with this small change.
>
> After all, I will give up for now. I also tried a web search
> to see if someone has done this before, but to no avail.
>
Yep, I see I flubbed this one.
Being the point and clicky type I hadn't noticed the behavior you
describe in the Swing menu UI. All of the native applications I've since
looked at, both in linux-gtk and windows, implement the behavior you
hope for. I'm surprised.
After a good bit of reading on the subject since your post, I find your
statement: "»Overwriting« something in a LaF also is not obvious"
remarkably mild.
I ran across an article, "Enhancing Swing Applications", located here:
<http://today.java.net/pub/a/today/2006/10/03/enhancing-swing-applications.html>
that I hope to pursue further after my holiday weekend.
The project described in the article seems to have changed homes, it is
now located here:
<http://insubstantial.github.com/insubstantial/laf-widget/>
the links to documentation and etc. in the article still point to the
old home.
Kirill Grouchnikov seems to have a very good grasp of the PLAF system
and writes a lot about it, worth a look.
> Jeff Higgins<je...@invalid.invalid> writes:
>> Have you looked about Focus Traversal Policy?
>
> In javax.swing.plaf.basic.BasicPopupMenuUI.java, there is
>> Have you looked about Focus Traversal Policy?
>
> the method selectParentChild(boolean), and at the end of
> this method, there is a new menu path selected that ends with
> the popup menu.
>
> It seems as if I need to overwrite this and extend the path
> so as to also include the first popup menu entry, but only
> if this selectParentChild(boolean) is called in response to
> an arrow key (not in the case of a mouse action).
>
> »Overwriting« something in a LaF also is not obvious: I want
> my program to use a new LaF that is just a copy of Oracle's
> Windows LaF but with this small change.
>
> After all, I will give up for now. I also tried a web search
> to see if someone has done this before, but to no avail.
>
Yep, I see I flubbed this one.
Being the point and clicky type I hadn't noticed the behavior you
describe in the Swing menu UI. All of the native applications I've since
looked at, both in linux-gtk and windows, implement the behavior you
hope for. I'm surprised.
After a good bit of reading on the subject since your post, I find your
statement: "»Overwriting« something in a LaF also is not obvious"
remarkably mild.
I ran across an article, "Enhancing Swing Applications", located here:
<http://today.java.net/pub/a/today/2006/10/03/enhancing-swing-applications.html>
that I hope to pursue further after my holiday weekend.
The project described in the article seems to have changed homes, it is
now located here:
<http://insubstantial.github.com/insubstantial/laf-widget/>
the links to documentation and etc. in the article still point to the
old home.
Kirill Grouchnikov seems to have a very good grasp of the PLAF system
and writes a lot about it, worth a look.
Message has been deleted
Jeff Higgins
May 27, 2012, 7:11:16 PM5/27/12
to
On 05/27/2012 06:52 PM, Stefan Ram wrote:
> Jeff Higgins<je...@invalid.invalid> writes:
>> After a good bit of reading on the subject since your post, I find your
>> statement: "»Overwriting« something in a LaF also is not obvious"
>> remarkably mild.
>
> I did accomplish it in the end by overwriting
> Jeff Higgins<je...@invalid.invalid> writes:
>> After a good bit of reading on the subject since your post, I find your
>> statement: "»Overwriting« something in a LaF also is not obvious"
>> remarkably mild.
>
>
> processKeyEvent
> ( final java.awt.event.KeyEvent keyEvent,
> final javax.swing.MenuElement menuElement[],
> final javax.swing.MenuSelectionManager menuSelectionManager )
>
> in JMenu, using
>
> javax.swing.MenuSelectionManager.defaultManager().setSelectedPath( javax.swing.MenuElement[] )
>
> to adjust the menu path.
>
So now you use ram.stephan.JMenu in place of javax.swing.JMenu?
import javax.swing.JFrame;
//import javax.swing.JMenu;
import ram.stephan.JMenu
import javax.swing.JMenuBar;
import javax.swing.JMenuItem;
Maybe I'm tipsy. I thought the whole idea was to replace the "feel"
rather than the component.
Sigh, back to the watermelon.
Jeff Higgins
May 27, 2012, 7:33:32 PM5/27/12
to
On 05/27/2012 07:11 PM, Jeff Higgins wrote:
> On 05/27/2012 06:52 PM, Stefan Ram wrote:
>> Jeff Higgins<je...@invalid.invalid> writes:
>>> After a good bit of reading on the subject since your post, I find your
>>> statement: "»Overwriting« something in a LaF also is not obvious"
>>> remarkably mild.
>>
>> I did accomplish it in the end by overwriting
>>
>> processKeyEvent
>> ( final java.awt.event.KeyEvent keyEvent,
>> final javax.swing.MenuElement menuElement[],
>> final javax.swing.MenuSelectionManager menuSelectionManager )
>>
>> in JMenu, using
>>
>> javax.swing.MenuSelectionManager.defaultManager().setSelectedPath(
>> javax.swing.MenuElement[] )
>>
>> to adjust the menu path.
>>
> So now you use ram.stephan.JMenu in place of javax.swing.JMenu?
ram.stefan.JMenu
> On 05/27/2012 06:52 PM, Stefan Ram wrote:
>> Jeff Higgins<je...@invalid.invalid> writes:
>>> After a good bit of reading on the subject since your post, I find your
>>> statement: "»Overwriting« something in a LaF also is not obvious"
>>> remarkably mild.
>>
>> I did accomplish it in the end by overwriting
>>
>> processKeyEvent
>> ( final java.awt.event.KeyEvent keyEvent,
>> final javax.swing.MenuElement menuElement[],
>> final javax.swing.MenuSelectionManager menuSelectionManager )
>>
>> in JMenu, using
>>
>> javax.swing.MenuSelectionManager.defaultManager().setSelectedPath(
>> javax.swing.MenuElement[] )
>>
>> to adjust the menu path.
>>
> So now you use ram.stephan.JMenu in place of javax.swing.JMenu?
>
> import javax.swing.JFrame;
> //import javax.swing.JMenu;
> import ram.stephan.JMenu
ram.stefan.Jmenu
> import javax.swing.JFrame;
> //import javax.swing.JMenu;
> import ram.stephan.JMenu
> import javax.swing.JMenuBar;
> import javax.swing.JMenuItem;
>
> Maybe I'm tipsy.
Yep, sorry.
> import javax.swing.JMenuItem;
>
> Maybe I'm tipsy.
Message has been deleted
Jeff Higgins
May 27, 2012, 9:20:47 PM5/27/12
to
On 05/27/2012 07:48 PM, Stefan Ram wrote:
> Jeff Higgins<je...@invalid.invalid> writes:
>> So now you use ram.stephan.JMenu in place of javax.swing.JMenu?
>
> Yes.
> Jeff Higgins<je...@invalid.invalid> writes:
>> So now you use ram.stephan.JMenu in place of javax.swing.JMenu?
>
>
>> Maybe I'm tipsy. I thought the whole idea was to replace the "feel"
>> rather than the component.
>
> I wanted to see that behavior in my programs. The first idea
>> Maybe I'm tipsy. I thought the whole idea was to replace the "feel"
>> rather than the component.
>
> was to modify the LaF, since this behavior seemed to be part
> of the LaF. But since I did not manage to do this, I chose
> other means.
>
Rodger that. Expediency.
Thanks for drawing my attention to a subject that I hadn't considered.
0 new messages