This starts to become a dangerous path (Was: New Feature for kdelibs)

Kevin Kofler kevin.kofler at
Thu Nov 17 13:26:19 GMT 2011

I think this thread is indeed quite a dead end, but since you mentioned my 

Thomas Zander wrote:
> And I'm still not seeing anyone put in the in comparison tiny fraction of
> time of porting the auto-download plasma thing to frameworks.

Let me clear up a few things:

* The problem isn't that I need to port the feature to Frameworks, but that 
I need to ship it in Fedora 17 in April-May 2012, not somewhere in 2013 when 
the Frameworks/libplasma2-based Plasma Desktop 5 will be ready.

* FYI, porting the feature to Frameworks 5 requires changes in PackageKit 
and Apper first: currently, the requested services are assumed to be in the 
type-name, e.g. dataengine-weather, format, and PackageKit then asks RPM for 
plasma4(dataengine-weather). Now, we need to have a separate namespace for 
Plasma 5 / libplasma2 services, so we need to change PackageKit to do what 
it already does for Python (python2 vs. python3 namespaces) and also accept 
requests of the plasma5(dataengine-weather) form (and just like for Python 
where it defaults to python2 if no namespace is given, it'll default to 
plasma4 if no namespace is given here, for backwards compatibility – note 
that this is already in released versions of PackageKit, so we can't just 
change the semantics to default to the new namespace). And the pretty 
display of the services in Apper also needs to cope with the extended 
format. So my plan is to submit patches to PackageKit and Apper first of 
all. (I'm sorry that I didn't get this right in the first place, but when I 
wrote the PackageKit and Apper patches, I had no idea libplasma2 would be 
such a pressing matter.)

        Kevin Kofler

More information about the kde-core-devel mailing list