amsn shouldn't use notifications with actions

[David Barth]

Binary package hint: amsn

When someone sends you an instant message while you are online, a notification bubble appears that, when clicked, displays the message. The button should be made conditional on whether the notification server supports actions.

When someone sends you an instant message while you are offline, a notification bubble appears that, when clicked, opens the login page for your Hotmail in a Web browser.

[Devid Antonio Filoni (d.filoni)]

kakaroto: can you take a look at this?

[kakaroto (kakaroto)]

Hi,
I just don't understand what your issue is. Can you be more specific ? what do you mean by "whether the notification server supports actions"??
about the second issue, it also makes no sense, it doesn't open your browser, if you get an IM while being offline, you'll see it in a chat window as an OIM.

[James Westby (james-w)]

Hi,

You can read more about this work at

  https://wiki.ubuntu.com/NotifyOSD

The issue here is that amsn appears to implement it's own notifications,
not use notification-daemon. It could be changed to not use actions, but there
is no "server" for it to query to know what it should do.

Thanks,

James

[kakaroto (kakaroto)]

Hi,
Thanks James for making it clearer.. in my mind notification server = the main MSN server being used for presence/chat (it's called the notification server) and the "supports actions" in my head meant that a peer supports receiving chat messages of type 'actions' (which is a specific msn message type).

anyways, well.... this looks complicated and we won't be planning on implementing that. You could take a look at the notify plugin for aMSN as its purpose is to replace the amsn notifications with external notifications (using 'notify-send').. If that's different than what you request then I guess it could be patched to use your own notification-daemon or something, but since this is a plugin, the aMSN team is not responsible, you would have to patch it yourself or find the original author and ask him kindly. It seems fairly easy, and the path to nofify-send is configurable, so if your application is using a notify-send compatible command arguments, then it should just work.
I hope this answers your question.

p.s: note that amsn is a Tcl program and is multiplatform, so the core code is meant to be multiplatform and use Tcl. For extra stuff like desktop integration and platform specific tasks, then a plugin would be created, which is the purpose of the 'notify' plugin : http://amsn.svn.sourceforge.net/viewvc/amsn/trunk/amsn-extras/plugins/notify/

[Mirco Müller (macslow)]

Uff... TCL well :) For the sake of completeness have a look at the jaunty notification development guidelines here http://wiki.ubuntu.com/NotificationDevelopmentGuidelines you at least find example code in C, Python and C#. That's the best I can provide right now. I'm just about to extend that document with examples for using notify-send so you could hook up those in the TCL-based program (using some TCL-equivalent of the system() call), because I don't think there are TCL-bindings for libnotify.

[kakaroto (kakaroto)]

Hi Mirco,
no there is no TCL bindings for libnotify, thanks for adding that text about notify-send in that guideline. As I said before, that's exactly what the notify plugin for aMSN does!
From your mail, it seems that you contacted the author and that you require some changes to the notify plugin for it to work on jaunty.. however I don't understand, if we use notify-send, then it should just work, right ?
Anyways, I spoke to the author in IRC, and he said that apparently (from what he understood) that the jaunty notify-send doesn't support the --timeout option.. I'd like to know more about this.. why did you drop the --timeout option? and what is the timeout if notify-send doesn't support it ? is it a global preference now or something?
Anyways, in my opinion notify-send should not fail if the --timeout option is passed, it should just ignore it if the notify-osd daemon doesn't support the timeout capability (or whatever method you use for determining that stuff), it should just ignore it and maybe output a warning. Removing the option is just a break in the API and unless you rename the tool to notify-send2 or something, then it's really bad for backward compatibility, etc...
Anyways, what solution do you propose? How can we see if the notify-send on the system is the one from jaunty or from an older version or other distro? Do we need a hack in the code to do a 'exec notify-send --help | grep timeout' to see if it supports the option ?
I personally think that all of this is not an aMSN bug, I think it should be reassigned as a notify-send bug because it breaks compatibility...

Anyways, if I misunderstood, then sorry about the rant.. then could you please explain to us in detail what exactly is it that you need modified in the notify plugin for it to be the way you like? And if some jaunty specific changes are necessary, can you describe exactly how we can do a check to see what notify-send supports or doesn't support?
And if I was right, tell me what you think about reassigning the bug as a notify-send bug since it breaks backward compatibility.

p.s: I gave the link to this bug to the plugin's author, so I think it would be best to keep all further discussion here for completeness and to keep everything public, instead of having half the info in a private mail to someone.

Thanks,
KaKaRoTo

[kakaroto (kakaroto)]

still waiting for an answer...

[Gianfranco Costamagna (costamagnagianfranco)]

So, is this a "won't fix" bug?

[Gianfranco Costamagna (costamagnagianfranco)]

Hi David and anyone else affected.
Could you please try the new amsn 0.98.9-1 from my ppa [1]?
this version is available for precise and quantal and it contains so many bug fixes.
If this doesn't fix the problem set the status back to new
[1] https://code.launchpad.net/~costamagnagianfranco/+archive/amsn

[Launchpad Janitor (janitor)]

[Expired for amsn (Ubuntu) because there has been no activity for 60 days.]