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!

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 plasma-scriptengine-applet-declarative.desktop in kde-runtime, which has a X-KDE-PluginInfo-Name different 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 kde-settings-4.7-8.fc17.

The plasma-dataengine-depextractor was passing a relative path to KDesktopFile, which misinterpreted it as relative to applnk rather than to the current directory. I fixed the patch to use QDir::absoluteFilePath instead of QDir::filePath.

The plasma-dataengine-depextractor was requiring the user or script calling it to explicitly pass the scripting API/language used through an --api argument. That information is already provided by the .desktop file, 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 -a language or --api language argument 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 isnan.

I have rebuilt kdelibs, kdebase-runtime, kdebase-workspace and kdeplasma-addons to 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 plasma-dataengine-depextractor in kdelibs-devel during the build process, unless/until the upstream metadata.desktop includes an X-Plasma-RequiredDataEngines entry.)

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 .desktop file.

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 X-Plasma-RequiredDataEngines entry.

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 kpackagekit package.

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-RequiredDataEngines entry) 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.