What about "Baloo file search"?

Thanks for the reviews everyone! I'll update the diff and respond to the comments no later than Tuesday

Issues with KIOFuse itself should be opened up as an issue, or as a reply to the MR that is being tested; this differential only concerns communication between the KIOFuse mount and KIO itself.

don't send http(s) to kioexec

So before this patch we had the following behaviour:

ignore scheme handler

In D23384#571358, @fvogt wrote:

In D23384#571276, @ngraham wrote:

I'm afraid that even with that change, the issue is still present. I honestly don't think it would be the worst thing in the world if we always handed the kio-fuse paths to apps that don't use ioslaves.

It would be. I like to have links like http://kde.org opened properly in the web browser, ftp://some/where opened in an FTP client and so on...
Media players know more about the format and streaming it than kio-fuse ever could, so avoiding layers in between if possible is definitely an advantage.

Convert KIO URLs to KIOFuse URL is app is not KIO-enabled.

Chek for userInfo instead of just password

Check for password instead of authority

In D23384#570347, @ngraham wrote:

In D23384#570119, @feverfew wrote:

In D23384#570016, @ngraham wrote:

In D23384#569929, @feverfew wrote:

This isn't reaching KIOFuse at all. I believe this is related to this bug and that you've also blogged about:
https://bugs.kde.org/show_bug.cgi?id=330192
https://pointieststick.com/2018/01/17/videos-on-samba-shares/

