The Terminal field in .desktop file was not taken into account as the desktop was only used to get an Exec line.
Also the supported protocols was missing x-scheme-handler declared protocols.
BUG:410506
FIXED-IN:5.67
ervin | |
ngraham | |
dfaure |
Frameworks |
The Terminal field in .desktop file was not taken into account as the desktop was only used to get an Exec line.
Also the supported protocols was missing x-scheme-handler declared protocols.
BUG:410506
FIXED-IN:5.67
Install mutt
Set mutt as default mail client in kcmshell5 componentchooser
kioclient5 exec mailto:test@test.com
Mutt is opened in default terminal application.
No Linters Available |
No Unit Test Coverage |
Buildable 21097 | |
Build 21115: arc lint + arc unit |
Please add me as reviewer when touching my code in KIO. I almost didn't notice this one.
src/core/desktopexecparser.cpp | ||
---|---|---|
213 | Move result of method call into local const variable. The usual range-for-detaches problem. Can you call mimeTypes() instead of serviceTypes() here? I'm trying to slowly split the two notions, after it all got mixed up long ago. | |
214 | QLatin1String is enough here | |
src/widgets/krun.cpp | ||
100–102 | Just remove the if then. This method becomes a one-liner. | |
101 ↗ | (On Diff #73490) | OK I wasn't happy about this docu disappearing but actually it fits better into hasSchemeHandler() which I later on moved to KIO::DesktopExecParser. Done in https://commits.kde.org/kio/45f5d79600809f4c153c7b39ad90652cb921875c |
952 | You forgot to pass d->m_asn here (last argument of runApplication). | |
963 | I think what you meant here was scheme-associated *mimetype* ? In a URL, scheme==protocol, but in KIO we're mostly using the word protocol to refer to those .protocol files. KProtocolInfo::exec() is also reading from the [scheme associated] protocol file so this comment is confusing. (I wonder if this isn't dead code though - helper protocols don't set an empty exec line and a default mimetype, this would make no sense, only real ioslaves like kio_man set a default mimetype, text/html) | |
967 | remove space before 'run' |
src/core/desktopexecparser.cpp | ||
---|---|---|
213 |
No in fact, "x-scheme-handler/<protocol>" are not included in KService::mimeTypes() :
|
src/core/desktopexecparser.cpp | ||
---|---|---|
213 | OK, I see. | |
src/widgets/krun.cpp | ||
962 ↗ | (On Diff #73449) | That is not true. isHelperProtocol returns true so there *is* a kio .protocol file. A helper protocol with an empty exec line is weird, but I see a few like mms.protocol (https://bugs.kde.org/show_bug.cgi?id=84664 has some context). A helper protocol with an empty exec line *and* a default mimetype... well there's one: rtsp.protocol which says defaultMimetype=audio/x-pn-realaudio. Well at least I see the point of that: it'll launch the app associated with that mimetype, for any rtsp://url. OK, scheme-handler replaces most of these uses. I think we should just deprecate "helper protocols" (which either hardcode an exec line or abuse mimetypes) and move it all to the scheme-handler mechanism. That's unrelated to your change so let's do that separately, of course. For now, this comment makes no sense, you can just remove this line (962) and push. |
OK, scheme-handler replaces most of these uses. I think we should just deprecate "helper protocols" (which either hardcode an exec line or abuse mimetypes) and move it all to the scheme-handler mechanism.
I completely agree, we have a standardized way to handle scheme better implement the standard and improve compatibility.
It means KService will gain more responsibility over KProtocolInfo.
Could be a KF6 item.