Bug 443253

*** Bug 446550 has been marked as a duplicate of this bug. ***

It looks like it chooses the default app for ftp:// links over the default app for that file type

Reproducible using "kioclient5 exec ftp://ftp.slackware.com/debian/README"

The problem is somewhat obvious, the best solution isn't.

The relevant Dolphin code is in https://invent.kde.org/system/dolphin/-/blob/master/src/dolphinviewcontainer.cpp#L658

KIO::OpenUrlJob first looks whether the scheme (ftp) is handles by any app and only when that isn't given tries to determine the MIME type.

I see a couple possible options:
1) Dolphin already knows the MIME type. We could resolve the preferred app and use KIO::ApplicationLauncherJob instead. That's probably what the context menu entry does anyway
2) Change OpenUrlJob to prefer determining the mime type over the scheme handler
3) Add API to pass the MIME type from Dolphin to OpenUrlJob and make it use that

David, Ahmad, Kai: thoughts?

> 2) Change OpenUrlJob to prefer determining the mime type over the scheme handler

Wouldn't that end us back at the "examining..." situation where we try to figure out how to open the app so it takes a while to open a file?

Maybe it really depends on the type of scheme... for a "browsable" protocol I would expect it to behave like a local folder. Maybe "if (supportslisting) { determine mimetype } else { open with handler }"?

3) Add API to pass the MIME type from Dolphin to OpenUrlJob and make it use that

But yeah, if the mimetype is known and we could save a stat, that would be nice either way.

(In reply to Kai Uwe Broulik from comment #5)
> > 2) Change OpenUrlJob to prefer determining the mime type over the scheme handler
> 
> Wouldn't that end us back at the "examining..." situation where we try to
> figure out how to open the app so it takes a while to open a file?
yeah, probably
 
> Maybe it really depends on the type of scheme... for a "browsable" protocol
> I would expect it to behave like a local folder. Maybe "if (supportslisting)
> { determine mimetype } else { open with handler }"?
hmm, interesting idea

> 3) Add API to pass the MIME type from Dolphin to OpenUrlJob and make it use
> that
> 
> But yeah, if the mimetype is known and we could save a stat, that would be
> nice either way.
My concern is that it's a bit magic to have the behavior change this way depending on whether you pass a mimetype or not

I tried implementing option 1), but that breaks running executable scripts (it always opens them in an editor)

A possibly relevant merge request was started @ https://invent.kde.org/system/dolphin/-/merge_requests/343

Git commit 3b4676b3871cad5cd0e4695b211581f8db8accd0 by Nicolas Fella.
Committed on 03/02/2022 at 23:18.
Pushed by nicolasfella into branch 'release/21.12'.

Fix opening FTP files in their preferred app

When passing an URL like ftp://foo/bar.txt OpenUrlJob opens it in the default handler for ftp urls, not the one for txt files, which would be more appropriate here

By passing along the mimetype we can change that behavior to what we want

M  +1    -1    src/dolphinviewcontainer.cpp

https://invent.kde.org/system/dolphin/commit/3b4676b3871cad5cd0e4695b211581f8db8accd0

Would you mind checking if you're seeing the same thing for smb:// files

If I run smplayer smb://path/to/video it works fine, however if I launch from Dolphin - which is just smplayer %U kioexec starts to copy the file rather than streaming

(In reply to Mike Lothian from comment #9)
> Would you mind checking if you're seeing the same thing for smb:// files

The problem/fix isn't specific to FTP, in principle it applies to smb too

> If I run smplayer smb://path/to/video it works fine, however if I launch
> from Dolphin - which is just smplayer %U kioexec starts to copy the file
> rather than streaming#
But it does open in smplayer when opening from Dolphin?

Yes, once it finishes downloading, it does open in smplayer

I'll raise a new bug for this

(In reply to Mike Lothian from comment #11)
> Yes, once it finishes downloading, it does open in smplayer
> 
> I'll raise a new bug for this

That's an smplayer issue, it should have the metadata showing it has support for this scheme. (vlc does it correctly)