New toolbar icons

[mdboom]

This does three things:

1. Updates the icons to a flat style. I've been feeling for a long time that the matplotlib icons look dated and don't really match modern UI design. The new icons are the same ones already used in the NbAgg/WebAgg backends, and come from Font Awesome. For the reasons of "moderized look", perhaps this belongs in 2.0, not that these sort of changes are really "backward incompatible".
2. Adds a script to generate all of the icons from source (in this case FontAwesome glyphs and a custom matplotlib plot for the application icon). In this way, it addresses this comment that the icons are not auto-generated and thus hard to update for different formats and resolutions.
3. Incorporates #5057 and updates the Qt5 backend use hires icons.

Here's what they look like:

Qt4 backend (which is still limited to the low-res icons for technical reasons)

Mac OSX backend:

I considered updating the application icon to be the polar bar plot like it appears on the matplotlib website, but it doesn't look very good at small sizes. If small sizes don't matter as much anymore, I'm happy to update that, too, for consistency between that and the "logo" on the website.

[mdboom]

Another random comment: Does anyone under 30 even know what a floppy disk is anymore? Font Awesome doesn't have a great alternative, but we could use "download" instead: https://fortawesome.github.io/Font-Awesome/icon/download/

[astrofrog]

@mdboom - thanks for working on this! A few comments:

• the zoom icon is definitely not intuitive in the new icons, and should instead probably be a magnifying glass, right?
• should the second icon from the right (for adjusting subplot params) really be a hand? If any, the panning one should be a hand, not this one.
• at the moment, the icons look a bit inconsistent in terms of linewidth - the four on the left and the one on the right look 'bold' while the three others look thinner. I would vote with making them all thinner if possible.
• the baseline for the icons is also inconsistent: the left/right/pan icons look a little too high compared to e.g. the zoom icon.
• a flat style doesn't mean that we necessarily have to go with just monochrome - what about keeping some of the broad colors from before (reddish for home, green/blue-ish for left/right/pan, etc.) while maintaining a flat style?

[efiring]

The floppy still seems to be the standard icon, even if the youngsters don't know what it is; but maybe the download icon is no worse. Would the plain "file" icon https://fortawesome.github.io/Font-Awesome/icon/file be better?
I find the hand to be no help in figuring out what that button will do, and the gear to be somewhat misleading. Normally the gear is used for configuring an application, which is not what it would do here. I think part of the problem is history: subplots_adjust and the artist editing have separate icons because their functionality was added separately, not because they are conceptually different from the user's standpoint. Both are aspects of editing a plot, so it might be better, and less cluttered, if they were combined (recognizing that the artist-editor is qt-specific). For an icon, maybe https://fortawesome.github.io/Font-Awesome/icon/line-chart would be as evocative as anything.

[mdboom]

@astrofrog wrote:

the zoom icon is definitely not intuitive in the new icons, and should instead probably be a magnifying glass, right?

Yes. I agree that makes more sense. I'll change that to

With regard to the subplot adjust/qt editor issue: @efiring, are you suggesting that on Qt only the latter would be available (and have the same icon as for subplot adjust in the other backends)? I worry that would lead to even more confusion.

What about this for subplot adjust: (it seems to suggest editing a box, which is essentially what it does):

For the Qt editor, we could use something very similar to the old one like below. I personally don't have much of a problem with the gear, which I take to mean a sort of "editor". I don't have a strong preference there, though.

at the moment, the icons look a bit inconsistent in terms of linewidth - the four on the left and the one on the right look 'bold' while the three others look thinner. I would vote with making them all thinner if possible.

the baseline for the icons is also inconsistent: the left/right/pan icons look a little too high compared to e.g. the zoom icon.

That's going to be tricky, though obviously not impossible. But we'd have to go from generating everything from matplotlib (which is nice dogfooding) to having an SVG source that we tweak and using ImageMagick or something to convert to everything else. The other advantage of FontAwesome is that it's really easy to use from the Jupyter notebook (which is already using FontAwesome). I say we punt on this level of detail for now.

