Plasma Weather widget: add your favorite weather data provider

So Plasma 5.6 has seen the revival of the Weather widget that is part of KDE Plasma Add-ons module (revival as in: ported from Plasma4 API to Plasma5 API).
(And even got the interesting honour to be mentioned as the selling item in the headline of a Plasma 5.6 release news article by a bigger German IT news site, oh well 🙂 )

This revival was concentrating for 5.6 to restore the widget in its old state, without any bugs. But that’s not where things are to end now…

And you, yes, you, are invited and even called in to help with improving the widget, and especially for connecting to more weather data providers, incl. your favourite one.

For a start, let’s list the current plans for the Weather widget when looking at the next Plasma release, 5.7:

  • Overhaul of look (IN PROGRESS)
  • Breeze-style weather state icons (IN PROGRESS)
  • also temperature displayed in compact widget variant, like on panel (TODO)
  • support for more weather data providers (YOUR? TODO)
  • privacy control which weather data providers are queried on finding weather stations (YOUR? TODO)

Overhaul of widget look

The KDE meta sprint at CERN (of groups WikiToLearn, Plasma, VDG, techbase wiki cleanup) at begin of this March, where I mainly went for techbase wiki cleanup work, of course was a great occasion to also work face-to-face with Plasma developers and VDG members on issues around the Weather widget, and so we did. Marco helped me to learn more about Plasma5 technologies which resulted in some small bugs fixed in the widget still in time for Plasma 5.6 release.
Ken presented me the drafts for the look & design and the config of the weather widget that he had prepared before the sprint, which we then discussed. Some proposals for the config could already be applied in time for Plasma 5.6 release (those without need for changed UI texts, to not mess the work of the translators). The rest of it, especially the new look & layout of the widget, is soon going to be transferred from our minds, the notes and the photos taken from the sketches on the whiteboard at CERN into real code.

Breeze-style weather state icons

