You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nicotine+ version: 3.1.2.dev1 • GTK 3.22.11
Operating System/Distribution: All, Linux MX18 and MX19
Describe the bug
The Result Filters are not applied unless the user hits the Enter key or clicks an item from the drop-down list, leaving any manually-typed entries present in the text entry boxes even when they no longer have the focus, yet the Results remain unfiltered so the interface is left in a misleading state which seems like an erroneous condition.
This condition remains even after switching tabs, the Results do not reflect the Filter parameters displayed on the screen.
There is hardly any visual indication that there are "0 active filter(s)" (hidden away in 'Result Filters' button ToolTip), apart from the tiny asterisk* is missing (but the user is unlikely to notice that).
The fact that the Text Entry field(s) have been populated, should be an indicator that Filter(s) must be active. Therefore, failure to apply the Filter(s) is a UI bug.
Expected behavior
After entering a Filter parameter, an end-user expects* this to be applied as soon as possible upon entry:
Predictably, upon focus moving away from the text entry box.
Perhaps also, upon Paste (but this (option?) may cause unwanted junk in the Filter History).
Ideally, upon every keystroke, aka "instant" (but this (option?) may cause all sorts of performance and history issues).
If there is Text present in the box and the box does not have focus, then the Filter must be applied.
Steps to reproduce the bug
Type or Paste a filter into any Filter Text Entry box,
Press the Tab key to navigate along to the next Filter Text Entry box, or click into another Filter Text Entry box,
Notice that the Results are not updated as expected.
Additional context
*This bug was noticed by one of my DJ/producer student's who has a learning difficulty that requires accessible UI design (by the way, all my students love Nicotine+ and Soulseek! :-)
As you can see from the above screenshot, with the Filter parameters entered/shown, the Results should be Zero, yet 1000 Results are displayed on the screen, and there it looks like the Filters are active because the Result Filters button looks pressed/active (this looks even more prominent on some other GTK themes).
This screenshot also illustrates related issue #1497
Nicotine+ version: 3.1.2.dev1 • GTK 3.22.11
Operating System/Distribution: All, Linux MX18 and MX19
Describe the bug
The Result Filters are not applied unless the user hits the Enter key or clicks an item from the drop-down list, leaving any manually-typed entries present in the text entry boxes even when they no longer have the focus, yet the Results remain unfiltered so the interface is left in a misleading state which seems like an erroneous condition.
This condition remains even after switching tabs, the Results do not reflect the Filter parameters displayed on the screen.
There is hardly any visual indication that there are "0 active filter(s)" (hidden away in 'Result Filters' button ToolTip), apart from the tiny asterisk* is missing (but the user is unlikely to notice that).
The fact that the Text Entry field(s) have been populated, should be an indicator that Filter(s) must be active. Therefore, failure to apply the Filter(s) is a UI bug.
Expected behavior
After entering a Filter parameter, an end-user expects* this to be applied as soon as possible upon entry:
If there is Text present in the box and the box does not have focus, then the Filter must be applied.
Steps to reproduce the bug
Additional context
*This bug was noticed by one of my DJ/producer student's who has a learning difficulty that requires accessible UI design (by the way, all my students love Nicotine+ and Soulseek! :-)
As you can see from the above screenshot, with the Filter parameters entered/shown, the Results should be Zero, yet 1000 Results are displayed on the screen, and there it looks like the Filters are active because the Result Filters button looks pressed/active (this looks even more prominent on some other GTK themes).
This screenshot also illustrates related issue #1497
This UI bug is an accessibility issue, see link:
Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT) Success Criterion 3.2.2: On Input
"ensure that entering data or selecting a form control has predictable effects. Changing the setting of any user interface component is changing some state in the control that will persist when the user is no longer interacting with it."
The text was updated successfully, but these errors were encountered: