Hi Cor, all
On 03/21/2012 01:23 PM, Cor Nouws wrote:
Hi Matteo, Stefan,
Great that you care for this, Matteo!
And of course that you helped with discussing, Stefan.
I'm a bit late: trouble to keep in track with the various topics in the
community, but found this important enough to read and try to add some
thoughts. Sorry if it is a bit too late.
Matteo Casalin wrote (03-03-12 18:54)
On 03/03/2012 04:07 PM, Stefan Knorr (Astron) wrote:
* left/right motion should not wrap around from first to last (or last
to first) item. Moving through lines is fine (behavior similar to
moving through text), although we can also just stay on the same line
and stop at its borders.
Makes sense to me. Although, of course the decision depends on whether
we want to make it fast to go to an arbitrary position without much
exactitude or whether we want to make it fast to go to the exact
start/end. Your proposal seemingly aims for goal #2.
Well, in this case my goal is to let the user see the content of
not-full rows without explicitly looking for it, and to move rapidly
from an item to another without too much corrections.
OK for me.
* page up/down should mimic the behaviour of up/down keys: move in the
same column when possible (even if the distance is less than a page)
and, when pressed again and no motion in the current column is
possible, reach the first/last element. I don't know if disabling
navigation when key-modifiers are pressed makes sense.
Makes sense. I guess, modifiers should be allowed (but not modify
anything), in all cases where that's possible without unintended
consequences.
I don't know the original goals of that features: currently it seems to
me that if you use modifiers than nothing happens.
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.
* If "none" item is present, then it could be accessed only from the
first item by pressing any of left/up (also page up/home ?) keys.
When selected, it can be exited only by pressing right/down (also
page down/end?) keys, but always lead to the first item.
Makes sense.
I'm less sure of this, now. If a wrap around for up/down is desired, the
current behavior of always passing through the "none" item probably
makes more sense. Unless we find a dedicated key to select that item,
which could solve the situation. Any idea?
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". 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? 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. Better approaches could be:
* NoneItem is accessed from:
* any item in the first row by pressing "up"
* the first item also by pressing "left"
* 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
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.
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. 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.
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?
Wow. Too many things I didn't consider!
Honestly, my plans were to simplify code and provide a more consistent
behavior than the current one, that I find somehow confusing.
I guess we should wait for some hints on the desired up/down behavior
and then see how to proceed (if there's need to).
More: there is different (Alt) Return-key behaviour sometimes in various
windows. Sometimes Space selects an item, sometimes Return and space can
do. etc. etc.
Is this included in your current investigation too ?
As pointed out earlier, I have no clear idea about this but I find that
current behavior is not very "consistent". This is something that has a
wider scope than the ValueSet widget itself and should be addressed on
its own.
Regards,
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.
Thanks and best regards
Matteo
_______________________________________________
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise
