New toolbar icons #5626
New toolbar icons #5626
Conversation
|
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/ |
|
@mdboom - thanks for working on this! A few comments:
|
|
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? |
|
@astrofrog wrote:
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.
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.
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. |
|
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. |
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 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. |
|
Furthermore, there is discussion to generalize the functionality provided On Thu, Dec 10, 2015 at 1:05 PM, Michael Droettboom <
|
ddd7f05 to
f0607fa
Compare
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? |
|
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. |
|
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). |
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 How should we move this forward? Take it to some kind of a vote? |
|
Great! The only thing that I don't like too much is that we are restricting ourselves to We could even ask latter for icon proposals from users. |
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). |
|
In my opinion is worth letting the A simple bash script with a series of calls to imagemagick, will do the trick of generating all the files. |
|
A better option to keep it in python would be http://cairosvg.org/ |
|
Hi, 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. I think it would be very appreciated to get some additional zooms as default. |
|
The scrollwheel zoom/unzoom action is by default with the new |
|
Great!! |
|
@tacaswell asked for my suggestions --
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. |
|
Time to move this along, taking advantage of @doraf's advice.
|
|
This needs a rebase, and some updates. |
|
Ping again if this is going in 2.0. |
|
I'm reviving this as we speak. |
1e6f221 to
b775a26
Compare
|
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. |
|
@mdboom - the vertical alignment of some of the icons in |
It should be easy enough to fix. A little surprising that the alignment isn't already good in the font... |
Add new icons
|
Vertical alignment should be better now. |
|
Not that anyone asked me, but I do prefer the "download" as save over the floppy disk. |
|
I verified that this works correctly with:
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. |
|
Ok, I think this is ready to merge, then. Thanks for all the extra testing, @jenshnielsen |
ENH: New toolbar icons Conflicts: doc/users/navigation_toolbar.rst - kept new wording lib/matplotlib/backends/backend_qt5.py - wording + indentation change which is now correct
|
backported to v2.x as 8356fc2 |
|
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.
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
|
|
Also, note that the new icons are particularly ugly under Tk (Python 3.5 / Arch Linux). |
|
ugh... that is ugly! On Sat, Jun 18, 2016 at 3:44 AM, Antony Lee notifications@github.com
|
|
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. |
|
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. |
|
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 You may have to pull the old icons from git history, I think we no longer ship them. |
|
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). |
|
It turned out to be pretty easy. I was already subclassing |
This does three things:
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.