Bug 125934 - No application icon on Wayland with the qt5 / kf5 backend
Summary: No application icon on Wayland with the qt5 / kf5 backend
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.2.0.3 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0 target:6.3.0.1
Keywords:
: 139921 148335 (view as bug list)
Depends on:
Blocks: KDE Qt5
  Show dependency treegraph
 
Reported: 2019-06-15 09:28 UTC by Jan-Marek Glogowski
Modified: 2022-05-29 16:36 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan-Marek Glogowski 2019-06-15 09:28:36 UTC
Description:
In Wayland the application icon is loaded from the desktop file by the compositor. Therefore Qt has an API call to set the desktop file for the application, which correctly sets the appId on Wayland: QGuiApplication::setDesktopFileName

But this still leaves us with just a single icon. There is a Wayland API to set a surfaces appId via the XDG shell protocol: set_app_id. This is - AFAIK - the same call that is used by setDesktopFileName, but it can be used per Wayland surface and isn't restricted to the global QGuiApplication. A XDG surface normally maps to a top level window or a popup. And Michael tested that changing the setDesktopFileName also changes the icon for the next created window.

I'm told that appId is supposed to be fixed like the WM_CLASS, but just like the latter, it's currently not enforced. So changing appId works and the icon of the window changes, but currently has side effects, like crashes in "kwin_wayland --xwayland" on shutdown. It works fine with Weston 5.0.0-3 on Debian Buster.


Steps to Reproduce:
1. Start LO on Wayland with the kde5 backend


Actual Results:
The task manager and the window decorations show the default Wayland icon.

Expected Results:
The task manager and the window decorations show the document / module specific LO icon.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Jan-Marek Glogowski 2019-06-15 09:35:56 UTC
Preliminary patch: https://gerrit.libreoffice.org/#/c/74083/
Comment 2 Jan-Marek Glogowski 2019-06-15 09:44:17 UTC
From the QtWayland source:

dist/changes-5.7.0:- Set appId according to QGuiApplication::desktopFileName()

https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandwindow.cpp#n151

