For example: I have my own definition (see screenshot) of file type "*.old" for kwrite with command "kwrite %u". The files on "sftp://.../x.old" are opened from a local directory "~/.cache/kioexec/.." (and are not stored remotely on ctrl-s!!!). If I use the right-click option "open with" and type "kwrite %u" it works like expected. Reproducible: Always
Created attachment 96784 [details] Showing my *.old file configuration
Thanks for the bug report. Dolphin uses KRun from KIO to open files (Dolphin itself is entirely unaware of what application and what command line arguments are used when you open a file), so I'll reassign.
Is this still an issue with KDE Frameworks 5.49? How are you opening the files in the first place? Are you opening them from the "sftp://.." path with Dolphin or the file dialog, or directly from "~/.cache/kioexec/.."?
This is still an issue. With some file-extensions it works like expected, but with others like ".old" or ".jsp" it does not work. I open them from dolphin (dolphin shows the sftp://user@domain/... path). When I open a file in kwrite, kwrite should show (you can make kwrite show the complete path in the title-bar) "sftp://..." and not "~/.cache/..". Also saving does not work in the last case.
When I manually open the right-click-submenu "open-with.." and type there "kwrite %u" it always works like expected, but this is too complicated, and often forgotten.
KRun ends up in KToolInvocation::startServiceByDesktopPath("/home/dfaure/.local/share/applications/kwrite-2.desktop"), so the problem is in klauncher (KLauncher::createArgs). Ah, I found it. KIO::DesktopExecParser::resultingArguments looks at which protocols the application supports. Since there's no X-KDE-Protocols entry in that desktop file (and no Categories=KDE either), we have to assume that sftp isn't supported (as we do with, say, LibreOffice or Firefox or whatever). The never-ending problems of locally-created .desktop files.... I think that when associating an existing app with a new mimetype, we need to copy over the existing desktop file, not just create one from scratch. Alternatively, or in addition, we could have a GUI for setting the supported protocols thing, but that's a bit too manual I guess. Short-term workaround: add X-KDE-Protocols=KIO to your local .desktop file for kwrite.
Thanks, I'll try that, and I'm glad to have a workaround for now.
> (and are not stored remotely on ctrl-s!!!) If KWrite performs atomic saves, this is Bug 397742, which should be fixed with https://phabricator.kde.org/D15180 > I think that when associating an existing app with a new mimetype, > we need to copy over the existing desktop file, not just create one > from scratch. That sounds like a sensible solution to me. Let's keep thie bug report open to track that.