GNOME Bugzilla – Bug 76495
Should be a default menu item icon for apps without icons
Last modified: 2020-11-07 12:15:07 UTC
Lynx, NMapfe, exmh, and so forth don't have icons in the GNOME menus-- it looks kind of silly for them not to, but why on earth would they be shipped with them? We ought to have a couple of default icons-- one for "Apps that are non-gnome apps" or "Apps that run in terminals" -- some sort of generic Application icon-- that appears when other icons are missing.
Be nice if you guys could whip something up for this.
Created attachment 7486 [details] This is the generic executable icon from nautilus themes we ship. Might be good to the generic app
Created attachment 7487 [details] this might work for the generic terminal app
Usability team. Should we do this ?
I might make the diamond thingy a bit smaller so it looks clearly different from the non-term default app icon.
I'd certainly like to see some sort of generic icon... I guess the diamond design works okay for me in principle, although I'm sure Bill would have something to say about the lack of contrast between the cogwheel colour and the background colour :)
Yeah, but the important thing is the diamond shape, it is clearly distinguishable from files (which mostly have the white sheet thingy) - the cogwheels are just eyecandy; I think the shape alone is enough to tell them apart.
I've struggled with this, but my personal opinion is that we should not display items that do not at least suggest an icon. We can have a broken fallback icon in the event that this icon is not found or something, but we should *strongly* encourage all apps, gnome or otherwise to provide icons assuming they are placing entries to go in the GNOME menus.
Yeah. I agree, that these icons are just a fallback for stuff that 1. Does not yet have an icon or 2. The icon is not found Not an excuse for not making an icon for an application.
Having a fallback icon will make it more likely (hom much, I do not know) for developers to be lazy and not get/make an icon for their menu items. In almost all cases the entries without icons I would rather not have until they have icons... So I'm inclined to say we should implement a technical solution and refuse to show entries unless they set an icon.
s/developers/tigert and jimmac/ :-)
But yea, I agree on the point.
(that's why I put the "get" in in additon to "make" ;-)... you guys do the work, but ultimately the responsibility for coaxing somebody into making an icon or making one (probably shitty) themselves lies with the module maintainer)
Windows and OS/2 use a blank window as the generic program icon. The diamond just looks too nice for something like this. :-) (Also, I think I've seen something very similar to the diamond used as the icon for some non-free app.) Having the same icon over and over on menus would be bad, but I think that says more about menus and icons on menus than it does about having a generic icon.
Created attachment 7780 [details] This is like the Windows or OS/2 generic program icon.
The comments on the desktop-devel-list convinced me and placed me very firmly in the "we shouldn't display entries without an icon" camp. Almost everyone was in favour of "no icon". The reason they almost universally cited was so programmers could not set an icon and it wouldn't look too bad. What scared me was that almost all their perspectives seemed to be not "it won't look terrible if the programmer is negligent" but that this is a programmer convenience "the programmer can not set an icon and things won't work out so bad". That's exactly the sort of reason I think we shouldn't allow icon-less menu entries. We don't want 'em. We have the potential to make them a thing of the past. I think we should do it. Does anyone seriously think that someone won't make a GNOME program because they have to set an icon? So if we really really don't want entries without icons (I think we don't, it makes the menu quite a bit harder to scan), just make people set an icon. It will provide the kick with a boot they need to Just Do It.
in windows, file without asociation is using window logo but ugly one. my sugesttion: Gnome icon but ugly one. or any ugly icon. so for developer, surely they dont want their apps with ugly icon.
In the workspace switcher applet, we use a default blank icon for apps without icons. There should be some consistency between this applet and the menu.
I can't tell what happened with this bug. If I had something to the panel, the default icon is a gnome foot. I don't know how to add anything to them menu. If I install lynx through synaptic, it doesn't appear in the menus.
Lynx should not have an icon, since it's a console application. This would be for an application like Tetravex, which seems to have a missing icon; or if the file has been deleted or something like that.
Created attachment 39168 [details] Proposed image for default icon It's the libwnck default_icon.png enlarged and retouched. Should be into /usr/share/icons or be part of the stock iconset
Created attachment 39169 [details] [review] patch to show a default icon if none present on .desktop it neeeds the icon (proposed at http://bugzilla.gnome.org/attachment.cgi?id=39168 or another) placed on /usr/share/icons or in the stock
I suggest you don't use that icon because it is not consistent with Nautilus' "generic application". This is the generic app icon for Gnome: http://www.gnomefiles.org/shots/generic.gif It might not serve the purpose as well as the icon you suggested, but it's more consistent.
The empty window is, however, consistent with the default Window List/Window Selector icon is 2.10-- I think that's a better angle to look at. (In most cases, you don't double-click a binary in Nautilus to launch an app)
Dave, Eugenia: I think the main problem is that there is no consensus on the path to take. Should we: + show an icon like the ones you proposed? + show an ugly icon? + not show any icon (like what we have right now)? + not show the menu item if it doesn't have an icon? This is the first thing to decide.
>(In most cases, you don't double-click a binary in Nautilus to launch an app) I do. I have a /home/eugenia/Applications/ folder and many apps are installed there. Especially now that there is no way to add easily a menu item on gnome, I use nautilus more to load these apps. Another point is that the theme can be enforce the change of that icon if the theme changes. But the 'window list' icon is always the same as it's specific to these panel applets. >The empty window is, however, consistent with the default Window List/Window Selector icon is 2.10 These have more have to do with windows as objects, as part of the window manager thing, rather than the "binary application" thing. > + show an icon like the ones you proposed? Yes. I advocate the default binary icon Nautilus shows to be used as linked above. http://www.gnomefiles.org/shots/generic.gif > + show an ugly icon? I don't find the default Nautilus binary icon ugly. It's just generic. As it should be.
We definitely should show something-- the old Sun usability study mentions this-- the inconsistency of icon/no icon made for some confusion in 1.x... several users got the impression that the icon somehow indicated whether the program was running or not. I think the binary icon for most people represents something more equivalent to a "binary file" that you manage, as opposed to an "application" that you run. The current UNIXian filesystem unfortunately doesn't encourage a conceptual link between the two. (I'd love for this to change, but that's way, way out of the current scope of discussion) The empty window icon, however, seems to represent a generic "window"-- and I think it's a reasonable assumption that any menu entry, unless custom-crafted by the user, will open a window.
FWIW, bug 156635 contains some gnome-window icons we might want to use here.
Can we apply the patch? It's been used in Debian and Ubuntu since at least March 2008.
Except that last time I heard from the GNOME usability team: they preferred to have no icon at all :-)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.