This starts to become a dangerous path (Was: New Feature for kdelibs)
Kevin Kofler
kevin.kofler at chello.at
Thu Nov 17 13:26:19 GMT 2011
I think this thread is indeed quite a dead end, but since you mentioned my
feature:
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