--===============0708790388==
Content-Type: multipart/signed;
  boundary="nextPart1963440.fe4HHHiO6o";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1963440.fe4HHHiO6o
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 05 May 2009 01:16:23 Ingo Kl=C3=B6cker wrote:
> On Tuesday 05 May 2009, Thomas McGuire wrote:
> > Hi,
> >
> > now that KPIMTextEdit is basically complete, I wanted to support
> > images in signatures.
> > The signature editor is in kpimidentities, so kpimidentities needs to
> > link to kpimtextedit so that the signature editor there can support
> > images.
> >
> > Problem is, kpimtextedit already links to kpimidentities, because it
> > has some functions to insert signatures into the text edit.
>
> Why do those functions exist in kpimtextedit? Wouldn't it be sufficient
> to have a method insertSignature() which is called by somebody (e.g.
> KMail) who can link against both libraries?

right, getting rid of these looks like the best way to solve this. Can't we=
=20
move those to kpimidentities instead?

> > So there is a link cycle between kpimtextedit and kpimidentities, and
> > CMake won't let me do that.
> >
> > Any idea how to resolve that? One idea would be to move all of
> > kpimtextedit (two classes at the moment) to kpimidentities and get
> > rid of the kpimtextedit library altogether.
> > The downside of this is that a text edit doesn't really fit there.
>
> Exactly.
>
> > Does anybody see a better way out of this situation?
> > If not I'll move the classes soon.
>
> I object. Creating yet another libkdepim or libkpimutils (*sigh*) is a
> no-go. Putting everything and the kitchensink in one library is no
> solution for bugs in the class and/or library design. The solution is
> to fix the design.

I agree.

> One solution would be to split kpimidentities into a backend library
> kpimidentities-core (ideally using only non-GUI libraries) providing
> access to the PIM identities and a second library kpimidentities-ui
> providing the UI components for editting the PIM identities. I suppose
> this would allow kpimtextedit to link against kpimidentities-core and
> kpimidentities-ui to link against kpimtextedit. (The names of the
> libraries are just suggestions.)

I'm not sure if such a split would be BC. Probably needs some kind of=20
kdepimidentities dummy lib that links to both new ones.

> A similar solution, but with the benefit that it doesn't increase the
> number of libraries, would be to merge kpimidentities-ui and
> kpimtextedit into kpimui. Then kpimidentities-core could keep the name
> kpimidentities. I think I prefer this solution.

kpimui sounds dangerously like yet another libkdepim though...

regards
Volker

--nextPart1963440.fe4HHHiO6o
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iD8DBQBKABU6f5bM1k0S0kcRAi0oAKCs4zIBaFZgky8GlR6OrBShyusSLgCfdZ1u
ozsVKtzZWuZ4DtWp6mGKQW8=
=blxZ
-----END PGP SIGNATURE-----

--nextPart1963440.fe4HHHiO6o--


--===============0708790388==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
--===============0708790388==--