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

List:       kopete-devel
Subject:    Re: [Kopete-devel] capabilites design
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-06-17 7:53:56
[Download RAW message or body]

On Monday 17 June 2002 00:43, Daniel Stone wrote:
> > 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.

Could you define "fucking around with it"? If that is 'instantiating a class', 
then I disagree. How hard is it to do KopeteColourPicker *p = new 
KopeteColourPicker( optionsWidget ); ? (Or whatever API we pick).

> Remember, it also gives
> us the power to change it with one global preference.

With a colour picker capability plugin outside libkopete you still can.

> > 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?

No, I would be happy if each capability got its own shared library. It's the 
only way to make them truly reusable *and* extensible without requiring a new 
Kopete/libkopete release for extending them. Think 3rd-party plugins.

BUT: I talked about this with Andres on IRC last night and we concluded that 
having this in .so files hardly changes the design. And we also need a good 
design. Therefore we concluded that the best solution was to introduce a 
separate subdir in libkopete (capabilities/ ?) where we can put all 
capability code and use it directly for now and move to true shared libs 
later. Delaying that change is not the same as not taking the step at all 
though.

> Ick. Ick, ick, ick. How many shared libraries do you want to have?

A lot, if needed. Or do you see another solution that allows 3rd party plugins 
to add and extend capabilities without recompiling libkopete?

> 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

And libkopete will parse that enum? Yuck, how inflexible can you get it?

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

I wish it was. For flexibility I fear it's not. And giving up flexibility is 
even worse IMHO.

-- 
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]