953878 - Allow to summarize events in conversations

Status: REOPENED

(Thunderbird :: Instant Messaging, enhancement)

Description

[Benedikt Pfeifer]

*** Original post on bio 437 at 2010-07-05 09:19:00 UTC ***

Would be nice if messagestyle could summarize events in conversations.

So for example instead of several lines with grouped system messages, e.g. for people joining a channel, you could have a list of nicknames that all joined shortly after another.
Maybe it could even do that when there are different messages mixed,e.g. a LEAVE message in between wouldn't prevent the join messages to be grouped. The leave message(s) would just get an extra line like the other. 


Examples:
Old:
9:12 - ABC entered the room.
9:14 - DEF entered the room.
9:17 - GHI entered the room.

New:
9:12 - 9:17: ABC, DEF and GHI entered the room.

Comment 1

[Benedikt Pfeifer]

*** Original post on bio 437 at 2010-07-05 09:34:08 UTC ***

11:26:46 - flo: and if you have someone who is "dancing", what do you display?
11:28:59 - Mic: Good point :) Maybe consecutive joins and leaves could be cancelled and after that the grouping takes place?
11:30:34 - flo: and repetitive nick changes? :)

...

Comment 2

[Patrick Cloke [:clokep]]

*** Original post on bio 437 at 2010-09-29 20:41:45 UTC ***

Bug 953881 (bio 440) is related to this, but not an actual duplicate. 440 asks for hiding all events at the protocol level, while this is related to themeing, just wanted to point it if there's a more "proper" way to do this.

Comment 3

[Florian Quèze [:florian]]

*** Original post on bio 437 at 2010-09-30 09:04:39 UTC ***

I guess the way to fix this is to have the protocol plugins send "raw" information to the conversation rather than writing plain text status/system messages.
This way we can add preferences to decide if we want to show the messages or not, and add code that decides what to show in the conversation based on all the available data.

I don't think this should be part of the messagestyles as having localizable strings there is really a pain.
I would rather see this implemented inside the conversation binding (conversation.xml).

Comment 4

[Patrick Cloke [:clokep]]

*** Original post on bio 437 at 2010-09-30 13:31:45 UTC ***

(In reply to comment #3)
> I guess the way to fix this is to have the protocol plugins send "raw"
> information to the conversation rather than writing plain text status/system
> messages.
You mean the protocol would tell the UI "so and so has parted" and the UI would choose to display that or not?  I think that would be pretty difficult since I'm sure different protocols have different actions that can occur (or at the very least call them different things).

Also, wouldn't that require heavy editing of libpurple? :)

Comment 5

[Florian Quèze [:florian]]

*** Original post on bio 437 at 2010-09-30 15:06:47 UTC ***

(In reply to comment #4)
> (In reply to comment #3)
> > I guess the way to fix this is to have the protocol plugins send "raw"
> > information to the conversation rather than writing plain text status/system
> > messages.
> You mean the protocol would tell the UI "so and so has parted" and the UI would
> choose to display that or not?
The protocol would notify the conversation of an event with details on this event, and the conversation display would decide what should be shown to the user and how.
The adium message theme spec as something about this that Instantbird doesn't implement (yet): they have classes for the system/event messages so that different kind of messages can be themed differently.

Common events:
 left (details: username, quit message)
 joined (details: username)
 nickchange (details: old/new nick)
 away
 idle
 unaway
 unidle
 events related to file transfer
 events related to your accounts (if you are disconnected, ...) 

> I think that would be pretty difficult since
> I'm sure different protocols have different actions that can occur (or at the
> very least call them different things).
There will be unhandled cases that are displayed just like we currently do. But not so many I think :).

> Also, wouldn't that require heavy editing of libpurple? :)
Not really more than already required by making all of this really compatible with JS protocols :).

Comment 6

[Patrick Cloke [:clokep]]

*** Original post on bio 437 at 2011-02-24 16:22:47 UTC ***

In reply to comment #5)
> (In reply to comment #4)
> > Also, wouldn't that require heavy editing of libpurple? :)
> Not really more than already required by making all of this really compatible
> with JS protocols :).

I think on IRC we talked about rewriting the conversation binding to handle contacts + making it compatible w/ jsProto (people entering/leaving a channel, etc.). This might be a good time to at least think about support for this.