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

List:       kopete-devel
Subject:    Re: [Kopete-devel] capabilites design
From:       Daniel Stone <dstone () kde ! org>
Date:       2002-06-16 22:43:16
[Download RAW message or body]

On Sun, Jun 16, 2002 at 12:03:02PM +0200, Martijn Klingens wrote:
> On Sunday 16 June 2002 11:42, Daniel Stone wrote:
> > How do I add a new contact list without touching libkopete? What about
> > if I want to add a new UI? Different preferences dialog, maybe?
> >
> > This is *shared* *code* *between* *protocols*. It's meant to cut down on
> > code reuse.
> 
> "Cut down on code duplication" rather, I presume ;-)

Er, yes.

> Nitpicking aside, the point is that
> 1. Not all plugins have the same capabilities
> 2. Future plugins may need other capabilities, or not support our current 
> capabilities.

That's entirely correct.

> Whatever goes into libkopete is *required* to be supported by _all_ plugins. 
> If a single plugin doesn't support it then it is apparently not generic 
> enough for libkopete.

Not necessarily. What about colour support? I think it's pointless
fucking around with it for every single plugin. Remember, it also gives
us the power to change it with one global preference.

> That doesn't mean the code shouldn't be shared between those plugins that do 
> support feature X, it only means the code should be placed elsewhere, using a 
> different solution, and not in libkopete.

Why? Where else would you put it? Would you be happy if I changed
libkopete's name to libfoobar, and put it there?

> If we had a trader to find plugins and dependencies we could have a system 
> where the MSN protocol plugin required the 'foreground colour' capability 
> plugin and the ICQ protocol plugin required both the foreground and 
> background colour capability plugins. That way plugins can be added and 
> reused without touching libkopete. That is called 'extensible'.

Ick. Ick, ick, ick. How many shared libraries do you want to have?
The correct solution is instead this:
MSN protocol - KMMF->create(me, them, KCW, CAP_FGCOLOR)
ICQ protocol - KMMF->create(me, them, KCW, CAP_FGCOLOR | CAP_BGCOLOR)
etc

> However, I am not particularly willing to write a trader if there were serious 
> plans made during LinuxTag to develop exactly such a thing for kdelibs. What 
> *might* be a solution is if someone cantacts Matthias Kretz <kretz@kde.org> 
> and offers cooperation. Currently the code resides in kdegraphics/kview and 
> is far from complete, but if some of us join his effort now we can at least 
> make sure all of kopete's requirements are met.
> 
> I for one want to do the contact list first, so for the forseeable future I'm 
> not available. After that I think I'll tackle this issue, but that might be 
> too late. If someone has the time and knowledge *now*, please speak up.

I don't see you insist on trying to kill a mouse with a BFG. Your
solution is complete overkill.

-- 
Daniel Stone	   <daniel@raging.dropbear.id.au>   http://raging.dropbear.id.au
KDE Developer	   <dstone@kde.org>	                      http://www.kde.org
Kopete: Multi-protocol IM client	    		   http://kopete.kde.org

[Attachment #3 (application/pgp-signature)]
_______________________________________________
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]