Several icon themes lack an "internet-mail" icon, causing it to go missing from the XFCE menu
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | exo (Ubuntu) |
Undecided
|
Unassigned | ||
Bug Description
The XFCE main menu in xubuntu uses the "internet-mail' icon for the default "Mail Reader" menu entry. Many icon themes have that icon, but many more do not. If you choose one of the themes that does not have that icon it will disappear from the menu.
I worked around this issue by placing a copy of the old internet-mail.svg icon from the elementary theme (which I personally like better than any of the new ones) in /usr/share/pixmaps. For a default install a symlink to one of the existing icons would also work.
A more robust solution would be to ensure that all icon themes have at least one icon that fills the requirement for each of the default icons used by the menu, and any other system functions. Again, symlinks would work here ...
This issue is still present on a clean install of xubuntu 14.04 b1, although it appeared in previous versions as well. Sorry I didn't have a chance to report it sooner. :-/
| affects: | xfdesktop4 (Ubuntu) → exo (Ubuntu) |
| Doug Barton (dougb) wrote : | #1 |
| Simon Steinbeiß (ochosi) wrote : | #2 |
> The only themes that have the internet-mail icon at all in the 14.04 b1 default install are elementary-xfce and HighContrast. The other themes lack this icon and will trigger the bug as described above.
Yes, in fact if you look closely, the gnome-icon-theme has dropped *all* symlinks upstream and I have the feeling that gnome-icon-
To quote another widespread example, Faenza still has this icon.
I guess it would be okayish as a workaround for exo to ship at least one icon per default app category. But in general I think it's best to stick to standards, i.e. choosing a standard icon name (if one exists in the freedesktop.org icon spec) would be preferred imo.
Note: If exo ships an icon for this, it would put it in /usr/share/
Summing up: I consider this an upstream bug, but in Xubuntu the behavior is actually fine. Our default icon-theme supports the icon and we ship it, to some extent this is all we can do. The rest should be handled upstream (a Xubuntu-specific patch is not desirable in my opinion).
| Doug Barton (dougb) wrote : | #3 |
Simon,
Thank you for taking the time to consider this report. However with resepect I believe that you are thinking about this problem in the wrong way.
I count at least 2 dozen icon themes in synaptic. That would render "fix it upstream" a Herculean task, even if we could guarantee that it would stay fixed once the task was complete (which obviously we cannot).
FYI, your suggestion of putting the icon in /usr/share/
Your suggestion of choosing more standard icon names may be a good one, although I am not familiar enough with what the "standard icon names" are to be able to comment about it. If someone chose to undertake a project to look at what names were included in all of the icon themes and restrict the set of icons used for our menus to just those names, that would be an interesting project. However there is still no guarantee that we would stay up to date with this method. (That is, we still have no way to control what happens upstream.)
More importantly I'm very concerned about your statement that "Our default icon-theme supports the icon and we ship it, to some extent this is all we can do." I think users have a very reasonable expectation that changing icon themes should not cause icons for certain things to disappear. Your statement would be slightly less disturbing if all of the icon themes which shipped by default had this icon, but that's not even true. In the sense that it is the choice of icons in the xubuntu menus that creates the problem, it IS an xubuntu-specific problem, and needs a fix that we have control over.
My suggestion is simple, lightweight, and has the virtue of actually working. :) I hope that it will be seriously considered.
Doug
| Sean Davis (bluesabre) wrote : | #4 |
There are a few instances where this is discussed with xfce and icon themes. Here, as well as with this linked bug [1]
/usr/share/
As the linked bug points out, it would probably be best to create a generic "xfce" theme that gets inherited, but again this requires all icon themes be updated with the new inherited location.
Really, there are two tasks here. One, xfce components should install generic icons if they provide launchers depending on those icons. Two, icon themes need to inherit hicolor if they are not already.
[1] https:/
[2] http://
| Sean Davis (bluesabre) wrote : | #5 |
Small edit: Xfce components should install generic icons if they are "non-standard" (i.e. not in the XDG specification) and they provide launchers depending on those icons.


A little more detail from discussion on IRC ...
The only themes that have the internet-mail icon at all in the 14.04 b1 default install are elementary-xfce and HighContrast. The other themes lack this icon and will trigger the bug as described above.
In the /usr/share/pixmaps directory the following will fix it: elementary- xfce/apps/ 128/internet- mail.png
ln -s ../icons/
Arguably a different size might be a better choice .... SVG icons would be better still. :)
To solve this particular problem with the internet-mail icon one could arguably place the creation of this symlink in the exo-utils package, since it is responsible for the /usr/share/ applications/ exo-mail- reader. desktop file. The same icon is chosen in the /usr/share/ app-install/ desktop/ exo-utils: exo-mail- reader. desktop file which comes from app-install-data. (Arguably the fact that there are 2 versions of this file is a different bug.)