It won't.
The only difference is the 'key name" in the properties. The value
"qtcreator" is the same and everything there onwards is the same.
David
On martedì 12 settembre 2017 23:50:57 CEST, David Edmundson wrote:
you'll be getting wl_shell_surface@N.set_class("qtcreator") on current kwin.
It's a wl_shell vs xdgv6 difference, but they're both getting
the same data from the QtWayland code.
It's just different implementations of mShellSurf
you'll be getting wl_shell_surface@N.set_class("qtcreator") on current kwin.
It's a wl_shell vs xdgv6 difference, but they're both getting the same data
from the QtWayland code.
It's just different implementations of mShellSurface->setAppId
On lunedì 11 settembre 2017 22:15:20 CEST, David Edmundson wrote:
From a KDE side we can't use that as we don't have it.
There is no icon name part of the specification in either of
the shell protocols.
The only relevant event is AppId.
Qt could base the appId off the window icon but it would
Note that even if this is added, the Task Manager is just going to
ignore it. The Task Manager is written to try and identify the app
that owns a window and use the icon from the .desktop file, to
enable consistent theming (not all apps load icon assets the same
way and set it well on the window o
Am 2017-09-11 21:46, schrieb Elvis Angelaccio:
Hi,
kwin_wayland currently sets the application icon only if it can
retrieve the .desktop filename of the application.
Is there a reason why it doesn't use the icon passed to
setWindowIcon() as fallback? This seems to work with weston, so I
guess it
>From a KDE side we can't use that as we don't have it.
There is no icon name part of the specification in either of the shell
protocols.
The only relevant event is AppId.
Qt could base the appId off the window icon but it wouldn't make any sense;
(code for this and it's fallbacks if the .desktop
