Or in layman terms, don't pop up reminders during a presentation.
Plasma has a "do not disturb" setting (which is even automatically
enabled when mirroring the screen onto a projector), and that setting is
available via a property in a freedesktop notifications interface.
The code is in alarmdialog rather than alarmclient because the "suspend"
code is in alarmdialog and calls wakeUp() directly.
| No Linters Available |
| No Unit Test Coverage |
| Buildable 18947 | |
| Build 18965: arc lint + arc unit |
lgtm
| korgac/alarmdialog.cpp | ||
|---|---|---|
| 794 | This blocks. What happens when the "inhibited" property doesn't exist? Will it return a default-constructed (false)? | |
| korgac/alarmdialog.cpp | ||
|---|---|---|
| 794 | Something's really weird. If I kill plasmashell, then this blocks for 25 seconds (and then returns false indeed). That timeout is reproducible on the command-line, qdbus org.freedesktop.Notifications blocks for 25s when plasma isn't running. I found why: /usr/share/dbus/services/org.kde.plasma.Notifications.service says [D-BUS Service] Name=org.freedesktop.Notifications Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications This looks like an awful hack to me. It only makes sense if plasma is currently starting, but otherwise, it will just block for 25s for no purpose. I could work around it by making this code non-blocking, but it would still delay all notifications by 25 seconds, and probably output warnings about dbus timeouts. I would say this org.kde.plasma.Notifications.service file is an unrelated issue affecting all users of org.freedesktop.Notifications. | |
Thank you David.
I'm very much in favor of this once you have the blocking figured-out.
Something's really weird. If I kill plasmashell, then this blocks for 25 seconds (and then returns false indeed).
Ooooh, yeah, we have some "plasma-waitforname" script that is autostarted by dbus when notification service is called. This is so apps sending notifications before plasma is up on login don't end up showing ontop of the splash screen and whatever. But also causes this annoying behavior. You could check QDBusConnectionInterface::isServiceRegistered before calling into it.
@davidedmundson any way to restrict dbus autolaunch to certain methods?
Good idea, I'll use isServiceRegistered to avoid DBus activation which is definitely not wanted here.
This is actually the answer (AFAIK) to your question for davidedmundson - unguarded calls *will* activate (i.e. autostart) services, isServiceRegistered is the way to avoid it.
With that in, I don't think the blocking call is an issue. If Plasma blocks for a long time we have bigger problems than a slightly delayed reminder.
If Plasma blocks for a long time we have bigger problems than a slightly delayed reminder.
The service isn't neccessarily owned by Plasmashell. There's alternative services, such as Dunst. That inhibited property is non-standard but when not present I think it will just return false which is desired here.