If you’re fed up of staring at a boring, low-contrast all-gray system tray with icons inconsistent with the rest of your system, it’s time to bring some color into your life, or at least your system tray. ;) In other words, my Oxygen Plasma (≥ 4.5) system tray icons are for you. Please note that credit for the actual artwork goes to the Oxygen icon theme team, I only did the required format conversions. (On the other hand, if things look ugly, it’s probably my fault. ;))
Today, I have updated the package to include a colored version of
kpackagekit.svgz, which contains 3 icons (plus a currently unused fourth one) used by Apper. The icons are again converted from the Oxygen icon theme. So if you were using revision 1 of my theme on Fedora 16 and the gray Apper icon was sticking out like a sore thumb, the updated revision 2 is for you!
In other news, I have recently laid the first stone for a port of my work to KDE Frameworks 5, by getting support for a
plasma5 namespace into PackageKit.
The GSoC deadline is now over. I passed the final evaluation and got my payment, still waiting for the t-shirt and certificate though. But the fact that the deadline has passed doesn’t mean I stopped maintaining the code. This week, the
telepathy-kde-presence-applet has landed in Rawhide, which made me find and fix a few issues in my GSoC work:
- The RPM auto-Provides script got confused by
kde-runtime, which has a
X-KDE-PluginInfo-Namedifferent from the
X-Plasma-API(the name is qmlscript, the API is declarativeappletscript). The dependency extractor was preferring the
X-KDE-PluginInfo-Name, but that name is not used for script engines, only the API is relevant. This is fixed by this kde-settings commit, in
- The data engine dependency extraction did not support
declarativeappletscriptQML code. I updated the patch to add support for that feature.
plasma-dataengine-depextractorwas passing a relative path to
KDesktopFile, which misinterpreted it as relative to
applnkrather than to the current directory. I fixed the patch to use
plasma-dataengine-depextractorwas requiring the user or script calling it to explicitly pass the scripting API/language used through an
--apiargument. That information is already provided by the
.desktopfile, which is required anyway, so I dropped the useless parameter and changed the code to detect the scripting API automatically. (If anybody is already using the
plasma-dataengine-depextractor: please just remove any
--api languageargument you’re passing, it is now all detected automatically.)
Unfortunately, I haven’t been able to build the updated data engine dependency extraction patch into Rawhide yet because the
kdelibs build fails due to an unrelated issue with
glibc has been fixed in Rawhide, and
kdelibs-4.7.1-4.fc17 was built successfully.
My GSoC 2011 work has now fully entered Rawhide, i.e. what will eventually become Fedora 17 and later.
The PackageKit portions of the work have already been in Rawhide for a while:
- PackageKit-0.6.16-1.fc16 (patch included upstream) was built on July 4.
- gnome-packagekit-3.1.3-2.fc16 (patch included upstream) was built on July 4 as well.
- kpackagekit-0.6.3.3-3.fc17 (patch backported) was built (by me) on August 1.
I have just imported the remaining portions of the work into Rawhide:
- kde-settings-4.7-4.fc17 includes the RPM dependency generators.
- I have rebuilt
kdeplasma-addonsto pick up the new Provides. Other packages will automatically pick up Provides and script engine Requires the next time they are rebuilt. (For data engine Requires, you will want to run the new
kdelibs-develduring the build process, unless/until the upstream
- kdelibs-4.7.0-3.fc17 includes all the libplasma portions of my GSoC project (as backported patches).
The new features should now be fully testable in Rawhide.
Update: I built kde-settings-4.7-5.fc17, which fixes showstopper bug #732271. (I also fixed a related issue in libplasma in kdelibs-4.7.0-4.fc17, but that fix should not be strictly required because the only thing I use
Plasma::PackageMetadata::serviceType() for is to figure out the precise type of script engine to verify the presence of, and if I don’t have a service type, I just conservatively look for any script engine for the language, which should be fine as they tend to be packaged together anyway.)
I have just submitted a patch which implement automatic scanning of the source code of Plasma-related packages (e.g. widgets) for required data engines.
For packages in scripting languages and distributed through Open Collaboration Services (OCS), this is fully automatic and triggered from
Package::installPackage. If an
X-Plasma-RequiredDataEngines entry is present in the .desktop file (even if empty), the dependency extraction is not run and the explicitly provided information is trusted instead.
For native distribution packages, my patch adds a tool called
plasma-dataengine-depextractor which can be run at any time during the build process and which adds the dependency information (the
X-Plasma-RequiredDataEngines entry) to the relevant
Authors of plasmoids are encouraged to run
plasma-dataengine-depextractor and/or fill in
X-Plasma-RequiredDataEngines manually. (Please note that the list is expected to be comma-separated.)
Of course, the automatic scanning is not perfect; in particular, it will not detect convoluted ways to load data engines (e.g. if the name is a variable), and it may have false positives in some corner cases (commented-out use of a data engine, some other function called
dataEngine and taking a string literal). However, I expect it to work well in practice, and if it doesn’t work, there’s always the possibility to explicitly add the
This is the final portion of my GSoC 2011 project, so the project can now be considered 100% complete.
Sorry, I haven’t blogged for a while, but rest assured that I’m still alive and coding. :-) I passed the midterm evaluation, and the final evaluation is approaching. So what do we have in the store?
- My patches to PackageKit, Apper and gnome-packagekit got pushed upstream. The changes to the PackageKit core even trickled down all the way to Fedora 15 (and of course Fedora 16 and Rawhide). I have backported the Apper changes to the Rawhide
- I added support for Plasma to automatically prompt for the installation of missing script and data engines the first time something attempts to use them. This patch got pushed upstream.
- I submitted another patch for review, which makes Plasma request the installation of required script engines (always, as this is covered by existing metadata) and data engines (if specified in the metadata through a new
X-Plasma-RequiredDataEnginesentry) as soon as a package (usually a widget) is installed through Open Collaboration Services (OCS), rather than only when the user attempts to add the widget to some containment (desktop, panel etc.). This patch is pending upstream feedback.
- I also wrote an RPM auto-Requires script based on the same metadata as the above patch. This ensures script and data engine dependencies will be automatically detected in future Fedora packages.
Now the only remaining work item on my project plan is automatic scanning for required data engines. (Script engines are already completely handled by the above patches.)
Richard Hughes requested a small change to the PackageKit session API used to look up Plasma services before accepting the added function upstream: instead of a dedicated
InstallPlasmaResources method, the
org.freedesktop.PackageKit.Modify D-Bus interface got a generic
InstallResources method, which allows installing all the existing resource types as well as Plasma services, and any other resource types added in the future. It takes a
type parameter, which must be set to
"plasma-service" in our case.
With those tweaks, the PackageKit change and the gnome-packagekit change are now committed to upstream git. For Apper (KPackageKit), which is our main target, there is a patch for Apper master on Review Board and a backport for KPackageKit 0.6.x on the packagekit mailing list. Hopefully, Daniel Nicoletti will have some time to review the patch soon. If not, he suggested on IRC that I can just commit the patch as is and he’ll refactor it later if needed, so that’s my fallback plan.