On Sun, 26 Apr 2020 10:42:10 GMT, Jeanette Winzenburg <faste...@openjdk.org> wrote:
>>> repeating my comment from the [previous pull >>> request](https://github.com/openjdk/jfx/pull/136#issuecomment-608401086): I >>> don't think this is yet ready for a technical review - there are some more >>> basic questions that are not yet answered :) >> >>> - is it really a bug or a nice-to-have enhancement? couldn't find an >>> example in win, didn't try too hard and nowadays, such plain combos are not >>> a really frequent >>> - while none of the virtualized controls (nor ChoiceBox) combines >>> selection with scrolling to the selected item. For combo and choice, I see >>> no reason not make it the default behavior. We need to make certain it >>> behaves "naturally" when navigating in the open popup. >>> - instead of catching every list.select (and not forget the unselect) we >>> might consider doing it in a showing handler >>> - alternatively, we might consider to go deeper and support it directly in >>> the listView >> >> - 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. >> >> - 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. >> >> - 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. >> >> - Implementing the change in ListView would not change/improve ChoiceBox >> simply because it does not use an underlying ListView. 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? > >> 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 <g>- 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. I meant to close this PR out a while ago, but it kept getting put on the back burner. I don't think this PR is the right approach to the problem. I can confirm that this doesn't behave naturally at all when using the arrow or page up / page down keys when the combo is open. Before we make any changes in FX itself we need to specify what the behavior should be for various cases, including multiple selections, scrolling while the combo is open, changing the selection while the combo is open, etc. ------------- PR: https://git.openjdk.java.net/jfx/pull/166
