[Kde-pim] kdepim from 3.5 running within KDE SC 4.3

[Volker Krause]

On Friday 23 April 2010 17:08:06 Bernhard Reiter wrote:
> Am Freitag, 23. April 2010 16:30:34 schrieb Volker Krause:
> > On Friday 23 April 2010 12:35:22 Bernhard Reiter wrote:
> > > Am Freitag, 23. April 2010 09:59:37 schrieb Volker Krause:
> > > > > But until the, we need to run e35 on KDE SC 4.
> > > > > We have been checking into Ubuntu and UCS all Debian based a bit
> > > > > for this so far. One problem is that the kdepimlibs are build in a
> > > > > way that packages like  plasma-dataengines-workspace,
> > > > > plasma-runners-addons, kopete, kgpg and  python-kde4 depend on it.
> > >
> > > How hard do those packages depend on kdepimlibs?
> >
> > In order of appearance above the features affected are rss plasmoid,
>
> Seems useful without Kontact, thought e35 comes with Akregator and people
> might want to see the same feeds in both.

I don't think the feed config is shared between both at the moment.

> > contact krunner search plugin,
> > addressbook integration in kopete,
>
> Only useful if the contacts from Kontact can be accessed I assume.
>
> > no idea  about kgpg, kdepimlibs python bindings. Possibly a few more.
>
> The bindings for kdepimlibs could be separated from other kde4-python
> bindung.
>
> > > Are there other drawbacks except double configuration?
> > > E.g. can the new Kopete still access the contacts from the old Kontact?
> >
> > For vcf and ical files that should work,
>
> Sounds untested. :) Is there any locking going on if those two applications
> work on the very same .vcf file?

Not sure about the locking, but keep in mind that this is not a new problem, 
the same happens with two KDE3 apps accessing the same file already. One of 
the many problems that is solved by Akonadi, by providing a central instance 
for conflict detection.

> > for Kolab as well in theory,
> > although that would mean two local caches, so the data might not be in
> > sync between KDE3 and KDE4 apps then.
>
> Two local caches sound like a separate access not Kopete accessing the data
> via the KDE3 kdepim.

Right, there is no way to use the same data for Kolab caches.

> This looks to me like a viable solution for packaging is
>
> 1) Separate out the applications depending on kdepimlibs from
> plasma-dataengines-workspace and plasma-runners-addons
> to resolve the conflict and do not install the -with-kdepimlibs variants.
> Also for the kde4-python bindings.
> 2) Install the old Kopete. And the old kpgp if you must (Kleo should
> surpass it hopefully soon.)
> 3) conflict kdaddressbook e35 package with kdepimlibs5
>
> This means users would not have a modern Kopete and not all of the
> plasmoids, but an old integrated Kopete. No need for separate .kde35 and
> .kde directories.
>
> I believe this should be prefered over separated config directories,
> because separated config directories will not give the expected integrated
> experience for Kopete and Rss plasmoids either, but would be more work
> given the current Debian package structure. The plus of separated config
> directories would be that you could use a modern Kopete if you wanted to.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100423/52166fd7/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/