Matteo Casalin wrote (23-03-12 21:30)
On 03/21/2012 01:23 PM, Cor Nouws wrote:
One could say, that because in other locations using modifiers do make a
difference, it is good to have that here too, thus that unintended use
of the modifiers, while no specific function is linked to that use,
indeed results in nothing happening.
Sorry, I think I made a little confusion here saying "nothing happens":
in my previous mail those words meant "if page up/down are pressed while
holding a key modifier, then the highlighting box is not moved but stays
on the previously highlighted item", but it could also be understood as
"cursor is moved but no special action is taken".
So: should the current behavior (highlighting box does not move) be kept
or should the modifiers be neglected and the highlighting box move one
page up/down as if the unmodified page up/down where pressed? My feeling
is that the first solution is the desired one, but I would prefer to
have a final confirmation on this.
I agree with you.
I agree with always passing through the "none" item.
I think we should split this point in two:
* Should top/bottom wrap-around behavior be allowed? This is the
current solution, but honestly I find it somewhat confusing (columns
can be long and scrolling can be involved) and, from my understanding,
Astron already agreed to remove this "feature".
OK for me.
If this wrap-around
should be kept, then passing through NoneItem is required (unless we
find a specific key combination to select/deselect it).
* If we do not want this wrap-around, what should we do for NoneItem?
OK..
My original proposal involved moving first to the first item, from where
the NoneItem could be accessed (with up/left key-presses). This may be
too tricky.
Current behaviour (from your 1st mail) does not remind me of
difficulties while using:
* Home key move to the "none" item if present, to the first element
otherwise.
* End key moves to the last item.
Better approaches could be:
* NoneItem is accessed from:
* any item in the first row by pressing "up"
* the first item also by pressing "left"
I would prefer the current behaviour. I associate Home & End with that.
* NoneItem can be exited by pressing
* "down", which move to first item in the last selected column
* "right", which moves to the first item of the first column
I agree with that.
This would allow to alway move in nearby locations, with full control
on what is being done. I would exclude page up/down because NoneItem
cannot be considered part of a page and, moreover, I wouldn't be able
to say what's the correct target position for page down when in
NoneItem. For consistency with this, I would also exclude "home" and
"end", but I'm less strong biased on this.
So that opens the door to an agreement ;-)
This proposal is of course arguable and my approach is biased by my
programmer side (I prefer to avoid special cases).
* Return key behavior: at least it should not close the color
configuration window, but my guess is that's a misconfiguration of
the specific instance of ValueSet.
Not sure which window you are looking at (Tools > Options > General ->
Colors -> Edit ?) and what behaviour is odd.
Correct, the window is the one you pointed to. I find odd that pressing
"return" key while moving through the ValueSet items closes that window,
especially because during key-navigation items are highlighted with a
different border than the one used for selected ones: this would lead me
to press the "return" key to perform a selection, but that also closes
the window.
I agree that it is confusing. Quite often (always?) when in a
list/control where items can be selected, Alt-Return is needed to start
the OK button.
In other situations, just Return is sufficient.
Using TAB to move to the next widget could be a solution,
but it's not straightforward, IMHO, since in other instances of ValueSet
(color selection menus) return is a better choice for selection. While I
expect a menu to close on selection, I do not expect a window to do so.
ValueSet key-navigation code seems to offer two different ways of
handling return keys, depending on WB_NO_DIRECTSELECT configuration
flag, but I didn't investigate it deeply, yet.
OK, looks as in indicator in the direction of what users experience ;-)
Not entirely sure about this one, although probably most people would
want to use Return and Tab the same way (i. e. to get to the next
widget and select a colour).
When there is some select+close behaviour, I never expect the Return to
move to another widget.
My point is if "select + close" is right for e.g. the configuration
window. I would expect that window to close if any of its exit buttons
were selected and return was pressed, but I just verified that it's
closed on "return" key-press almost independently on the selected
widget: the only exception found so far is when the "RGB/CYMK" dropbox
is expanded, in which case return is used for selecting the highlighted
item and close the drop down.
What's the correct/desired behavior?
I am not completely unhappy with the current behaviour (as I wrote out a
bit before).
(But that might be because I just add some random modifier when hitting
a certain key does not give the desired effect ;-) )
But ... for me it would be logic that
- selecting an item from a combobox, is done with Tab or Enter
- selecting an option or checkbox is done with space
- OK is always Enter
Or do I miss situations?
[ skipped some other thoughts on ALt-Return behaviour ]
I currently have made some modification to the navigation code,
according to the action list validated by Astron. I plan to play with
this code at least until I feel comfortable with the results and I also
get some more feedback about the points discussed in this email. Since
real usage is showing me that some of my original proposals are not so
user friendly, so we will probably need to refine this behavior after
some tests in the field.
Yes, good idea.
When part is available in master, I would like to play with it (and
other prolly too).
Cheers,