On Sun, 19 Apr 2020 10:37:56 GMT, Craig Cavanaugh
wrote:
>For me / my users / and the open bug, it is a bug due to the current
> behavior being unexpected. It creates the
>illusion of a preselected value not actually being selected because it's
> not visible if the list is large and has been
>shown. It creates doubt and the user has to scroll to reconfirm their
> selection which takes extra unnecessary effort
>and time.
>
Yes, I understand the perspective of the users (would be unhappy with it as
well) - but from the perspective of the fx,
it's the job of the application developer to keep a selected item visible.
Which s/he could do easily enough, even for
a comboBox. Also I agree, that in the case of the combo it feels unexpected to
not the selected item on opening the
popup. So we could do something about it - but we have to specify _exactly_
what that something should be.
>With my testing, for the ComboBox, behavior was smooth and natural. I've
> not made any attempt to change selection with
>it shown and I'm not certain it can happen unless done programmatically.
> User selection within the list requires
>scrolling, so the selected value is already visible.
>
Hmm, probably wasn't clear enough: have a combo with many items, open the
popup, navigate (via keys like page/up/down
..) and compare the behavior before/after the fix. I see considerable
differences in behavior. F.i. keyDown does move
the selection one-down without scrolling before and scrolls down by one after
(making the selected item visually
"stick" at the top). Do you see that as well or did I goof somehow (also a
possibility :) ?
Navigation behavior should be the same before/after, I think. There might be
other behavior changes introduced (didn't
check further, it's your issue :), that we should actively look out for.
>I'm not opposed to taking this approach. My current work around by
> extending ComboBox is based on scrolling when the
>value is set (restored) programmatically. I could see how it may be more
> efficient if multiple selections were being
>performed programmatically, but not sure why someone would write code this
> way. I would think it's a one shot process
>to select the final value.
>
not sure what you mean by "one shot process" and "final value": the fix
scrolls the list to top whenever the value
changes, and the value is changed whenever the selectedItem is changed which
happens on navigation (that is user
interaction) as well as changing it programatically.
Maybe we should really go back to square one and _exactly_ specify when we want
the value be scrolled into view. The
current fix does so for _each_ selection (which has rather broad effects). If
it could be bounded a bit more, the
effects would be narrower. That's why I suggested to limit it f.i. to the time
of opening the popup (which is rather
rare compared to selection change).
> Implementing the change in ListView would not change/improve ChoiceBox
> simply because it does not use an underlying
> ListView.
yeah, forget about ChoiceBox, I was wrong - whoever needs to scroll to the
selected value is using the wrong control
..
> My search on uses of ListView only reviled ComboBox other than itself. Since
> ListView by itself is not
> collapsed/hidden for typical uses, would automatic scrolling within ListView
> create a confusing experience?
Ahh, guilty of having been unclear again, sry - what I meant is to add support
of doing a well-behaved scrolling in
ListView (and the other virtualized controls): scrollTo is not overly
well-behaved. And I agree, doing it always and
unconditionally, might introduce a bad user experience.
-
PR: https://git.openjdk.java.net/jfx/pull/166
