[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] KMM question
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-04-29 18:49:20
[Download RAW message or body]

On Monday 29 April 2002 20:09, Andres Krapf wrote:
> another question on the KMM design. KMM is in charge of emitting
> messageSent when a message is sent from the message window.
>
> but when (if at any) is it deleted ? (it emits a dying() signal... i

Sounds redundant: there is QObject::deleted() which can almost always be used 
for that.

> suppose it's for something). i wouldn't expect a KMM to have the same
> lifecycle as Kopete... at least if it models a "chat session".

KMM can't know when the session ends. A disconnect should delete all 
instances, and if the protocol supports some form of notification it can be 
used as well. Additionally you *could* consider closing a chat window (if 
it's used instead of the passive popups) being the end of a chat, although 
the chat preserving its data on close might not be bad.

I don't think this is currently very well defined, though.

> are the plugins expected to keep track of the KMMs they use ?
>  - if they don't, do they create one on each incoming message with the help
> of the factory ? that's a problem because the factory doesn't tell us if
> it's a newly created KMM or an existing reused KMM. so how do we know if we
> have to reconnect the messageSent ?

Yikes... this was the idea, but indeed the messageSent signal gets a bit 
loose. Grmbl...

Hmmm, a possible solution is

virtual void KopeteProtocol::send( const KMM *manager, const KopeteMessage 
&msg ) = 0;

this way KMM pushes the message to the protocol, not using signals/slots.

Another way would be to allow subclassing KMM to MSNMM, AIMM, ICQMM, etc., 
which is kinda complex if you ask me.

Any other ideas maybe?

>  - if they do, it defeats some of the purpose of having the factory that
> helps reuse opened chat sessions, because the plugin has to find out if it
> a KMM for some chat session already existed anyways.

See above. This is indeed the case, but that was definitely not planned :/ - 
back to the drawing board I guess...

> one solution would be for the factory to tell us wheter it's a new KMM or
> not somehow.

Bah...

> i've looked at how jabber does it, and storing KMMs in Contacts won't work
> for multiuser chats...

Nope, although for most protocols single and multi chats are so completely 
different that it is a good idea to do it like this and add special 
provisions for multi-chats. One only has to watch out extremely carefully for 
code duplication. It's a bit protocol-dependent what's better.

In jabber a group chat gets its own group id, which is also very easy to map, 
so it might be useful to have something like

class JabberIdentifier
{
  property QString m_id;
  bool isContact();
  JabberContact *contact();
};

class JabberContact : public KopeteContact, public JabberIdentifier
{
 ...
}

class JabberProtocol
{
  QMap<JabberIdentifier, KMM *>  m_chats;
  QMap<QString, JabberContact*> m_contacts;
}

or so. In other protocols you probably can't generalize like that, which is 
mainly the reason why this is not explicitly defined.

Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]