Change styling of slider widgets #19265

ianhi · 2021-01-09T05:53:39Z

PR Summary

Closes: #19256

Updates the styling of the slider widgets to look like this:

Made the poly patch smaller
Added a circle handle to indicate that the sliders can be grabbed with the mouse
- ~~will change color when grabbed~~
removed the black border of the Axes and indicate the length of the slider with rectangle patch.
- This is skinnier than previously.

PR Checklist

[NA?] Has pytest style unit tests (and pytest passes).
Is Flake 8 compliant (run flake8 on changed files to check).
[I guess?] New features are documented, with examples if plot related.
Documentation is sphinx and numpydoc compliant (the docs should build without error).
Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

QuLogic · 2021-01-09T07:42:40Z

Is _above_rect for the grey part? Why not set a default Axes facecolor instead? This would be more directly overriddable, I think.

ianhi · 2021-01-09T15:53:04Z

I did it that way for two reasons:

If you make the blue polygon have an alpha != 1 then setting the facecolor of the axis looks bad.
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

ianhi · 2021-01-09T18:24:56Z

Just tried out with using the facecolor approach. I found that it doesn't look good with the default scaling (first slider), but that if I made the Axes 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.

ianhi · 2021-01-09T18:25:41Z

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

WeatherGod · 2021-01-09T18:36:54Z

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

…

On Sat, Jan 9, 2021 at 1:25 PM Ian Hunt-Isaak ***@***.***> wrote: I guess it would make sense to simplify by just having a single static background rect — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHF6FM564N5NFWJVKOU2DSZCNTFANCNFSM4V3KRDVQ> .

ianhi · 2021-01-09T18:38:38Z

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 by ax.axvspan.

ianhi · 2021-01-09T18:42:06Z

How about lightgrey? The bottom slider here:

timhoffm · 2021-01-10T00:12:45Z

lib/matplotlib/widgets.py

@@ -404,11 +424,31 @@ def __init__(self, ax, label, valmin, valmax, valinit=0.5, valfmt=None,
        self.val = valinit
        self.valinit = valinit
        if orientation == 'vertical':
-            self.poly = ax.axhspan(valmin, valinit, 0, 1, **kwargs)
-            self.hline = ax.axhline(valinit, 0, 1, color=initcolor, lw=1)
+            self.bkd = Rectangle((.25, 0), .5, 1, transform=ax.transAxes, facecolor=bkd_color)


Can we have a more telling name?

Suggested change

self.bkd = Rectangle((.25, 0), .5, 1, transform=ax.transAxes, facecolor=bkd_color)

self.track = Rectangle((.25, 0), .5, 1, transform=ax.transAxes, facecolor=bkd_color)

seems to be the technical term.

Ah that's a much better name thanks. I was struggling to find the correct term.

timhoffm · 2021-01-10T00:28:40Z

lib/matplotlib/widgets.py

+        if event.name == 'button_press_event':
+            self._handle.set_markeredgecolor(self._handle_color_grabbed)
+            self._handle.set_markerfacecolor(self._handle_color_grabbed)


I'm not sure if this action helpful. If sliders have GUI feedback, it's usually already done on hovering to indicate that you have an control element under the cursor. IMHO changing the color after clicking is too late and serves no purpose.

For simplicity, I'd refrain from changing the color at all.

I did this because I was copying the behavior of ipywidgets sliders without much critical thought 😬.

I have a slight preference for them changing color after selection vs not but I'll happily remove it when I next push here. Reducing the number of new configuration kwargs seems like a good thing.

That said changing as you mouse over the axes could be nice. I imagine this could be accomplished by using axes_enter_event and axes_leave_event

ipywidgets use color to indicate focus (e.g. which control reacts to the keyboard). I don't think our widgets have a concept of focus.

If you want an effect, see also Button for a mouse-over effect. Though here you might want to additionally check if the cursor is on the knob.

We could also say that the "active" color is the same color as the bar (C0). That would still save us the extra argument. One can always add more configurability later when the need arises.

ipywidgets use color to indicate focus (e.g. which control reacts to the keyboard). I don't think our widgets have a concept of focus.

aaah. I'm fully convinced by this, I'll remove it as it's bad to indicate something that is isn't there.

WeatherGod · 2021-01-10T00:41:16Z

I like the lightgrey. Works very well. Another thing to be aware of is that while white (or rather transparent on top of the standard gui window color, which is white) is the default, there are people who change these defaults or are embedding matplotlib in other apps. I haven't looked at the changes yet. but how easy is it going to be to tweak these colors?

…

On Sat, Jan 9, 2021 at 1:42 PM Ian Hunt-Isaak ***@***.***> wrote: How about lightgrey? The bottom slider here: [image: image] <https://user-images.githubusercontent.com/10111092/104106018-752b5e00-5280-11eb-94af-805d1e5383e3.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19265 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACHF6FWSBPTYLU2HN6OBYTSZCPQVANCNFSM4V3KRDVQ> .

ianhi · 2021-01-10T05:49:15Z

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

The track color has a kwarg 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 to axvspan.

lib/matplotlib/widgets.py

ianhi · 2021-01-10T17:05:52Z

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

lib/matplotlib/widgets.py

ianhi · 2021-01-12T22:57:47Z

lib/matplotlib/widgets.py

        Notes
        -----
        Additional kwargs are passed on to ``self.poly`` which is the
-        `~matplotlib.patches.Rectangle` that draws the slider knob.  See the
-        `.Rectangle` documentation for valid property names (``facecolor``,
+        `~matplotlib.patches.Polygon` that draws the slider knob.  See the


https://matplotlib.org/devdocs/api/_as_gen/matplotlib.pyplot.axvspan.html

ax{h,v}span returns a Polygon not a Rectangle patch.

ianhi · 2021-01-12T23:02:00Z

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

ianhi · 2021-01-12T23:40:07Z

I've also reworked the slider_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?

timhoffm · 2021-01-17T22:40:50Z

lib/matplotlib/widgets.py

+            )
+            ax.add_patch(self.track)
+            self.poly = ax.axhspan(valmin, valinit, .25, .75, **kwargs)
+            self.hline = ax.axhline(valinit, .25, .75, color=initcolor, lw=1)


Suggested change

self.hline = ax.axhline(valinit, .25, .75, color=initcolor, lw=1)

self.hline = ax.axhline(valinit, .15, .85, color=initcolor, lw=1)

The init line extends one pixel more to the right (or bottom for horizontal sliders), which looks a bit awkward.

I suspect that the effect comes from different to-pixel mappings of lines and rectangles (lines render including both end points; i.e. two lines ending in the same point would draw on top of each other. But rectangles are designed to not overlap if they are side-by-side). - This is just speculation, but I've checked and excluded some other possible reasons (capstyle and snapping).

The cheap solution to get away with a reasonably looking init marker is to let it extend slightly on both sides. The pixel difference is still there, but 2 vs. 3 is less noticeable than 0 vs. 1.

Same for horizontal slider.

I agree that this simple solution is the way to go. Though I actually feel it is more noticeable in the horizontal slider in your second screenshot. Maybe this is due to your screenshot program but it looks as though on the vertical slider it is 2 vs 3 (or even the same):

whereas on the horizontal slider:

lib/matplotlib/widgets.py

timhoffm · 2021-01-17T22:56:30Z

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. 😝 )