This can be solved in this patch (and I did, although I removed it at Harald's request). I think I'll move it back in, and will leave it if it does solve this issue for you.

Great! Once it's back in, I'll re-test that.

Updated the diff. give it a go...
Also I assume that if it does work for you it resolves 330192?

Yay case #1 is fixed now! VLC and SMPlayer still unnecessarily download the URL locally like Totem does, but the large video file does at least open now when accesses from the non-FUSE location in Dolphin.

This seems like the best solution. From what I understand, not sending the credentials is a security feature, so doing it via KIOFuse is unavoidable

In D23384#570349, @ngraham wrote:

In D23384#570125, @dfaure wrote:

@ngraham AFAIK gnome has a trick where a fuse mount is created, its path is passed to the application being started, and the application, if it supports gvfs, re-translates that into a URL and uses that instead if it makes more sense. This way "dumb" apps get a local file (with all the limitations of doing synchronous I/O over the network) and network-transparent applications use URLs.
On the other hand, the KDE logic is "if the app takes %f and not %u in the Exec line, it doesn't support remote URLs, so we need to download the file first" (that's done by kioexec). If you see a "download first" check if kioexec is running. But if it's the app doing it, then I have no idea.

kioexec is not running during any of these lengthy downloads. Totem, VLC, and SMplayer all have %U in their desktop files, FWIW.

We may want to rethink this logic anyway. Any app that doesn't integrate with ioslaves should get the FUSE path rather than a locally-downloaded file, irrespective of whether or not its desktop file has %f or %u IMO. There are just too many disadvantages to the locally downloaded file approach, which is why we're doing this FUSE thing in the first place.

Perhaps the "lengthy local download first" issue is caused by not having https://invent.kde.org/kde/kio-fuse/merge_requests/2 yet.

In D23384#570016, @ngraham wrote:

In D23384#569929, @feverfew wrote:

This isn't reaching KIOFuse at all. I believe this is related to this bug and that you've also blogged about:
https://bugs.kde.org/show_bug.cgi?id=330192
https://pointieststick.com/2018/01/17/videos-on-samba-shares/

This can be solved in this patch (and I did, although I removed it at Harald's request). I think I'll move it back in, and will leave it if it does solve this issue for you.

Great! Once it's back in, I'll re-test that.

Updated the diff. give it a go...

You must be doing something wrong. FUSE provides output of all calls that it receives (and how kio-fuse responds). Let me write the instructions more verbosely for CLI to make sure no steps are missed:
$ killall kio-fuse
$ export QT_LOGGING_RULES="*.debug=true"
$ kio-fuse $myFavLocation -d &> ~/kio-fuse-debug.txt (I recommend $myFabLocation isn't empty if you haven't installed the kio-fuse-tmpfiles.conf exclusion file at the system level.)

Then open the file in the media player. Once your done simply attach ~/kio-fuse-debug.txt here.
It's really important for us to know what kind of read requests are being called to help us diagnose the issue.

I think I found part of the problem. When I follow these instructions, the log file has only a single line:

kio-fuse: command not found

This is because the path it is installed to (~/kde/usr/lib64/libexec/) is not in $PATH. When I add that location to $PATH and try again, the log file contains the following:

It should probably not assume that <prefix>/usr/lib64/libexec/ is in $PATH, at the minimum.

That's just an annoying issue locally, which is resolved by that hack. On the system level this won't be a problem at all.

• Get rid of unnecessary copying of URLs
• Switch to interface generated at compile time
• Delete unused interfaces
• Merge branch 'master' into arcpatch-D23384
• remove kiofuseinterface from build
• Align arguments
• Only send original URLs to non-KIO apps if authority is empty

In D23384#569926, @ngraham wrote:

In D23384#569645, @fvogt wrote:

Issue #1:

That happens because the .desktop file sets X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb:
https://code.videolan.org/videolan/vlc/blob/master/share/vlc.desktop.in#L124

I'm not sure about that. If I remove that line from VLC's installed desktop file, the problem still happens. And SMPlayer exhibits the same problem yet its desktop file doesn't define X-KDE-Protocols at all: https://sourceforge.net/p/smplayer/code/HEAD/tree/smplayer/trunk/smplayer.desktop

• Align arguments

• Get rid of unnecessary copying of URLs
• Switch to interface generated at compile time
• Delete unused interfaces
• Merge branch 'master' into arcpatch-D23384
• remove kiofuseinterface from build

• Align function arguments
• Remove hack
• Get rid of iterator

@dfaure Just to give you a bit of context. KIOFuse is about to enter KDE Review, but at the same time, KIOFuse is most useful when integrated to KIO via this patch. So we'd like to get this reviewed early to save a bit of effort; instead of getting it passed KDE Review and then having to wait for approval for this patch, we'd like to do both concurrently, and simply merge this once KIOFuse is officially a KDE project.

Don't use KIOFuse with mtp/gdrive

• Switch from KDED module to DBus service

On Linux appstream URLs don't work for me on Firefox Kubuntu 19.04. Should we really be using them if they're broken?

I won't review, but would like to note I think that with KIOFuse, in conjuction with fio we can do some really complex testing on KIO, correct me if I'm wrong.

@davidedmundson would be happy to work on this. Do you have the URL to the proposal on the mailing list?

There is a BoF on this!

Assuming it's tested LGTM.

In D23672#524727, @elvisangelaccio wrote:

Go for it ;)

Simplifying getIndexByUrl function

@ngraham I believe if you rebase on D23672 then the FIXME is solved. I also believe that dolphinInstanceData() should have an empty QString() in your case. I've tested your patch with an empty QString() and it worked, it might not work with what you currently have...

• Revert "Fixing bugs in new folders in tabs feature"

@ngraham I believe the diff in src/main.cpp may help with the speed issues in D11382. Haven't checked though...

In D23207#520233, @sitter wrote:

Not knowing the background here at a glance I would argue that SlaveBase in KIO should be getting state verification on all of this,.

• Removing flush on write

• Fixing typos
• Adding test for reading of 0 bytes and asserting that the close signal is

actually emitted.

In D23445#518992, @ngraham wrote:

Will do.

I thought all GSoC students needed to have commit access though? Please apply. https://community.kde.org/Infrastructure/Get_a_Developer_Account

In D23445#518985, @ngraham wrote:

Thanks for the quick fix. Stable branch please!

In D21691#518929, @ngraham wrote:

Go ahead, I'm sure you can fix it in no time.

In D22708#516132, @ngraham wrote:

In D22708#516131, @feverfew wrote:

In D22708#516128, @ngraham wrote:

Also feel free to pop by #kde-fm for discussions or if you want to ask a question.

It kicks me out for not having a registered nickname even though I totally do and am using it. If it's not necessary anymore, it might be nice to remove that restriction.

In D22708#516128, @ngraham wrote:

Oh good. :) Is there anywhere I can follow the progress?

In D22708#507449, @ngraham wrote:

What?

Making comments clearer

In D11382#513245, @ngraham wrote:

This is ready for re-review, with one specific thing I could use help debugging: when you enable the new option, launching Dolphin and opening new windows becomes interminably slow, probably due to some extra DBus overhead that's still a bit beyond my comprehension. See the FIXME in the code.

Unnecessary min version upgraded

Addressing comments

Can't test, but looks sane to me. I have a small comment, but can be left for later if time is of the essence.

Also would like to see a push for advertising KDE Apps on Windows and Mac OS, where possible. This will bring us a wider audience, and can even help switch people to Linux.

I also believe T11093 can tie very well with this and T11080. If we brainstorm properly we can standardise certain widgets such that many goals are met at once, with a decreased maintenance burden for everyone involved.

Note that this goal is necessary for T11080 to succeed. It's quite common in a lot of companies/governments that they make suitable provisions for those with disabilities, where possible.

In D21736#484989, @ngraham wrote:

Thanks, the issue is fixed now. I could not find any other behavioral regressions, and I've verified that the new feature behaves correctly. The code looks good to me too!

Next, do you think you could work on https://bugs.kde.org/show_bug.cgi?id=408919?