=== yofel_ is now known as yofel === bdrung_ is now known as bdrung [20:00] chrisccoulson, the http:// link bug in evo is back. weird [20:00] fta - that doesn't surprise me, i'm not sure why it worked in the first place ;) [20:01] it should be completely broken at the moment because of the glib change [20:23] *sigh* [21:14] fta - you can fix it by adding x-scheme-handler/http and x-scheme-handler/https to the Mimetype entry in the desktop file for chromium [21:14] and then running update-desktop-database [21:15] (if you've not done that already) [21:15] i shall be doing the same for firefox in the next upload [21:15] (and tbird) [21:18] i guess we'll need to update desktop-file-utils this week to add the default handlers [21:36] chrisccoulson, is it a fix or a temporary workaround? [21:37] fta - that's the fix (to add the x-scheme-handler types to the desktop file) [21:38] chrisccoulson, hmm, so to fix evo, i need to tweak chromium?? weird [21:39] fta - yeah. all applications which ship desktop files are responsible for indicating to the system which types they handle [21:39] this has always been the case for content types, but protocol's were previously handled via a different mechanism [21:39] (which has now been removed) [21:40] the problem is there are no applications on your system that are registered to handle http:// URI's, which is why evo fails to open the links in your browser [21:40] previously, it just looked up the handler in gconf [21:40] ok, i see [21:41] this also breaks the default browser check :/ [21:41] so i must add those 2 handlers in MimeType? [21:41] yeah, that will fix it [21:42] if you're manually editing the desktop file installed on your system, you'll need to run update-desktop-database too [21:42] but that normally happens automatically on package installs [21:42] i hope it won't hurt backports [21:42] it's fine, it will be ignored there [21:45] committed