Relocate inode/directory association; use Files context menu #857
Conversation
|
I don't know what I'm doing with meson. I think this should be an easy patch-in but I don't know what's triggering meson to attempt to overwrite the config target. Help? Edit: this got resolved, btw. |
Use a separate .desktop to handle inode/directory for Code--the same way Terminal does this. Other programs should not interfere with Files' (or user's configured file browser) ownership of inode/directory. This causes problems, like Plank's Trash Can opening the trash directory in the wrong program. When right clicking a folder in Files, the "Open in..." context menu will direct users to Code.
|
I am not entirely sure this is the root cause of the original issue - it should be possible to have multiple applications able to accept the same mimetype (e.g. inode/directory) without them conflicting. You just have one set to the default for that mimetype. For example I have more than one filemanager installed but Files is the default and this opens unless I specifically use another one. I do not get the original problem with the the dock Trash can opening in Code anyway. |
|
I cannot seem to trigger the dock Trash problem even if I edit my |
|
The problem is not with
Edit again:
Edit: Unfortunately it may not be as simple as that, because there are many possible override files. I have no setting for This issue is 100% reproducible, but you have quite a few apps handling Edit: It has been proven, conclusively, that the reason this issue does not occur in elementary OS is that the session-settings package provides an override. Anyone attempting to use Code in another distribution or desktop environment is likely to be affected. begin rant: In the bigger picture, the freedesktop mime handling model is an extremely fragile piece of poorly understood filigree. There are several different files serving the same purpose and overriding each other in scarcely documented ways, deprecated files (like The most robust solution would be to deprecate everything other than :end rant |
|
The freedesktop documentation states:
https://specifications.freedesktop.org/desktop-entry-spec/0.9.5/ar01s07.html However, my findings are that it lists them in alphanumerical order, giving priority to the first in the list. Neither behavior is conducive to a consistent workflow with multiple applications handling the same mime type. |
|
@jeremypw What you did there was the right thing to do: separate folder handling into its own .desktop with a name that orders alphanumerically after Files. You should really do the same with Code, trust me. I can't be sure why you were unable to reproduce the issue on your system, but my guess is that you have defaults specified in multiple places, overriding the changes you made. There are about a half dozen files in which these defaults could be specified, some shipped with elementary OS and others you may have (inadvertently) created. |
|
I think that the Terminal solution does not (now) suffer this problem is probably fortuitous - I think that at the time, the Terminal desktop file was named |
|
Have you checked what (if any) current legitimate use is made of the |
Out of interest, what is your $XDG_DATA_DIRS ? Mine is `/usr/share/gnome:/usr/share/pantheon:/home/jeremy/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share:/var/lib/snapd/desktop I still feel we are not dealing with the root cause here. Relying on the sort order of the names of desktop files feels at best a hack You may well be right that the mime-handling model is flawed but there is no evidence at present that the issue is widespread and not a quirk of your particular set up. |
There was a problem hiding this comment.
This change interferes with the ability to launch Code with a directory as a parameter, which it opens as a project folder. This is because your new desktop file simply launches the same commandline as the original - but Code no longer is associated with inode/directory so the parameter is ignored.
The way Terminal does it is to have a commandline option to open a directory and this is used in the "open --- here" desktop file.
You could do the same with Code but as mentioned previously I am not convinced the issue is systemic.
That is not the case. Here's a video to prove that it is not the case. Here's another video illustrating the initial problem. I am certain the reason you have not yet reproduced this issue is that you have overrides somewhere other than I note that session-settings now ships an overrides file (probably installed to I do not have overrides for The issue is systemic: Code's application .desktop holding the Whichever application is listed first on that line is what opens Plank's trash can, ergo the order of applications listed on each line of this file is meaningful: the first one is the system's default association (unless you have overrides somewhere). The solution is to move the |
|
My comments are based on running this PR on an up to date copy of Odin in a VM (Virtual Box) - I have not modified the original install. @tintou What is your opinion? |
I think this means elementary OS comes with overrides, at least The 'quirk' of my setup, in this respect, is likely that it is exceedingly default. |
|
@davidmhewitt I would value your opinion on this - is it a real issue and is this fix appropriate? |
|
Converting to draft as it needs further work before reviewing. @quequotion If you are not still working on this maybe consider closing it? |
I am still very much advocating for this. The only issue here is what we should name the separate, hidden shortcut that handles the inode/directory association. I followed your example in Terminal, and named it As has been pointed out, the limitation of that is if someone is using a file manager with a shortcut name that would list alphanumerically after 'open'. This is a fundamental flaw in how everyone implements the freedesktop design: we ought to be prepending '.desktop' shortcut names with priority numbers, just like udev rules and other config files use. Another way to handle this would be to prepend the hidden shortcut's name with a character that would ensure it lists alphanumerically last, but it's not pretty: Whichever solution you prefer, by the way, needs to be applied to Terminal's hidden shortcut as well. In any case, as I said before, instead of closing this, append it to the Distro-agnostic Pantheon project. This issue affects anyone who attempts to use Code without the session-settings package. Edit: It's been a while since I read through the whole discussion. I had forgotten @davidmhewitt wanted a comment in the meson file explaining this; should be easy to add when I get a moment. |
Fully explain the need to do this (the same thing that was done for Terminal). Since other distributions and desktop environments cannot be relied on to provide overrides that ensure a specific file manager gets priority for the inode/directory association, Code must attempt to avoid making itself the default handler.
|
As there does seem to be an official project to make pantheon apps distro-agnostic I am not averse to merging this although it is not required for ElementaryOS assuming no regressions/adverse side-effects in Elementary, subject to @davidmhewitt 's approval. |
There was a problem hiding this comment.
This new file needs adding to po/extra/POTFILES https://github.com/elementary/code/blob/master/po/extra/POTFILES
That isn't gonna work with flatpak, flatpak requires that exported .desktop files have the app-id as prefix, so it would need to be
Well, that already get any flatpak that starts with i believe this issue in GLib is what we want. |
|
Will the distro-agnostic project continue to support distros/users that do not use the flatpak'd version? Even so, failure to work under Flatpak is another reason not to merge this but wait for the upstream fix. |
|
How is this being handled in Terminal, which is still using open-pantheon-terminal-here.desktop? Is Terminal available as a flatpak? The report @Marukesu has linked is, like my ranting in this one, a proposal to change the standard by adding priority numbers to .desktop shortcuts (using a new field rather than alternative filenames). I am all for that, but curious how long it could take. I've just left a comment there myself and I note the previous one was two years ago. |
|
There are no plans as far as I am aware to Flatpak Terminal (or Files). I don't think either would work properly in a sandbox. |
|
I got in touch with @dfaure-kdab as suggested in the report linked by @Marukesu. Unfortunately, extending the .desktop file standard with the I plan to look up that discussion and see if I can't revive it, but I am not going to hold my breath for this solution. Edit: Found it. See "New |
|
I think this can be closed now as there appears little prospect of progress without external changes. |
Fixes #856 .
Don't interfere with Files' ownership of inode/directory, use its context menu for this task (opening folders in various applications, like Code).
Plank's Trash can is not the only thing that unexpectedly opens in Code. I've tested a few other applications, such as Transmission, which opens a directory when a user attempts to open an incomplete download.
The problem appears to be that
update-desktop-databaselists associated.desktopshortcuts for a particular mimetype in alphanumerical order by their filenames inmimeinfo.cache, thereforeio.elementary.code.desktopcomes beforeio.elementary.files.desktop.Another elementary OS application that opens folders, Terminal, avoids a conflict by having a separate, hidden shortcut named
open-pantheon-terminal-here.desktopwhich handles the inode/directory association. Accordingly, I have made one for code calledopen-pantheon-code-here.desktop.