lib/matplotlib/widgets.py

timhoffm

There are more warnings causing the doc build to fail due to #19415.

Please rebase so that that fix is picked up.

lib/matplotlib/widgets.py

timhoffm · 2021-02-17T22:18:37Z

lib/matplotlib/widgets.py

+            edgecolor color '.75'   The edgecolor of the slider handles.
+            size      int   10      The size of the slider handles in points.
+            ========= ===== ======= =========================================
+            Other values will be transformed as marker{foo} and passed to the


Suggested change

Other values will be transformed as marker{foo} and passed to the

Other values will be transformed as marker{foo} and passed to the

ianhi · 2021-02-17T22:27:40Z

Please rebase so that that fix is picked up.

rebased - thanks for the heads up

ianhi · 2021-03-07T18:39:26Z

Hi,

I think I've addressed all of the requested revisions. Is it ok to remove the needs 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

anntzer · 2021-03-07T18:58:59Z

Is it ok to remove the needs revision tag?

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

timhoffm · 2021-03-08T00:47:36Z

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.

ianhi · 2021-03-08T03:40:03Z

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.

timhoffm · 2021-04-20T21:23:32Z

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

ianhi · 2021-04-20T22:05:26Z

@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.

timhoffm · 2021-04-20T22:52:51Z

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).

timhoffm · 2021-04-29T20:01:56Z

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.

Goal is to add a clear handle for the user to grab and to provide visual feedback via color change of when the slider has been grabbed. Simplify slider background rectangles rename bkd -> track + change default color to lightgrey lint remove facecolor from snap demo example Don't change handle color on grab. correct errors in slider docstrings Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

ianhi · 2021-06-24T17:14:31Z

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

jklymak · 2021-07-04T16:30:37Z

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

ianhi · 2021-07-05T15:54:09Z

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

jklymak

Not an expert on widgets, but I think @timhoffm gave this a through review.

ianhi added the topic: widgets/UI label Jan 9, 2021

timhoffm reviewed Jan 10, 2021

View reviewed changes

ianhi commented Jan 10, 2021

View reviewed changes

lib/matplotlib/widgets.py Show resolved Hide resolved

ianhi mentioned this pull request Jan 10, 2021

Expand on slider_demo example #19264

Merged

3 tasks

timhoffm reviewed Jan 11, 2021

View reviewed changes