a flat style doesn't mean that we necessarily have to go with just monochrome - what about keeping some of the broad colors from before (reddish for home, green/blue-ish for left/right/pan, etc.) while maintaining a flat style?

True. And we could use specific colors from our new color cycle as well. What do others think about that? I don't have strong feelings either way.

[efiring]

My suggestion was that the subplot tool be included in the qt editor tool (probably via a third tab) instead of being a separate button. In other words, the qt backend simply has additional manual adjustment options beyond subplots_adjust, but they are all just that--manual adjustment options--so there is no need for two separate buttons on the toolbar. Furthermore, it makes no sense to have the Figure Options button hanging out on the RHS, with the Save button separating it from the subplots button.

The pencil-in-box edit icon would be OK--especially for the unified Figure Options button that I am advocating. I realize that this unification is a more difficult change, but I think it would be a substantial UI improvement. It's not just cosmetic.

I have never thought the check mark icon (original or new) gave much indication of what that button was for. I would prefer that it be ditched.

And returning to the floppy-vs-download question, upon further consideration, I would not oppose the download icon; it probably does give a better visual clue.

[mdboom]

My suggestion was that the subplot tool be included in the qt editor tool

That's fine, but I think shouldn't hold up this PR. Maybe @anntzer or @mfitzp, both of whom have worked on the Qt editor dialog recently, want to work on that.

I have never thought the check mark icon (original or new) gave much indication of what that button was for. I would prefer that it be ditched.

I agree. I think for now (until the Qt editor dialog is improved) we can use a checkmark or a gear. Once the Qt editor dialog unifies things, I agree the pencil-in-box is best.

[WeatherGod]

Furthermore, there is discussion to generalize the functionality provided
by the Qt editor across all interactive backends with the new toolmanager
system, so that might be the better place to merge those functions.

On Thu, Dec 10, 2015 at 1:05 PM, Michael Droettboom <
notifications@github.com> wrote:

My suggestion was that the subplot tool be included in the qt editor tool

That's fine, but I think shouldn't hold up this PR. Maybe @anntzer
https://github.com/anntzer or @mfitzp https://github.com/mfitzp, both
of whom have worked on the Qt editor dialog recently, want to work on that.

I have never thought the check mark icon (original or new) gave much
indication of what that button was for. I would prefer that it be ditched.

I agree. I think for now (until the Qt editor dialog is improved) we can
use a checkmark or a gear. Once the Qt editor dialog unifies things, I
agree the pencil-in-box is best.

—
Reply to this email directly or view it on GitHub
#5626 (comment)
.

[anntzer]

My suggestion was that the subplot tool be included in the qt editor tool

That's fine, but I think shouldn't hold up this PR. Maybe @anntzer or @mfitzp, both of whom have worked on the Qt editor dialog recently, want to work on that.

From an UI point of view it's a bit awkward because the subplot tool applies to the whole figure whereas the qt editor tool applies to a single axes (and because of that, when there are multiple axes it first pops up an axes selection combobox, which is totally irrelevant for the subplot tool). Thus, if you really want to unify the two tools you'd probably end up with a two-pane/tab solution, with subplot tool on one and axes parameters (including a combobox at the top to select which axes to work on) on the other. In other words, I don't think the two GUIs can be naturally combined. Or does someone have a better suggestion?

[mdboom]

I think this is at a point where it meets the initial scope now. The issues with the Qt editor can always be addressed later.

[efiring]

I don't want to hold this up unnecessarily, but looking through the changes I find the new qt editor option to be even less evocative than the previous one, which was already inscrutable. How does an arrow sticking out of a window indicate that one can fiddle with the artists? How many people are going to make the connection upon seeing it? The edit icon being proposed for the subplot editor is closer to what the qt editor does (lots of editing) than to what the subplot tool does (just moving/resizing of subplots).
Maybe I have already said this, but the nearest thing I can find in font-awsome to what the subplot tool does is https://fortawesome.github.io/Font-Awesome/icon/object-group or https://fortawesome.github.io/Font-Awesome/icon/object-ungroup. If one of those were used for subplot tool, that would leave the pencil-edit icon for the qt editor. Alternatively, https://fortawesome.github.io/Font-Awesome/icon/line-chart could be considered.

