D23384: [WIP] Adding support for mounting KIOFuse URLs for applications that don't use KIO

[Alexander Saoutkin]

feverfew added inline comments.

INLINE COMMENTS

> dfaure wrote in desktopexecparser.cpp:323
> Could we have a kill switch for KIOFuse if it fails to work properly in some release?
> 
> E.g. some `export KIO_FUSE=0` or `export KIO_FUSE_DISABLE=1`.
> Or a KConfig entry (use `KSharedConfig::openConfig()->group("KIO")` for best performance and flexibility -- then it can be disabled for one calling application or for all)

One can always remove/uninstall kiofuse if it doesn't work or if they don't really want the feature?

> dfaure wrote in desktopexecparser.cpp:331
> The comment says "in case there is a password", the code doesn't.
> Probably historical, please fix :)
> 
> On this topic I saw earlier comments in the merge request which I found confusing.
> It's very rare for an application to have the password stored inside the URL itself. That would mean the user typing it in clear in a location bar or in a terminal, bad idea. Instead, the user typically types a URL like ftp://user@host/ and the kioslave asks for the password, and stores it in kpasswdserver.
> 
> Also you wrote "we strip out the stuff that's in userInfo()". (where QUrl::userInfo is username+password). But surely, while we might strip out passwords for security reasons, we never strip out the username, do we?

From what others have tested `userInfo()` is always empty even when the URL is actually a protected Samba share... This means I can't know if a certain URL is likely to have a password or not, I just have to assume it does. I'll check again just in case, as indeed it does seem odd, but that was my conclusion.

> broulik wrote in desktopexecparser.cpp:356
> Blocking IO is worse than blocking DBus, still not nice, especially given the "job"-like nature of `KRun` I would expect it to be fully async.

In these methods I have to return the URLs within the function, so blocking is inevitable. If I could return the URLs via a signal then blocking could be avoided.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D23384

To: feverfew, fvogt, davidedmundson, dfaure, ngraham
Cc: alexde, broulik, sitter, davidedmundson, kde-frameworks-devel, ngraham, LeGast00n, GB_2, michaelh, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191212/6bca7480/attachment.html>