Correctly handle executable names typed into KOpenWithDialog
Review Request #111272 - Created June 27, 2013 and submitted
The attached patch addresses a bug where a user enters the name of a KDE application in OpenWith dialog to open a remote file and the file is opened as if the user requested to open it with a non KDE application. That is a local copy of the file is created first. Currently this problem can be reproduced with kate because the "Exec=" line in its desktop file contains an additional option, "-b". Note that this patch only addresses the specific condition where the user only typed in the KDE executable name. Other scenarios, like the user typing in not only the name of the KDE app but also additional command line options, will still produce this same issue.
Try to open a remote text or source file by typing "kate" in the open with dialog.
This will create further trouble, I would say. What if an application installs several .desktop files, like: kmail --attach %U kmail --view %U kmail --check kmail --erase-my-harddisk By typing "kmail" in the open-with dialog, you would now randomly pick any of these? That doesn't sound like it will do what one would expect. Either we can "kmail %U" (directly or via a .desktop file), or we can't, but we certainly shouldn't take any existing .desktop file with any sort of stuff in the Exec line.
How about a setExec() method rather than a special constructor? This seems a lot clearer to me (and e.g. easier to grep for in order to find usages, etc.). But anyway, I have my doubts that this really works: returning a KService that isn't exactly like the one in ksycoca seems fragile to me. E.g. when krun uses that service, it will call KToolInvocation with the entry path to the service - i.e. just the path to the desktop file. The modified Exec field (in memory) won't be used in that case. What KRun can do, though, is work with a "temp" kservice, created like this: KService::Ptr service(new KService(_name, _exec, _icon)); This is detected as "not in ksycoca" and therefore not given to KToolInvocation (but to runTempService). I think this would recreate the issue you saw though, since indeed nowadays it's not enough to have %U in the exec line, one must also have Categories or X-KDE-Protocols indicating that KIO protocols are supported. But this could be copied from the orig file, using a new setter in KService. Hmm. Maybe it would be simpler to just clear entryPath() in the KService::setExec() I'm suggesting initially. i.e.: if we're modifying the KService then the path to the file that has been cached in ksycoca, no longer applies. And then KRun will go to runTempService, when running it.
this comment should move with the code that it affected
Review request changed
Updated the previous iteration of the patch to - Remove the entryPath() from the custom KService we create so as not to confuse KRun. - If the typed executable does not contain a %U or %F, but the matching service does, append those options so that KRun won't end up using kioexec.
Revision 3 (+57 -6)