> 1. (Improvement / New Feature)
> org.apache.pivot.wtk.Keyboard has the following method which is used
> extensively thoughout the keypress handling code within Pivot
>
> public static boolean isPressed(Modifier modifier) {
> return (modifiers & modifier.getMask()) > 0;
> }
> http://svn.apache.org/repos/asf/pivot/trunk/wtk/src/org/apache/pivot/wtk/Keyboard.java
>
> It returns true if the specified modifier is pressed, regardless of any
> other modifiers which might also be pressed.
> I think there should be an equivalent method which only return true if all
> specified modifiers are pressed
Keyboard.getModifiers() returns the ORed mask of all currently pressed
modifiers. It might be best to simply use this method when we want finer
control over key press behavior (such as in #2 below).
> 2. (Improvement / New Feature)
> org.apache.pivot.wtk.skin.ComponentSkin.keyPressed() handles TAB & SHIFT+TAB
> keys to transfer focus between components
> It doesn't care whether any or all of ALT, CTRL, META are also pressed.
> http://svn.apache.org/repos/asf/pivot/trunk/wtk/src/org/apache/pivot/wtk/skin/ComponentSkin.java
>
> (SHIFT+)ALT+TAB is commonly used in MS Windows to switch between running
> applications (Task Switcher)
> http://en.wikipedia.org/wiki/Alt-Tab
>
> and (SHIFT+)CTRL+TAB is often used to navigate between tabs
> http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts#Tab_management
I'm not sure if this is a bug or an improvement. If you press Shift-Alt-Tab on
Windows, what happens? What do you think should happen?
> 3. (Improvement / New Feature)
> XXX.keyTyped() methods which select the next item matching the keypress
> should probably
> - Move in the opposite direction when SHIFT is pressed
This seems weird to me, but maybe it is a standard I am not familiar with.
> - Loop around so that it would be possible to loop through all matching
> items if you press the key enough times
Agreed.
> 4. (Improvement / New Feature)
> Pressing SPACE in TerraListViewSkin & TerraTreeViewSkin will toggle check
> mark state only when selection mode is SelectMode.SINGLE
>
> Why not process all selected items, and therefore work SelectMode.MULTI?
> This could either just invert each individual item, or set them all to a
> common state before toggling between checked and unchecked.
What would be the use case? Checkboxes are often used as a more "user-friendly"
alternative to multi-select lists - it is less common to see them combined.
> 5. (Bug)
> TAB & SHIFT+TAB have no effect in MenuBarItemSkin, but should perform like
> LEFT & RIGHT arrows and change the activated menu
> http://svn.apache.org/repos/asf/pivot/trunk/wtk/src/org/apache/pivot/wtk/skin/MenuBarItemSkin.java
>
> This looks to be because ComponentSkin.keyPressed() consumes the TAB
> keypresses, so they never reach MenuBarItemSkin
Consuming an event only prevents it from propagating up the container hierarchy
- it doesn't stop it from reaching a subclass (or superclass). That needs to be
done programmatically. Either way, it sounds like it could be a bug (or an
oversight). I'll take a look.
> 6. (Question)
> In TerraFileBrowserSkin, the ENTER key only works if
> keyboardFolderTraversalEnabled has been set, but
> DELETE & BACKSPACE work regardless.
>
> For consistency, should DELETE & BACKSPACE require
> keyboardFolderTraversalEnabled to be true if ENTER does?
> http://svn.apache.org/repos/asf/pivot/trunk/wtk-terra/src/org/apache/pivot/wtk/skin/terra/TerraFileBrowserSkin.java
Hm. That's a good question. I don't remember why that style exists. None of the
sample apps or tests seem to use it.