[mdboom]

How does an arrow sticking out of a window indicate that one can fiddle with the artists?

This is a fairly standard icon for "open a new window or dialog". See https://www.google.com/search?q=open+a+new+window+icon&espv=2&biw=1598&bih=720&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwi3odic1dvJAhXIOyYKHZgJDl4QsAQIGw

Design decisions always turn into bikeshedding, but I pretty strongly disagree that object-group or object-ungroup are any better.

How should we move this forward? Take it to some kind of a vote?

[fariza]

Great!

The only thing that I don't like too much is that we are restricting ourselves to FontAwesome I much rather have the source (in svg) of the desired icons, and generate all the rest from those sources.
This way we can add/remove/modify with PRs the look.

We could even ask latter for icon proposals from users.

[mdboom]

The only thing that I don't like too much is that we are restricting ourselves to FontAwesome I much rather have the source (in svg) of the desired icons, and generate all the rest from those sources.
This way we can add/remove/modify with PRs the look.

Sure. We could do that. But then we can't generate all the images with matplotlib like this (since matplotlib doesn't read SVG). We could just call out to inkscape to convert to PDF (so not the end of the world).

[fariza]

In my opinion is worth letting the font->matplotlib->image approach aside for this one.

A simple bash script with a series of calls to imagemagick, will do the trick of generating all the files.

[fariza]

A better option to keep it in python would be http://cairosvg.org/

[ahed87]

Hi,
would it be possible to consider to add 2 buttons/icons in this update?

I often find myself missing the zoom-in / zoom-out buttons on the plotwindow, something like +/-5% steps (or having the scrollwheel working as zoom as part of default functionality).

I looked at FontAwesome and did not find the classic circle plus and circle minus icons.
They did have square, so maybe that will do, or ask them for a quick update to get circles in there...
Anyways the square one's where plus-square-o & minus-square-o, and there was filled one's as well.

I think it would be very appreciated to get some additional zooms as default.

[fariza]

The scrollwheel zoom/unzoom action is by default with the new toolamanager

[ahed87]

Great!!

[doraf]

@tacaswell asked for my suggestions --

• Stick with font awesome. Its a consistent icon set, it’s super legible, and covers a ton of application icons.
• Consider grouping related functions, like ’configure subplots’ and ‘edit curves, lines, and axis properties’ since they have similar purposes. Move the ‘save/download’ to the end or beginning.
• Don’t use the arrow over the paper icon for the editor, as it usually represents an external link. Maybe try one of the ‘chart’ icons instead as it reads as plot related.
• Floppy drives are obsolete, but the image of a floppy disk is still synonymous with save. In deciding between the save and download icon. pick which ever one better represents the task.
• Check out the sliders icon for ‘configure subplots’ icon.

The general trick with picking icons is to find something that won’t make your users think too hard about what they need to do. They’ll hopefully just know what to do.

[efiring]

Time to move this along, taking advantage of @doraf's advice.

• sliders for 'configure subplots': yes! https://fortawesome.github.io/Font-Awesome/icon/sliders
• floppy vs download: I think this really is a "save to disk" operation--it's local--so I recommend the floppy.
• chart icon for property editor: yes! Like https://fortawesome.github.io/Font-Awesome/icon/line-chart.
• group and move: yes! put save-to-disk at the end. I'm not sure how easy or hard the grouping is, but fortunately it is lower priority. If there is grouping, then "home, previous, next", "zoom-pan, zoom-to-rect", "edit subplots, edit axes" are the natural groups.

[QuLogic]

This needs a rebase, and some updates.

[QuLogic]

Ping again if this is going in 2.0.

[mdboom]

I'm reviving this as we speak.

[mdboom]

This has been updated as summarized by @efiring above.

The grouping has been changed, but not all backends support adding "dividers" in the toolbar. I'm considering fixing that out-of-scope for now.

[astrofrog]

@mdboom - the vertical alignment of some of the icons in toolbar.png (added in this PR) is slightly off (e.g. next/previous/pan). Is that easy to fix?

