Re: [Gaim-devel] signals and (queued vs. received) (im or chat)

[Leif W <war...@us...>]

> From: "Luke Schierer" <lsc...@us...>
> Sent: 2005 September 19 Monday 17:25
>
>> On Mon, Sep 19, 2005 at 10:33:38AM -0400, Leif W wrote:
>>
>> I'm just curious why the UI and the core are so tightly bound in this
>> case, such that no signals are sent though some message has arrived 
>> at
>> my client, merely because a UI event has not occured.  A signal for 
>> an
>> incoming queued chat or im, and a headless conversation for response
>> (regardless of existing conv) would be desired.
>>
>> Leif
>
> This is, I think, a design failure on our part.  I'm not sure why we
> (well, primarily Chipx86, but no one stopped him either) chose this
> route.  as it stands the queued messages are in some kind of
> no-man's-land, not received but clearly in gaim's memory.  I hesitate
> to suggest what the best way to fix the situation at this point is
> though.  Tim would be in a better position to direct forward progress.
>
> luke

Well, at least on the positive side, I do not have to wonder if I 
misunderstood something, or missed something entirely.

But, how else to handle this?  I was looking at the irchelper plugin for 
insight, which might be doing something similar.  It sends commands 
during 'signed-on' signals, and suppresses display of some 
'receiving-im-msg' signal.  But I guess, the receiving signal is not 
sent until the UI conv is created, and later removed.

Leif