#10 Cleaner Conversations
When a user first starts a session, the line shows up as all of your ouotgoing lines do, with the name/timestamp, then text, like this:
(01:13:33) Remote User : Hi there! Incoming Message....
(01:14:35) Me : This is my outbound message
But once a session is established, and there's a "User is typing" message, it throws the incoming text to the next line, making the conversation appear disjointed and harder to follow:
(01:15:02) RemoteUser :
This is the Text I type...
This is a Feature request to look into cleaning that up a bit. So the text is either all on the following line for both incoming and outgoing, all the time, or standard like all the other protocols, where text immediately follows the username on the same line unless the user explicitly puts a linefeed in their input.
This request is rather to Pidgin team, not SIPE.
There is clear separation of duties between the two - Pidgin is responsible for UI (User Interface) and libpurple is responsible for wire protocol. SIPE in fact is plugin to libpurple, it's duty is to talk to MS Communications Servers, it by no means render the text.
There are different UI a top of libpurple - Adium for MAC, Empathy/Telepathy-haze for GNOME for example. I'm saying that UI can be anything, and it is responsible for actual information rendering.
Ok. This only does this with the Pidgin plugin that I've found so far. If it's only an artifact from one protocol plugin, is it still the UI team's issue? If yes, I'll wander over to the Pidgin site and add it.
It's quite strange that "User is typing..." message disjoins something.
This is how it works:
1. Remote user types message and then sends it (either by pressing Enter or pressing related button in UI),
2. Pidgin(+SIPE) receives it and renders in the conversation window, prepending time and name of the user which send the text.
<end of atomic action>
3. User keep typing. Information about it is sent and received.
4. This information arrears in the UI as grey text "<User> is typing..."
After some small time interval it disappears.
<end of atomic action>
When remote sends this portion of message, steps 1 and 2 repeated. I.e. timestamp and User name will be added again to this portion of message. Do you see problem here? This is how Pidgin behave. Office Communicator 2007 does not prepend the extra info in this case, but Office Communicator 2005 does.
So it's up to UI how to render this.
Are you saying that other Pidgin plugins behave differently than SIPE?
as for extra linefeed you mentioned, it does not happen in my case.
This is how incoming messages appear in my case:
(4:50:38 PM) Alice Alisson: 1
(4:50:39 PM) Alice Alisson: 2
(4:50:40 PM) Alice Alisson: 3
(4:50:41 PM) Alice Alisson: 4
(Where 1, 2, 3, 4 - are "messages" sent from OC2007 to SIPE)
I can only get this to happen from the OC 2007 R2 thick client. It doesn't happen for session between Pidgin and the Web Client.
Odd indeed. And to clarify, I've never seen this happen with any other Protocol plugin, that was why I made the assumption it's something with Pidgin.
I'll see if I can get a trace from a conversation that causes the weirdness. If I find something odd, it might end up being a bug. Maybe.
From my experience, the new Lync client puts newlines at the end of the messages they send some times.
I would love to be able to see the raw HTML that sipe is sending to pidgin to help debug.
From my testing with Lync 2013, all group chats (persistent chats) sent from Lync to the room have newlines at the end, but messages from other pidgin-sipe clients do NOT have newlines at the end.
eg.
Pidgin1: This is a test message
Pidgin2: And another test message
Lync1: My test message from Lync
Lync1: And another message
Lync2: Whats with the whitespace dude?
Pidgin1: Your both doing it! ARGH.
Pidgin2: test
For regular person to person conversations it happens less, where its only if the user ends the message with an explicit newline, it shows as two newlines in pidgin.
Lync1: Hey there
Pidgin1: Whats up?
Lync1: I heard you like newlines, so here is one...
Pidgin1: One? There is two!
I think SIPE could remove the trailing newlines from messages to make them consistent with other protocols.
And maybe what Jay is experiencing is OCS/Lync inserting newlines at the start of the message?
AH!
I think what Jay is talking about is that the messages from the full client dont word wrap!
They must be as part of a big span, and pidgin, when printing it, will lean towards starting it on its own line if it wont fit in the line above with the nickname.