Use QIcon.fromTheme() for icons

[flying-sheep]

like discussed in #950, #2210 advances the icons.

so let’s do it right and use QIcon.fromTheme. we’ll have to simply

1. put the icons into a freedesktop icon theme spec compatible directory (e.g. like here), and bundle this directory as QResources in ':/icons'.

2. anywhere we want to use an icon, we just need to do

   QIcon.fromTheme('document-new')

3. if we carefully choose the icon names to be compatible with linux standard names (e.g. aforementioned document-new), it’ll automatically use system icons on linux

this is the best of all worlds:

1. simple to implement
2. cross platform
3. native appearance
4. allows us to let users choose their own icon themes on all platforms (see comment below)!

[ccordoba12]

But this would be useful only for Linux, right?

[flying-sheep]

But this would be useful only for Linux, right?

it would be most useful for linux at first yes.

it also allows us to let users on any platform use their icon set. they just have to specify a theme name and put the theme in a folder which we have prepended to the theme search path.

note that i was wrong (bug description above is now fixed): the last item in themeSearchPaths already is ':/icons', so if we bundle our icons as qresources in this resource folder, we don’t have to do anything, just call QIcon.fromTheme('iconname'). awesome! we just have to do that, give the icons cool names (e.g. let’s use breeze’s names if applicable) and it will just work!

and as said, this allows us to easily let the user unzip e.g. this into e.g. %appdata%\Spyder\icon-themes and select “Faenza” in spyder’s config, even in e.g. windows (similarly in OSX):

if platform = 'win':  # use different path for OSX
    local_icon_dir = os.getenv('APPDATA')+ '/Spyder/icon-themes'
    QIcon.setThemeSearchPaths([local_icon_dir] + QIcon.themeSearchPaths())
#now add combobox with available themes to select, and add documentation where to put the themes!

---

but anyway, not doing this or similar makes Spyder simply butt-ugly in the eyes of any linux user.

using the system icon theme is something we expect, not some fancy gimmick.

if you don’t use my approach, then don’t, but if you still want to support native themes on linux, i simply think it’s going to be a pain not to use this simple solution, but i’ll be happy however you solve this. at least as soon as i don’t see a single bundled icon anymore.

[ccordoba12]

My thoughts:

1. It's cool that Spyder could blend with the default appearance in KDE or Gnome. The problem with this is that we would (probably) need to provide native versions for icons not present in breeze or faenza but needed in Spyder. This seems like too much work.
2. I'll leave to @SylvainCorlay to decide if we want to support this. I've to say that I'm -1 on this. I think it's better to make Spyder to look the same on all platforms, design just a couple of icons if needed and don't worry about this anymore.
3. If we decide to go native, there should be an option to make Spyder use its own icon theme, and this option should be the default.

[flying-sheep]

1. no we wouln’t. in those cases the system would automatically fall back to the bundled icons. it’s a really simple algo. it simply tries all paths, the last of which being the qresource path i mentioned (aka bundled icons). it creates and uses the first found icon

2. I think it's better to make Spyder to look the same on all platforms

   sorry, but not accepted. that’s appropriate for a website, not an application. fuck branding, and fuck “uniform” style which invariantly results in a hodgepodge of native and custom widgets anyway.

   big no from me for this argument

3. which is what i propose, but certainly not as default: as for widget style, give a combo box to select the theme, with “System Default” being of course the default, everything else, including builtin, choices.

i already made my choice for icon theme right in my system’s settings dialog. applications have to follow or are by definition standing out like sore thumbs.

[ccordoba12]

1. Exactly my point. It's not possible for our set of icons to go well with all other sets out there. That would make Spyder look even uglier, in my opinion.
2. Please tone down your comments. So far nobody has asked that Spyder should use the same icons as those used by the operating system, so I don't regard this as a so touchy issue.
3. We'll see, that's to be decided among the core devs.

[flying-sheep]

I just wanted to stress that this is important.

a cross platform application should behave well on all platforms.

and on Linux this means:

1. don't use your own notifications, use the Staten service
2. use the XDG spec for your config and cache files.
3. use the system widget set and colors
4. use the system icon theme

[goanpeca]

I agree with @ccordoba12,

