Recently, Signal stopped flashing when I receive a message in i3wm. The change in the source is pretty clear here, showing what happened:
Actual Result:
No visual indicator or flash is shown.
Expected Result:
The window flash will trigger i3 to highlight that window/desktop number.
Signal Version: 1.27.2-1 (from AUR)
Operating System: Arch Linux
Linked Device Version: 4.46.2 (Android)
Sadly, we received reports of pretty extreme window manager behaviors related to this simple call. We decided to turn it off because off the wide range of potential interpretations.
Thanks for the response. Signal desktop is basically unusable, in i3, without these flashes. Can we please put this behind a flag or setting, compile-time or run-time, so that those of us who need it can have it?
Or can we have a more generic approach and run a command on flash (which the user can specify)? I just need some way to know when a new message comes in.
@jeaye You don't have anything registered to handle Signal Desktop notifications?
@scottnonnenberg Apparently not, since I've never seen any. Seeing some desktop notifs would certainly help, since it's better than no visual indication at all. However, I don't think those notifs would flash the window the same way, to trigger my window manager to highlight that desktop as needing attention. So, if I miss the notif (AFK) and come back to work, I have no idea about the new message.
Seconded, signal-desktop is unusable without the flash: I do use desktop notifications, but as @jeaye noted they only show up for a small amount of time and therefore do not solve the "received a message while AFK" situation.
Saw this issue, kept an eye on it and seeing that it got closed I feel that I should say something. So: Seconded, I've got the same problem.
More or less guessing if someone wrote, or relying on my phone when I'm using a desktop application sort of backwards. (dwm user)
Sadly, we received reports of pretty extreme window manager behaviors related to this simple call. We decided to turn it off because off the wide range of potential interpretations.
I believe what occurs is that the _NET_WM_STATE_DEMANDS_ATTENTION property is set, as described in the spec.
Now, if there are window managers that 'go extreme' about this - by the way, which ones are those?, I think they should be asked to adjust and not applications adapted in a way to accommodate non straight-forward window manager behavior.
Philosophy aside, for me it would be good enough to have a commandline switch or similar that enables setting the ..._DEMANDS_ATTENTION property on incoming messages, as suggested by multiple people above already.
I agree with a lot of these comments. Now when I come back to my computer, there is no indication if I've missed messages. FWIW the previous behaviour worked fine with KDE/Kwin. For anyone looking for a quick fix, you can just patch the file as follows:
--- main.js.orig 2019-10-05 14:54:58.255575788 +1000
+++ main.js 2019-10-05 14:45:14.248803283 +1000
@@ -894,7 +894,7 @@
});
ipc.on('draw-attention', () => {
- if (process.platform === 'win32' && mainWindow) {
+ if (process.platform === 'linux' && mainWindow) {
mainWindow.flashFrame(true);
}
});
Yep, this is a quick fix to re-enable. Clearly people are vocal about this being an issue.
@scottnonnenberg-signal What do you say about opening this back up and coming to terms with how we can address it, either by re-enabling by default or behind a flag or config?
i also just noticed this after a recent upgrade, and i agree that this makes signal-desktop pretty unusable for me (since i have no other way of seeing that i have new messages if the signal window is on a different desktop).
Can we get this back through some configuration at least? When I started using signal, the first thing I did was opening the PR for urgency hints on linux (https://github.com/signalapp/Signal-Desktop/pull/1820).
Without it, using signal on the desktop became a real hassle, I need to check the window frequently to see if there are new messages. I do not use any notification daemon, because I found them to be way too interruptive and so I solely rely on urgency hints.
Sadly, we received reports of pretty extreme window manager behaviors related to this simple call.
@scottnonnenberg Do you know what exactly happened or which window managers are affected? I do not know what "extreme" means in this case, because urgency hints work quite well normally. I would be willing to help if I had more information.
In one case 'extreme' meant pulling a user from one desktop to another, where Signal Desktop was. A disruption we weren't interested in causing for anyone.
But we are considering a change given that so many of you have reached out. Maybe the right decision is to have it on by default for Linux then something like a command-line option to turn it off.
Indeed, that is an extreme situation which warrants attention. It's also, I'd bet, quite the edge case and doesn't render Signal neigh unusable on Linux for everyone like the current solution does (I've found this issue also applies to GNOME, which rules in many more affected users).
I would agree that it seems we should still enable this flash by default and allow those users with extreme situations to disable it. Thanks, @scottnonnenberg-signal!
Thanks @scottnonnenberg-signal! I appreciate how receptive you are to your users!
In once case 'extreme' meant pulling a user from one desktop to another, where Signal Desktop was. A disruption we weren't interested in causing for anyone.
That's obviously a bad situation for that user. However I seems like that's probably more an issue with their window manager. For example with KDE/kwin, there's an option to change "focus stealing prevention" along a range from None, Low, Medium, High, Extreme. My understanding is that you can intentionally set the WM to pull you to the desktop requiring attention, but you can tweak it yourself. Presumably the affected user's WM should have a similar setting too.
I would agree that it seems we should still enable this flash by default and allow those users with extreme situations to disable it.
Thank you for your response, that sounds awesome! Indeed, the focus-stealing sounds like an extreme measure from the window manager.
Looking at the standard protocol (https://tronche.com/gui/x/icccm/sec-4.html), it seems to be quite vague what the window manager should do, but I think raising the window is a very intrusive way of interpreting this flag:
The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user. [...] For example, the window manager may attract attention to an urgent window by adding an indicator to its title bar or its icon. Window managers may also take additional action for a window that is newly urgent, such as by flashing its icon (if the window is iconic) or by raising it to the top of the stack.
But we are considering a change given that so many of you have reached out. Maybe the right decision is to have it on by default for Linux then something like a command-line option to turn it off.
Is this the correct Issue to follow for updates even though it's closed? Would like to know when it's related to a commit or even a release.
If you're running the beta, please update and let us know what you think! https://github.com/signalapp/Signal-Desktop/commit/f79069455932397105e025ef9bc04e74a9e6f612
It's working great for me on Arch Linux and i3wm. However, it always worked fine for me. Someone with one of the "problematic" window managers should chime in maybe.
Most helpful comment
In one case 'extreme' meant pulling a user from one desktop to another, where Signal Desktop was. A disruption we weren't interested in causing for anyone.
But we are considering a change given that so many of you have reached out. Maybe the right decision is to have it on by default for Linux then something like a command-line option to turn it off.