This fixes the following on NixOS:
xfce-notify-log-util.c:40:10: fatal error: gio/gdesktopappinfo.h: No such file or directory
40 | #include <gio/gdesktopappinfo.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
The reason here is the same as xfce/xfce4-session!51.
Brian Tarricone (307c8641) at 25 Mar 03:30
common: Explicitly depend on gio-unix-2.0
looks good, thank you!
This fixes the following on NixOS:
xfce-notify-log-util.c:40:10: fatal error: gio/gdesktopappinfo.h: No such file or directory
40 | #include <gio/gdesktopappinfo.h>
| ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
The reason here is the same as xfce/xfce4-session!51.
It's still a bit strange that the color doesn't change. Might be something to look into there...
When changing some toggles on Applications tab of xfce4-notify-config (e.g. Mute application), the toggle appears unchanged after clicking it, but shows its new, changed state after closing and reloading config window.
The behavior with Adwaita is different. In that case, the toggle moves position immediately but doesn't change color (as in it moves left to right but is still gray). When reopening the dialog, the color is correct (to the right and blue).
Since this is Xfce 4.18 I didn't think to check if notifyd wasn't the latest version. I'll probably stick with the version in the 22.04 repos, since you're saying you don't see this issue in the latest version I'll close this out, thanks for checking!
Oh wow, that's very strange. Can you test with the default Adwaita GTK theme?
Also if it's possible to use the current version (0.9.4), that would be helpful. I don't really have the spare time to install and test old versions.
Hi, this is 0.7.3-1~bpo22.04 on Linux Mint 21.3 with one of the provided Mint-Y themes. Here's a video showing the issue with the "Mute application" toggle on Xfce volume control under Applications tab. At :08 the toggle is clicked but doesn't change state. Then the window is re-opened and you can see that Mute application is now toggled. Perhaps it's only an issue with certain applications? Thank you! simplescreenrecorder-2024-03-04_23.24.36.mkv
I don't see this behavior. What version of xfce4-notifyd are you using? If it is not the latest, please try with the latest. Which theme are you using? Can you make screenshots or create a short screencast video so I can be sure I understand what you are talking about?
On Wayland, we can't get the absolute location of the pointer, or even know which monitor the pointer is on. Sigh.
Instead, we can create the window with no set monitor, set it's opacity to fully transparent, map the window, and hope that the compositor's policy is to place layer-shell windows with no output set on the active monitor. Then we can see what monitor the window is on, move it to the appropriate place, and set the opacity back to normal.
Closes #125.
With a laptop monitor on the left and an external monitor on the right, if I run notify-send
from a terminal on the left monitor, the notification is correctly positioned at the top right of the left monitor.
But if I run it from a terminal on the right monitor, the notification seems positioned on the right monitor according to the dimensions of the left monitor (so somewhere in the top right quarter, but not top right).
xfce4-notifyd 0.9.4, i.e. current git-master.
Brian Tarricone (0e4a04fe) at 03 Mar 09:56
Fix positioning on Wayland in multi-monitor setups
... and 2 more commits
Ok, 100ms it is!
I think the timeout is too low. Even without putting the computer to work, I occasionally get badly positioned notifications with something like this:
while :; do notify-send test; sleep 0.5; done
With 100 ms it seems fine to me, and I don't see any visual edge effect.
Yep, really annoys me that we have to resort to things like this.
Anyhow, pushed something, let me know if it works for you (it does work for me). I was also right in my guess that positioning on other monitors on Wayland was broken in general, so I fixed that as well in a follow-up commit here.
Ah, that brings back memories, I've had to deal with that too, much as described above. I had probably tried a g_signal_connect_after()
on GtkWidget::draw
, which is the latest signal I think, and often gives good results on X11 in this type of situation, but not on Wayland.
And so yes, after that, all that's left is the timeout, i.e. something unsatisfactory :/
Ok, so this sucks. At the time of map-event
on the window, gdk_display_get_monitor_at_window()
is still returning monitor 0. If I then set a 1 second timeout afterward, I guess wl_surface.enter()
happens, and then it gets set to the right monitor.
I tried doing a wl_display_roundtrip()
on gdk's wl_display
before checking the monitor, but that didn't help. I guess I could... wait some amount of milliseconds and see? But there's no way to know if it's actually correct, since of course monitor 0 is a valid possibility. I think the wl_output
underneath all that is actually NULL
, but gdk_display_get_monitor_at_window()
will always return something non-NULL
, even if it has to guess (poorly). Sigh.
It does seem to happen quickly though. A g_idle_add()
right after map-event
doesn't catch it, but a g_timeout_add()
with a one millisecond delay does see the correct monitor. Maybe I'll just push that out to 10ms and call it a day for now...
Ok, took a look a look and I see it too.
The vertical position part is interesting: if I bring up a notification on the primary monitor, and then while that notification is still up, I bring up another on the second monitor, the vertical position is indeed wrong: it's positioned as if the first notification was also on the second monitor. Which makes sense, I think: it's still for some reason using the primary monitor for geometry, so it's probably also using it to figure out where there might be overlap with existing notifications.
So anyway, this is weird. Let's see...
No, that doesn't fix the issue. I've just noticed that, contrary to my description in OP, the vertical position is in fact correct, only the horizontal position is wrong. The position is the same for me before and after !66 (merged).