----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111272/#review35416 -----------------------------------------------------------
kdecore/services/kservice.h <http://git.reviewboard.kde.org/r/111272/#comment25945> 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. kio/kfile/kopenwithdialog.cpp <http://git.reviewboard.kde.org/r/111272/#comment25944> this comment should move with the code that it affected - David Faure On July 2, 2013, 2:41 a.m., Dawit Alemayehu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/111272/ > ----------------------------------------------------------- > > (Updated July 2, 2013, 2:41 a.m.) > > > Review request for kdelibs and David Faure. > > > Description > ------- > > 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. > > > This addresses bug 222519. > http://bugs.kde.org/show_bug.cgi?id=222519 > > > Diffs > ----- > > kdecore/services/kservice.h 3843bad > kdecore/services/kservice.cpp e2cc86f > kio/kfile/kopenwithdialog.cpp 84465cd > > Diff: http://git.reviewboard.kde.org/r/111272/diff/ > > > Testing > ------- > > Try to open a remote text or source file by typing "kate" in the open with > dialog. > > > Thanks, > > Dawit Alemayehu > >
