GNOME Bugzilla – Bug 627733
Opera entry has no icon in dropdown list of browsers
Last modified: 2010-10-05 15:18:47 UTC
Created attachment 168561 [details] [review] patch to fix this issue How to reproduce: 1. Install opera (either stable version: or development snapshot: ) 2. Open 'Preferred Applications' -> 'Internet' 3. Select Opera as default browser. Expected: Opera entry should have icon. Result: Icon is missing. -- comment from patch: Starting with Opera 10.60 opera is shipping more icons, thus main opera icon was renamed to avoid ambiguity. Without this change, browser list for choosing "default browser" is missing opera icon.
This change also applies to every gnome version after 2.28. Sorry, I forgot to paste urls: 1. Install opera (either stable version: http://www.opera.com/ or development snapshot: http://my.opera.com/desktopteam/blog/ )
It's up to Opera to install its own information about it. The Fedora Chromium packages already do that, for example: $ cat /usr/share/gnome-control-center/default-apps/chromium-browser.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE default-apps SYSTEM "gnome-da-list.dtd"> <default-apps> <web-browsers> <web-browser> <name>Chromium</name> <executable>chromium-browser</executable> <command>chromium-browser %s</command> <icon-name>chromium-browser</icon-name> <run-in-terminal>false</run-in-terminal> <netscape-remote>true</netscape-remote> <tab-command>false</tab-command> <win-command>false</win-command> </web-browser> </web-browsers> </default-apps>
Sorry, but no, this is not good solution. 1) If we did this, two different opera entries will appear - one without icon (supplied by gnome-control-center) and one with icon (supplied by opera); you may count this as separate bug if you like 2) this file in opera package will make opera dependent on gnome (because if opera were installed before gnome-control-center, it would own /usr/share/gnome-control-center directory - it may block user from installing gnome-control-center or corrupt his os installation 3) there is no clear way of handling list of installed browsers specified by freedesktop.org Mainly because of 2) we (as we - Opera unix team ;) ) are not going to do that. And chromium shouldn't do that also. Take a look at supplied patch, it's really trivial change :) Changed status back to "unconfirmed".
(In reply to comment #3) > Sorry, but no, this is not good solution. > > 1) If we did this, two different opera entries will appear - one without icon > (supplied by gnome-control-center) And we wouldn't be able to ship the icon anyway, for copyright reasons. > and one with icon (supplied by opera); you > may count this as separate bug if you like I'll remove Opera from the default list of browsers now. > 2) this file in opera package will make opera dependent on gnome (because if > opera were installed before gnome-control-center, it would own > /usr/share/gnome-control-center directory - it may block user from installing > gnome-control-center or corrupt his os installation That's bogus, and a package problem in any case (FWIW, we had the same problem with gtk-doc directory ownership, and looks something like that: http://pkgs.fedoraproject.org/gitweb/?p=gnome-keyring.git;a=commitdiff;h=037e1dca44805eceaf4e6c5e51dc91286bdbaa86 ) > 3) there is no clear way of handling list of installed browsers specified by > freedesktop.org It's not Freedesktop, but if you want to integrate into GNOME, adding a single file isn't that much trouble. > Mainly because of 2) we (as we - Opera unix team ;) ) are not going to do that. 2) is a red herring, and I'm sure you can work-around that, at least for RPM. > And chromium shouldn't do that also. Why not, we added the ability to drop those files in just so that you could extend it. > Take a look at supplied patch, it's really > trivial change :) > > Changed status back to "unconfirmed". commit b1250e03d6d4d09affbbf0326d90c913c149104d Author: Bastien Nocera <hadess@hadess.net> Date: Thu Sep 23 18:45:42 2010 +0100 Remove Opera from default browser choices Not free, and we can't ship the icon for copyright reasons. https://bugzilla.gnome.org/show_bug.cgi?id=627733
What, why you did that? I never asked you to ship opera icon, only to change already existing configuration entry, even sent you one-liner patch :( Have you read it? There are no "copyright reasons" in this case, revert that commit, please. You are just introducing bug for current gnome opera users this way. > That's bogus, and a package problem in any case (FWIW, we had the same problem > with gtk-doc directory ownership, and looks something like that: Thanks, I didn't know that rpm could handle multiple ownership of directories, I will look if it's not a problem for dpkg either. Still, creating gnome-specific file for users, that don't use gnome is sloppy, we would really, really prefer not to do that. > Why not, we added the ability to drop those files in just so that you could > extend it. How about implementing better solution? e.g. detecting installed browsers by reading .desktop files? Everything browser packagers would have to do is adding X-GNOME-BROWSER (or similar) tag in desktop file - and in turn, distributions wouldn't have to patch your gnome-control-center configuration files with translations. Last commit introduced bug for all users of gnome and opera <= 10.63, reopening.
Do we have a place (live.g.o or library.g.o) where 3rd part vendors can read about this feature and learn how to write and intall proper XML file? It's not fair remove stuff and don't warn developers/authors about how to re-include them :) Patryk, do you think the same file ownership issue will apply to DEB packages?
(In reply to comment #5) > What, why you did that? I never asked you to ship opera icon, only to change > already existing configuration entry, even sent you one-liner patch :( Have you > read it? Was a bit arse-hatty of me to just remove the entry, but correct nonetheless. > There are no "copyright reasons" in this case, revert that commit, please. You > are just introducing bug for current gnome opera users this way. That particular code is dead for GNOME 3.x anyway. > > That's bogus, and a package problem in any case (FWIW, we had the same problem > > with gtk-doc directory ownership, and looks something like that: > Thanks, I didn't know that rpm could handle multiple ownership of directories, > I will look if it's not a problem for dpkg either. Still, creating > gnome-specific file for users, that don't use gnome is sloppy, we would really, > really prefer not to do that. Sloppy? Why would you care, the file is a couple of kilobytes, and is package-managed. > > Why not, we added the ability to drop those files in just so that you could > > extend it. > How about implementing better solution? e.g. detecting installed browsers by > reading .desktop files? Everything browser packagers would have to do is adding > X-GNOME-BROWSER (or similar) tag in desktop file - and in turn, distributions > wouldn't have to patch your gnome-control-center configuration files with > translations. We have. See: http://www.hadess.net/2010/10/new-control-center-and-you.html Rodrigo is working on making all applications that handle the x-scheme-handler/http and x-scheme-handler/https mime-types being listed for the default web browser choice. You can even set your browser to be the default one after asking your users, by using FreeDesktop mime-type handling from Qt. > Last commit introduced bug for all users of gnome and opera <= 10.63, > reopening. It introduced no bug whatsoever. Our development is open, and sources available: http://git.gnome.org/browse/gnome-control-center/commit/?id=b1250e03d6d4d09affbbf0326d90c913c149104d That commit was only made on master, which is the target for GNOME 3.0.