1. Having some icons use the native theme, but the other icons (on fallback) using the spyder "native" theme would make the GUI look really unprofessional and ugly.
2. Even if having a single icon set in a cross platform application will inevitably result in mixing of the overall look of a GUI (native widgets) plus non native icons (spyder icons), it would still look better than a mix of icons of different (way different themes!) as mentioned in 1.
   • With so many themes available for Linux, having to construct and icon set that works for ALL of the themes, is non practical and not worth it for the time being and the man power at our disposal.
   • @flying-sheep I would not rule out this approach in the future, but right now is definitely not a priority. I think we would prefer to have an uniform and clean Spyder icon set based on fonts (take a look at this that looks great on all screen resolutions (retina etc...) even if not matching the OS.
   • For users sticking to a single OS, this might seems like something very important, but for cross platform users (like myself and @ccordoba12 and many others out there) we would rather have an uniform experience, and a Spyder Icon Set provides that.

In general I would say, as you also point out, "a cross platform application should behave well on all platforms" that meaning: Cross Platform experience is on top of specific OS experience, which means having a compromise to make the project sustainable as well. Qt lowers the burden of development incredibly but there are so many things beyond the GUI (and even within it), so it does not mean that it has to look "perfect" in every single OS, but work.

[flying-sheep]

which means having a compromise to make the project sustainable as well. Qt lowers the burden of development incredibly but there are so many things beyond the GUI (and even within it), so it does not mean that it has to look "perfect" in every single OS, but work.

my point is that with my approach, we leverage a built-in mechanism that can do everything you two want:

1. support high-DPI images
2. allow clean code without direct references to resource names

and on top of that also allows using the native icon theme without extra effort (what every linux user wants)

PS: did you have a look at breeze?

the action icons (i.e. what is used in a application toolbar/menubar/buttons) are on the bottom and have exactly the clean look you strive for. they also (other than font awesome AFAIK) have guidelines allowing to extend them with own icons matching the look.

i’d say that’s even better for your purposes, and allows you to achieve your goal very simply:

1. identify breeze icons you want
2. remove all others
3. add missing ones
4. bundle remaining directory with spyder
5. use QIcon.fromTheme

[goanpeca]

As I said earlier, there is no problem with using Theme approach (the dev team is aware of this), still it would result in mixing icons from whatever theme is on the OS and breeze icons + customs icons (in case the OS theme does not have the icon).

How would this look good in all the different theme options available in Mac, Windows, and Linux?

Breeze Icons are cool, we will take a look.

Update:

Bear in mind that we choose this also based on the following:

• font-awesome 31136 stars - 4682 forks
• breeze 53 stars - 10 forks
  1. Web will continue to grow and grow
  2. Qt and PyQt/PySide have some SVG issues right now, so using a ttf right now overcomes any svg problem. Although this will get fixed eventually I guess.

[flying-sheep]

github isn’t the big part of its story.

the icons are now a part of KDE, where they’ll be used to provide icons for many of those applications.

look e.g. into this directory. here’s the list of icons that start with “document”, “edit”, “debug”, “code”, “go”, “help”, and “run”, and are therefore useful for an IDE. (i’m sure there are more useful ones)

and the icons look flawless here on my Qt-only system…

document-close.svg
document-decrypt.svg
document-edit-decrypt-verify.svg
document-edit-decrypt.svg
document-edit-encrypt.svg
document-edit-sign-encrypt.svg
document-edit-sign.svg
document-edit-verify.svg
document-edit.svg
document-encrypt.svg
document-encrypted.svg
document-export-table.svg
document-export.svg
document-import.svg
document-new.svg
document-open-folder.svg
document-open-recent.svg
document-open-remote.svg
document-open.svg
document-preview-archive.svg
document-preview.svg
document-print-direct.svg
document-print-frame.svg
document-print-preview.svg
document-print.svg
document-properties.svg
document-revert.svg
document-save-all.svg
document-save-as.svg
document-save.svg
document-share.svg
document-sign.svg 
debug-execute-from-cursor.svg
debug-execute-to-cursor.svg
debug-run-cursor.svg
debug-run.svg
debug-step-instruction.svg
debug-step-into-instruction.svg
debug-step-into.svg
debug-step-out.svg
debug-step-over.svg 
code-block.svg
code-class.svg
code-context.svg
code-function.svg
code-typedef.svg
code-variable.svg 
edit-bomb.svg
edit-clear-history.svg
edit-clear-list.svg
edit-clear-locationbar-ltr.svg
edit-clear-locationbar-rtl.svg
edit-clear.svg
edit-copy.svg
edit-cut.svg
edit-delete-shred.svg
edit-delete.svg
edit-find-mail.svg
edit-find-project.svg
edit-find-replace.svg
edit-find-user.svg
edit-find.svg
edit-guides.svg
edit-image-face-add.svg
edit-image-face-detect.svg
edit-image-face-recognize.svg
edit-image-face-show.svg
edit-link.svg
edit-node.svg
edit-paste.svg
edit-redo.svg
edit-rename.svg
edit-select-all.svg
edit-select.svg
edit-table-cell-merge.svg
edit-table-cell-split.svg
edit-table-delete-column.svg
edit-table-delete-row.svg
edit-table-insert-column-left.svg
edit-table-insert-column-right.svg
edit-table-insert-row-above.svg
edit-table-insert-row-below.svg
edit-text-frame-update.svg
edit-undo.svg 
go-bottom.svg
go-down-search.svg
go-down.svg
go-first-view-page.svg
go-first-view.svg
go-first.svg
go-home.svg
go-jump-declaration.svg
go-jump-definition.svg
go-jump-locationbar.svg
go-jump-today.svg
go-jump.svg
go-last-view-page.svg
go-last-view.svg
go-last.svg
go-next-context.svg
go-next-use.svg
go-next-view-page.svg
go-next-view.svg
go-next.svg
go-previous-context.svg
go-previous-use.svg
go-previous-view-page.svg
go-previous-view.svg
go-previous.svg
go-top.svg
go-up-search.svg
go-up.svg
help-about.svg
help-contents.svg
help-contextual.svg
help-donate.svg
help-feedback.svg
help-hint.svg 
run-build-clean.svg
run-build-configure.svg
run-build-file.svg
run-build-install-root.svg
run-build-install.svg
run-build-prune.svg
run-build.svg 

[ccordoba12]

Ok, we are not going to maintain this discussion forever. This is my final take on this:

1. If @SylvainCorlay and @goanpeca want to support native themes, then we'll have them. If not, too bad.

2. Native themes (if supported) are not going to be the default. If people want them, then they'll have to:

   a. Opt in to them. b. Put up the ugly mix of native and our own icons.

3. XDG is not going to happen. IPython guys decided to revert to ~/.ipython and they are a much bigger project than us, so we have to learn from their path.

@flying-sheep, I know you mean well, but please don't derail us more into this discussion.

[ccordoba12]

One final thing: if someone else (besides @SylvainCorlay and @goanpeca) wants to implement native themes, he/she is welcome to make a pull request to make it happen, as long as he/she abides to the conditions mentioned above.

[flying-sheep]

XDG is not going to happen. IPython guys decided to revert to ~/.ipython and they are a much bigger project than us, so we have to learn from their path.

please don’t take this as personal attack, but i really don’t understand your decision making.

if you follow some other person’s/project’s lead then you need to make sure the situations and problems are comparable.

they did it because they are dependent on users manually finding and editing the files. ipython consists of multiple parts that all draw from the same configuration. some are TUI, some GUI. some settings can’t easily be set from a GUI or make no sense in the GUI parts. a unified config editor would make no sense.

this project on the other hand is one application with a central configuration dialog.

whoever wants to find the config files does so because he/she needs something very specific not available in the GUI. that’s a special case, not (like in ipython) the best way to access them.

[ccordoba12]

Don't worry, I know you're not attacking us :-)

