Closed DasJott closed 6 years ago
Thank you for the report.
I can't reproduce this issue. I've tested GNotifier with the up-to-date Arch and everything seems to be working fine. Do you see anything suspicious on Tools->Developer tools->Error console?
Hey!
When I opened the error console and pressed Test buttons, nothing happened.
But when I opened Thunderbird in Terminal, I saw something that is also shown in that error console on startup:
gnotifier:Notification API init has failed! main.js:202
Before that the console shows a few more errors. See Screenshot for detatils.
Hope, that helps! Best regards :)
@DasJott Does your notification daemon work?
notify-send a b
work and does it show a notification?gdbus call --session --dest org.freedesktop.Notifications --object-path /org/freedesktop/Notifications --method org.freedesktop.Notifications.GetServerInformation
report?Hey, sorry for the late response. Illness....
notify-send is what I use as a custom command anyways. And the command itself works fine. It is just not called by Thunderbird/GNotifier.
The response of the other command is as follows:
('1.2', 'DeepinNotifications', 'Deepin', '2.0')
Why do you use notify-send
as a custom command? I guess you should use the GNotifier backend, as this uses libnotify
without an additional command layer.
custom command
setting?I know, that it should. But it didn't and so I tried the custom variant. It doesn't matter, which type I choose. As you can see, GNotifier doesn't start at all.
gnotifier:Notification API init has failed! main.js:202
Not that it matters, but this is the custom command I set:
notify-send -a "Thunderbird Email" -i %image %title %text
gnotifier:Notification API init has failed! main.js:202
As there is no other log message (I assume, you would have sent previous log messages, too), I traced back the sourcecode and I guess, your notification manager doesn't propagate enough capabilites. It's the only path, I found, where nothing else is logged and notification api initialisation fails.
@DasJott Could you please give the output of gdbus call --session --dest org.freedesktop.Notifications --object-path /org/freedesktop/Notifications --method org.freedesktop.Notifications.GetCapabilities
?
@bebehei Please view this issue in github and scroll up a bit. I posted a screenshot with every logging there is. Also those before the quoted line.
The result of the command is as follows:
Fehler: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'GetCapabilities' in interface 'org.freedesktop.Notifications' at object path '/org/freedesktop/Notifications' (signature '')
I guess that pretty much explains the issue.
Just saw, you go a typo. It is Capbilities, and not Capabilities. Strange enough.
Here the result:
(['action-icons', 'actions', 'body', 'body-hyperlinks', 'body-markup'],)
@DasJott It's GetCapabilities. See https://developer.gnome.org/notification-spec/#command-get-capabilities
It's the case again, where you can reinforce all your resentments against chinese software.
Yep, you are right. So the bug is clearly somewhere else. But good to know, where it is!
Will close this one then. Thank you for your support anyway!
@mkiol I'm rethinking this: Wouldn't it be better to use the "custom command" as a whole backend? Because if you're on Linux and you've set a custom command, noone actually cares, if there is a DBus server active in the background and if it doesn't exist, there's no reason to actually fail. And additionally, a custom command is usually only used when something fails. notify-send
has got much less options than libnotify
and I don't see any actual reason to use a custom command, except when your notification daemon works differently (or doesn't stick to the spec).
@bebehei First of all thank you so much for your support on investigating this issue!
Regarding "custom command", so initial concept for this feature was to add an option that would enable external script execution for everyone who doesn't want to use dbus notifications. Actually, I'm surprised that someone runs notify-send
instead GNotifier's libnotify-based engine! But if it works, why not?
As you already mentioned, libnotify API provides much more options comparing to notify-send
but, first of all, it allows interaction with notification after it gets displayed. For instance, when you mark message as read and notification that was triggered by this message is present on your status bar, GNotifier will close this notification. Other example is Actions - thanks to callbacks provided by libnotify, GNotifier is able to execute some actions when you click on notification toast... To sum-up, with simple notify-send
it wouldn't be possible to implement most of GNotifier functionality.
Actually, I'm surprised that someone runs notify-send instead GNotifier's libnotify-based engine! But if it works, why not?
That was actually just a desparate try...
so initial concept for this feature was to add an option that would enable external script execution for everyone who doesn't want to use dbus notifications.
It seems, we're talking across each other. In the code, GNotifier
always tries to initialize the DBus or Windows Notification API. But if you're setting a curstom command you need neither of them. Currently, when you set a custom command, but your DBus API fails, you can't send notifications with the custom command. But should actually be the case, that you always can send notifications via a custom command, no matter if the DBus API would fail or not.
You're modelling it currently:
While it IMO makes more sense:
@DasJott You are 100% right. Current approach doesn't make any sense! I will fix it.
@mkiol Thank you!
At least here on Linux Arch with Thunderbird 52.6 this addon does nothing. Even the test buttons are dead.
It is simply ignored by Thunderbird, so it shows up with its own notifications. I set up a custom noticication and that also doesn't work. I can not even test, because the buttons, as already mentioned, do nothing.