[Gambas-user] Class Implementing DBus Notifications

[Tony Morehen]

1)  I tried to be as agnostic as possible.  The reference to the Gnome 
developer's specification is there because it is the only one available 
on the web.  There is not even one on freedesktop.org.  It is my 
understanding that modern DEs conform to that spec, including KDE, 
Gnome, Cinnamon, XFCE etc.  If the server supports a current libnotify, 
then is should support my code. Btw, I'm running Xfce on Manjaro.  Wrt 
Icewm, Icewm has not been updated since 2011.  It probably implements an 
old version of the spec.  People have my code they can change to suit 
their needs.   I recommend D-feet as a Dbus explorer, so people can see 
what application names, paths and interfaces to use.

2) Yes, this was a slip on my part.  My daemon returns the 4 parts that 
I coded for, but in the back of my mind I knew that only 3 were 
official.  I've changed the code to make SpecificationVersion optional.

3) I've added 0 = no timeout to the comments on duration. Another 
oversight.  Yes, some daemons ignore the Duration variable.  In fact 
they can ignore almost any of the Send parameters.  So providing a value 
may be wishful thinking, but at least it won't generate an error.

4) You're right, you can use standard icon names.  I've renamed the 
property to IconNameOrPath and the comment to reflect this. I'd insisted 
on full path because that was the only thing that worked for me.  The 
iconname I was using was drive-harddisk-usb, which is an icon in my 
theme.  It turns out that is a non-standard icon and so needs a full 
path to work.  When I shortened it to drive-harddisk, the simple name 
worked.

5) NotifyID is supposed to be a unique unsigned integer, starting at 0 
and increasing by one for each notification message that occurs during 
the session.  You need such an Id to replace a current notification or 
to close an open one, particularly a non-expiring one.  In my system, 
that is exactly what occurs.  For example, in my AutoMount program, when 
I plug in a drive, device added pops up, which is then replaced by drive 
mounted.  I use 2 separate notifications because mounting can take some 
time.

Anyway, attached is a revised class.


On 2017-08-20 10:19 AM, adamnt42 at ...626... wrote:
> Thanks, for that Tony, some good stuff in there (the least of which is 
> that damned "hints" collection!) Since my original post and everyones 
> comments I have spent more time reading than doing. So a few comments 
> (in the most sincerest mode possible).
> 1. We (gambas "we") should strive for agnosticism. This class is very dependent on some specific implementations of the so called gnome "standard" which is turn looks very much like the "specification" for the (lousy) notify-osd daemon. ("lousy" because it was dumbed down so far that even Shuttleworth could understand it.) Your class is dependent on the notification daemon that is running on a machine to a) use DBus messaging the way those (ahem) standards and specifications state.  DE's that use non-compliant notification daemons are not supported by your code.  This is not a biggy, But one has to take care. Secondly, you are relying on the daemon DBus interface being called exactly "org.freedesktop.Notifications" which is fine for all the common ones but I did find one today (might have been for IceWM - can't remember?) that registers as "org.freedesktop.notify".
>
> 2. (Very specific) the code at line 114: result.Add(sa[3], "SpecificationVersion") is very specific to notify-osd. All the so called standards only refer to 3 required items being returned from GetServerInformation.
>
> 3. This "duration" parameter seems to be supported/interpreted/used/abused willy nilly by different daemons. In general, it "appears" that a value of 0 tends to indicate a non-disappearing notification (but then again sometimes not). It "appears" that a value of -1 is generally used to do whatever the daemon designers thought might be a good idea. It appears that other values may or may not be used as a timeout period.  In short,
> apart from the actual libnotify library (which after all is only going to pass that value on to the display daemon) its' use is rarely "the timeout before a notification is closed" ( without user interaction).
>
> 4. One thing I did find that was quite good and apparently generally broadly implemented is the use of the so called "standard" desktop icon names e.g. instead of passing a fully qualified path to a specific icon you can send one of these "names". For example, setting IconPath to, say, "task-due" will use the task-due picture depending on the users actual active icon set. The names are at: https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html#names
>
> 5. Question: In the (little) amount of playing around today I am having trouble with the "replaces_id" parameter for the notify method, i.e your $iLastNotifyID returned by the Notify function.  All I ever seem to get back is zero?? The Ubuntu spec (for notify-osd) seems to be pretty quiet about this value, but then again they refer to it elsewhere as being of significant importance? any clues?
>
> Finally, I have spent a couple of hours today building a skeleton component version of what you have put in one class.  Essentially, it exports two classes "CNotify" and "CMessage", CNotify is intended to be a facade to some (currently one) lower level worker classes that do the actual talking to the daemon. The "currently one" is the CDBusNotify class that is going to talk to ... gues what. This is sort of like the gb.gui aproach where your client project doesn't care what widget manager is actually being used. CMessage is really just a struct that carries the specific stuff for each "message"  around ( header, text and icon). Early days yet, but I'll be using a lot of your class code! So thanks again.
>
> regards
> bruce

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TerminalView.class
Type: application/x-java
Size: 19943 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20170820/e4cbaa1b/attachment.bin>