Does is work in an X11 session? Is it restricted to "htop" or also other command line applications?

(In reply to Christoph Feck from comment #1)
> Does is work in an X11 session? Is it restricted to "htop" or also other
> command line applications?

Htop works fine while X11 session, but doesn't appears while Wayland session.
I didn't test that bug with other console utilities which have shortcuts in Kicker or Kickoff menu.

When I use Konsole directly, I don't have any bugs (X11 or Wayland).

I can confirm this problem on Arch Linux.
Htop opens as expected on Wayland session if I set Gnome Termnial as default terminal emulator in system settings > applications > default applications.

Operating System: Arch Linux 
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.13.0

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

The reason is (likely) this code in kio (https://cgit.kde.org/kio.git/tree/src/core/desktopexecparser.cpp#n429):
        if (terminal == QLatin1String("konsole")) {
            if (!d->service.workingDirectory().isEmpty()) {
                terminal += QLatin1String(" --workdir ") + KShell::quoteArg(d->service.workingDirectory());
            }
            terminal += QLatin1String(" -qwindowtitle '%c' %i");
        }

%i expands to "--icon xxx", which is not supported (by Qt) on Wayland.

See https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Exec_key_of_.desktop_files :
> The Exec key of your .desktop file should not contain the %i "field code".
> Your application won't start on Wayland otherwise, because the specification
> expands that code in the --icon argument, which is accepted by QGuiApplication > only on XCB platforms. This code review contains a discussion about the
> upstream decision. You can use the -qwindowicon argument as replacement. It
> still won't work on Wayland (it will on most other platforms) but now your app > will start everywhere.
> 
> // Don't
> Exec=someapp %i %U
> // Do
> Exec=someapp -qwindowicon someicon %U

So IMHO, one way to fix it would be to explicitly handle the "-icon" option in konsole, the other to make kio not use that option on Wayland.

Nice find. Wanna submit a patch? Both might be desirable, but the %i fix seems more important since it's a Wayland incompatibility and could bite other apps too.

>So IMHO, one way to fix it would be to explicitly handle the "-icon" option in konsole, the other to make kio not use that option on Wayland.

There's no point doing the -icon thing on wayland, there is no spec for window icons to be passed. It would just be a lie for compatibility.

Lets do the kio thing

(In reply to Nate Graham from comment #6)
> Nice find. Wanna submit a patch?
When I find the time...

> Both might be desirable, but the %i fix
> seems more important since it's a Wayland incompatibility and could bite
> other apps too.
It cannot bite other applications, as this code is specific for calling konsole, see the 'if'.

I do agree that it should better be fixed in kio though.

But if you mean "fixing" the %i handling in general (e.g. to use "-qwindowicon" instead which would also "work" on Wayland, although it would have no effect), that is not a good idea either, as it is written in the freedesktop.org .desktop file specifications that %i shall be expanded to "--icon xxx".
Quoting from https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#exec-variables :
> %i	 The Icon key of the desktop entry expanded as two arguments, first --icon
> and then the value of the Icon key. Should not expand to any arguments if the
> Icon key is empty or missing.

And non-Qt applications likely won't support -qwindowicon anyway, although they might "support" --icon even on Wayland. ;-)

Although, as changing the window icon apparently is not possible on Wayland anyway, maybe the best fix would indeed to just always expand %i to an empty string on Wayland?

Ok, I can confirm now that removing the %i when calling konsole indeed fixes the bug on Wayland.

But what would be the best way to test for Wayland or xcb inside kio?
Using QGuiApplication::platformName() doesn't work (it gives a compiler error) because kio (this part at least) isn't linked against QGuiApplication I think.

And removing it unconditionally would be a "regression" on X11/xcb... :-/
Although, specifying "--icon someicon" seems to have no effect on Plasma/X11 either anyway, so that might be acceptable (it does work on other desktops I tried though).

Hm, seems my thinking went a bit overboard now... ;-)

In the konsole specific code, we can of course just use "-qwindowicon someicon" instead of "%i", that's supported by Qt on any Platform and won't change existing behavior in any way either ("--icon" is just a synonym for "-qwindowicon" on xcb, it's handled by the very same code path in Qt).

Patch is upcoming, I just want to test a few things before.

https://phabricator.kde.org/D27654

Git commit 07ab04bfe77475438fca0996d48116bbc17eedd6 by Wolfgang Bauer.
Committed on 28/02/2020 at 10:25.
Pushed by wbauer into branch 'master'.

Fix running konsole on Wayland

%i expands to "--icon someicon", but Qt recognizes this option only on
X11/xcb.
So konsole failed to start on Wayland.

To fix this problem, pass "-qwindowicon" instead, which is supported on
all platforms.

See https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Exec_key_of_.desktop_files for details.
FIXED-IN: 5.68.0
Differential Revision: https://phabricator.kde.org/D27654

M  +4    -1    src/core/desktopexecparser.cpp

https://commits.kde.org/kio/07ab04bfe77475438fca0996d48116bbc17eedd6