Review Request 108896: Add a method to jump to know what's the next active conversation

[Lasath Fernando]

> On Feb. 12, 2013, 3:56 p.m., Lasath Fernando wrote:
> > KTp/Declarative/conversations-model.h, line 55
> > <http://git.reviewboard.kde.org/r/108896/diff/1/?file=113528#file113528line55>
> >
> >     I don't think this is the right way to go.
> >     
> >     If you look at https://git.reviewboard.kde.org/r/107833/diff/#1 , you'll see that I greatly simplified ConversationQueueManager.
> >     I considered replacing it with this approach, but I kept it around for 2 reasons. 
> >     
> >     1. It helps get rid of the *horrible* binding loop with base.currentIndex.
> >     2. I want to have the possibility of this working across multiple instances of this plasmoid (which should be possible, since K_GLOBAL_STATIC should ensure there's only one instance across all of plasma).
> 
> Aleix Pol Gonzalez wrote:
>     1. What binding loop are you talking about?
>     
>     2. this won't work, the activate shortcut is targeted to 1 plasmoid. If we want something more sophisticated, it should be considered KTp-wide. (as in it should focus a window, if there's a chat on a window as well)

1. I can't run the plasmoid atm so I can't tell you exactly. But IIRC it was something to do with the kludge that kept the currentIndex of the model, the visible property of the delegate (button) and the visible property of the Dialog as well as the visibleToUser property of the model in sync, trying (but failing) to propagate the changes in both directions. I've been wanting to redesign that for a long time and I don't think we should be using the 'index' of a conversation any more than we have to at this stage.

2. Having a KTp-wide solution would be nice, but a little out of scope (and I don't know how we could such a thing). But the approach in my patch should work because each plasmoid would have a ConversationQueueManager exposed to it, and since it's internally a global static anyway, they should all share the same queue. Then when any plasmoid calls dequeueNext(), the ConversationQueueManager would call a method in the MessagesModel which will emit a signal to the appropriate plasmoid which will make the conversation visible. Makes sense? :-)


- Lasath


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108896/#review27308
-----------------------------------------------------------


On Feb. 11, 2013, 12:57 a.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108896/
> -----------------------------------------------------------
> 
> (Updated Feb. 11, 2013, 12:57 a.m.)
> 
> 
> Review request for Telepathy and David Edmundson.
> 
> 
> Description
> -------
> 
> This way, we can have a key binding to jump to the next important conversation.
> This new method is used in: https://git.reviewboard.kde.org/r/108897/
> 
> 
> Diffs
> -----
> 
>   KTp/Declarative/conversations-model.h 60bd6dc 
>   KTp/Declarative/conversations-model.cpp 2c6007f 
> 
> Diff: http://git.reviewboard.kde.org/r/108896/diff/
> 
> 
> Testing
> -------
> 
> manual testing :/
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20130212/6fc15ba3/attachment.html>