I thought about using KRun::setShowScriptExecutionPrompt() for D10835, but "Recent Documents" include only those files which were opened, and doesn't include ones which were executed, so an execution prompt there would be totally unexpected by a user. KRun currently doesn't seem to have a way to force opening of executables - one can only prohibit running them with setRunExecutables(), in which case an error message is displayed. That's why I decided to go the way it is now.

I think, the best solution would be to add a new KRun::RunFlag (like OpenExecutables) which'd make it open executable files instead of running them, and then use it here.

Well there was already KRun::setRunExecutables :)

In D26582#591959, @meven wrote:

Well there was already KRun::setRunExecutables :)

I've already talked about it in my previous message:

In D26582#591952, @aleksejshilin wrote:

KRun currently doesn't seem to have a way to force opening of executables - one can only prohibit running them with setRunExecutables(), in which case an error message is displayed. That's why I decided to go the way it is now.

For example:

1. Install Okteta.
2. Associate application/x-sharedlib mime type with Okteta.
3. Open a shared library with Okteta.
4. Try to open it again from 'Recent Documents'.

Instead of opening the file in Okteta, it'll show a message box saying that the executable file won't be started for security reasons.

I admit that it's not a likely scenario though, so let's see what others have to say.

In D26582#592266, @aleksejshilin wrote:

In D26582#591959, @meven wrote:

Well there was already KRun::setRunExecutables :)

I've already talked about it in my previous message:

In D26582#591952, @aleksejshilin wrote:

KRun currently doesn't seem to have a way to force opening of executables - one can only prohibit running them with setRunExecutables(), in which case an error message is displayed. That's why I decided to go the way it is now.

For example:

1. Install Okteta.
2. Associate application/x-sharedlib mime type with Okteta.
3. Open a shared library with Okteta.
4. Try to open it again from 'Recent Documents'.
   
   Instead of opening the file in Okteta, it'll show a message box saying that the executable file won't be started for security reasons.
   
   I admit that it's not a likely scenario though, so let's see what others have to say.

Thanks for testing this. There is a different treatment with nativeBinary in KRun,
We may want to change KRun::runUrl when a native binary is to be run but with runExecutable is false, around line 400:

} else if (isNativeBinary) {
    // Show warning for executables that aren't scripts
    noRun = true;
}

I guess in this case with could check for mime-type associated apps like oketa can be with any binary file, perhaps adding a flag.

In D26582#592469, @meven wrote:

We may want to change KRun::runUrl when a native binary is to be run but with runExecutable is false, around line 400:

} else if (isNativeBinary) {
    // Show warning for executables that aren't scripts
    noRun = true;
}

KRun currently doesn't seem to consider that there may be a reason to open native binaries in an application - its execution confirmation dialog doesn't give such option even if some application is associated with the corresponding mime type. I believe, they thought that an average user is unlikely to ever need this - and they may be right. :)

Given that such use case is probably orders of magnitude less likely than sftp: and especially smb:, I guess, it's OK to merge this, and address the issue with native binaries in KIO later. @broulik ?

ping :) @hein

So does this fall through to the dialog when the type hasn't been determined?

In D26582#600469, @hein wrote:

So does this fall through to the dialog when the type hasn't been determined

Any file has always one mime type : "application/octet-stream", but KRun generally resolves mimetype throug extension then through kio.
And then will use KOpenWithDialog when there is no app associated to this mimetype.

And this code basically reverts :
https://phabricator.kde.org/D10835
Just adding run->setRunExecutables instead.

5.18 or not ?

Let's be safe and targe 5.19