On 18 September 2010 05:27, Greg Brown <[email protected]> wrote:
> >> 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.
>
> I couldn't tell you of a single place off the top of my head where this
does occur, but it was something that seemed natural to my (clearly)
perverted way of thinking ;)
It would be very useful given the current functionality where only later
items are considered for selection, but less so if the selection looped back
to the top.
Even in that scenario, it would allow faster keyboard navigation of lists by
allowing bi-directional searching. I can add it in to my own components
easily enough, so won't sulk if it is not included into Pivot.
> >> 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.
>
> My use case might be that I have a list of items which I am navigating with
the keyboard.
I use SHIFT+arrow keys to define my selection and then want to toggle all at
once to a common state,
I will then perform some action on those items based on the checkbok state.
Being able to toggle the checkbox state of potentially the entire list would
speed things up immensely.
I see your point though and think that perhaps it is best to leave it to the
application.
If we were to implement it, my algorithm would be as follows
If selection contains more than a single checkbox state {
Toggle unchecked to checked
} else {
Toggle entire selection
}
(If mixed states are supported then go from unchecked -> mixed -> checked)
> >>> 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.
>
> Good stuff. You are certainly on a roll today. Closing out tickets like
there is no tomorrow!
> >>> 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?
>
I am happy to but it will have to wait until Tuesday as I am away for the
weekend.
Chris
