>>> 2. (Improvement / New Feature) ... > ALT+TAB on Windows will show the task switcher dialog and advance to the > next icon(application). > Adding SHIFT into the mix will move in the reverse direction > > My point here was that unless the intent was to process focus traversal when > ALT/META/CTRL are also pressed, then it is better to check what modifiers > are pressed and only proceed if the (optional) SHIFT modifier is pressed or > none at all.
OK - makes sense. >> 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. > > Just as before, it is a continuation of the SHIFT key reversing direction That's what I figured, but is this a common convention? I have never heard of it before. >> 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. >> > It just seems insconsistent to me. I see the SPACE key as a means to > toggle the selection state. If I can select multiple checkboxes (or list > items in this case) I would expect the toggle to have an effect on the > entire selection. It may be inconsistent, but without a use case (or a comparison to a similar component in another toolkit) it is difficult to know what the "right" behavior should be. Maybe the spacebar shouldn't have any effect on the check state, and it should be up to the application? Whatever we decide, the same should apply to TreeView. >>> 5. (Bug) >> > From memory I think there is an early call to super.keyPressed(). The problem was that TerraMenuPopupSkin was allowing ComponentSkin#keyPressed() to consume the event. This is now fixed. >>> 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. >> > > I'd vote to lose the style altogether, combine the 2 behaviours, or rename > the property to reflect what it actually does. I'm OK with dropping the style. The default value is true, and I can't find any examples that set it to false. Do you want to make this change?
