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

[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.
> >
> > This is correct in my understanding.
>
> How hard do those packages depend on kdepimlibs?

In order of appearance above the features affected are rss plasmoid, contact 
krunner search plugin, addressbook integration in kopete, no idea about kgpg, 
kdepimlibs python bindings. Possibly a few more.

> > > If the following packages are installed, not surprisingly the contacts
> > > resource gets deleted from .kde/share/config/kresources/contact/stdrc
> >
> > What probably happens here is the migration of the old KResource
> > configuration to Akonadi. IIRC this was still disabled in the 4.3 release
> > though and should only happen from KDE 4.4 onwards. Again, this is the
> > correct and expected behaviour.
>
> Those are the Debian KDE SC 4.3.4 packages as far as I  have understood.
>
> > > ii  kdepimlibs-dat 4:4.3.4-1.1.20 core shared data for KDE PIM 4
> > > applications ii  kdepimlibs5    4:4.3.4-1.1.20 core libraries for KDE
> > > PIM 4 applications
> > >
> > > Of course it seems like the new kdepimlibs want to access the
> > > configuration and have no "imap" resource (because that is called kimap
> > > with
> > > kaddressbook, if I remember correctly.) See part of the kdebug output
> > > below at [2].
> >
> > What you are doing here, if I understand correctly, is using KDE 4.3+
> > config files with KDE 3.5 code.
>
> To me it looks like it is the other way around. KDE 4.3+ code using the old
> config files. Migration was done once what afterwards e35 code wrote new
> config files.

Same thing, you are using config files in a way not supported by KDE.

> > This is not supported by KDE. Configuration
> > files are migrated forward on upgrades, but are not guranteed to be
> > backward compatible. So, accessing them with older versions will result
> > in undefined behaviour.
>
> Yes, which means I have to make sure that only one code generation accesses
> the configuration files at a time.

Right, therefore the suggestion to use two different KDEHOMEs.

> > The problem is not Kopete or any of the other apps mentioned here, there
> > is nothing in there that you could change to make this work. The problem
> > is using a new kdepimlibs anywhere, since that will trigger the config
> > file format update. And besides not installing kdepimlibs (which is
> > pretty much impossible), the only way around this I see is separating the
> > config files entirely, as already suggested in this thread.
> >
> > That's also what I use here to run a e35 Kontact on my KDE 4.4 desktop.
> > Of course the downside of this is that you have to configure your PIM
> > stuff twice, for KDE3 and KDE4.
>
> 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, 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.

regards
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/d3a7aa51/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/