Review Request: wetter.com Weather Ion

Thilo-Alexander Ginkel thilo at ginkel.com
Wed Nov 4 19:46:26 CET 2009 


> On 2009-11-03 17:31:01, Will Stephenson wrote:
> > You could work out the "Current Conditions" and "Condition Icon" data on each update using the current system time and the UTC time in the forecast periods, and set these on the data source.  This would AFAICS get rid of the 'missing icon' icon and make the applet usable in panels.
> 
> Thilo-Alexander Ginkel wrote:
>     I thought about that before, but found it rather weird to call an interpolated value from the forecast a "current" weather condition. Of course, it would be much more pleasing to the eye to have an icon to display. An alternative would be to fix the weather applet to display no icon instead of a broken one if no data is supplied for the current condition.
> 
> Shawn Starr wrote:
>     I used dptrs because I didn't want to break the internal API, which is public in a way. As more people use the backend changing things get more risky. the dptrs are for the member data vs functions. But, if we don't need the dptrs in the ions, we can get 'em out.
> 
> Aaron Seigo wrote:
>     in classes which are linked to by the ion plugins (e.g. Ion), it makes sense. for the ion plugins themselves it doesn't: those symbols aren't exported or used by anything that needs binary compatibility in their interfaces.
> 
> Will Stephenson wrote:
>     (Umm, threading, folks?)
>     
>     Re Current Conditions - I see your point.  ATM on wetter.com the current weather is 'cloudy' here but both their morning and midday values are 'rainy' so an interpolation would be off.  Is it worth asking wetter.com to expose this too, since they obviously have it on the site.  If other providers do give this data directly, perhaps they will feel it's ok to.
>     
>     However what icon should the applet use when it's in a panel with no Current Conditions data?

I asked wetter.com for a way to retrieve the current weather conditions a couple of weeks ago and got the reply that these are only available through an API for paying subscribers. Now, one could fall back to screen scraping, but that is no option as it violates their TOS.

The panel use-case - admittedly - is kind of tricky. What about an icon that mixes multiple weather conditions (so it is obvious that this isn't the current weather)?


- Thilo-Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2026/#review2904
-----------------------------------------------------------


On 2009-11-03 19:51:12, Thilo-Alexander Ginkel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2026/
> -----------------------------------------------------------
> 
> (Updated 2009-11-03 19:51:12)
> 
> 
> Review request for kdelibs, Plasma and Shawn Starr.
> 
> 
> Summary
> -------
> 
> This change brings support for wetter.com (a weather forecast web site especially popular in Germany) as a weather data source to KDE.
> The Ion makes use of wetter.com's officially-supported REST API. The API supports forecasts for up to three days, so the Ion does not supply any information about the current weather conditions. The forecast for the current day is split between night and day whereas the following two days are provided as an aggregated value for the whole day, respectively. 
> 
> Any feedback is much appreciated!
> 
> 
> This addresses bug 204219.
>     https://bugs.kde.org/show_bug.cgi?id=204219
> 
> 
> Diffs
> -----
> 
>   /trunk/kdereview/plasma/dataengines/CMakeLists.txt 1043003 
>   /trunk/kdereview/plasma/dataengines/weather/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/CMakeLists.txt PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion-wettercom.desktop PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.h PRE-CREATION 
>   /trunk/kdereview/plasma/dataengines/weather/ions/ion_wettercom.cpp PRE-CREATION 
> 
> Diff: http://reviewboard.kde.org/r/2026/diff
> 
> 
> Testing
> -------
> 
> Tested the Ion under a current KDE installation from trunk, fixed all Krazy warnings before the move to kdereview. Profiled it for memory leaks using Valgrind, which did not bring up any leaks in the control of the Ion. Those two still look somewhat suspicious, so I'd like to get your opinion about them:
> 
> 42 bytes in 1 blocks are definitely lost in loss record 372 of 1,156
>    at 0x4C25153: malloc (vg_replace_malloc.c:195)
>    by 0x60EDCB4: QString::QString(int, Qt::Initialization) (qstring.cpp:1027)
>    by 0x61BD5EE: QUtf8::convertToUnicode(char const*, int, QTextCodec::ConverterState*) (qutfcodec.cpp:169)
>    by 0x60EFDFA: QString::fromUtf8(char const*, int) (qstring.cpp:3850)
>    by 0x614C052: fromPercentEncodingMutable(QByteArray*) (qurl.cpp:223)
>    by 0x614EFB3: QUrlPrivate::parse(QUrlPrivate::ParseOptions) const (qurl.cpp:3781)
>    by 0x61534FE: QUrl::isValid() const (qurl.cpp:4124)
>    by 0x5A23B5A: KUrl::_setEncodedUrl(QByteArray const&) (kurl.cpp:1538)
>    by 0x5A23F19: KUrl::KUrl(QString const&) (kurl.cpp:411)
>    by 0x1FAE37D6: WetterComIon::getForecast(QString const&) (ion_wettercom.cpp:504)
>    by 0x1FAE5BAA: WetterComIon::updateIonSource(QString const&) (ion_wettercom.cpp:320)
>    by 0x1F267CBE: IonInterface::sourceRequestEvent(QString const&) (ion.cpp:47)
> 
> 176 (32 direct, 144 indirect) bytes in 1 blocks are definitely lost in loss record 882 of 1,156
>    at 0x4C2596C: operator new(unsigned long) (vg_replace_malloc.c:220)
>    by 0x1F267795: IonInterface::IonInterface(QObject*, QList<QVariant> const&) (ion.cpp:36)
>    by 0x1FAE151D: WetterComIon::WetterComIon(QObject*, QList<QVariant> const&) (ion_wettercom.cpp:68)
>    by 0x1FAEE366: QObject* KPluginFactory::createInstance<WetterComIon, QObject>(QWidget*, QObject*, QList<QVariant> const&) (kpluginfactory.h:461)
>    by 0x5B3367B: KPluginFactory::create(char const*, QWidget*, QObject*, QList<QVariant> const&, QString const&) (kpluginfactory.cpp:191)
>    by 0x5594EB5: Plasma::DataEngineManager::loadEngine(QString const&) (kpluginfactory.h:515)
>    by 0x1F6C813F: WeatherEngine::loadIon(QString const&) (weatherengine.cpp:92)
>    by 0x1F6C8C7C: WeatherEngine::sourceRequestEvent(QString const&) (weatherengine.cpp:226)
>    by 0x55913AC: Plasma::DataEnginePrivate::requestSource(QString const&, bool*) (dataengine.cpp:670)
>    by 0x5591421: Plasma::DataEngine::connectSource(QString const&, QObject*, unsigned int, Plasma::IntervalAlignment) const (dataengine.cpp:89)
>    by 0x1F05608D: WeatherPopupApplet::connectToEngine() (weatherpopupapplet.cpp:234)
>    by 0x1F05815E: WeatherPopupApplet::init() (weatherpopupapplet.cpp:223)
> 
> 
> Thanks,
> 
> Thilo-Alexander
> 
>

More information about the Plasma-devel mailing list