"headline" messages should not ask to be acknowledged

[tobutaz+bugs@…]

headline messages are meant for transient messages like feeds (using eg the jabrss bot).

A notification that times-out after 5 seconds would be perfect for them.

The current way of queuing them and displaying them as pop-ups that have to be opened then closed one by one is really bad; past headlines should simply be dropped, kept into the history at most.

[asterix]

this will be improved with #1525

[anonymous]

I hope you'll consider the "just notifications, no window at all" idea!

[asterix]

that's hard to do, imagine you get a huge message, do you want to see a full screen popup ?

[anonymous]

The notification could be snipped.

I don't have a problem if clicking the notification gives me a window, I just want not to have to open then close a window in the 99% of cases when a quick notification is enough.

[anonymous]

Maybe the bug should be renamed: "headline messages should not ask to be acknowledged".

What I think is wrong is just that they change the status icon, the contact's icon, and are queued for later.

[asterix]

ok I see what you mean, Gajim is not designed to loose a message untill you really read it. Maybe a new option in #1005 could do what you want

[anonymous]

That daunting preference screen in #1005 is not needed in this case, because it would just be done automatically for headline messages, not the rest.

As far as I know headline is only used for feeds and IRC MOTDs, those are time-sensitive and can safely be lost. I've found the time-sensitive and automated properties are mentioned in the specs.

   o  headline -- The message is probably generated by an automated
      service that delivers or broadcasts content (news, sports, market
      information, RSS feeds, etc.).  No reply to the message is
      expected, and a compliant client SHOULD present the message in an
      interface that appropriately differentiates the message from
      standalone messages, chat sessions, or groupchat sessions (e.g.,
      by not providing the recipient with the ability to reply).

-- From http://tools.ietf.org/html/rfc3921

headline -- Messages with a 'type' attribute whose value is "headline" SHOULD NOT be stored offline, since such messages are usually time-sensitive.

-- From http://www.xmpp.org/extensions/xep-0160.html

[asterix]

I agree to not store them, at least by default. A user may want to save them anyway.

but I don't know where you see it can be lost. I mean if I'm not in front of my computer when they arrive I have no way to see them with the solutino you propose!

I see no reason to destroy them as soon as they are shown in a popup window.

[anonymous]

I am in fact all right with losing them when I'm not in front of my computer.

True I can only say that because I know what kind of headline messages I receive; I don't think any application writer would make the mistake of sending headline messages when the message is, in fact, critical, or was written by a human instead of being the automated kind.

Imagining I have time to hack on this tonight, would you accept a patch doing what I suggested? Or would you accept a patch that does the same but also added a preference:

• [tab] Events
  • [text] Headlines are [insert quick explanation here]
  • [checkbox] if I miss a headline, don't keep it for later

[asterix]

until #1525 and #1005 are done, we can indeed have an advanced option to do that, no need of a GUI option. So yes this could go in trunk.