GObjectified Conversations

[Paul Aurich]

On 2010-07-21 20:28, Sadrul Habib Chowdhury wrote:
> * Richard Laager had this to say on [21 Jul 2010, 21:59:35 -0500]:
>> It seems to me that this complicates the situation with MSN, where you
>> can add a third user to a one-on-one conversation at any time. Assuming
>> this is still possible with the MSN protocol, how are we going to handle
>> that transition?
>>
>> If we can avoid this distinction in libpurple, we can leave the UI
>> decisions to the UI. On the flip side, though, I don't think we want the
>> UI to represent an IRC/Jabber/etc. room with two users the same way it
>> represents a one-on-one AIM conversation.
> 
> This is one of the primary reasons I think we should maintain the
> distinction between IM and MUC. A few of us discussed this a bit in
> devel at cpi a couple of days back, and a few of us agreed that the UI will
> need some help from libpurple to decide whether a conversation with
> one/two users is a MUC or an IM.

I personally think having a boolean flag is sufficient to give this help
to the UI, and is my preference over distinct types.

MSN (and XMPP -- XEP-0045 offers functionality somewhat akin to what MSN
does) would twiddle the flag, which presumably emits a signal, at which
point the UI adds a chat sidebar and does whatever else to turn a 1:1
into a MUC.

>> So, perhaps we'll just need a defined way to switch between the two
>> types? Even so, do we need different objects, or just a bit that flags
>> what type it is currently?
> 
> We can do that even now, since we maintain the message history in a
> PurpleConversation. So we would do something like this:
> 
>   PurpleConversation *convert_im_into_muc(PurpleConversation *im)
>   {
>     PurpleConversation *muc =
>       purple_conversation_new(TYPE_CHAT, im->account, im->name);
>     GList *iter;
>     for (iter = im->message_history; iter; iter = iter->next) {
>         PurpleConvMessage *msg = iter->data;
>         add_message_to_history(muc,
>                 msg->who, msg->alias,
>                 msg->what, msg->flags, msg->when);
>     }
>     return muc;
>   }
> 
> [treat this as pseudocode]

I'm honestly not keen on this.  I think that this method of upgrading
would be problematic, in particular because any code/plugins that
hang(s) on to a PurpleConversation* would have to know that it had been
replaced, which necessitates they all contain glue code to listen for
that signal and then replace the pointer everywhere, when it would be
much easier to just keep the same object around with a twiddled bit
(then only things that need to know about a 1:1->MUC change have to
listen for a signal/check the bit as needed). :)

~Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100721/058cd84a/attachment.sig>