Is_above_rect for the grey part? Why not set a defaultAxes facecolor instead? This would be more directly overriddable, I think.

I did it that way for two reasons:

1. If you make the blue polygon have analpha != 1 then setting the facecolor of the axis looks bad.
2. I think it looks better when the line the slider is on is smaller and this way the existing slider axis size from the example (and thus probably most peoples code) will not need to be modified for that visual change

I suppose those probably don't fully justify the added complexity though

Just tried out with using thefacecolor approach. I found that it doesn't look good with the default scaling (first slider), but that if I made theAxes used to make the slider smaller in order to look nicer it was significantly more difficult to click on due to the axis being so small. That's compounded by the fact that clicking on the handle when it clips outside doesn't register as moving the slider unfortunately as the events are all tied to the axis.

I guess it would make sense to simplify by just having a single static background rect

can we have a bigger difference in brightness for the right and left
rectangles? They are too close to easily distinguish.

Fine by me. Any specific suggestions for colors? The left rectangle is currently just whatever is first in the users color cycle as it is generated byax.axvspan.

How aboutlightgrey? The bottom slider here:

I haven't looked at the changes yet. but how easy is it going to be
to tweak these colors?

The track color has akwarg dedicated to it + the underlying rect is accesible as a public attribute of the slider, and the blue color has always configurable as**kwargs has always been passed on toaxvspan.

Also: heads up to@t-makaro you may be interested in this on account of animatplot.

rebased + squashed and updated the GIF on the first post.
I also added a change the notes of the slider docstring as theself.poly is aPolygon not aRectangle

I've also reworked theslider_snap_demo to be an example of many sliders that demonstrates how to style them. (see it here:https://github.com/ianhi/matplotlib/blob/slider-styling-example/examples/widgets/slider_styling.py)

Should I include that here or add that as a followup PR?

Should I include that here or add that as a followup PR?

I recommend a separate PR, because that makes reviewing simpler. (The longer a PR is, the less likely somebody takes the time to review. And the relation is non-linear. 😝 )

Please rebase so that that fix is picked up.

rebased - thanks for the heads up

Hi,

I think I've addressed all of the requested revisions. Is it ok to remove theneeds revision tag?

Well, perhaps with the exception of the issue of the red line offset#19265 (comment) though I don't think that that is waiting on me

Is it ok to remove the needs revision tag?

Yes. (Basically whenever you consider you handled the revision requests.)

Well, perhaps with the exception of the issue of the red line offset#19265 (comment) though I don't think that that is waiting on me

Actually, I was waiting on a code change here. IMHO uneven extensions are at least better than one side ending exactly on the line and the other going beyond. Since we cannot be pixel-perfect, the default lines should be a bit wider than the bar.

At a closer look, you are right that .15, .85 work for the vertical slider but not very well for the horizontal slider. I'd be ok if you tune the horizontal slider by using .2, .9 and adding a comment on that. Interestingly, this asymmetric axes coordinates result in a symmetric extension of the line. It seems that for some reason, horizontal and vertical coordinate to pixel mapping is different. If somebody is interested, you're welcome to dig in this. But just using the empirical values is good enough for now. In the worst case we accidentially fix the coordinates and the line will move one pixel again, but that would also not be the end of the world.

Actually, I was waiting on a code change here.

ack! sorry for misinterpreting.

At a closer look, you are right that .15, .85 work for the vertical slider but not very well for the horizontal slider. I'd be ok if you tune the horizontal slider by using .2, .9 and adding a comment on that. Interestingly, this asymmetric axes coordinates result in a symmetric extension of the line. It seems that for some reason, horizontal and vertical coordinate to pixel mapping is different. If somebody is interested, you're welcome to dig in this.

Oh that's wild. Thanks for finding those values! I've gone with the simple solution for now.

Milestoning as this is ready modulo the what's new entry, and we should not miss the next minor release.

@timhoffm sorry I stalled out here. I was asking on gitter awhile ago about how to show the style in the whats new and@tacaswell expressed concern that these changes are somewhat backwards incompatible as there is not easy way to get the old style back.

Hm ok, maybe that's to be discussed on the dev call. OTOH, this is essentially UI element style change, which I consider less invasive than a plot style change (Any OS I'm using is changing its UI under me all the time).

Discussed in the dev call today: Widget apperance is not considered stable API. We can change this in minor releases.

This shoud still get a "What's new" entry.

Rebased to pick up fix for failing tests#20488

Rendered What's new Entry here:https://61099-1385122-gh.circle-artifacts.com/0/doc/build/html/users/next_whats_new/slider_styling.html

Any other widget users want to bless this? Please squash commits unless@ianhi thinks they are all meaningful.

Any other widget users want to bless this?

Maybe@snowtechblog@redeboer@t-makaro

Please squash commits unless@ianhi thinks they are all meaningful.

They are not - I can squash