Package Details: signal-desktop-beta 7.52.0beta1-1

Git Clone URL: https://aur.archlinux.org/signal-desktop-beta.git (read-only, click to copy)
Package Base: signal-desktop-beta
Description: Signal Private Messenger for Linux - Beta version.
Upstream URL: https://signal.org
Keywords: secure-messenger signal signal-desktop
Licenses: GPL3
Conflicts: signal-desktop-beta-bin
Submitter: Edu4rdSHL
Maintainer: Edu4rdSHL
Last Packager: Edu4rdSHL
Votes: 16
Popularity: 0.44
First Submitted: 2020-08-17 19:09 (UTC)
Last Updated: 2025-04-19 00:51 (UTC)

Dependencies (33)

Required by (0)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 15 Next › Last »

Edu4rdSHL commented on 2024-07-08 01:08 (UTC)

This package is not building currently. Upstream bug report is available at https://github.com/signalapp/Signal-Desktop/issues/6935

mkurz commented on 2024-06-06 22:59 (UTC)

Also opened merge request for the arch signal package: https://gitlab.archlinux.org/archlinux/packaging/packages/signal-desktop/-/merge_requests/4

mkurz commented on 2024-06-06 22:30 (UTC)

Commented on https://github.com/signalapp/Signal-Desktop/issues/6239#issuecomment-2153467204 also because the official Signal distributions are broken also.

mkurz commented on 2024-06-06 22:00 (UTC)

I now also tried WM_CLASS=signalbeta in the .desktop file, also does NOT work.

Actually I think WM_CLASS is not a valid key according to https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s06.html - I think you meant StartupWMClass, which I also tried (see comments below) but did not work.

Edu4rdSHL commented on 2024-06-06 21:47 (UTC)

VM_CLASS needs to be set on the .desktop file, not on the command line.

mkurz commented on 2024-06-06 21:42 (UTC)

Question, does setting WM_CLASS=signalbeta fix the issue for you?

No, this does not fix the issue. I tried four things:

  1. StartupWMClass=signalbeta in the desktop file did NOT work.
  2. StartupWMClass=signal-desktop-beta did NOT work (I already explained that in "side note 1" in https://aur.archlinux.org/packages/signal-desktop-beta#comment-976954)
  3. Running the app from command line with WM_CLASS=signalbeta signal-desktop-beta did NOT work.
  4. Renaming the desktop file to signalbeta.desktop WORKED!!!

If you look at the code I referenced in my previous comments it's pretty clear that the desktop file needs to be renamed. For me this is 100% clear.

I will also open bug reports at - https://gitlab.archlinux.org/archlinux/packaging/packages/signal-desktop and - https://aur.archlinux.org/packages/signal-desktop-beta-bin

so they fix this as well.

Edu4rdSHL commented on 2024-06-06 21:27 (UTC)

Hey, thanks, now I understand what you're talking about. Yes, I don't have that "app icon" in the titlebar, the StartupWMClass works for the icon on the dash panel, but you're talking about something different that I didn't even know it exists.

Question, does setting WM_CLASS=signalbeta fix the issue for you?

mkurz commented on 2024-06-06 21:21 (UTC)

I think you totally misunderstand what I am talking about.

signal-desktop-beta is running great on KDE with native wayland. It works! EXCEPT the app icon in the titlebar. Here is a screenshot to show you what I am talking about: https://gist.githubusercontent.com/mkurz/f9ee4ba8487dbd075b3350dc7b71680d/raw/af1c75e80067844393da5c4070939f6d8fb1ccb3/signal-desktop-beta-screenshots.png

So you see, when using native wayland the title bar icon does not get set correctly. This is because wayland is using an app_id. Now, the app_id for signal-desktop-beta is signalbeta. The app_id has to match the desktop file. I did explain this in my previous post. So this has nothing to do with KDE or Gnome.

In Gnome, do you even have icons in the title bar? I think you do not even have this icons... Can you post a screenshot with the title bar icon running native wayland in gnome?

Now, even Gnome recommends that the desktop file name should match the app_id (or WM_CLASS in X), please see the gnome wiki: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased#The_WM_CLASS_X_Window_property:

To ensure the GNOME 3 Shell will track your application, you can also set the WM_CLASS X window property to be the same as your application's .desktop file name, without the .desktop extension (the desktop file should be lower-case). The easiest way to achieve this is to have your application's process name match the .desktop file name, and ensure you use g_option_context_parse.

Also more proof. Look at this code: https://github.com/electron/electron/blob/v32.0.0-nightly.20240605/shell/browser/native_window_views.cc#L303-L304 It calls this method: https://github.com/electron/electron/blob/v32.0.0-nightly.20240605/shell/common/platform_util_linux.cc#L410-L419

I am 100% sure the desktop file name needs to be changed for correct wayland support, no matter if using Gnome or KDE.

I hope you now understand what I am talking about. If you read my previous comments again, maybe it is more clear now.

Edu4rdSHL commented on 2024-06-06 20:32 (UTC) (edited on 2024-06-06 20:34 (UTC) by Edu4rdSHL)

Yes, natively on Wayland. I'm using Gnome.

Edit: see https://bbs.archlinux.org/viewtopic.php?id=280119 for a similar issue to what you're having, which seems to be KDE-specific.

mkurz commented on 2024-06-06 20:23 (UTC) (edited on 2024-06-06 20:24 (UTC) by mkurz)

StartupWMClass works perfectly on Wayland.

Did you test that? I mean using Wayland natively, not using XWayland. Which DE are you using?

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 15 Next › Last »