Open foresto opened 2 months ago
Not a solution to your problem (and you may not get one as the package seems to be unmaintained...), however I've written a StatusNoifierHost app and I check every StatusNotifierItem for the Menu
property. It is part of the spec and I've not come across an app that hasn't provided it.
Why not just provide an empty string?
I do appreciate the above was just an example so your issue remains valid.
Not a solution to your problem (and you may not get one as the package seems to be unmaintained...),
I'm not looking for a solution for my own code. I can work around it in the current situation. However...
Why not just provide an empty string?
I reported this because it's a general problem. It doesn't apply only to the Icon
property. (Note that I updated my example to show the same thing happening with an IconThemePath
property, which is not in that interface's spec.) More importantly, it doesn't apply only to this particular interface.
It applies any time an external program tries to access something that isn't there, whether it's in (some version of) a spec or not. Users of this library shouldn't be burdened with spurious error logs and stack traces just because some other software, outside of our control, happens to be impolite. :)
Yeah, that's totally fair (and I've come across the issue myself). However, as this package seems to be unmaintained, I doubt you'll see anything change any time soon.
When some other program on the bus tries to access a nonexistent property on a dbus-next service, BaseMessageBus currently raises an exception, and handles it by writing both a log message and a stack trace at the ERROR log level.
For example:
That's a lot of noise to have spamming my application's (and users') logs. I could silence it by disabling all dbus-next logs below CRITICAL, but then I would miss any legitimate errors if they come up.
Since an external program requesting an invalid property is not a bug in the program using dbus-next, shouldn't the log message be downgraded to DEBUG or INFO level? And shouldn't the stack trace be removed entirely?
And, if the library is going to log anything, shouldn't it also log which dbus sender tried to access the nonexistent property?