Wayland: Set app_id for icon in kde #718

Merged
ColinKinloch merged 2 commits from wl_icon into main 2023-03-29 11:28:17 -03:00
ColinKinloch commented 2023-03-28 10:00:32 -03:00 (Migrated from github.com)

KDE requires set_app_id to be called to display the app icon.
I don't know if there's a way to set this value in wxWidgets, in Gtk it's for each window by the GtkApplication
This hack set's it directly for a Gtk window.

cemu_kde
Screenshot from 2023-03-28 16-28-27

Currently it's only applied to the main window and the GamePad window but ideally it would run after Show for each toplevel window (wxFrame).

The gdk_wayland_window_set_application_id function was added in gtk 3.24.22. Ubuntu 20.04 LTS supports 3.24.18 and with updates 3.24.20. Therefore the function call will be dynamic.

KDE requires [set_app_id](https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_app_id) to be called to display the app icon. I don't know if there's a way to set this value in wxWidgets, in Gtk it's for each window by the [GtkApplication](https://docs.gtk.org/gio/property.Application.application-id.html) This hack set's it directly for a Gtk window. ![cemu_kde](https://user-images.githubusercontent.com/334272/228243011-09b98abd-0a4b-4c8c-ae5d-f884f40fab8d.png) ![Screenshot from 2023-03-28 16-28-27](https://user-images.githubusercontent.com/334272/228288925-33865a83-88ca-4ff3-8a5c-bceca6316388.png) Currently it's only applied to the main window and the GamePad window but ideally it would run after `Show` for each toplevel window (`wxFrame`). The `gdk_wayland_window_set_application_id` function was added in gtk `3.24.22`. Ubuntu 20.04 LTS supports `3.24.18` and with updates `3.24.20`. Therefore the function call will be dynamic.
Exzap (Migrated from github.com) reviewed 2023-03-28 10:29:26 -03:00
Exzap (Migrated from github.com) commented 2023-03-28 10:29:26 -03:00

HAS_WAYLAND only indicates compile time support for Wayland, the actual window still might end up using X11. I recommend adding an extra check like this:

if (wxWlIsWaylandWindow(m_mainFrame))
    wxWlSetAppId(m_mainFrame, "info.cemu.Cemu");

And then implement wxWlIsWaylandWindow like this:

bool wxWlIsWaylandWindow(wxFrame* frame)
{
    GtkWidget* gtkWindow = static_cast<GtkWidget*>(frame->GetHandle());
    GdkWindow* gdkWindow = gtk_widget_get_window(gtkWindow);

    return GDK_IS_WAYLAND_WINDOW(gdkWindow);
}

Note that this code is untested and I wrote it off the top of my head. You could also avoid the extra function and check inside wxWlSetAppId directly, but personally I think conditionally calling wxWlSetAppId makes it more obvious that the window isn't always wayland baked.

HAS_WAYLAND only indicates compile time support for Wayland, the actual window still might end up using X11. I recommend adding an extra check like this: ```cpp if (wxWlIsWaylandWindow(m_mainFrame)) wxWlSetAppId(m_mainFrame, "info.cemu.Cemu"); ``` And then implement wxWlIsWaylandWindow like this: ```cpp bool wxWlIsWaylandWindow(wxFrame* frame) { GtkWidget* gtkWindow = static_cast<GtkWidget*>(frame->GetHandle()); GdkWindow* gdkWindow = gtk_widget_get_window(gtkWindow); return GDK_IS_WAYLAND_WINDOW(gdkWindow); } ``` Note that this code is untested and I wrote it off the top of my head. You could also avoid the extra function and check inside `wxWlSetAppId` directly, but personally I think conditionally calling wxWlSetAppId makes it more obvious that the window isn't always wayland baked.
Exzap commented 2023-03-29 08:27:54 -03:00 (Migrated from github.com)

Seems like gdk_wayland_window_set_application_id was added with GTK 3.24 but the ubuntu package that we build with is only 3.0

You could change the call to be conditional at runtime and not rely on gdk_wayland_window_set_application_id being present in headers:

    static auto set_application_id = reinterpret_cast<void (*) (GdkWindow*, const char*)>(dlsym(nullptr, "gdk_wayland_window_set_application_id"));
    if (set_application_id)
    {
        set_application_id(gdkWindow, application_id);
    }
Seems like `gdk_wayland_window_set_application_id` was added with GTK 3.24 but the ubuntu package that we build with is only 3.0 You could change the call to be conditional at runtime and not rely on `gdk_wayland_window_set_application_id` being present in headers: ```cpp static auto set_application_id = reinterpret_cast<void (*) (GdkWindow*, const char*)>(dlsym(nullptr, "gdk_wayland_window_set_application_id")); if (set_application_id) { set_application_id(gdkWindow, application_id); } ```
ColinKinloch commented 2023-03-29 08:57:29 -03:00 (Migrated from github.com)

The build is on Ubuntu 20.04 LTS which is might be GTK 3.24.18 (20.04 libs).
Seems the function was merged 2 years ago.
I'll make the function call dynamic, but would there be any downside to bumping the build image to 22.04 LTS?

The build is on Ubuntu 20.04 LTS which is might be GTK 3.24.18 ([20.04 libs](https://packages.ubuntu.com/focal/libs/)). Seems the function was [merged](https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2205) 2 years ago. I'll make the function call dynamic, but would there be any downside to bumping the build image to 22.04 LTS?
Exzap commented 2023-03-29 09:21:02 -03:00 (Migrated from github.com)

The build is on Ubuntu 20.04 LTS which is might be GTK 3.24.18 (20.04 libs).

Yeah not sure whats going on. In the log I saw 3.0 somewhere. But the function is definitively not available in the headers we include. So maybe the dev package is outdated but GTK itself isn't. Granted, I only did a surface level check.

I'll make the function call dynamic, but would there be any downside to bumping the build image to 22.04 LTS?

It would lock out anyone trying to compile on 20.04. Might also affect the base requirements of the appimage but I'm not sure whether it comes with its own GTK or not.

> The build is on Ubuntu 20.04 LTS which is might be GTK 3.24.18 ([20.04 libs](https://packages.ubuntu.com/focal/libs/)). Yeah not sure whats going on. In the log I saw 3.0 somewhere. But the function is definitively not available in the headers we include. So maybe the dev package is outdated but GTK itself isn't. Granted, I only did a surface level check. > I'll make the function call dynamic, but would there be any downside to bumping the build image to 22.04 LTS? It would lock out anyone trying to compile on 20.04. Might also affect the base requirements of the appimage but I'm not sure whether it comes with its own GTK or not.
Exzap (Migrated from github.com) reviewed 2023-03-29 10:43:05 -03:00
Exzap (Migrated from github.com) commented 2023-03-29 10:43:05 -03:00
		gdk_wl_set_app_id(gdkWindow, applicationId);

instead of application_Id
Assuming this is the last issue I'll commit it right away

```suggestion gdk_wl_set_app_id(gdkWindow, applicationId); ``` instead of `application_Id` Assuming this is the last issue I'll commit it right away
ColinKinloch (Migrated from github.com) reviewed 2023-03-29 10:50:18 -03:00
ColinKinloch (Migrated from github.com) commented 2023-03-29 10:50:18 -03:00

Hah, I have that on my working tree. I guess I forgot to git add.

Hah, I have that on my working tree. I guess I forgot to `git add`.
ColinKinloch (Migrated from github.com) reviewed 2023-03-29 10:51:14 -03:00
ColinKinloch (Migrated from github.com) commented 2023-03-29 10:51:14 -03:00

I've got nothing else to add, merge it :)

I've got nothing else to add, merge it :)
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: cemu-project_Mirror/Cemu-2024-03-05#718
No description provided.