In the spirit of writing more demos for Qt/S60, I thought about having something that I will actually use on a daily basis. A weather applet came to my mind. While my previous weather example was more a visual web-scraping attempt based on QtWebKit, this time I wanted something else and hence I decided to use the unofficial Google Weather API just like what is used in Weather Globe Google gadget. The query for this Google service will give back the result in an XML format, which is quite easy to parse. Unfortunately Qt/S60 Tower release does not bundle the XML Patterns module yet, so I have to use the classic stream reader to digest the XML data.
Here is the screenshot of this little weather tool running on the desktop. Use right-click to pop up the context menu, from which you can choose one of the predefined places. The dialog to ask the user for a custom location is left as an exercise for the readers. The beautiful icons are taken from the Tango Desktop Project with an additional set from darkobra at devianart.com. Because I want to take into account the different S60 phone resolutions, these vector-based icons are rendered at run-time thanks to our QtSvg module.
Just like in the case of both the digital clock and kinetic scrolling demos, Alessandro was (more than) willing to waste his precious time filming the following video, for our pleasure. It shows the weather info running on Nokia 5800.
The code is just one git pull away from the usual repository, see the weatherinfo subdirectory. As you might guess, it is using Graphics View, although the layout and animation are done semi-manually. This is because I want to make sure it looks good both on Portrait and Landscape Mode. If you are brave and want to experiment, convert the simple animation to use the brand-new Animation Framework slated for Qt 4.6. Still need some challenges? How about using XPath and XQuery to process the XML? Feel free to implement auto refresh and multiple cities features, too!
Last but not least: thank you, Google!
18 Responses to “Weather info for Qt/S60”
Cool, but it’s not very smooth. So far it seems like only the iPhone manages smooth animation. Android has jerks occasionally (maybe due to the garbage collector running?) and this seems even less smooth.
@Tim: Bear in mind, this is Qt/S60 prerelease, not a final release yet.
Cool.
But why don´t you use the KDE Oxygen Icons?
http://websvn.kde.org/trunk/kdesupport/oxygen-icons/scalable/status/
awesome, you are The Chief!
Very cool! I’ll look zo zhe code!
Really nice.
But when I change
url.addEncodedQueryItem(”hl”, “en”);
to
“url.addEncodedQueryItem(”hl”, “ru”);”
I see some weird characters instead of Russian.
Why could this be?
“QString toCelcius()”
is spelled wrong 
@Frank: A matter of personal taste (and I wanted something different this time).
Where could I get the *.sis file? Unfortunatelly I’m not able to compile the source :/
Very fine example of Qt’s capabilities although expect fierce competition from similar widget (HTML/CSS/JavaScript) technologies that seem to be optimized for such applications.
I noticed font anti aliasing issue:
http://vitalyk.com/temp/fonts.png
When you enlarge the window at some point font anti aliasing method changes, which makes fonts look much better.
Compiled weatherinfo with Qt SDK 2009.03 (open source), running Windows 7 RC.
@Vitaly: I agree that the right one (bigger) looks better than the left one.
The difference is that the left text is rasterized by Windows using cleartype, while the right (bigger) one is rasterized by Qt itself, with normal antialiasing. Qt’s raster paint engine has a threshold right between those two sizes, which changes the way how text is rasterized.
The small texts in your screenshot showing the temperature are also rasterized with cleartype. They look pretty good (at least on my LCD screen). So, apparently, while cleartype is great for small fonts, it does not really improve the rendering of big fonts. That is however the situation with big fonts in many Windows applications (e.g. Firefox), since they all use Windows’ rasterizer, and unless they use Qt, they won’t have that magic threshold.
Not sure if Qt should/can fix that in a senseful way. Any suggestion?
@Alessandro
Thanks for explaining!
That’s a pretty smart move, switching to Qt’s rasterizer as cleartype fonts become bigger and uglier 
Wish Firefox did something similar.
Though, how would I override this behavior if I wanted to use Qt’s rasterizer only?
@Vitaly: The reason for Qt to rasterize glyphs by it’s own above a certain size is not in order to have nicer fonts. But rather for better housekeeping in the text rendering system of Qt (highly condensed condensed explanation).
One way to avoid cleartype is disabling it in the OS. I assume that Microsoft’s normal antialiased rasterizer gives about the same results as Qt’s rasterizer but probably much faster.
If you still want to ensure that Qt’s text rasterizer is used for text, You may try to add text to a painter path…
http://doc.qtsoftware.com/latest/qpainterpath.html#addText
…and draw that path…
http://doc.qtsoftware.com/latest/qpainter.html#drawPath
@Alessandro
Thanks again!
Disabling cleartype fonts helped:
http://vitalyk.com/temp/fonts2.png
There is still a visible transition, but overall, font’s look much better.
Have to give credit to MS here, its rasterizer still tries to align to pixel grid, which makes fonts look crisper.
Oh well, I guess it’s always a compromise until we all have 300 DPI displays and resolution independent UI
Nokia 5800 has a 230 DPI display, maybe that’s why fonts on the above weather info video are pixel perfect.
Back to my first post, I still don’t get why non-Latin characters are not displayed correctly?
@Vitaly: Apparently the xml data from the weather service is UTF-8 encoded, but it gets interpreted as some other encoding.
My poposed quick solution: In line 105 change…
digest(networkReply->readAll());
…to…
digest(QString::fromUtf8(networkReply->readAll()));
@Alessandro
Thank you. Your solution is much simpler (and works!) than what I was trying to do. (I’m new to Qt and C++)
@vitaly: I have committed the encoding fix (see commit 152d1e7).