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

List:       kde-telepathy
Subject:    Re: Metacontacts/KPeople status
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2013-02-05 11:18:42
Message-ID: CAGeFrHC9ey+nc3SFVGrOrkpXdkvbhdN53DXXfHdap9u77P79Hw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


I've had an idea.
It's possibly controversial.

The current state:
 - KPeople relies on ktp-common-internals because we have a lot of useful
code we don't want to reproduce.
global-contact-manager, KTp::Contact itself with logic for working out
shared capabilities and gabble workarounds, and listing actions etc. We are
now able to dynamically list all actions including stream/dbus tubes we
want to be able to do that in all places.


Apol (correctly IMHO) thinks this is a problem as kpeople should be
entering as a framework without a dependency on ktp-common-internals. This
is probably a requirement if we want to be used in PIM.
Long term I want the switching between kpeople and contact-list-model to be
done behind the scenes, which means k-c-i has to depend on kpeople. This
would be a circular dependency.

Option 1:
 - we duplicate a tonne of code (bad)

Option 2:
 - kpeople has a plugin infrastructure.
we only need ktp-common-internals at runtime.

So what if it went like this:

kpeople builds a model. Then it loads a set of plugins (passed as a
stringlist to the constructor) this can set a QIdentityProxyModel (like we
use at the moment)
The telepathy part of kpeople can then reside in our repository as a
kpeople plugin

This would also allow for us to add actions easily, and would allow other
people to extend kpeople too with any actions or UI components or anything.

It's not a lot of work mostly moving some things, and a design that I think
is pretty clean, simple and extensible.

David

[Attachment #5 (text/html)]

I&#39;ve had an idea.<div>It&#39;s possibly controversial.</div><div><br></=
div><div>The current state:</div><div>=A0- KPeople relies on ktp-common-int=
ernals because we have a lot of useful code we don&#39;t want to reproduce.=
</div>
<div>global-contact-manager, KTp::Contact itself with logic for working out=
 shared capabilities and gabble workarounds, and listing actions etc. We ar=
e now able to dynamically list all actions including stream/dbus tubes we w=
ant to be able to do that in all places.</div>
<div><br></div><div><br></div><div>Apol (correctly IMHO) thinks this is a p=
roblem as kpeople should be entering as a framework without a dependency on=
 ktp-common-internals. This is probably a requirement if we want to be used=
 in PIM.</div>
<div>Long term I want the switching between kpeople and contact-list-model =
to be done behind the scenes, which means k-c-i has to depend on kpeople. T=
his would be a circular dependency.</div><div><br></div><div>Option 1:</div=
>
<div>=A0- we duplicate a tonne of code (bad)</div><div><br></div><div>Optio=
n 2:</div><div>=A0- kpeople has a plugin infrastructure.</div><div>we only =
need ktp-common-internals at runtime.=A0</div><div><br></div><div>So what i=
f it went like this:</div>
<div><br></div><div>kpeople builds a model. Then it loads a set of plugins =
(passed as a stringlist to the constructor) this can set a QIdentityProxyMo=
del (like we use at the moment)</div><div>The telepathy part of kpeople can=
 then reside in our repository as a kpeople plugin</div>
<div><br></div><div>This would also allow for us to add actions easily, and=
 would allow other people to extend kpeople too with any actions or UI comp=
onents or anything.</div><div><br></div><div>It&#39;s not a lot of work mos=
tly moving some things, and a design that I think is pretty clean, simple a=
nd extensible.</div>
<div><br></div><div>David</div><div><br></div>


_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy@kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy


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