From: Leif W <war...@us...> - 2005-09-19 14:33:55
|
Well, here's a nut I coulkdn't crack a while back when playing with my own plugin. Now I see another plugin author with a similar problem (Autoreply). If there's something I don't understand, please advise. If messages are queued, there's no signal or any indication that something arrived, and no way to respond, because no conversation exists. This makes a conversation dependant on the UI existing. However, the message was sent from another user, and it did arrive at Gaim, so it is somewhere. Is there any other option to get some sort of hook to a conversation to send messages back while incoming messages are queued? In the case of my plugin, my goal is to specify text patterns for triggers, and either respond with some static text, or call a program to generate text and send that back. I'd be using this in IRC chat most often, with trigger requests received by chat or IM, and responses sent by IM, and as a result total strangers will commonly make use of a trigger. They won't expect me to manually chat with them. In the case of receive by chat, send by im, the response would require a new conversation window. :-\ I don't want that. I simply want to log the request and response, perhaps with my plugin. With new messages queued, chats are still received, so no problem. In the case of receive by im, send by im, then it could be IRC or any other protocol. I may or may not have a window open and actually talking. Ideally, I would not want any of that to clutter a conversation. But it would be ok for now if I use an existing conversation window. However, I don't want to create a new one. With new messages queued, I won't know if any IMs arrive and can't scan for a trigger, unless I already have a conversation window open. 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 |
From: Luke S. <lsc...@us...> - 2005-09-19 21:26:08
|
On Mon, Sep 19, 2005 at 10:33:38AM -0400, Leif W wrote: > Well, here's a nut I coulkdn't crack a while back when playing with my > own plugin. Now I see another plugin author with a similar problem > (Autoreply). If there's something I don't understand, please advise. > > If messages are queued, there's no signal or any indication that > something arrived, and no way to respond, because no conversation > exists. This makes a conversation dependant on the UI existing. > However, the message was sent from another user, and it did arrive at > Gaim, so it is somewhere. Is there any other option to get some sort of > hook to a conversation to send messages back while incoming messages are > queued? There is not. See below. > <snip> > > 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 |
From: Leif W <war...@us...> - 2005-09-19 22:41:55
|
> 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 |
From: Casey H. <cas...@gm...> - 2005-09-26 05:01:43
|
Luke Schierer wrote: <snip> > > 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. > I'd like to offer up a possible solution. Queuing is broken/disabled in HEAD right now (some would argue it was broken before too). In the process of revamping the docklet, I came up with a solution to implement the hide new messages until tray icon is clicked feature without requiring a queue at all. Instead, I added a flag in gtkconv.c which will block conversation windows from being shown. In addition, I added two functions to gtkconv.c to hide/show all conversation windows. It works like this... When the buddy list is hidden to the docklet and the queue preference is set, the docklet sets the flag in gtkconv to not show new conversations. When the buddy list is un-hidden, it unsets this flag and calls the function to show all conversations, ensuring that any new conversation windows get shown. This gives the illusion of queuing, without actually queuing. With this approach, the signals are emitted as normal and logging will happen if enabled. The only quirk is if a conversation window is already open, a new conversation could still be added to that window since it is already visible. I'm still working on the docklet, but I've thrown up a work-in-progress patch if anyone would like to take a look at this approach: http://www.upl.cs.wisc.edu/~charkins/gaim/gaim-docklet-WIP.patch Thoughts? I'd be happy to work on fixing the away queuing feature using this approach if others feel its reasonable. -casey |
From: Leif W <war...@us...> - 2005-09-26 05:42:06
|
> From: "Casey Harkins" <cas...@gm...> > Sent: 2005 September 26 Monday 01:01 > It works like this... > > When the buddy list is hidden to the docklet and the queue preference > is set, the docklet sets the flag in gtkconv to not show new > conversations. When the buddy list is un-hidden, it unsets this flag > and calls the function to show all conversations, ensuring that any > new conversation windows get shown. This gives the illusion of > queuing, without actually queuing. > > With this approach, the signals are emitted as normal and logging will > happen if enabled. The only quirk is if a conversation window is > already open, a new conversation could still be added to that window > since it is already visible. I can't test at the moment. However, one thing. If I have some feature to queue messages, I'd like them to flash in the tray, regardless if the Gaim taskbar entry is shown, regardless if the buddy list is visible or sent to tray, regardless if I have any other windows open. I hate typing mid-stream, or web surfing, and a chat pops up. Or I'm working with people looking over my shoulder, and a private conversation pops up. I think new signals would be in order, to distinguish between a message received, conversation created, a message queued, and user interface conversation is drawn. No, I'm not aware of the issues with the code at present (only briefly familiarized with 1.4.0), or if it's a radical suggestion, or chicken/scrambled eggs problem, but these are primary logical distinctions that a user will experience, and thus a programmer should be able to listen to and do something at each event if necessary or desired. As for my original post, there's kind of a cumbersome workaround, to get the data from other data structures (account, protocol, sender), but no idea if any of it gets handled properly for logging purposes. Well, thanks for looking into it! Best of luck! Leif |
From: Kevin M S. <ke...@si...> - 2005-09-26 08:58:37
Attachments:
signature.asc
|
Casey Harkins wrote: > Luke Schierer wrote: > <snip> >> >> 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.= >> >=20 > I'd like to offer up a possible solution. Queuing is broken/disabled in= > HEAD right now (some would argue it was broken before too). In the > process of revamping the docklet, I came up with a solution to implemen= t > the hide new messages until tray icon is clicked feature without > requiring a queue at all. Instead, I added a flag in gtkconv.c which > will block conversation windows from being shown. In addition, I added > two functions to gtkconv.c to hide/show all conversation windows. >=20 > It works like this... >=20 > When the buddy list is hidden to the docklet and the queue preference i= s > set, the docklet sets the flag in gtkconv to not show new conversations= =2E > When the buddy list is un-hidden, it unsets this flag and calls the > function to show all conversations, ensuring that any new conversation > windows get shown. This gives the illusion of queuing, without actually= > queuing. I like your idea, but the implementation being based on the buddy list doesn't work the way most people will expect it to. The docklet queuing should queue messages when the preference is set regardless of the state of the buddy list. Honestly, the buddy list state has very little to do with whether I want to see conversations. I see there are two options in the docklet prefs panel now. The idea to have conversations hide with the buddy list is neat, though not something I will use. I'm having trouble testing the original queuing option, because it keeps adding new conversations to my existing conversation window instead of queuing them. Is that functionality working using the same basic implementation as the blist hiding/showing? Queuing in the docklet should cause it to blink to indicate new messages are available, and a click should cause the messages to appear. Also, you might want to consider making it so the docklet can suppress or change the sound effect to indicate that a message has been queued instead of released to the wild. > With this approach, the signals are emitted as normal and logging will > happen if enabled. The only quirk is if a conversation window is alread= y > open, a new conversation could still be added to that window since it i= s > already visible. That's definitely something that needs to be fixed, of course. > I'm still working on the docklet, but I've thrown up a work-in-progress= > patch if anyone would like to take a look at this approach: > http://www.upl.cs.wisc.edu/~charkins/gaim/gaim-docklet-WIP.patch I'm definitely pleased to see you cleaned out the docklet hacks from Gaim and moved them into the plugin. You seem to have left a stray gaim_gtk_blist_docklet_add(); in docklet.c. Unresolved symbols cause the plugin not to load. > Thoughts? I'd be happy to work on fixing the away queuing feature using= > this approach if others feel its reasonable. The away feature is similar, but without the docklet as a place to queue the messages, they need to "go" somewhere in terms of notifying the user that messages are waiting since the "Away!" window is now gone. We cannot assume the existence of or use the docklet, though the docklet implementation is welcome to optionally hook onto these queued messages and blink if it wants (I think it probably should as it used to). To that end, Gaim probably needs to be able to know if and/or how many messages are currently hidden, so that it can know that it has some waiting to be shown and let the user know somewhere in the UI. For that reason, it may make sense to re-port the code back into Gaim's core so that Gaim itself handles queuing or "non-showing...ness" of conversations, then provide functions/signals/handlers to allow plugins to help get conversations in and out of this state as well as find those that are. > -casey Kevin |
From: Casey H. <cas...@gm...> - 2005-09-26 15:34:06
|
Kevin M Stange wrote: > I like your idea, but the implementation being based on the buddy list > doesn't work the way most people will expect it to. The docklet queuing > should queue messages when the preference is set regardless of the state > of the buddy list. Honestly, the buddy list state has very little to do > with whether I want to see conversations. Only the docklet "queuing" is based on the buddy list being visible. This is the same behavior as in 1.x.x versions. This could be changed however to queue all "new" conversations, regardless of whether the buddy list is visible. We definitely don't want to queue all messages or you won't be able to carry on a reasonable conversation as you'd have to click the icon every time. > I see there are two options in the docklet prefs panel now. The idea to > have conversations hide with the buddy list is neat, though not > something I will use. I'm having trouble testing the original queuing > option, because it keeps adding new conversations to my existing > conversation window instead of queuing them. Is that functionality > working using the same basic implementation as the blist hiding/showing? The new docklet pref was requested in some RFE's, so I added support for it in. As I mentioned, there is currently a quirk that if a conversation is visible, new conversations will be added as tabs to that window. I'm working on a solution to that as well to get it back to the original behavior. If you close all conversations and minimize to the docklet, the queuing should work (if you have the pref set). > Queuing in the docklet should cause it to blink to indicate new messages > are available, and a click should cause the messages to appear. Also, > you might want to consider making it so the docklet can suppress or > change the sound effect to indicate that a message has been queued > instead of released to the wild. This would require using a real queue and for some new signals to be added. Maybe that would be the better approach. > >>With this approach, the signals are emitted as normal and logging will >>happen if enabled. The only quirk is if a conversation window is already >>open, a new conversation could still be added to that window since it is >>already visible. > > > That's definitely something that needs to be fixed, of course. Yup. :-) > >>I'm still working on the docklet, but I've thrown up a work-in-progress >>patch if anyone would like to take a look at this approach: >> http://www.upl.cs.wisc.edu/~charkins/gaim/gaim-docklet-WIP.patch > > > I'm definitely pleased to see you cleaned out the docklet hacks from > Gaim and moved them into the plugin. Yeah, though some might miss those wonderful comments: "Get this out of here", "Move this! HACK! :( Aww..." and "UGLY HACK OF THE YEAR". > You seem to have left a stray gaim_gtk_blist_docklet_add(); in > docklet.c. Unresolved symbols cause the plugin not to load. Thanks. Missed that one. > > The away feature is similar, but without the docklet as a place to queue > the messages, they need to "go" somewhere in terms of notifying the user > that messages are waiting since the "Away!" window is now gone. We > cannot assume the existence of or use the docklet, though the docklet > implementation is welcome to optionally hook onto these queued messages > and blink if it wants (I think it probably should as it used to). > > To that end, Gaim probably needs to be able to know if and/or how many > messages are currently hidden, so that it can know that it has some > waiting to be shown and let the user know somewhere in the UI. For that > reason, it may make sense to re-port the code back into Gaim's core so > that Gaim itself handles queuing or "non-showing...ness" of > conversations, then provide functions/signals/handlers to allow plugins > to help get conversations in and out of this state as well as find those > that are. > The code necessary to make this work is in gtkconv.c with this patch. To implement the away queuing, gaim just needs to call: gaim_gtk_conversations_set_show_enabled(FALSE); To disable the away queuing and show any queued messages: gaim_gtk_conversations_set_show_enabled(TRUE); gaim_gtk_conversations_show_all(); As for the number of "queued" messages, the notify plugin figures this out, but its not pretty. It'd be nice if gaim conversations kept track themseleves of the count of unseen messages and emitted a signal when it changes. -casey |
From: Kevin M S. <ke...@si...> - 2005-09-26 22:31:20
Attachments:
signature.asc
|
Casey Harkins wrote: > Kevin M Stange wrote: >> I like your idea, but the implementation being based on the buddy list= >> doesn't work the way most people will expect it to. The docklet queui= ng >> should queue messages when the preference is set regardless of the sta= te >> of the buddy list. Honestly, the buddy list state has very little to = do >> with whether I want to see conversations. >=20 > Only the docklet "queuing" is based on the buddy list being visible. > This is the same behavior as in 1.x.x versions. This could be changed > however to queue all "new" conversations, regardless of whether the > buddy list is visible. We definitely don't want to queue all messages o= r > you won't be able to carry on a reasonable conversation as you'd have t= o > click the icon every time. >=20 The docklet queuing was never based on the buddy list being visible. It simply queued new conversations in the docklet. If a conversation was available and visible for the given user, it wrote messages into that conversation, otherwise the conversation was not shown until you clicked the docklet icon. The state of the buddy list was never relevant. It doesn't seem logical to me that having the buddy list hidden should have any impact on whether or not messages are queued. I'm pretty sure I remember this correctly, as I used to use the feature. Kevin |
From: Casey H. <cas...@gm...> - 2005-09-26 23:19:42
|
Kevin M Stange wrote: > The docklet queuing was never based on the buddy list being visible. It > simply queued new conversations in the docklet. If a conversation was > available and visible for the given user, it wrote messages into that > conversation, otherwise the conversation was not shown until you clicked > the docklet icon. The state of the buddy list was never relevant. It > doesn't seem logical to me that having the buddy list hidden should have > any impact on whether or not messages are queued. > > I'm pretty sure I remember this correctly, as I used to use the feature. Yup, you've got it right, I had it wrong. After giving it some more thought today, I think having a queue is a better way to go. So, I'm going to work on getting a queue working first. I'll get a patch up in the tracker soon for discussion. I'll continue working on the other aspects of the docklet in a separate copy of the tree so the queuing patch can be considered on its own. -casey |
From: Tim R. <tim...@co...> - 2005-09-26 12:35:10
|
Casey Harkins wrote: > I'm still working on the docklet, but I've thrown up a work-in-progress > patch if anyone would like to take a look at this approach: > http://www.upl.cs.wisc.edu/~charkins/gaim/gaim-docklet-WIP.patch Hm, no one's complained the patch isn't in unified diff format yet? > Thoughts? I'd be happy to work on fixing the away queuing feature using > this approach if others feel its reasonable. That sounds like a reasonable approch. I would probably move the preference to a 3 way pref in the ui, to queue messages always, never, or when away. I would think queueing should be possible with or without the docket. The docket would then just provide an extra means to knowing that messages are in the queue, and poping open the first conversation. --Tim |
From: Casey H. <cas...@gm...> - 2005-09-26 15:41:59
|
Tim Ringenbach wrote: > Casey Harkins wrote: > > I'm still working on the docklet, but I've thrown up a work-in-progress > >> patch if anyone would like to take a look at this approach: >> http://www.upl.cs.wisc.edu/~charkins/gaim/gaim-docklet-WIP.patch > > > Hm, no one's complained the patch isn't in unified diff format yet? Yuck. Sorry about that, just threw it up quick and forgot the -u. > >> Thoughts? I'd be happy to work on fixing the away queuing feature >> using this approach if others feel its reasonable. > > That sounds like a reasonable approch. I would probably move the > preference to a 3 way pref in the ui, to queue messages always, never, > or when away. I would think queueing should be possible with or without > the docket. The docket would then just provide an extra means to knowing > that messages are in the queue, and poping open the first conversation. > I just realized that with my approach there could be some odd interaction between the docklet/away if they are both flipping the switch in gtkconv to show/not-show conversations. The 3-way pref in the ui could potentially fix this, as it'd be controlled entirely in the ui, not from the docklet. -casey |
From: Casey H. <cas...@gm...> - 2005-09-29 15:30:30
|
Tim Ringenbach wrote: > > > That sounds like a reasonable approch. I would probably move the > preference to a 3 way pref in the ui, to queue messages always, never, > or when away. I would think queueing should be possible with or without > the docket. The docket would then just provide an extra means to knowing > that messages are in the queue, and poping open the first conversation. > 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: 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. 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. -casey |
From: Leif W <war...@us...> - 2005-09-29 17:37:58
|
> From: "Casey Harkins" <cas...@gm...> > 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. > 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. 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 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. :-) Leif |
From: Casey H. <cas...@gm...> - 2005-09-29 20:34:25
|
Leif W wrote: >> From: "Casey Harkins" <cas...@gm...> >> 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 indication). > 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! > Leif > -casey |
From: Leif W <war...@us...> - 2005-09-30 02:05:30
|
> From: "Casey Harkins" <cas...@gm...> > Sent: 2005 September 29 Thursday 16:34 > > 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). So like this? If so, sounds good. Set Gaim -> Pref -> Queue Option Incoming message. Emit "receiving-im-msg" signal. Queue message. Emit "message-queued" signal. Gaim sits around until (one or) all messages are unqueued. Emit "message-queue-flushed". Draw UI conversation. Emit "received-im-msg" signal. > 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. I've not used the Linux version in a while, so I forget how it differs in various window managers. But in Windows, it is definitely double click for toggling buddy list. So I think single click might be how to unqueue, regardless what I forgot. ;-) So long as a double click doesn't eat a click, trigger unqueue, and not toggle, and so long as it does not do it all. ;-) > 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. Well, if there's some means to tweak this as a plugin, and I write such a plugin for myself or anyone who wants it, then great. I would not like to be bombarded when returning. I'll get to it in my own time. ;-) > 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 indication). So if I uncheck the System Tray Icon plugin, I can't always queue? Can't there be a notification on the buddy list, like a pseudo-buddy who comes online, name like "Queued Messages", which you click and open them all (or a selector). Again, if it can be achieved by plugin, great, then maybe another thing I'd eventually tweak. > Sounds like overkill to me. Not sure many users would use it. Forget everything but the desire to select what I want when I want. Or at the very least notify me how many messages I'm going to open, and give me the chance to make the decision. Please do not just dump it all to draw UI windows. I still think it's a bad idea to open an unspecified number of conversations, with no way out. > However, there will be a public API to the message queue. I could > expand I look forward to it. Thanks for all your efforts! > 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. It's not paranoia, it's sensible precaution. Maybe you've never been in such situations where it was needed, or when you made others wish it existed, and so don't fully appreciate. ;-) > I enjoy my blissful ignorance! I did too! But I have it no longer. ;-) Anyways, whatever, not going to beat a dead horse. It'd still be a great compromise to at least have the hooks available and do what I want for myself in a plugin, so I don't have to maintain private patches to Gaim as well. :-) Leif |
From: Casey H. <cas...@gm...> - 2005-09-30 04:24:48
|
Leif W wrote: > So like this? If so, sounds good. > > Set Gaim -> Pref -> Queue Option > Incoming message. > Emit "receiving-im-msg" signal. > Queue message. > Emit "message-queued" signal. > Gaim sits around until (one or) all messages are unqueued. > Emit "message-queue-flushed". > Draw UI conversation. > Emit "received-im-msg" signal. Yup, that's how I have it working now. > > I've not used the Linux version in a while, so I forget how it differs > in various window managers. But in Windows, it is definitely double > click for toggling buddy list. So I think single click might be how to > unqueue, regardless what I forgot. ;-) So long as a double click > doesn't eat a click, trigger unqueue, and not toggle, and so long as it > does not do it all. ;-) Been a while since I've used the windows version, but I'll take your comments into account when I get back to work on the docklet. I wasn't planning on changing the original behavior, so we should be fine there. >> 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 indication). > > > So if I uncheck the System Tray Icon plugin, I can't always queue? Can't > there be a notification on the buddy list, like a pseudo-buddy who comes > online, name like "Queued Messages", which you click and open them all > (or a selector). Again, if it can be achieved by plugin, great, then > maybe another thing I'd eventually tweak. > No, it happily will always queue without the system tray plugin. Which brings us back to my original question, what kind of ui should there be to show that there are queued messages and how to unqueue them? >> Sounds like overkill to me. Not sure many users would use it. > > > Forget everything but the desire to select what I want when I want. Or > at the very least notify me how many messages I'm going to open, and > give me the chance to make the decision. Please do not just dump it all > to draw UI windows. I still think it's a bad idea to open an > unspecified number of conversations, with no way out. > This is how it worked previously and I think you're the only one I've heard think this is a problem. Unless there is an overwhelming desire for this, I don't think its worth complicating the ui over. The message queuing api will provide various ways to count the messages in the queue (total count, total per account, maybe per buddy/conversation). The docklet for example will use this to show the total count in a tooltip. As I said before, I'll make sure there is a suitable API to muck with the queuing so that a plugin could accomplish some of these goals. > > Anyways, whatever, not going to beat a dead horse. It'd still be a > great compromise to at least have the hooks available and do what I want > for myself in a plugin, so I don't have to maintain private patches to > Gaim as well. :-) I'm glad you've brought these issues up, so I can take them into account in the queue api. Thanks! -casey |
From: Adil <ad...@ya...> - 2005-09-30 04:45:21
|
Hi. I think the message-queueing thing can be done from a plugin, without much/any change in the core. I have written a "demo-plugin" which starts queueing messages when you first click `Tools -> Plugin Actions -> MsgQ'. It stops queueing and spits out all the queued messages when you click it again. (clicking the menu toggles queueing on and off. it's always off at the beginning) Here is a link: http://sadrul.no-ip.org:1337/~sadrul/gaim/msgq.c Is it at all relevant? -- Adil --- Casey Harkins <cas...@gm...> wrote: > Leif W wrote: > > So like this? If so, sounds good. > > > > Set Gaim -> Pref -> Queue Option > > Incoming message. > > Emit "receiving-im-msg" signal. > > Queue message. > > Emit "message-queued" signal. > > Gaim sits around until (one or) all messages are unqueued. > > Emit "message-queue-flushed". > > Draw UI conversation. > > Emit "received-im-msg" signal. > > Yup, that's how I have it working now. > > > > > I've not used the Linux version in a while, so I forget how it differs > > > in various window managers. But in Windows, it is definitely double > > click for toggling buddy list. So I think single click might be how > to > > unqueue, regardless what I forgot. ;-) So long as a double click > > doesn't eat a click, trigger unqueue, and not toggle, and so long as > it > > does not do it all. ;-) > > Been a while since I've used the windows version, but I'll take your > comments into account when I get back to work on the docklet. I wasn't > planning on changing the original behavior, so we should be fine there. > > >> 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 indication). > > > > > > So if I uncheck the System Tray Icon plugin, I can't always queue? > Can't > > there be a notification on the buddy list, like a pseudo-buddy who > comes > > online, name like "Queued Messages", which you click and open them all > > > (or a selector). Again, if it can be achieved by plugin, great, then > > maybe another thing I'd eventually tweak. > > > > No, it happily will always queue without the system tray plugin. Which > brings us back to my original question, what kind of ui should there be > to show that there are queued messages and how to unqueue them? > > >> Sounds like overkill to me. Not sure many users would use it. > > > > > > Forget everything but the desire to select what I want when I want. > Or > > at the very least notify me how many messages I'm going to open, and > > give me the chance to make the decision. Please do not just dump it > all > > to draw UI windows. I still think it's a bad idea to open an > > unspecified number of conversations, with no way out. > > > > This is how it worked previously and I think you're the only one I've > heard think this is a problem. Unless there is an overwhelming desire > for this, I don't think its worth complicating the ui over. The message > queuing api will provide various ways to count the messages in the queue > > (total count, total per account, maybe per buddy/conversation). The > docklet for example will use this to show the total count in a tooltip. > As I said before, I'll make sure there is a suitable API to muck with > the queuing so that a plugin could accomplish some of these goals. > > > > > Anyways, whatever, not going to beat a dead horse. It'd still be a > > great compromise to at least have the hooks available and do what I > want > > for myself in a plugin, so I don't have to maintain private patches to > > > Gaim as well. :-) > > I'm glad you've brought these issues up, so I can take them into account > > in the queue api. Thanks! > > -casey > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Gaim-devel mailing list > Gai...@li... > https://lists.sourceforge.net/lists/listinfo/gaim-devel > __________________________________________________________ Find your next car at http://autos.yahoo.ca |
From: Casey H. <cas...@gm...> - 2005-09-30 05:40:43
|
Adil wrote: > Hi. > > I think the message-queueing thing can be done from a plugin, without > much/any change in the core. I have written a "demo-plugin" which starts > queueing messages when you first click `Tools -> Plugin Actions -> MsgQ'. > It stops queueing and spits out all the queued messages when you click it > again. (clicking the menu toggles queueing on and off. it's always off at > the beginning) > > Here is a link: http://sadrul.no-ip.org:1337/~sadrul/gaim/msgq.c > > Is it at all relevant? > I considered basing the queuing off of the receiving-im-msg signal (as you do in your plugin), but it has the potential for some bad side effects. Take for example the timestamp plugin. If your plugin received the signal first, the timestamp plugin would never receive the signals. Another issue is that auto-replying when away would cause the conversations to be shown with the auto-reply message, but not the queued message. Then dequeuing would result in the messages being out of order in the conversation. With some restructuring of the message delivery process, it would be possible to implement queuing reliably in a plugin (I considered this as well). -casey |
From: Adil <ad...@ya...> - 2005-09-30 05:52:58
|
--- Casey Harkins <cas...@gm...> wrote: > Adil wrote: > > Hi. > > > > Here is a link: http://sadrul.no-ip.org:1337/~sadrul/gaim/msgq.c > > > > Is it at all relevant? > > > > I considered basing the queuing off of the receiving-im-msg signal (as > you do in your plugin), but it has the potential for some bad side > effects. Take for example the timestamp plugin. If your plugin received > the signal first, the timestamp plugin would never receive the signals. I think priority has been introduced for signal-handlers to have an order among them. So it should be possible to have this plugin be the last one to process the message. > Another issue is that auto-replying when away would cause the > conversations to be shown with the auto-reply message, but not the > queued message. Then dequeuing would result in the messages being out of > > order in the conversation. True. Haven't considered the matter of auto-replying yet. But it would be real non-difficult if the auto-reply is also included in this plugin. :) > > With some restructuring of the message delivery process, it would be > possible to implement queuing reliably in a plugin (I considered this as > > well). > Agreed. > -casey > > -- Adil __________________________________________________________ Find your next car at http://autos.yahoo.ca |
From: Adil <ad...@ya...> - 2005-09-30 16:24:22
|
--- Adil <ad...@ya...> wrote: > --- Casey Harkins <cas...@gm...> wrote: > > > Another issue is that auto-replying when away would cause the > > conversations to be shown with the auto-reply message, but not the > > True. Haven't considered the matter of auto-replying yet. But it would > be > real non-difficult if the auto-reply is also included in this plugin. :) > I have made changes so that auto-replies are also sent. For now, it's *always* sent when the messages are being queued. But that can always be changed from preferences. I have used serv_send_im -- which probably is not the recommended way of doing it. But `it works'. The adjustment probably needs to be made so that messages can be *sent* without having a conversation with an account (and without using serv_send_im). -- Adil __________________________________________________________ Find your next car at http://autos.yahoo.ca |
From: Gary K. <gr...@re...> - 2005-09-30 17:04:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > --- Adil <ad...@ya...> wrote: > >> --- Casey Harkins <cas...@gm...> wrote: >> >> > Another issue is that auto-replying when away would cause the >> > conversations to be shown with the auto-reply message, but not the >> >> True. Haven't considered the matter of auto-replying yet. But it would >> be >> real non-difficult if the auto-reply is also included in this plugin. :) >> > > I have made changes so that auto-replies are also sent. For now, it's > *always* sent when the messages are being queued. But that can always be > changed from preferences. > > I have used serv_send_im -- which probably is not the recommended way of > doing it. But `it works'. The adjustment probably needs to be made so that > messages can be *sent* without having a conversation with an account (and > without using serv_send_im). > > -- Adil I've been meaning to reply to this earlier but have been busy and dealing with getting my wisdom teeth removed. Anyways, theres been a long standing bug in Guifications about clicking a notification (to bring up the conversation) for a conversation that is queued. With the old queueing stuff I could not find a way to properly unqueue the message. So basically please make sure you make it possible to determine if a message is queued and be able to unqueue from other plugins. - -- Gary Kramlich <gr...@re...> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPW9zdf4lmqisgDIRAjAMAJ4vFp7MGL2YFpRDECWSdDqLeVvLFwCfX82W 6e1tIr3e9lgBVtUx783y1D8= =vDmj -----END PGP SIGNATURE----- |
From: Casey H. <cas...@gm...> - 2005-10-02 20:38:57
|
Gary Kramlich wrote: >>I have made changes so that auto-replies are also sent. For now, it's >>*always* sent when the messages are being queued. But that can always be >>changed from preferences. >> >>I have used serv_send_im -- which probably is not the recommended way of >>doing it. But `it works'. The adjustment probably needs to be made so that >>messages can be *sent* without having a conversation with an account (and >>without using serv_send_im). >> What if a user wants an auto-reply without queuing, would they think to load the queuing plugin? Auto-reply could be moved into its own plugin, with some sort of optional dependency on the queuing plugin. I'm not convinced that doing this in a plugin is the right approach. It will limit other plugins from being able to count on a queuing system being available to muck with. What do others think? > > I've been meaning to reply to this earlier but have been busy and dealing > with getting my wisdom teeth removed. Anyways, theres been a long > standing bug in Guifications about clicking a notification (to bring up > the conversation) for a conversation that is queued. With the old > queueing stuff I could not find a way to properly unqueue the message. So > basically please make sure you make it possible to determine if a message > is queued and be able to unqueue from other plugins. > With my current queuing code, you would receive the "message-queued" signal instead of the "received-im-msg" signal. Assuming there were some notification based on the "message-queued" signal, clicking that notification could call into the queuing api telling it to dequeue messages for that account/buddy (which would in turn emit the "received-im-msg" signal). It would probably be helpful to add bit to the GaimMessageFlags so handlers of the "received-im-msg" signal know if the message came through the queue or not. (Maybe use the GAIM_MESSAGE_DELAYED flag, which is currently only used for chat messages?). The queuing code is mostly ready. I'm just waiting on the account-status-changed signal (patch #1227231) or the account-away/account-back signals (patch #1306359) to make it into HEAD before I submit it to the tracker. I still need to add some non-plugin ui for notifying the user that there are queued messages and providing them a means to dequeue. -casey |
From: Adil <ad...@ya...> - 2005-10-02 22:35:37
|
--- Gary Kramlich <gr...@re...> wrote: > > --- Adil <ad...@ya...> wrote: > > > >> --- Casey Harkins <cas...@gm...> wrote: > >> > So > basically please make sure you make it possible to determine if a > message > is queued and be able to unqueue from other plugins. > I have arranged for a few signals (message-queue-queued, -dequeued, -peek, -extract, -get-all) that can be used by other plugins to communicate with this one. The first two are not implemented yet. The last three enables a plugin to (-peek): take the first message from a contact (without removing from the queue), (-extract): extract and remove the first message from a contact, and (-get-all): get all the queued messages from all the contacts in a hash-table. (The implementation of the signals might be off a bit. I haven't been able to test that part of the code at all) I hope this is going on the right track. (The link is http://sadrul.no-ip.org/~sadrul/gaim/msgq.c if anyone decides to take a look) -- Adil __________________________________________________________ Find your next car at http://autos.yahoo.ca |
From: Casey H. <cas...@gm...> - 2005-10-02 22:16:12
|
Adil wrote: > > I have arranged for a few signals (message-queue-queued, -dequeued, -peek, > -extract, -get-all) that can be used by other plugins to communicate with > this one. The first two are not implemented yet. The last three enables a > plugin to > (-peek): take the first message from a contact (without removing from the > queue), > (-extract): extract and remove the first message from a contact, and > (-get-all): get all the queued messages from all the contacts in a > hash-table. > > (The implementation of the signals might be off a bit. I haven't been able > to test that part of the code at all) I don't have time to check the source, but isn't registering signals from a plugin a bad idea? I would assume that a signal_connect requires that the signal has already been signal_register'ed. If so, loading this plugin after say the docklet/guifications/notify plugins are loaded (which would want to connect to those signals) would prevent those plugins from properly registering for the signals. If not, this is a clever use of the signals for solving the optional plugin dependency issue. I'd rather not duplicate effort on this, so if you want to continue working on the queuing I'll focus on some other pieces that need some love. I can post what I've got for adding queuing in core. Any of developers have an opinion on whether queuing should be in a plugin or core? -casey |
From: Ethan B. <ebl...@cs...> - 2005-10-02 17:19:28
|
Hey, sorry for the delay here. Casey Harkins spake unto us the following wisdom: > 1) Should the queuing be considered a core or ui functionality? It was=20 > some of both in 1.x versions of gaim. The preferences were gtk specific,= =20 > but the code was in server.c. Currently I have it implemented entirely=20 > as core functionality, because the easiest place to queue is in=20 > serv_got_im() in server.c. I don't see the logic in putting queueing in the core. In my mind, it is entirely a user interface issue ... therefore, I think it belongs in the UI. The disadvantage I see to this is that more than one UI may indeed want to implement queueing in some fashion, so conceptual home and practical home may differ in this case. The right solution might be to implement this in two sort of "layers", one UI-agnostic and one Gtk+-specific, but then put them both in the UI; one might even envision building up a small library of such UI-specific functions which are yet toolkit-agnostic. > 2) What ideas do people have for the ui to notify the user that there=20 > are queued messages waiting? How should they unqueue the messages?=20 > Obviously the docklet will provide notification, but not everyone will=20 > be using the docklet. I don't really know, as I've never wanted to queue messages ... but what about something like the "typing" badge in the conversation window menu, only on the blist menu? Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |