Ofline message flag

Richard Laager rlaager at wiktel.com
Sat Sep 8 22:56:49 EDT 2007


On Sat, 2007-09-08 at 16:04 -0500, Jorge Villaseñor wrote:
> stupid != lazy to read the exact date and hour of all messages

> Do you really
> want to read all the timestamp of the messages? or only look at the
> gtkconv and say "oh this is offline and this is not"  I like the
> second one =P

(2007-09-08 11:30:00) bob: Hey, you going to lunch?
vs.
(13:00:00) jim: Did you read that latest memo?

Telling the difference is pretty easy.

Now, we only show the full date for messages sent over 20 minutes ago,
but within that window, I'm not sure that it much matters. If it does, I
think we could probably turn that window down to just a couple of
minutes.

I really don't see "offline messages" needing any distinction at all. If
I was disconnected from the Internet for a minute and then re-connected,
I wouldn't require that messages have a different style. I think our
existing *time-based* logic makes far more sense. It's useful to know
when a message was not immediately received. This is my primary reason
for being opposed to an _OFFLINE flag. If standardization of the
time-based logic is desired, we could have the *core* set an _OFFLINE
flag based on the timestamp.

khc mentioned that we may not want to log the XMPP chat log messages
over and over, just the first time. That would be a good reason for a
_CHAT_LOG or similar message flag. We could just use the existing
_DELAYED flag for that (changing the name later, if desired), unless we
apply that flag to offline messages (see below).

I think that we *do* want to play sounds and give other notifications
for offline messages, so the current behavior for _DELAYED should not be
applied to offline messages.

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20070908/7ce8d5a1/attachment.sig>


More information about the Devel mailing list