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

Wed Feb 2 11:08:38 GMT 2011

[Doing a full quote, because I am following up on an old discussion.]

Am Sonntag, 25. April 2010 23:33:47 schrieb Ingo Klöcker:
> On Friday 23 April 2010, 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.
> >
> > > 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?
> >
> > > 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.
> >
> > 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. 

The split of dependencies seems necessary, 
independently of the question of separate config directories. 
Dependencies should be constructed in a way that as many application depending 
on KDE Platform 4 can be installed with interfering with Kontact E35.
Right now some plasma-dataengines-workspace apps cannot be installed,
because the general dependency on kdepimlibs5.

> > No need for separate .kde35 
> > and .kde directories.

As David Jarvie pointed out, there can be other reasons for two separated
config direction: Possible conflicts in commonly used configuration files like 
kdeglobals.rc. This would need investigation and problably discussion in other 
places of KDE, like core-devel.

> > 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.
>
> Denying the user the usage of a modern Kopete somehow doesn't fit with
> Free Software principles IMHO. Separating the config directories is the
> only solution that allows the user the execution of the rights
> guaranteed by the GPL.

( Free Software principles does not say anything about what is a nicely usable 
combination and configuration of applications and libraries. )

Thinking through the consequences of two configuration directories I still 
find it scary. I would require the user to do many configurations twice, 
including suprising effects if one of the components has slightly different 
behaviour. If anyone has, I would be interested in pointers towards KDE 
discussions about this.

To me it seems useful to offer packaging and code with says:
For each application, choose which one you want to have, e.g. for Kontact E35
and Plasma for the Desktop. And then have those applications access one 
configuration e.g. what should happen for an URL with "mailto:" or "http:".
That cannot be perfect if applications are tightly coupled like Kopete is with 
a list of contacts which might come from Kontact. I guess it would require 
significant coding to change this for Kopete and other Plasmoids. Being 
pragmatic, we could allow this contact list connection be non-functional, 
until there is code for this.

Best,
Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110202/f405d43f/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/