- User Since
- Mar 5 2015, 12:44 PM (273 w, 3 d)
Sat, May 30
Fri, May 29
I have modified DesktopExecParser in kio commit d1e9325fba37eddb9cb44173edfc1fee122a0c57 to return an error string so that its users don't need to do the work again of figuring out what went wrong (see DesktopExecParser::errorMessage()).
I just realized that this would be very useful here as well. AFAICS the current patch only works if the user types a full path, not with a relative path.
Please check that kfileplacesmodeltest and kfileplacesviewtest still pass.
Can you explain how to trigger this crash in the first place? Which application triggers it?
Wed, May 27
I'm a bit confused by the bug this is fixing. Surely this doesn't happen to all cases of crashes without autorestart enabled??
Makes sense; just two minor things.
Tue, May 26
Mon, May 25
Sat, May 23
Fri, May 22
Thu, May 21
add missing braces
They are used. But indeed I don't actually need that to fix my use case. I thought proper cascading was better than just fixing my use case?
Wed, May 20
Tue, May 19
adjust commit log
Mon, May 18
Sun, May 17
(Intrusive) fix is up at https://invent.kde.org/frameworks/kio/-/merge_requests/3
KServiceFactory::findServiceByStorageId falls back to "new KService" if it can't find the storageId in ksycoca. So yes it worked, but it's kind of pointless (and confusing) to call it just to go to the new KService fallback, better do that directly.
Well spotted. Indeed, when using kioexec (because of the DeleteTemporaryFiles option) we no longer detect non-existing executables. I'll look into fixing this.
Yeah, the full story is that I pushed to git.kde.org, reverted because I changed my mind, then the sysadmins told me I wasn't supposed to push to git.kde.org at all (it was blocked for everyone, but I have sysadmin privileges for historical and bus-factor reasons). We realized there was nothing to sync to gitlab anyway, since I had simply done push+push+revert+revert.
Not committed after all.
Sat, May 16
Thanks for the unittest and fix!
OK, I picked testtrash because kio_trash *is* a :local protocol. If it doesn't use UDS_LOCAL_PATH, at least it means the job will actually go through (no early filtering out). That's at least interesting to test too.