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

List:       kde-pim
Subject:    Re: [Kde-pim]
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2009-05-05 22:17:04
Message-ID: 200905060017.04491 () thufir ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 05 May 2009, Volker Krause wrote:
> On Tuesday 05 May 2009 01:16:23 Ingo Klöcker 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 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
> kdepimidentities dummy lib that links to both new ones.

Hmm, yeah. BC. Totally forgot about that. To bad that the good old days 
when we didn't have to think about BC in kdepim are gone. Not! :-)


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

Yes. Kind of. Although it would be reserved for UI related classes (just 
like kdeui). Now we do have a new very small library called 
kpimtextedit with just a few classes. I don't really like 
libkdepim-style libraries, but I also don't really like having 1001 
small libraries. *shrug*


Regards,
Ingo

["signature.asc" (application/pgp-signature)]

_______________________________________________
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/

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