Below is a quick demonstration on a new Keyboard nav handler for the Ext JS Menu system that I’m working on. I would like any and all opinions.
Demo screencast on a new keyboard nav handler for the Ext JS menu classes.
Posted on 13. Aug, 2009 by Jay Garcia in EXTJS, Ext Extensions

8 Responses to “Demo screencast on a new keyboard nav handler for the Ext JS menu classes.”
Leave a Reply
You must be logged in to post a comment.


exceptione
14. Aug, 2009
Yeah, but what if you want to have a number as a trigger character rather than as index?
I can imagine that you have a menu with 3 items
low priority
normal priority
high priority
Now you are requiring that the trigger character is in the description itself.
Well, that requirement is not too bad.
1. low priority
2. normal priority
3. high priority
is more clear.
But there is a more fundamental problem and that is internationalization.
Using a numerical index can easily lead to inconsistencies and even serious problems:
– lang:EN
[k]itten
[h]orse
– lang:NL
[p]oes
[p]aard
index 0 will pose problems for this dutch translation.
That means that in keyboard navigation one should be able to tell what language dictates the key-strokes if you want a cross-language key scheme.
Jay Garcia
14. Aug, 2009
Very good points.
Re: numbered items
I guess we could conceptually allow for a custom key stroke – other than something that exists in the title. Like the “1″ Key for the ‘low’ menu item.
Thoughts?
Re: Internationalization Couldn’t you just do this:
– lang:NL
p[o]oes
p[a]ard
?
Thanks so much for the feedback.
exceptione
14. Aug, 2009
> Re: numbered items(…)
> Thoughts?
I can imagine that you make a distinction between a character ’0′ and a number 0. When the supplied key is an int, it should be treated as index. If the key is a char it is the trigger character itself.
> Re: Internationalization Couldn’t you just do this:
yeah, that it way. But note that the english interface would then behave differently from the dutch interface. After some though: this is not really strange, and sometimes unavoidable.
Real keyboard shortcuts are normally cross-language (like CTRL+P etc), but keyboard navigation doesn’t need to be.
However, in a translation we would still need to be able to set the key-index explicitly per item. Index 1 in your example works, but for a certain other example it doesn’t.
–
So ideally you would be able to specify per item and per language what key [index] you want to assign.
—
Thank you for posts and screen casts. I always enjoy them.
Jay Garcia
14. Aug, 2009
> I can imagine that you make a distinction between a character ‘0′ and a number 0. When the supplied key is an int, it should be treated as index. If the key is a char it is the trigger character itself.
Most menus that I’ve encountered in the past have been triggered by menu item name, not index. What desktop applications have you used that used the menu index item instead of or in addition to the menu item name?
>However, in a translation we would still need to be able to set the key-index explicitly per item. Index 1 in your example works, but for a certain other example it doesn’t.
What Ext JS components change their behavior based on language? I thought changing a language was just changing screens. I think i’m a little inexperienced here.
Thanks for the comments and suggestions. They are valuable.
exceptione
14. Aug, 2009
> Most menus that I’ve encountered in the past have been triggered by menu item name, not index. What desktop applications have you used that used the menu index item instead of or in addition to the menu item name?
O I think we got some misunderstanding. What I mean is that
for example «horse» we will get these results:
key menu listens to
—————————-
3 ‘s’
’3′ ’3′
‘y’ ‘y’
See? if you supply a char for the ‘key’ property you mean an independent trigger key. On the other hand, if you supply an int instead, you are referring to the index of the menu caption “horse”.
That’s just an idea. You could also provide a seperate property for it, so you have triggerKey and triggerIndex or something.
> What Ext JS components change their behavior based on language? I thought changing a language was just changing screens. I think i’m a little inexperienced here.
Ghehe, let me assure you that I am *totally* inexperienced there. So yes, if it internalization is just changing all configuration data than this won’t be an issue.
After searching the docs I couldn’t find any info on I18N. There are some people (e.g. http://elmasse.blogspot.com/2008/04/i18n-with-extjs-resource-bundle.html) who builds some things themselves.
I am sorry that I alarmed you to early.
exceptione
14. Aug, 2009
Oh i lost my formatting. Hope this is more clear.
key -> menu listens to
—————————-
3 -> ’s’
‘3′ -> ‘3′
‘y’ -> ‘y’
MasterAM
23. Aug, 2009
Perhaps we could have a bit more flexible configuration handling in order to resolve these problems mentioned above.
The plugin can, for example, process the triggerKey as follows:
typeof === ‘int’:
—————–
get the char in the specified index.
(should it also add underline to it?)
typeof === ‘string’:
——————–
Now, here comes the fun part:
If a ‘normal’ string is provided, namely a single char string, act as normal and add it to the trigger list.
However, we can decide on a certain value, for example ‘guess’, which when specified, the plugin will try to determine the key based on the item text.
(we can also test for the string length to decide if it is a ‘normal’ or ‘special’ string config).
I believe that we would like to give the user a hint for the key, and this is usually done by underlining the char.
So, we can use a regexp to search for the chars within ‘u’ tags and add them to the triggers list.
So, to make it a bit clearer:
text is: horse
if triggerKey is:
‘a’->’a’
‘guess’->(get the underlined chars)->’r’
We can even take an array, which will cause the triggerKey adder to call itself for each value in the array.
This way, the i18n issue can be resolved (given that the key is hinted via underline and the triggerkey is set to ‘guess’):
kitten->k
horse->h
pooes->o
paard->a
That said, here’s an idea for another project…
Having all of the available trigger keys shown next to the corresponding menu option. This can be done in several ways.
The most interesting, imho, is what I have seen done in MS Office 2007, where you hit ‘alt’ in order to see a small balloon next to the each menu, showing the available shortcut key for that menu (nicer than the default alt behavior in normal windows apps).
What do they do on Mac, btw?
MasterAM
23. Aug, 2009
Lost my formatting as well (stripped the ‘u’ tags from the comment)
should I have used < > ?
Anyway, should’ve been:
[u]k[/u]itten->k
[u]h[/u]orse->h
p[u]o[/u]oes->o
p[u]a[/u]ard->a
(replaced lt and gt with [])