// The appId is the desktop entry identifier that should follow the
// reverse DNS convention (see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s02.html).
// According to xdg-shell the appId is only the name, without
// the .desktop suffix.
//
// If the application specifies the desktop file name use that
// removing the ".desktop" suffix, otherwise fall back to the 
// executable name and prepend the reversed organization domain
// when available.
if (!QGuiApplication::desktopFileName().isEmpty()) {
    QString name = QGuiApplication::desktopFileName();
    if (name.endsWith(QLatin1String(".desktop")))
        name.chop(8);
    mShellSurface->setAppId(name);
} else {
...
Comment 3 Jan-Marek Glogowski 2019-06-15 10:43:51 UTC
So thinking about this a bit more, maybe there should be an overload for QWindow::setIcon, which accepts the desktop file as a QString. IMHO it shouldn't accept a file name on other platforms as a convenience to load an icon. Or just allow a desktop file per QWindow? QIcon::fromTheme shouldn't work, as the icon is specified in the desktop file, not the theme. Maybe a QIcon::fromDesktopFile?
Comment 4 Commit Notification 2019-06-15 12:55:32 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/045de7a51f402062f23a3deeb15a199fd039a6f2%5E%21

tdf#125934 Qt5 set the desktop file name

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 5 Commit Notification 2019-06-15 14:17:47 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/fda85282ee11d4be5239ea15ee59d37f5f8cf062%5E%21

tdf#125934 Qt5 set the desktop file name

It will be available in 6.3.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Caolán McNamara 2019-06-15 20:32:30 UTC
our one-window which changes to be different applications, e.g. from writer to startcenter, to calc, is unusual.

When this arose for the gtk3 case I eventually gave up on per-libreoffice-component icons for libreoffice under wayland and used the universal generic start-center one i.e. https://cgit.freedesktop.org/libreoffice/core/commit/?id=6903066822900a700ccf67ae70fa171c94644a9a which has some bug ids tracking my efforts across some bug trackers. I had hoped that something would come along to solve this somewhere along the line, but AFAIK nothing did

There was some other gtk api to set the icon image, I forget which one, but it (at the time at least) also didn't work under gtk.

 I also tried unmappaping the window and replacing it with another of a different appid, but that looked even weirder.
Comment 7 Commit Notification 2019-06-18 18:23:22 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/17c91a53d25c0b82524e04a0c108f8e0abc76685%5E%21

tdf#125934 Qt5 set the desktop file name...

It will be available in 6.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2019-06-18 21:30:12 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-3":

https://git.libreoffice.org/core/+/f9cc6303d80ee70e44ce090c6ad2714f7430a7c9%5E%21

tdf#125934 Qt5 set the desktop file name...

It will be available in 6.3.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Jan-Marek Glogowski 2019-07-07 13:54:43 UTC
Thread on wayland-devel: https://lists.freedesktop.org/archives/wayland-devel/2019-July/040704.html
Comment 11 Jan-Marek Glogowski 2019-07-25 11:12:38 UTC
Qt bug report: https://bugreports.qt.io/browse/QTBUG-77182
Comment 12 Xisco Faulí 2019-10-29 09:31:55 UTC
A polite ping to Jan-Marek Glogowski:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing?
Thanks
Comment 13 Jan-Marek Glogowski 2019-10-29 09:42:58 UTC
This is not fixed, as it needs upstream Qt changes and then fixes to LO. Since I currently have no time to fix this, I'm unassigning this bug. I would also reset this to UNCONFIRMED, but that is not available in my dropdown box, so it goes to NEW. And I also set the version to 6.2, as there wasn't any kde5 / qt5 backend before this release.
Comment 14 QA Administrators 2021-10-29 03:49:36 UTC Comment hidden (obsolete)
Comment 15 Cor Blom 2021-11-19 19:32:11 UTC
I found a workaround for this (which is not a solution) by using window rules in Plasma.

By right clicking on the title bar > more actions there is the possibility to configure special window settings. I have added the option Window Title, which should partly be equal to "Libreoffice Writer", then I enforce that with another option that the desktop filename "libreoffice-writer" is used. I repeat this for the other applications and now I have separate icons on my wayland taskbar for each libreoffice app.
Comment 16 Buovjaga 2022-04-12 14:21:12 UTC
*** Bug 148335 has been marked as a duplicate of this bug. ***
Comment 17 Gauthier 2022-04-19 14:28:13 UTC
I can confirm that this bug is still present in LO 7.3.2
Comment 18 Buovjaga 2022-04-28 12:31:50 UTC
*** Bug 139921 has been marked as a duplicate of this bug. ***
Comment 19 Gauthier 2022-05-15 10:27:54 UTC
Looking at this thread https://ask.fedoraproject.org/t/broken-icon-for-libreoffice-writer-in-wayland/4987 it looks like this bug is also there in Gnome so I wonder if this is definitely a Qt issue? 

It might be an overall LibreOffice issue on Wayland.
Comment 20 Michael Weghorn 2022-05-16 06:27:40 UTC
(In reply to Gauthier from comment #19)
> Looking at this thread
> https://ask.fedoraproject.org/t/broken-icon-for-libreoffice-writer-in-
> wayland/4987 it looks like this bug is also there in Gnome so I wonder if
> this is definitely a Qt issue? 
> 
> It might be an overall LibreOffice issue on Wayland.

By now, it works when using the gtk3 VCL plugin, see 

commit 2d8e2813ddc87f7ce03b97e4d603df11613461f0
Author: Caolán McNamara
Date:   Wed Jul 8 10:13:26 2020 +0100

    use gdk_wayland_window_set_application_id when it becomes available

and https://gitlab.gnome.org/GNOME/gtk/-/issues/767 which is referenced in a comment added by the above commit.

You can test this by starting LibreOffice with the environment variable SAL_USE_VCLPLUGIN=gtk3 set (and double-checking in "Help" -> "About LibreOffice" that gtk3 is actually used).
Comment 21 defetov503 2022-05-18 06:15:30 UTC
(In reply to Michael Weghorn from comment #20)
> (In reply to Gauthier from comment #19)
> > Looking at this thread
> > https://ask.fedoraproject.org/t/broken-icon-for-libreoffice-writer-in-
> > wayland/4987 it looks like this bug is also there in Gnome so I wonder if
> > this is definitely a Qt issue? 
> > 
> > It might be an overall LibreOffice issue on Wayland.
> 
> By now, it works when using the gtk3 VCL plugin, see 
> 
> commit 2d8e2813ddc87f7ce03b97e4d603df11613461f0
> Author: Caolán McNamara
> Date:   Wed Jul 8 10:13:26 2020 +0100
> 
>     use gdk_wayland_window_set_application_id when it becomes available
> 
> and https://gitlab.gnome.org/GNOME/gtk/-/issues/767 which is referenced in a
> comment added by the above commit.
> 
> You can test this by starting LibreOffice with the environment variable
> SAL_USE_VCLPLUGIN=gtk3 set (and double-checking in "Help" -> "About
> LibreOffice" that gtk3 is actually used).

Unfortunately, this does not work on Ubuntu 20.04, using latest LO from PPA (7.3.3.2). However, when using SAL_USE_VCLPLUGIN=gen or SAL_USE_VCLPLUGIN=qt5, application icons are displayed correctly. Gtk3 is the only one working the other way around.
Comment 22 Michael Weghorn 2022-05-18 07:01:31 UTC
(In reply to defetov503 from comment #21)

> Unfortunately, this does not work on Ubuntu 20.04, using latest LO from PPA
> (7.3.3.2).

What gtk version do you have? IIUC, this requires >= 3.24.22 (which contains the commit for https://gitlab.gnome.org/GNOME/gtk/-/issues/767 ).

> However, when using SAL_USE_VCLPLUGIN=gen or
> SAL_USE_VCLPLUGIN=qt5, application icons are displayed correctly. Gtk3 is
> the only one working the other way around.

SAL_USE_VCLPLUGIN=gen probably works because it is using X11 (xwayland).
In the same way, it works for qt5/kf5 when forcing to use the Qt xcb platform plugin by setting environment variable QT_QPA_PLATFORM=xcb .

For me, the generic icon is used for SAL_USE_VCLPLUGIN=qt5 (just as for kf5) if not setting QT_QPA_PLATFORM=xcb in addition.
Comment 23 xisir56027 2022-05-18 20:51:41 UTC
(In reply to Michael Weghorn from comment #22)
> What gtk version do you have? IIUC, this requires >= 3.24.22 (which contains
> the commit for https://gitlab.gnome.org/GNOME/gtk/-/issues/767 ).

Latest release of gtk3 for Ubuntu 20.04 was 3.24.20 (https://launchpad.net/ubuntu/+source/gtk+3.0/3.24.20-0ubuntu1.1)

The only workaround for such systems would be a sandboxed version of LO. See snap, flatpak, etc.
Comment 24 Gauthier 2022-05-29 11:24:34 UTC
Ok great, thanks for the info, so now we know the issue in only there with the qt5/kf5 backend. Do we know if there is anyone working on this at the qt / lo level?
Comment 25 Jan-Marek Glogowski 2022-05-29 16:36:35 UTC
(In reply to Gauthier from comment #24)
> Ok great, thanks for the info, so now we know the issue in only there with
> the qt5/kf5 backend. Do we know if there is anyone working on this at the qt
> / lo level?

(In reply to Jan-Marek Glogowski from comment #11)
> Qt bug report: https://bugreports.qt.io/browse/QTBUG-77182

There isn't much to do on the LO level. If Qt is fixed, it's probably a single call to the new Qt API. I opened the QT bug report back in 2019 and nothing was done. Gtk is fixed, because Caolan prepared a patch himself. And I have enough other LO bugs to fix, so I doubt anything will change in the near future.