Hi all,
When I click on an executable file in Dolphin it now shows me only the option to launch it and no longer to open it in a text editor. Is this a new feature or is something wrong here?
It used to be so nice to have the choice between opening it and launching it.
Thanks
Oops, I forgot to add this:
My versions are exactly the same as yours, except that i am already on 7.2.6. However, I am still on F44: so that adds the possibility that the configuration defaults have changed in F45? Usually we focus on doing stuff like that upstream, which means it would end up in a different version. So my guess remains a type of local customization on your system? Your window looks different than mine, not sure if any theme may change such defaults? I have no experience with themes etc
In my case, it looks that way:
I just thought that maybe its different when the file is read-only to the given user (despite plenty reasons to read read-only files), but just tested it, and on my system, I still have all three possibilities in a file that is executable but me having no write priv.
I will check my F45 installation, out of curiosity. I’ll report back 
Update: it seems indeed like a F45 thing → in my default F45 installation, it looks your yours, so “open” is gone, even with a file that I own and of which I have all privileges.
So right mouse click and then “open with…” is the easiest way to get what you want (if what you want is only to read the file).
Maybe that was a means to less confuse users? Given we have an increasing amount of users with little experience in technical realms, I wonder if some might had complaint in the past about what the difference of launch and open is, or something like that.
I can only speculate of course. Anyway, I still would assume its a customization issue, and I expect that can be configured somewhere, to have it as you had in on your F44. Maybe someone has more experience than me and knows off the cuff 
Supplement: I forgot, you might informally ask in the KDE channel in Matrix or so
In KDE Linux I get the same behaviour as you. So I think this is an upstream change, though it’s not immediately clear why F45 and F44 behave differently both on the same Plasma version.
I wonder if a fresh F44 install would behave the same, or if older installs retain the old behaviour and new installs get the new behaviour.
While I cannot prove it by explicit means, I don’t think that is the case: I have the same version of KDE Plasma, KDE Frameworks and Qt than JandeMus on F44. Yet, it looks different.
But that is also what makes me curious, normally we avoid to do that not upstream. But it occurs, and user feedback might be one explanation for that.
I’m using KDE Linux, which is the “latest and greatest, how KDE intends it” distro.
So if I see the behaviour there, it seems like it’s what upstream intends.
Ah, I misunderstood you. I thought you meant the KDE Spin. Yeah it makes one question about that, but I don’t know their policy, nor if KDE Linux always uses the unmodified 1:1 upstream? Being the default distribution does not automatically imply that for multiple reasons.
Let me check the package… the versioning makes me suspicious
Yes, that’s a fair point. But KDE Linux generally uses the git-master version of upstream Plasma, and I’m reasonably sure it doesn’t override anything in this particular case.
Ok, I checked the sources of the packages: the dolphin (and sub package) sources are equal in F44 and F45, so the difference cannot be contained there. The versions are really equal. This also counts to the package versions we are shown in the settings.
However, in KDE, a lot of stuff is intertwined and what impacts a tool might be not only contained in the tool itself: F45 has many more KDE updates recently compared to F44: 148 to be precise.
However, when I check some of these 148 manually, I can see that in all three cases I checked, they had been already updated on F44 before, so the sources are, again, equal.
So the remaining possibility is that, if one checks all remaining 145 rpms, in any of them F45 has already a newer version, making this difference being not part of dolphin or the packages related to the KDE versions we are shown in the settings. Or, its a customization that is imposed after the source rather than being imposed by the source. The latter can also occur to reference implementations and even be intended by the upstream developers, and our KDE team is heavily intertwined and overlapping with the upstream team, so they usually act in consensus, and they align as far as possible. I could also imagine technical or organizational reasons why that would be not (yet?) set in the upstream source. Or, again, maybe its indeed some change that for whatever reason was introduced by some inconspicuously package/rpm that somehow impacts dolphin.
I still have a tendency to assume the “customization after source” thing, given how the packages and rpms are managed and pushed. But I don’t know KDE architecture sufficiently to make more than a rough guess about this (and I definitely have not the time today to get too deep into this, as curious as I am at the moment 
)
So the potential paths of asking are these:
@jandemus must decide which he wants to ask, and in all cases, my first attempt would be to go to the KDE Matrix channel and informally ask there
This would be not necessarily an override.
No, I don’t think this behaviour is an override. My point is that:
Hi Chris, yes I use a different KDE theme, but I am using that for a longer period of time and from day to the next the option to open a file was gone. It is something which I am used to and would like to keep it like that. Guess I will have to file a bugreport, also a suggestion I read on the KDE forum.
You think KDE has removed the feature to open a file that way? Hope not cause it was so handy. Will protest against that, will probably not help, but who knows?
It looks very much like a KDE rather than a Fedora change.
But not necessarily an intentional one - looks like a bug has been raised and accepted against it?
It looks like it’s waiting on a fix up-upstream, i.e. in Qt.
There seems to be some dependency on MIME type, and I wonder if this might be related to @py0xc3 's file behaving differently.
