exo-file-manager.desktop breaks file opening in non-XFCE DEs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Exo |
Fix Released
|
Medium
|
||
| exo (Mandriva) |
Unknown
|
Unknown
|
||
| exo (Ubuntu) |
Undecided
|
Unassigned |
Bug Description
When exo-utils is installed on a system that is also running Gnome, the mime type entries in exo-file-
This has been reported upstream (https:/
To reproduce, log in with Gnome on a system that also has Xfce installed, and do:
xdg-open /some/file.pdf
With that fix, I imagine that newer versions than the 0.6.0-1 in Natty are likely fixed. It'd be nice to have this patch backported to Natty, though. My university only updates to spring releases, and I'd like the fix.
|
#8 |
Let Gnome users complain at bugzilla.gnome.org. They removed the on place we could influence the behaviour of gio in a decent way. So instead, knowing this would make things harder for not-fully-Xfce users, I choose to make it work for us.
Make exo-open could be a bit more intelligent, if so, I can fix that, but if Gnome decides to not care about others, I fix it the ugly way.
|
#9 |
Another comment from the downstream report:
"One way to solve this for XFCE and other DEs would be (I think) having an
exo-file-
x-scheme-
the call to "exo-open --launch FileManager ..." if running under XFCE or plain
"exo-open ..." if not. I checked that the latter indeed calls the appropriate
application.
Another way could be to find out if XFCE needs to have "MimeType:
x-scheme-
|
#10 |
(In reply to comment #1)
> Let Gnome users complain at bugzilla.gnome.org. They removed the on place we
> could influence the behaviour of gio in a decent way. So instead, knowing this
> would make things harder for not-fully-Xfce users, I choose to make it work for
> us.
Could you please point me to the discussion so that we can find out the requirements?
> Make exo-open could be a bit more intelligent, if so, I can fix that, but if
> Gnome decides to not care about others, I fix it the ugly way.
I'm not aware of what exactly exo-open does, but the x-scheme-handler takes priority on search - how do you handle finding the appropriate application for the given type, avoiding hitting the scheme handler?
|
#11 |
There was a suggestion to replace "x-scheme-
|
#13 |
Dropped the mime-types for all the exo-open desktop files in 2e3744b. We only use this for menus and stuff, should not be used for opening files in thunar etc.
Changed in exo (Ubuntu): | |
status: | New → Fix Released |
Changed in exo (Ubuntu Natty): | |
status: | New → Confirmed |
Alad Wenter (the-changing-side) wrote : | #1 |
Looks like this bug wasn't fixed, or at least reintroduced. Still present in Trusty. It also has the side effect of showing "File Manager" in every file's "Open With" menu.
In Xubuntu:
/usr/share/
MimeType=
/usr/share/
x-scheme-
~/.local/
x-scheme-
tags: |
added: trusty removed: fixed-upstream |
tags: | added: natty |
Alad Wenter (the-changing-side) wrote : | #2 |
edit: /usr/share/
Alad Wenter (the-changing-side) wrote : | #3 |
Fixed in this PPA for Trusty:
Changed in exo (Ubuntu): | |
status: | Fix Released → Triaged |
|
#14 |
Please re-open.
This bug was re-introduced later, see the log:
http://
It looks like the suggestion from Tomas works:
> There was a suggestion to replace "x-scheme-
diff --git i/exo-open/
index 3d7653e..8d0a6cf 100644
--- i/exo-open/
+++ w/exo-open/
@@ -7,6 +7,6 @@ StartupNotify=true
Terminal=false
Categories=
OnlyShowIn=XFCE;
-X-XFCE-
+X-XFCE-
_Name=File Manager
_Comment=Browse the file system
(for reference, the bug in Launchpad/Ubuntu: https:/
Daniel Hahler (blueyed) wrote : | #4 |
It got initially "fixed" by removing the mime-typed, but changed later again:
http://
I have asked in the upstream report to please re-open and fix it.
Daniel Hahler (blueyed) wrote : | #5 |
For reference: https:/
https:/
I have proposed it upstream at:
https:/
I will upload a fixed package later for utopic, and we could have a backport for Trusty then.
It would be nice it somebody could help with the SRU process:
https:/
Daniel Hahler (blueyed) wrote : | #6 |
I have uploaded the package from Alad, which contained another fix.
Thanks!
Changed in exo: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
Changed in exo (Ubuntu): | |
status: | Triaged → Fix Released |
no longer affects: | exo (Ubuntu Natty) |
Daniel Hahler (blueyed) wrote : | #15 |
If you are still affected with the fixed package in place, see http://
I still had the buggy line in my local configuration:
% grep exo ~/.local/
x-scheme-
x-scheme-
Removing the `x-scheme-
|
#16 |
Nick or Jannis, could someone take a look at the last patch and maybe commit it if it sounds sane?
|
#18 |
Reopening to get it back on the radar.
|
#19 |
The patch is sane and sufficient to me, applied at http://
Daniel Hahler (blueyed) wrote : | #17 |
Darin (newhoa) wrote : | #20 |
I didn't have this problem in Zesty but since updating to Artful a few days ago this is a problem. I installed Nautilus on Xubuntu (uninstalled Thunar), and Nautilus opens files with itself until I uninstall exo-utils. Once I uninstall exo-utils Nautilus behaves as it should.
|
#21 |
possible duplicate: https:/
can someone please confirm?
From downstream report:
https:/ /bugzilla. redhat. com/show_ bug.cgi? id=674321
Basically exo causes problems for other desktops by setting up these mime types.
From the report:
--cut-- handler/ file=exo- file-manager. desktop" record share/applicati ons/mimeapps. list file. This seriously messed up
Something has added a "x-scheme-
in my ~/.local/
overall functionality of gvfs-open (called through xdg-open). I only get a "The
location is not a folder" error (coming from Nautilus probably).
g_file_ query_default_ handler( ) is correct in this case and behaves according to
settings.
So my question is, why exo-file- manager. desktop contains this scheme handler in handler/ trash.
a first case? Same situation with x-scheme-
As long as /usr/share/ applications/ mimeinfo. cache is composed from available
desktop files, this borked overall system functionality.
Version-Release number of selected component (if applicable): 0-1.fc15. x86_64
exo-0.6.
How reproducible:
always
Steps to Reproduce: handler/ file picked up before application/pdf
1. install exo
2. gvfs-open /tmp/file.pdf
3. see a x-scheme-
--cut--
So, things work fine for Xfce users, but people who switch desktops or normally run gnome or the like are getting messed up. ;(
Not sure what the solution might be.