ianhi force-pushed the style-slider-for-real branch from cc44f7d to b335716 Compare January 12, 2021 22:53

ianhi commented Jan 12, 2021

View reviewed changes

timhoffm reviewed Jan 17, 2021

View reviewed changes

timhoffm reviewed Jan 23, 2021

View reviewed changes

lib/matplotlib/widgets.py Outdated Show resolved Hide resolved

QuLogic added the status: needs revision label Feb 4, 2021

timhoffm reviewed Feb 17, 2021

View reviewed changes

ianhi force-pushed the style-slider-for-real branch from 1d555c0 to 24ff1a9 Compare February 17, 2021 22:25

timhoffm added this to the v3.5.0 milestone Apr 20, 2021

QuLogic added the status: needs rebase label Apr 30, 2021

jklymak marked this pull request as draft May 10, 2021 16:28

ianhi force-pushed the style-slider-for-real branch from 6b4cbc8 to 91c2e4e Compare June 23, 2021 21:22

ianhi removed the status: needs rebase label Jun 23, 2021

ianhi marked this pull request as ready for review June 23, 2021 21:23

timhoffm removed the status: needs documentation label Jun 23, 2021

ianhi force-pushed the style-slider-for-real branch from 91c2e4e to 56ae7d3 Compare June 23, 2021 23:40

jklymak added the status: needs review label Jun 24, 2021

ianhi and others added 8 commits June 24, 2021 13:13

correctly specify the type of the slider poly attribute

61304ad

Consolidate slider handle styling kwargs

776af75

Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

promote all keys to marker{key}

2f153b8

Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

expand doc string for handle_style

1e3f652

fix errors in processing handle style

e160db4

tune slider initline parameters to minimize asymmetry

a7c4df6

Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>

Add whats new for new slider styles

f5dcedd

ianhi force-pushed the style-slider-for-real branch from 56ae7d3 to f5dcedd Compare June 24, 2021 17:13

ianhi mentioned this pull request Jul 6, 2021

Added a new public API update_range to Slider widget. It helps to change the valmin and valmax of the Slider #20579

Draft

7 tasks

jklymak approved these changes Jul 7, 2021

View reviewed changes

jklymak merged commit 2a7d9bf into matplotlib:master Jul 7, 2021

QuLogic removed the status: needs review label Jul 7, 2021

anntzer mentioned this pull request Oct 25, 2021

Clip slider init marker to slider track. #21460

Merged

7 tasks

	self.bkd = Rectangle((.25, 0), .5, 1, transform=ax.transAxes, facecolor=bkd_color)
	self.track = Rectangle((.25, 0), .5, 1, transform=ax.transAxes, facecolor=bkd_color)

	self.hline = ax.axhline(valinit, .25, .75, color=initcolor, lw=1)
	self.hline = ax.axhline(valinit, .15, .85, color=initcolor, lw=1)

	Other values will be transformed as marker{foo} and passed to the

	Other values will be transformed as marker{foo} and passed to the

Change styling of slider widgets #19265

Change styling of slider widgets #19265

Conversation

ianhi commented Jan 9, 2021 • edited Loading

PR Summary

PR Checklist

QuLogic commented Jan 9, 2021 • edited Loading

ianhi commented Jan 9, 2021

ianhi commented Jan 9, 2021

ianhi commented Jan 9, 2021

WeatherGod commented Jan 9, 2021 via email

ianhi commented Jan 9, 2021

ianhi commented Jan 9, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timhoffm Jan 10, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WeatherGod commented Jan 10, 2021 via email

ianhi commented Jan 10, 2021

ianhi commented Jan 10, 2021

Choose a reason for hiding this comment

ianhi commented Jan 12, 2021

ianhi commented Jan 12, 2021

timhoffm Jan 17, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timhoffm commented Jan 17, 2021

timhoffm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ianhi commented Feb 17, 2021

ianhi commented Mar 7, 2021 • edited Loading

anntzer commented Mar 7, 2021

timhoffm commented Mar 8, 2021 • edited Loading

ianhi commented Mar 8, 2021

timhoffm commented Apr 20, 2021

ianhi commented Apr 20, 2021

timhoffm commented Apr 20, 2021

timhoffm commented Apr 29, 2021 • edited Loading

ianhi commented Jun 24, 2021

jklymak commented Jul 4, 2021

ianhi commented Jul 5, 2021

jklymak left a comment

Choose a reason for hiding this comment

ianhi commented Jan 9, 2021 •

edited

Loading

QuLogic commented Jan 9, 2021 •

edited

Loading

timhoffm Jan 10, 2021 •

edited

Loading

timhoffm Jan 17, 2021 •

edited

Loading

ianhi commented Mar 7, 2021 •

edited

Loading

timhoffm commented Mar 8, 2021 •

edited

Loading

timhoffm commented Apr 29, 2021 •

edited

Loading