OSX does the same thing: Apple-Tab moves forward, Shift-Apple-Tab moves backward in the open apps list.
On Sep 17, 2010, at 3:27 PM, Greg Brown wrote: >>>> 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? > > >
