GObjectified Conversations

[Paul Aurich]

On 2010-07-22 08:56, Sadrul Habib Chowdhury wrote:
> * Mark Doliner had this to say on [21 Jul 2010, 22:30:03 -0700]:
>> On Wed, Jul 21, 2010 at 8:38 PM, Paul Aurich <paul at darkrain42.org> wrote:
>>> 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
> 
> If a plugin stores a PurpleConversation*, then it would need to clean up
> when the conversation is destroyed anyway, and since in this transition,
> a new chat is created, and the old IM is removed, thus the cleanup code
> should kick in and it should not be a problem.

Knowing that an IM is being destroyed because it's being supplanted by a
MUC (as opposed to simply being destroyed) sounds a bit tricky.  Not
impossible, but delicate, and something which which third-party
developers might run into issues.

>>> , which necessitates they all contain glue code to listen for
>>> that signal and then replace the pointer everywhere
> 
> Creation of the new chat will trigger all the relevant signals, so the
> plugin should be able to keep track of it if it wanted to, I think.
> 
>>> 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). :)
>>
>> I totally agree with Paul on this.  Aside from his well articulated
>> points, I have "a feeling" that having something simple like an
>> "always display as a multi-user chat" hint is more natural and will
>> result in cleaner code.
> 
> I am not sure I understand the 'always display as a muc' hint. Do you
> mean the UI should always display a userlist, topic for an IM too?

What I was describing is a boolean associated with a PurpleConversation
that just says "Is this a MUC?".  I definitely don't think Pidgin should
always show a userlist and topic, regardless of the decision made at
this juncture.

  * For 1:1 conversations, it's FALSE, so the UI wouldn't display a
userlist or topic.
  * When joining a MUC directly, regardless of the number of
participants, it would be set to TRUE.
  * When upgrading an IM to a MUC, it would be toggled to TRUE, which
would signal to the UI to change its display (i.e. add in the userlist
and topic).

> I thought about the toggle-bit approach, and we would need to determine
> a few things:
> 
>  * Should a conversation always maintain a userlist? When it's an IM,
>    should it return NULL or a list with me and my friend in it? If my
>    friend is included in the returned list, can it be inferred
>    (mistakenly, of course) that he is still in this conversation (i.e.
>    he has his window open)?

I'd say yes to maintaining it for an IM, with documentation noting it's
not useful for an IM, and should not be interpreted as any indication of
his/her still having the window open.

>  * What happens with the logs when the conversation type is toggled?

Keep them (maybe with a magic "message type" divider indicating this was
the point at which it changed?).  I can't speak for MSN, but XMPP's
1:1->MUC conversion (http://xmpp.org/extensions/xep-0045.html#continue)
allows for sending the history to the room, which would leverage this.

>  * What do we do if someone toggles the flag from MUC to IM?

Make the toggle-bit quasi-immutable (once set, it cannot be unset).

> 
>  * With PurpleIM and PurpleMUC, it would be possible for a plugin to
>    connect to signals of only one class if it so desires, and not have
>    to check for the type of the conversation from the callbacks. This is
>    clearly not a significant advantage, it seems kind of nice.

True.

> Right now, PurpleIM is simply an instantiable PurpleConversation.
> PurpleMUC is a PurpleConversation, with some additional code (for
> dealing with topic, adding/removing/renaming users etc.). So merging the
> two involves (1) Making PurpleConversation instantiable (2)
> s/muc/conversation/g, (3) Removing PurpleIM and PurpleMUC ... and that's
> about it, i.e. fairly trivial.
> 
> I am not really dead set on either approach, yet, but like Mark, I have
> a 'feeling', only that keeping that code related to MUC separate may
> result in a cleaner code (... and of course, that tonight's gonna be a
> good good night) ;)

I think it might make the core conversation code somewhat cleaner, but I
really have concerns about the complexity of other
subsystems/plugins/UIs handling an upconversion properly, and, as Mark
said, think their code would likely be cleaner with one unified object.

~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/20100722/c0a6fe72/attachment.sig>