Another reason for IPython to finally not go with XDG (and the most important one for me) is that is harder to point people to where configuration files reside, in a simple and multi-platform way.

I think that's a valid reason, and why I decided to not follow XDG either.

[flying-sheep]

yes, i know! my point is that it’s a valid point for them, as they actually do have to point people to the config file on a regular basis, unlike us who point people to the settings dialog instead.

[SylvainCorlay]

Ok, here are the different reasons for our choices so far:

• I think that everyone agrees that vector icons are the way to go,especially since people were complaining that png icons were ugly on retina display.
• SVG is not well supported in PySide and PyQt4, which we still support
• Even on platforms where SVGs are supported, and even when SVGs will be supported everywhere, they are much more general than the type of vector graphics allowed with fonts. Fonts are more restrictive (only one color, no gradient etc) but front-end frameworks such as Qt or web browsers are very good at rendering text and font faces. Performance-wise it is much better to render hundreds of characters with fonts than 20 complex SVG images.
• My bike-shading argument. I find the minimalist look of font icons great. Thinking of it as font faces forces one to make the design as simple as possible.
• Eventually Spyder will integrate the notebook application, which uses bootstrap and font-awesome. To have a uniform design with those, it is more natural to use font-awesome ourselves.
• Native icon themes usually don't have icons for IDE - specific actions (step forward, debug). We would have to devise consistent icons for those themes.

[SylvainCorlay]

Keeping this one open for now since there has been a lot of discussions here. Will probably close when some new icon set lands into Spyder.

[flying-sheep]

good points, but i disagree about performance:

Qt renders the SVG icons once for every used size, and caches them. that hardly makes any impact.

also the restrictiveness with one color isn’t a good thing. when you look at the (sparingly used) color in the breeze icon set, you’ll see that it draws attention to the right things and is an improvement in terms of usability (especially for users over the age of 25) and distinction.

i’d rather have all people use it efficiently after 25ms more loading time than older users having to frustratingly search icons all the time.

---

could you please point me to the bug report about Qt4 having problems with SVG? and how that relates to different platforms?

[Nodd]

