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 |