Please test new Picard Windows builds

Tags: #<Tag:0x00007f9ad5964408> #<Tag:0x00007f9ad5964340> #<Tag:0x00007f9ad5964250>

it’s just like a USB 2.0 plug, you’ll get it right the third time. :wink:


Erratic ? Can you elaborate ?
The behaviour was modified a bit, it goes 5 by 5.

A tooltip was added that shows the current value, not perfect, but it should help.


When you encounter sliders in a program, you expect them to slide.
But nothing slides here.
When you click and drag the big white slider button nothing happens at all.
(except from sometimes seeing the value changing with a value of 5)
So why the button?

Now I learned that you are supposed to probably just click on any area of the slider except on the button.
That’s not what you would expect.

And when you do click on a location distant from the button, it indeed seems to work, but you often see some overshoot happening before the value is set.
So all-in-all it’s an implementation of sliders I am not encountering very often.
Maybe erratic is the wrong term after you have learned and understood what you are supposed to do, but the looks do not match the inners.

I’m on Windows b.t.w., perhaps it’s different on other platforms?


I’m running windows 10 with latest MB-dev app. When I slide to the right, it increases the percent. Note: I can’t click the “box” and slide it. I have to just click the line where I want the box to move to.

Does the tooltip appear ? i suspect it appears over the handle, the position might be incorrect on Windows.

When hovering over the button, no tooltip appears.
When clicking the button no tooltip appears.
When dragging the button the tooltip appears showing the current value, but after dragging the button and releasing the mousebutton nothing has happened.

Clicking somewhere on the slidebar will change the value, but you can only set it to a preferred value by some trial and error.

Here’s a video showing what it looks like on my system:


Yes, I can reproduce this on Windows. What I think what’s happening is that the tooltip steals the focus from the slider, which makes the slider not react anymore to mouse movements. I’ll take a look whether I can find a fix.


I had a look at it, it is really a focus stealing issue that happens only on Windows. There seems to be no really easy fix other than implementing custom tooltips. So for the upcoming release I think I will just submit a release to disable those tooltips on Windows again.

But maybe somebody has an idea how to improve the sliders. Th tooltip was an attempt at indicating to the user what setting indicates a higher preference (even though the value itself is not really interesting, but higher = more preferred). This is how it currently looks like (screenshot is on Windows, on Linux it is pretty similar, macOS a bit different):

Any idea how to improve this?

If sliders are difficult or very time consuming to get right, perhaps just use a few selection dots for each release type?
I don’t think the current fine-grained 5% steps are really needed (or useful?) so that would probably not be missed?

I’m not sure if the current 0% setting actually means that the specific release type will never be matched?
In that case, there could be a ‘disable’ or a ‘0’ button added at the front of the line.

And perhaps, while at it: add the option for a couple of presets for these settings?

This might look nicer and probably demands less work?:

1 Like

What about numeric values that the user could modify? E.g.:

Album [100]
Single [50]
EP [50]
Other [50]
Broadcast [50]
Compilation [0]

Where the scale goes from 0 to 100 with 50 being the default value. I doesn’t look “pretty”, but at the same time it’s not confusing to the user.

1 Like

Would it possible to have a “Min” in one end and a “Max” in the other end? Maybe on top, above the sliders? Does @chhavi have any ideas maybe?


Don’t make it too complicated. Just use simple numeric values, like suggested from @culinko.
Or do it the same way as with the preferred release countries. Let the user sort the the preferred release types by drag & drop. The one not used remains on 0, the choosen one becomes 100, 80, 60, 40, 20, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1

Yes, that could work. Also 5 steps really sounds about right, it would correspond to 0, 25, 50, 75, and 100. And no, there is no option here to completely blacklist a release type, only making it less likely to be picked. But if you have set e.g. Audiobook to 0, but there is no other release matching at least somewhat the file you try to lookup you will still get a match for Audiobook.

I don’t like this very much. The whole point here is making this easier to use, and fiddling around with a bunch of integer values in text boxes isn’t. Also it does not provide an immediately visible impression of what is set to hight and what isn’t. Also it gives a false sense of accuracy I think.

I also thought about a “-” and “+” sign to either side of the sliders. I main issue here was that adding scales or indicators to each sliders makes this view look very busy, but the idea of putting this above the sliders might work.

That doesn’t work the same, you always have to pick one over the other, you cannot just lower one an keep the rest the same. Also this detail at the bottom is not really needed. Some values like suggested by @hiccup probably would be sufficient.

Along the right side:

Along the left side:

Another idea is to use color-changing sliders. The bar could start out colored yellow when the thumb is at the middle position, as you move it right, the bar turns green, as you go left, the bar turns red.

Personally I like the simple clarity of a bar that fills with colour. Like @hiccup’s example, but fill blue in from left there. So the first three blocks would be blue, the next two white. That then shows clearly if you have “more” of that one selected. Like a glass filling with water. Or a thermometer.


  • Keeping at five steps seems sensible.
  • I would avoid adding more words (translation issues).
  • I’d avoid using red and green (colour blind issues).
  • Numbers are always confusing (is a higher number more or less of this?)

Some nice suggestions in this thread, few points:

  • color-coded information should be avoided, we already have too much of this, Picard accessibility sucks and i don’t think we need to make it even worse :wink:
  • we only need 5 values (originally it was a percentage with 1%, currently that’s down to 5% steps, but since those are at the end relative weights, 5 levels seem enough to express user preference)
  • instead of 1 2 3 4 5, we could have – - 0 + ++, and defaulting to central position
  • we could use standard radio buttons until we have a fancier widget (there’s no such 5-segments bar in Qt widgets afaik)

Overall, those settings are not easy to understand for the user, I still wonder if it’s only an UI issue.


A short description of what the feature does and how might help a lot. And the Help button currently goes to a page with a list of all options, without even scrolling to the relevant part of the help page. That certainly isn’t helpful.

1 Like

@Zas, yes, I hadn’t thought of the colorblindness issue.

I just had a thought. How about rotating the sliders 90 degrees. Up for prefer and down for reject is much more intuitive than left or right.

I like the radio button example you posted, but perhaps -2 -1 0 +1 +2 instead of just the signs doubled up? Then again, I suck at UIs. :wink:

I’ve been out of the loop, but just updated and excited to see how it goes.

1 Like