GNOME Bugzilla – Bug 500299
wrong icon for extensions manager
Last modified: 2013-05-27 16:09:11 UTC
Please describe the problem: icon used by extension manager is good for preferences/etc. extensions manager icon should puzzle element/etc. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information: There's good icon: http://tango.freedesktop.org/Firefox
-> epiphany-extensions Makes sense to me. Reassigning, and a patch is following.
Created attachment 99982 [details] universal-addon icons Icons to be placed in data/icons.
Created attachment 99983 [details] [review] patch to include icons Patch to include the icons in the Makefile and to have them used by the manager.
You should place 48x48 and SVG in archive too. They're needed.
Ah, there's not 48x48 and scalable. I'll tell jimmac to create them.
Jakub: for what are they needed? The biggest use for this icon I seem to find is in the Alt+Tab switcher, and it's 32x32. I also left the 64x64 one out of this patch, as it seemed of no use to me.
some apps, like compiz or avant-window-navigator [dock] uses higher size, like 48x48. svg are provided by all apps for all window icons. when i'll find jimmac's e-mail address, i will send a request for this size and svg.
You really should be using the epiphany icon for all of epiphany's dialogs, for the window icons. This lets the user know what app the dialog is associated with, if for instance, they have multiple extension manager dialogs open. Having firefox and epiphany use the same window icon would be a bit weird I think. How would you know which is which, from looking at the task bar items?
From the text, Rodney, from the text.
Ekhm, Rodney, Firefox doesn't use this icon as window icon. It used in menu [maybe] and in Addons tabbed manager.
Sorry for monolog... Rodney, if app icon should be used by all app's windows, Epiphany would do it from the beginning. It's mature web browser, so this behavior is correct. A question: if app's windows would use app window, how could i know which window is which (what role is has)?
It's a bug. Epiphany is not without bugs. Epiphany used to have favicons for the window icons. It doesn't any more, because doing so was awful. Almost all favicons are 16x16 only, and they got scaled up and distorted in almost 100% of the cases. Epiphany, as an MDI application, needs to have it's windows use the app icon. If it was a document-centric SDI application, it could use per-document icons. But it's not. Having it use favicons with tabs, wouldn't let you know what content was avaiable in the window anyway. Firefox uses the firefox icon for the add-ons window (which has extensions, themes, and languages in the dialog). This is the correct behavior. Child windows need to be associated with their application. Why is it that only the extensions and preferences dialogs in epiphany have a different icon? All of the preference dialogs for the extensions that i have enabled in epiphany, use the epiphany icon. Those are the epilicious, adblock, and cert manager dialogs. The role of a window is not set by its window icon. In fact, there is no visible way for you to know what a window's role is. That is a property of window management, and the window hierarchy.
(In reply to comment #9) > From the text, Rodney, from the text. > [ Extensions ] [ Extensions ] Which one is epiphany? Which one is opera? Which one is gedit? If they all use the same text and icon, how do you tell them apart?
(In reply to comment #8) > You really should be using the epiphany icon for all of epiphany's dialogs, for > the window icons. This lets the user know what app the dialog is associated > with, if for instance, they have multiple extension manager dialogs open. > Having firefox and epiphany use the same window icon would be a bit weird I > think. How would you know which is which, from looking at the task bar items? (CC-ing Reinout to hear his opinion too). This is a good point but, if we go this way, also our history window and bookmarks editor would not be OK, as they have their unique icon. Also, for instance, Evolution's "New Message" window would not be OK as it has a different icon from Evolution stock one. I think (but am no usability expert, so this is just my own thought) the rule here should be that if the window has a value of his own (e.g. it's useful for the user user to leave it in the background while using the main application) the icon could also be different, as it can be useful to recognize it in the taskbar to do some other action in that window. The Extensions Manager window is quite corner case here...I don't think user has any benefits to leave it in the background, but is also in the taskbar when opened, so I don't know what we should do. @Jakub: could you please post your comments in a single post instead of two or three subsequently posts? Thanks :)
(In reply to comment #14) > This is a good point but, if we go this way, also our history window and > bookmarks editor would not be OK, as they have their unique icon. > Also, for instance, Evolution's "New Message" window would not be OK as it has > a different icon from Evolution stock one. Evolution is certainly nowhere near perfect, and also a very special case, as it is many apps in one. If you create a new message from the calendar view, it shouldn't use the calendar icon for the new message window. That would be odd. In fact, it seems to use the evolution app icon when opening individual message windows, and the new mail icon for new mails, while the main window uses the component's icon. Evolution can get very confusing very quickly, due to its complexity. I don't think we should look to it for usability suggestions. :) > I think (but am no usability expert, so this is just my own thought) the rule > here should be that if the window has a value of his own (e.g. it's useful for > the user user to leave it in the background while using the main application) > the icon could also be different, as it can be useful to recognize it in the > taskbar to do some other action in that window. The Extensions Manager window > is quite corner case here...I don't think user has any benefits to leave it in > the background, but is also in the taskbar when opened, so I don't know what we > should do. I don't think this is a particularly good heuristic to follow. Doing so means you're putting more emphasis on the parts you think would be ok to have open in the background, than the parts the user cares to really interact with. How often does one really open the bookmarks editor or history browser? Not very often. Making them special cases encourages other applications to do the same. And then we would hit the example I made earlier, where multiple apps will have the same window icon and title text, for their windows that provide the same functionality.
Also before you take the icon from firefox, be aware that this is licensed under the mozilla tri-license. So just putting this one into A GPL app is something you don't want to do.
Why not? tri-licence includes relicensing to GPL 2+, so it's fine to take for epiphany.
I agree partly with comment #14, as the Bookmarks editor really is a special case. It can be run standalone, because it is designed as "launching platform" for bookmarked webpages. With regard to History: we hope to integrate history and bookmarks at some point. But for now my advice would be to let the BME have its own icon and bite the bullet about the other window icons, make them the same as Epiphany itself. [off-topic about MDI vs SDI: if you don't use tabs, Epiphany essentially behaves like an SDI app so the favicon-as-window-icon feature isn't really that ugly. If Metacity started supporting window grouping with tabs then presumably we'd have Epiphany drop the MDI like a hot potato.]
Let's use the gnome-web-browser (EPHY_STOCK_EPHY) icon for this dialogue.
I still think it's wrong. Maybe fusion of two icons: logo and package/addons icon as an emblem (same for history, bookmarks) ?
Dies with libpeas port. Setting depends
According to its developer, epiphany-extensions is not under active development anymore. (For reference: https://mail.gnome.org/archives/gnome-i18n/2013-May/msg00035.html and bug 700924.) It is unlikely that there will be any further active development. Closing this report as WONTFIX as part of Bugzilla Housekeeping - Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.