Ken also did a Breeze style set of the currently used weather state icons. While touching the icons, a few icon naming issues are going to be handled as well (e.g. resolving inconsistent naming pattern or deviation from the weather state icon names actually defined in the XDG icon naming spec (see Table 12. Standard Status Icons). Should soon be done as well.

Temperature display in compact widget variant

One thing that has been missing also from the old version of the Weather widget is the display of the current temperature in the compact widget variant, where now only the current weather condition is shown (e.g. when on the panel). While some weather data providers (like do not provide that detail, so there is nothing to display, others do, and often it is pretty nice to know (clear sky can happen with temperatures of any kind, so it’s good information about if and then what kind of jacket to put on before stepping outside). First code is drafted.

Now, finally the things were you can improve things for yourself and others:

Supporting more weather data providers

The Weather widget does not talk to any weather data providers directly. Instead it talks to a weather dataengine (currently part of the Plasma Workspace module), to query for any weather stations matching the entered location search string when configuring the widget and to subscribe to the data feed for a given weather station from a given weather data provider.
That weather dataengine itself again also does not talk directly to any weather data providers. Instead it relies on an extendable set of sub-dataengines, one per weather data provider.

The idea here is to have by the one weather dataengine an abstraction layer (he, after all this is KDE software 😉 ) which maps all weather data services into a generic one, so any UI, like the Weather widget, only needs to talk one language to whoever delivers the data.
Which works, more or less. Because of course there are quite some weather data specifications out there, what else did we expect 😛 And possibly the spec interpretations also vary as usual.

((You might think: “Well, screw that over, there is only one user of the weather dataengine, so integrate that directly into the Weather widget!”
While that might be true right now, it does not need to stay this way. There are ideas like showing the weather forecast also with the days in Plasma calendar widgets. Having a KRunner plugin to quickly request weather in some place. Or having a wallpaper updater reflecting the current weather by showing matching images, yes, not everyone has the joy to work close to a window, enjoy if you do. And also alternative weather widgets with another UI, remember also the WeatherStation widget in kdeplasma-addons (still waiting for someone to port it), which focussed on details of the current weather state. These kind of usages might prefer a normalized model of weather data as well, instead of needing custom code for each and any provider again. Actually long-term such a model would be interesting outside of Plasma spheres, e.g. for any calendaring apps, for a plugin for Marble-based apps showing weather states over a map or whatever other fancy uses there can be. Feel free to share ideas in the comments, to improve motivation for creating such a Plasma-independent lib!))

While I only took over kind of maintainership in the last weeks, so did not design the current system myself, I still think it’s a good approach, having in mind reusable UIs and relative independence from any given weather data providers. So for now I do not plan to dump that, simply lacking a more promising alternative.

So, given you are still reading this and thus showing me and yourself your interest 🙂 let’s have a closer look:

The sub-dataengines for the different weather data providers have been named “ion”s. On the code level they are subclasses of a class IonInterface, which itself is a subclass of Plasma::DataEngine.
See here for the header defining IonInterface:

This header and the respective lib libweather_ion are public and should be installed with the devel packages of Plasma Workspace. Which means you should be able to develop your custom ion as 3rd-party developer without the need to checkout the plasma-workspace repository and develop it in there.

Plasma 5.6 itself installs three such ions:

  • adapter to service of the private company running
  • envcan: adapter to service of Environment Canada, by Government of Canada
  • noaa: adapter to service of USA’s National Oceanic and Atmospheric Administration

Find their sources here:

In that source folder you will also spot a bbcukmet ion, for the BBC weather service. While being ported to build and install at least with Plasma5, the service API of BBC as used by the code seems to have been either changed or even removed. So that ion is currently disabled from the build (uncomment the #add_subdirectory(bbcukmet) to readd it to the build). Investigations welcome.
Update: There are patches for the Plasma4 version of the bbcukmet ion to make it work again with current BBC service API. See below in the comments for detailed info. Should be easy work and a chance to contribute also for beginners.
Update2: Those patches have been used to restore the bbcukmet ion, it will be part of Plasma 5.6.2 and later. Still would be good to have someone look closer at it, there is room for improvements.

Another old ion which though already got removed during the revival was a more fun one: there used to be a Debian “weather” service (random related blog post), which reported the status of Debian-based distros by number of working packages as weather reports, and this ion connected to them. But the service died some years ago, so the ion was just dead code now (find the unported code in versions of “Plasma 5.5” and before)

Talking about funny weather reports: why not write an ion for the CI system Jenkins, e.g. with, which while perhaps not being able to give forecasts at least reports the current build state, with builds mapped to stations. After all the short report for a build uses the weather metaphor, see 🙂

For more serious weather data provider ions again, as you surely know or can guess, there are many more public & private weather data providers than those 3 currently supported. And they not only may have a better coverage of your local area, but might also provide more data or more suited ones.

Please also see the proposal for using “weather data from the open data initiatives” in a comment on the first blog post on the Weather widget.

It would be great to have a larger selection of weather data providers supported in Plasma 5.7. So while having your ion as 3rd-party plugin somewhere else is fine, consider maintaining it inside one of the Plasma repositories, either with the existing ions in the repo plasma-workspace or as part of addons in the repo kdeplasma-addons. This should ensure more users and also more co-developers.

Do a good check of the licenses for using the data services of the weather data providers. Especially public ones should be fine given their purpose, but if in doubt after reading the details, ask the providers.

Privacy control

One issue in the old and current Weather widget code is that when searching for a weather station suiting the users desire, as expressed by the location search string, all currently installed ions are queried. Which of course is a problem from a privacy point of view. And will be worse the more ions there will be.

So there needs to be a way to limit the scope of ions that would be queried. Given that dataengines by design should be used by all kind of dataengine consumers, a Weather widget-only solution might be only a short jump here. There are very possibly other Plasma modules talking to remote services as well, like geolocation services. And ideally one is able to control system-wide (so even beyond Plasma scope) which remote services are allowed and which not.

Until such a global solution exists a Weather widget-only solution is better than nothing surely. Still, it needs to be designed UI-wise, so a job to be picked up by someone 🙂

Getting started with your own ion

So while I am currently impeded these days from hacking, among other things by waiting for new development-capable hardware being delivered (disadvantage of small towns: need to use an online shop for special hardware desires, and there latency unit is days, not minutes, especially bad when wrong stuff is delivered and then also holidays get into the game. Looking on the bright side of life, my old hardware only broke right after the CERN sprint, not before 🙂 )…
… Do not hesitate to look into things already. I would have liked to provide a KAppTemplate-package with an ion sample in this post already, so you could experiment right away. But perhaps you are experienced enough to get a new ion working by looking at the existing ones. If not, in a few weeks hopefully there should be a template, so watch out.
Update: There is now such a template, see this blog post.

And do not hesitate to ask for support on #plasma on irc or on the Plasma mailinglist, I received lots of help there with the Weather widget porting, so you should when trying to write an ion 🙂


12 thoughts on “Plasma Weather widget: add your favorite weather data provider

  1. The bbcukmet ion requires a bunch of fixes that were lost in the mess of Plasma 4 to 5 transition and lack of an active maintainer for the weather plasmoid:


    Some additional notes:
    * The patch adds a mapping for “Light Cloud”, but there are also new weather conditions “Thick Cloud” and “Thunderstorm” (possibly more, but those are the ones I remember encountering) that are not currently mapped.
    * There was some discussion on the patch fixing the timezone parsing after some BBC site changes, because it tries parsing the timezone abbreviation, which requires classes deprecated in KF5 (KTimeZone) and which is a bad idea to begin with because those abbreviations are usually not unique. A workaround is needed that neither requires parsing those abbreviations, nor assumes that the local machine’s time zone is the one the weather data is in.

    But other than those issues, the ion works in the KDE 4 version with the above patches.

    • Excellent, that is good news. Thanks Kevin, for compiling and providing that here!
      So you people living in BBC weather covered regions, anyone up to take care of reviving the bbcukmet ion using these patches and knowledge? Can also be your chance for getting into Plasma development, this should be a nice junior job 🙂

      • Gave the patches a try, and now locally have the bbcukmet working basically again 🙂 Next will give that timezone parsing thingie some more thoughts and also look into the weather conditions, given your mentioning.
        If solved to my satisfaction I think I should be able to smuggle this into the Plasma 5.6.2 release already, no new strings added and it was a regression against Plasma4 😉

  2. Does this mean the revival of weather wallpapers, perhaps?

    I’m very tempted to take up the cause of the Environment Canada ion if it hasn’t been ported yet, although that’ll probably have to wait until I upgrade my work desktop to Kubuntu 16.04 (from 14.04) and can vaguely justify doing the work on company time 😉

    • Hi keithzg, the envcan ion is already ported (as in: builds, installs and seems to spit out usable data from a quick look), it is part of Plasma 5.6.
      But would be still good to have someone looking closer at it who also is or would be using it. So please give in to your temptation, and e.g. do some proper checks and then fixes/improvements where needed 🙂

      WRT weather wallpapers, I just heard about the idea before, did not know it is already a thing (across operating systems even) 🙂 For Plasma, did you have the following in mind?
      Would be nice to see someone porting them then and also giving feedback about the weather dataengine and what could be improved there.

      • Oh there are some cool ideas for that (weather wallpaper) I really really wanted to make like a weather + time wallpaper for Plasma where you have every season, like 6 “times of day” and a stock set of weather (lets say sunny, cloudy, fog, rain, snow).
        The issue is that that would mean (4x6x5) 120 different wallpapers to cover every single angle. Which, although a cool project, is also a massive project 🙂

      • I’ll definitely give in to temptation fairly soon, then, or at very least fire up a VM and start playing around 🙂 I’ve been meaning to give the new incarnation of Project Neon a shot, after all . . .

        Yeah, I think that’s the Weather Wallpaper plugin I use, although here on Plasma 4 (Kubuntu 14.04) I’m not using it from kde-look, rather from the mainlined version of it that was included in the plasma-wallpapers-addons package; see and, which appears to be a subset of the kdeplasma-addons project. Yeah it seems like the Weather portion was just never ported.

        Again I’m by no means a trained programmer so I give no guarantees, but I’ll definitely give it a look, scratching my own itch as they say 🙂

      • ohyran, the old one was purely weather conditions and ignored time of day, and there were still *barely* enough pictures shipping with the extra wallpapers package! So yeah, that’d be a pretty massive project. Although with just day and night images it might be doable . . . I think we’re getting ahead of ourselves, though, lets get weather conditions working and *then* plot to take over the world 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s