-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG]: Combo boxes in OS Customization window behave unintuitively #865
Comments
Thanks for the report, @lennartb- You are correct in your hypothesis - this errant behaviour is directly linked to the specific version of the Qt library we're linking against. Raspberry Pi Imager, using QML, wound up using widgets that were designed for a touch-first UI. As such, for the scrolling, for example, you might get more success by 'dragging' the list with your primary mouse button. I'm expecting this to be at least partially resolved by #818, however I'm not able to dedicate the required time to resolve the various UI issues that upgrade presents in the near future. I'm going to hold this one open to call out the specific behaviours you've mentioned, to confirm the Qt upgrade will resolve this. |
I can confirm I expect this to be resolved in the upcoming v1.9.0, where in my internal testing I've confirmed that:
|
@lennartb- If you have the time, I'd appreciate your take on the behaviour of v1.9.0 - available in the 'Releases' area of this repository. |
@tdewey-rpi Sure! I've tried to replicate my initial use case and did some smoke testing:
I don't have any other OS available to test atm, is this different under macOS or Linux? A bit unrelated:
|
I can confirm this also works on macOS - and I expect it to also work on Linux.
I've noticed this as well - unfortunately there's still no obvious mechanism to increase the scroll speed. Rather than treating the items as a canvas, it looks like it's mapping 'clicks' of a scrollwheel to position increment/decrement, which produces the lumpy scrolling behaviour.
I can confirm I can reproduce this. I can't see a way to change that behaviour without doing some intrusive customisation of the ComboBox class - which may have to wait for v2.0.0
Thankfully, this appears to be pretty consistent, which meets my objectives for this release.
I can reproduce that, and it's very much unexpected - we tell those controls to allow selection by mouse, and I agree that I would have expected that to operate without using keyboard inputs. Thanks for taking a look. I'm going to introduce a change in v1.9.1 to allow selection by mouse in the ComboBoxes too, but I think we might be due a new bug for the specific cases we've seen. |
What happened?
All combo boxes in the OS Customization window behave "incorrectly" when compared to how they basically work in all other Windows applications:
Take for example the "Wireless LAN country" box. It defaults to UK, but I want to put it to DE. My first intuition is to use the mousewheel, but it takes ages to scroll up to DE, so I switch to the scrollbar. Oh, the scrollbar is not working and results in the list actually scrolling in the other direction. At least using the cursor keys behave as expected and enable me to quickly scroll up.
(I assume this in an issue with the QT controls, which the application seems to be build with)
Version
1.8.5 (Default)
What host operating system were you using?
Windows 11
Host OS Version
23H2
Selected OS
Default selection, doesn't matter
Which Raspberry Pi Device are you using?
Raspberry Pi 3B, 3A+, 3B+, and Compute Module 3, 3+
What kind of storage device are you using?
microSD Card in a USB reader
OS Customisation
Relevant log output
No response
The text was updated successfully, but these errors were encountered: