Leif W wrote:
>> From: "Casey Harkins" <caseyharkins@...>
>> Sent: 2005 September 29 Thursday 11:30
>> The not-showing of conversation windows turned out to be too messy and
>> unreliable. I have a real message queue working again, using a 3 way
>> pref as suggested (always, when away, never). I have two questions:
> Great! I think the three way pref will be just awesome.
>> 1) Should the queuing be considered a core or ui functionality? It was
>> some of both in 1.x versions of gaim. The preferences were gtk
>> specific, but the code was in server.c. Currently I have it
>> implemented entirely as core functionality, because the easiest place
>> to queue is in serv_got_im() in server.c.
> I'm coming from the point of view of a novice plugin author. The core
> seems like the right place for the queue logic and the signals to be
> generated. What I hoped for was a way to hear the
> receiv(ing|ed)-(im|chat)-msg without being dependent of a UI window.
> Then I could get hooks for my plugin, process incomming messages, and
> either respond from the plugin or pass through, all while having
> messages queued.
I have "message-queued" and "message-queue-flushed" signals emitted when
a message is queued. This happens after the "receiving-im-msg" signal.
The "received-im-msg" signal is not emitted until the message is
delivered to the conversation (after the queue is flushed).
>> 2) What ideas do people have for the ui to notify the user that there
>> are queued messages waiting? How should they unqueue the messages?
>> Obviously the docklet will provide notification, but not everyone will
>> be using the docklet.
> I liked the blinking tray icon (in Windows, some UIs do that, it's least
> invasive). With the old code, however, if multiple messages were
> queued, there were some problems. With (Windows) task bar entry hidden,
> sys tray only, then double click toggles raise / lower of buddy list
> window. Double click (I think, may be mistaken) also was used to
> display queued messages. With buddly list minimized and in tray icon
> only, sometimes a double click raised the buddy list, stopped the
> blinking notice for queued messages, and showed no messages, with no
> (obvious) way to retrieve those conversations (not even logged). Also,
> with multiple queued messages, double click unconditional raised all
> queued messages and opened conversations, without any indication how
> many windows would open.
I think it was as single click not double. What I'm considering for
docklet behavior is, the icon will blink if messages are queued. A
single click on a blinking tray icon will unqueue all messages. A single
click on a non-blinking icon will toggle the buddy list visibility.
There still should be some sort of non-plugin ui for notifying users
that messages are queued. In the case of queuing when away, the messages
get unqueued automatically when the account returns from being away.
However, in the case of always queuing, without the docklet, the only
way to unqueue these messages is to change the preference from always
queue to never queue or queue when away. In either case, there is no
notification of queued messages without the docklet (or potentially some
other plugin monitoring the queue signals and providing some sort of
> Either a single left or right click on a blinking system tray icon does
> something. For either, raise a menu (if left and multiple messages) or
> add sub-menu (if right), with at least enough info to see who sent the
> msg. On the (sub) menu, options to view queued messages (greyed out as
> "(none)" if none), view one, view all, cancel one or cancel all. This
> is for the case of spammers, to avoid wasting more memory for the conv
> UIs. I was initially thinking, just a single left click to open a
> single queued message by default, or menu if multiple. But maybe I'd
> want the option to cancel even one msg. Never open anything blind.
> Could be someone trying out a vulnerabilty exploit. But some users
Sounds like overkill to me. Not sure many users would use it. If it was
an attempt at vulnerability exploit, they've already had the message
pass through most of core by this point, so it'd only theoretically
prevent against exploits in the ui code. We all know there are no
exploits in gaim anyways! :-)
However, there will be a public API to the message queue. I could expand
this a bit to allow a plugin to perform these sorts of actions on a
queue. The ultra-paranoid users could then use a plugin to view, cancel
or individually unqueue messages.
> might think it's more convenient to remain blissfully ignorant and open
> blindly, so long as it's two tenths of a second quicker, and rather deal
> with total information loss and hours (or likely in their case, weeks)
> of recovery in the event it happens. :-)
I enjoy my blissful ignorance!