Hey, this is a enhancement request, but there might be a need for some more discussion before, because I'm not so sure the issue is completely known and there's no side effects on the solution. Anyway: right know, application selection is done in Xfce through exo-preferred-applications. I'm not completely sure what it does, I guess the exo Gio module is involved, but I'm not sure. Anyway, gvfs-open uses .local/share/applications/defaults.list and look there for some stuff like x-scheme-handler/http etc. Right now this file is not set by exo-preferred-applications, and that means applications using gvfs won't use the correct settings (for example, in my case, on one box I have midori and chromium installed but chromium is the browser I use and the one selected in exo but evolution keeps opening midori). There might be some related bug reports, and it might happens since a recent Glib upgrade, I'm not too sure, thus the request for discussion.
Ok, defaults.list might not be the correct file, it should be mimeapps.list apparently.
The GIO module is obsolete, it is not build anymore with recent GIO versions. Currently we write this to ~/.local/share/applications/mimeapps.list for GIO and this was already implemented in exo-0.5.5.
(In reply to comment #2) > The GIO module is obsolete, it is not build anymore with recent GIO versions. Ha yes, sorry for that. > > Currently we write this to ~/.local/share/applications/mimeapps.list for GIO > and this was already implemented in exo-0.5.5. Hmmh, and it seems to not work here. What I have in mimeapps.list is: text/html=chromium.desktop but it seems that recent glib might use x-scheme-handler/http. Re-configuring the default browser in exo-pref-apps adds the following lines: x-scheme-handler/http=exo-web-browser.desktop x-scheme-handler/https=exo-web-browser.desktop which seems to do the right thing.
It's a partial solution. The exo-*.desktop files are there for the global menu entries (shared between panel and xfdesktop, used in garcon) and they execute exo-open with arguments. If the preferred application framework is capable of handling desktop files (still on the 4.10 todo), we can also set the 'real' desktop file in mimeapps.list, but for now this is a mid-term solution. So it's not perfect, because startup-notification is not working, but best we can do atm. I think we can close the bug right? I'm aware of the issue, but it's much bigger than this.
(In reply to comment #4) > It's a partial solution. The exo-*.desktop files are there for the global menu > entries (shared between panel and xfdesktop, used in garcon) and they execute > exo-open with arguments. > > If the preferred application framework is capable of handling desktop files > (still on the 4.10 todo), we can also set the 'real' desktop file in > mimeapps.list, but for now this is a mid-term solution. > > So it's not perfect, because startup-notification is not working, but best we > can do atm. > I think we can close the bug right? I'm aware of the issue, but it's much > bigger than this. Yeah, I guess so, sorry for bothering.