[mdboom]

@mdboom - the vertical alignment of some of the icons in toolbar.png (added in this PR) is slightly off (e.g. next/previous/pan). Is that easy to fix?

It should be easy enough to fix. A little surprising that the alignment isn't already good in the font...

[mdboom]

Vertical alignment should be better now.

[phobson]

Not that anyone asked me, but I do prefer the "download" as save over the floppy disk.

http://fontawesome.io/icon/download/

[jenshnielsen]

I verified that this works correctly with:

• WX
• GTK
• GTK3
• QT4
• QT5
• OSX

The home icon look a bit to low for me still but perhaps I am being to picky.

@phobson I think the download icon makes more sense in the Web/Notebook backends but less so in the gui frameworks. Here I tend to prefer the floppy.

[mdboom]

Ok, I think this is ready to merge, then. Thanks for all the extra testing, @jenshnielsen

[tacaswell]

backported to v2.x as 8356fc2

[flying-sheep]

i don’t really like those particular icons. they look too fat.

i really like breeze, and it has SO MANY icons. e.g. zoom icons to choose from.

• zoom original
• zoom previous
• zoom next
• zoom in
• zoom out
• zoom fit-best
• zoom
• and many more x-y- specific ones

those are of course not what people are accustomed to, but much better than the old stuff. why a house? why just arrows? i’m sure they were the best at the time but right now, i’d rather see

[anntzer]

Also, note that the new icons are particularly ugly under Tk (Python 3.5 / Arch Linux).

[WeatherGod]

ugh... that is ugly!

On Sat, Jun 18, 2016 at 3:44 AM, Antony Lee notifications@github.com
wrote:

Also, note that the new icons are particularly ugly under Tk (Python
3.5 / Arch Linux).
[image: screenshot_20160618_004307]
https://cloud.githubusercontent.com/assets/1322974/16169741/b22a1e82-34ed-11e6-89c7-ff8557f3a676.png

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#5626 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AARy-KoZ9zNqmr45C4j4f9t-Jcj19AFZks5qM6HYgaJpZM4GvtSm
.

[efiring]

It looks like they could be improved by being re-rendered from the pdf or svg using antialiasing. The Tk backend is using ppm files. It could use gif as well, I believe.

[rayosborn]

Would it be possible to have a configurable option to use the old icons? I have added a couple of my own in NeXpy, which are not monochrome and so now clash badly. Since I'm customizing the toolbar anyway, it's not a problem for me to keep the old ones, but I find the new ones a little too austere for my taste and others might feel the same.

[tacaswell]

The way this is currently implemented in the backends this is annoying to provide configuration for (it is basically a hard-coded path), but PRs are welcome. This is something that @OceanWolf may have something to say about in the toolbar refactor.

If you want to control the icons I suggest you monkey-patch or sub-class NavigationToolbar2QT to override the class attribute toolitems with whatever filenames you want.

You may have to pull the old icons from git history, I think we no longer ship them.

[OceanWolf]

I must say I don't like the new icon-set, they look a bit monotonous to me. All the same colour and shape. I find it more difficult finding the right button to click as they no longer stand out to me.

Anyway, in answer to your question, with the toolbar refactor it becomes easier to change the icons used. At the moment we do this by setting the icon for the tool... but I would like to extend it to deal with iconsets rather than change tool icons individually (though one could loop through this to do it), and I think I would need to do this anyway to get the web-backends working with the refactored logic, but I had planned to cross that bridge when I got to it, aka after the merging of #4143 (we should set a date when we can spend a day or two going through it together, blitzing it like we did with #3652).

[rayosborn]

It turned out to be pretty easy. I was already subclassing NavigationToolbar2QT, so all I had to do was override the _icon function to point to my own image directory. It wouldn't be that hard to add a configuration option to the same function to use the old images, i.e., add '_old' to 'name' in the same way that '_large' is added for PyQt5 icons. Or you could redefine self.basedir in _init_toolbar. I don't know how this would work for other backends though. I can see that it might not be worth the effort. (P.S., I wrote this before seeing the previous comment by @OceanWolf)