I arrive a bit late in the discussion, sorry. I won't go against current conclusions, but I think it would be a good idea to at least follow the standard name for icons that exists, and find non-clashing names for the others, so that it's easier to go either way if we want to change our minds later. I don't know if it is (or can be made) compatible with Font Awesome, however. @flying-sheep since you seem to know the themes well, you could make a list of equivalences (or a PR applying the transformation). Helping is always more efficient than reporting (even if it is of course useful in its own right).

Another question is, what are other editors and IDE doing with their icons in Linux ? I suppose that Eclipse and Matlab use their own set of icons, but what is using kdevelop for its debug icons, for example ?

Finally, I head that svg in small sizes look bad because the details are blurred together instead of simplified. Could it be an additional problem ?

[flying-sheep]

@flying-sheep since you seem to know the themes well, you could make a list of equivalences (or a PR applying the transformation). Helping is always more efficient than reporting (even if it is of course useful in its own right).

i like helping, but only if there’s a future to the work. as it looks now i’d like to have confirmation that using native icon themes will be an option before i do something pointless.

but what is using kdevelop for its debug icons, for example ?

KDevelop uses native icons only.

I head that svg in small sizes look bad because the details are blurred together instead of simplified.

that’s only if you use SVGs created for big resolutions. breeze aligns their icons according to a pixel grid of a certain size, e.g. the normal toolbar size 22×22 for actions (e.g. new file, copy, debug, run, draw rectangle) and additional sizes for other things like mime types (aka file icons)

when compare this with the font awesome examples (which are designed to look good for arbitrary sizes), breeze certainly looks sharper.

[SylvainCorlay]

I am looking into the standard naming conventions from freedesktop, and I think that it is reasonable to use those names. It will make it easy to use Qt/KDE themes etc...

[goanpeca]

:+1:

[ccordoba12]

@SylvainCorlay, great! In case you didn't follow the discussion above: I'd like this to be opt-in, i.e. users should select an option to use the KDE/Gnome icons.

I find the KDE icons for IDEs not so beautiful, so if people want to use them it has to be by their choice, not ours.

[SylvainCorlay]

Agreed. Whether we use QIcon.fromTheme or not we will need a mapping from icon names and using standard ones will make any further changes easier.

[flying-sheep]

great!

[flying-sheep]

hi, i did a PR for another PyQt project where I implemented a qrc-based fallback/default theme that can be used via QIcon.fromTheme: takluyver/nbmanager#10

it’s not hard, only the index.theme files are a bit annoying.

[blooalien]

So, on my system (Kubuntu Zesty) the icons look like hell on the dark theme that looks fine on ALL other apps on my system, including GTK apps. About half of the icons don't show up visible at all since they're the same color as the toolbar background, and changing the system icon theme does NOTHING since you're dead set on forcing YOUR choice of icons upon my desktop, unlike the other apps I use. I really LOVE Spyder IDE, but I'm going to have to switch back to using plain old Kate for Python development, since I'm not going to switch my entire desktop theme for one single app.

[goanpeca]

@bavarin-fleetfoot we are working on a unified theme that will work fine for dark and light apps, the work is a couple of months away

[blooalien]

That's great news, because reading the thread for this enhancement request made it sound like there was strong pushback against the idea of supporting system/Qt standard icons because it would make things "ugly", which it already IS on any system that uses their desktop's built in theme options to change to a darker theme. This one factor of utterly unusable toolbars kills the usefulness of an otherwise fantastic app for me. If I have to guess what button I'm about to press, then there's no point in having a bunch of nice features, any of which might randomly cost me hours of work because I clicked the wrong invisible icon by mistake.

[goanpeca]

@bavarin-fleetfoot we have reviewed the suggestions and we are working on using from theme and the breeze icon theme by default. We will provide OS based look and unified look

• For OS based we will use on all OS the breeze theme for light and dark (most likely)
• For Unified based theme we will used the same themes but colors of the icons will updated based on the syntax highlighter

It is a big refactor and that is why we have taken some time to do it

[blooalien]

Right on. I'll leave it installed for easy updates until I can see the icons on the toolbar. Greatly looking forward to using Spyder again. Other than this one appearance issue (which honestly made no sense to me that it was even a problem), it's by far one of the better Python IDEs in existence.

[SylvainCorlay]

@bavarin-fleetfoot The issue with qtawesome is the look on dark backgrounds?

[ccordoba12]

No Sylvain, the main problem is Windows 10 forbids to load fonts not installed in the system, so we have to resort back to the Spyder 2 icon theme there.

So for Spyder 4 our plan is to use SVG icons instead, from the KDE theme called Breeze.

[blaze-the-star]

Does this work on Mac?

[ccordoba12]

It's not possible for us to implement this feature at this point because we have several custom-made icons and we plan to add more in the future.