Episode 13

Episode 13

Length: 
(18:24)
Date: 
Wednesday, August 4, 2010

 

  • Qt Mobility 1.1 Tech Preview
  • Qt Web Runtime Preview
  • Qt 4.7 String Freeze
  • Qt Ambassador Program
  • Qt Dev Days T-Shirt Contest
Transcript: 
Mark Hatch and Justin Noel

Intro: Welcome to ICSNetwork's This Week in Qt, the ten minute podcast that keeps you informed of significant events that may impact your engineering projects. If you have not yet heard about ICS, please visit our website at www.ics.com. As an organization, we believe we have the best independent team of Qt engineers in the world. Whether you're starting a new project or need help removing that insurmountable roadblock that every project has, please contact us at sales@ics.com.

Mark: Good morning. This is Mark Hatch. I run the Qt business here at ICS and with me today is Justin Noel our lead engineers in the Qt area who is going to help me with This Week in Qt. Good morning again Justin.

Justin: Good morning Mark. It's been a pretty eventful couple of weeks in Qt; there is a lot to talk about. Today we're going to be talking about the new Qt Mobility 1.1 APIs. While a point 1 release doesn't seem like much too huge there are about a half dozen all new APIs ready for your consumption. We'll talk about the very beginnings of the Qt Web Runtime and a little bit about the forthcoming release of Qt 4.7. They have gone into a string freeze. We'll also talk about the new Qt Ambassador program and the contests that Nokia is running in regards to Dev Days.



M: That's great. Let's start with the Qt Mobility APIs. Tell me about them.

J: So, like I said, there are about 8 or so brand new sets of APIs that are going to help you build applications for mobile devices - things like phones and gps's and things like that. The biggest one, of course, is a Telephony API. Right now this is going to be a Telephony Notification API. What this means is that you can subscribe essentially to something like DBus and get events when an incoming call comes in, when a call is finished, and the status of the telephone call. This is something that could be useful for an application that might be hooked up maybe to your CRM - your customer database - so your sales guys can track how much time they've talked to particular customers, they can have a tickler system to make them insert their notes, and things like that. What this is not though, there is not enough API to actually manipulate the dialer or the telephony hardware on the phone. So you can't actually create an application that will make an outgoing phone call. That is something that we might see in the future but not in this release. This is a notification telephony API.

M: Okay, so this is the equivalent of the little pop-ups you see in the lower right when you get a new email in Thunderbird or something like that.

J: Exactly, so something can be watching, keep statistics on your telephone calls.

M: Excellent.

J: Another interesting thing, also based on a DBus type of concept, IPC basically, is a new, out of process service API. It's based on the Qt meta object system, which will help you define contracts for objects that go across IPC and the concept is based on multiple back-ends. So if you use the service API on Linux, you'll use DBus. If you use it on Symbian, you'll get CServer2. And any other platform, if will default back to qlocalsocket. This is going to make it very easy for one application to communicate with another application. You might even do this with your own suite of applications.

M: Any examples of the types of applications you'd use that would be good on this?

J: Well really anything that needs IPC. For example, if you have a data engine for your application that runs in the background and you have the gui for your application, this would be an excellent way to communication between those two.

M: So how would you have done that before?

J: Well before, you would have had to use straight DBus or straight qlocalsocket, so what this is going to do is allow you to choose an API that's going to get you the best IPC on every platform that you use. Rather than defaulting to something that works everywhere - like qlocalsocket. There's also the mapping API, which is probably the most visual new API in the Mobility 1.1. This will allow you to make an instance of a mapping widget. And it's all based on plugins, so right now there's only one plugin and it's for Ovi Maps. That's Nokia's product and they're the first ones releasing this. You can make an instance of a map widget. Right now it will load you an Ovi Map widget, but if somebody wrote a plugin, it could be a Google Maps widget. You can take that widget and then you can add markers or landmarks onto the map. So if you wrote an app that's going to tell you all the restaurants and give you reviews of all the restaurants in your physical location, then you can bring up one of these maps, you can find all the restaurants, and pop up the reviews right on top of the map. There's also an API that will do routing for you. You can actually do routing between point A and point B, and you will let Ovi or the mapping toolkit figure out how to get you from point A to point B in a car.

M: Okay, got it. With hopefully avoiding the "at the next stoplight make an illegal u-turn and come back."

J: Exactly, or going the wrong way down a street that doesn't exist anymore. So on and so forth.

M: Yep, been there.

J: So, that's probably the most complicated one. It will be interesting to find out what happens when a third party writes a plugin for this system. Say I wanted to use Google Maps instead of Ovi Maps, what would happen? It would be very interesting.

M: How flexible is the marker system? Have you looked into that yet?

J: The marker system right now is fairly rudimentary. You get to draw circles, rectangles, and lines from around a point - or from point A to point B.

M: But no pixmaps or anything?

J: It doesn't seem to do anything too custom right now, but I assume that will come in the future. This is just the technology preview. Like I said, in my example, I would hopefully be able to put an actual restaurant review in some sort of popup right on the map where the restaurant is.

M: Exactly. And maybe have a knife and fork, something that kind of signifies it's a restaurant.

J: Exactly, so there's an organizer API, which basically just means calendaring. It has input. It can take in things like iCalendar information so all those meeting notices you get in the mail can be added to the Calendar. And for the backend, once again we're seeing multiple backends, basically plugins. They have one for Maemo, probably moving forward into MeeGo, one for Symbian, and actually one for a desktop system, KDE's KCal. So that's the backend storage for the scheduling, and you can basically make instances of the calendar and find out when things are happening and manipulate it. Right now there don't seem to be any widgets available for the calendaring, but you either write your own or there are QML bindings, which makes it look like the possibilities for making a really cool calendaring app are definitely there. Two more notables, very short, first is the camera API that will allow you to snap a photograph, focus the camera, things like that, and a set of document gallery widgets. These are widgets that you can bring up on the screen, you give it a pile of mp3's, it will read the meta information and will automatically be able to do things like: sort by artist, sort by song, do cover flow, things like that.

M: I wish we had this about three months ago.

J: Yeah every time I see these things, I think to myself wow, we live so far on the bleeding edge that we implement things just before Nokia does.

M: I know, that would have cut the time of our recent project in half. Well that sounds like a really exciting set of functionality in Mobility 1.1. So is this tech preview available now? Do we have a beta on the way?

J: There is no schedule; however the code is not only in git as usual, but is also available as tarball packages that you can download. You can get those off of labs.trolltech.com.

M: Maybe a beta by Dev Days?

J: I'm sure that's the target for some sort of release.

M: Okay, so what's next?

J: Qt Web Runtime. Some of you out there, probably most of our listeners, are C++ developers, so they might hear Web Runtime and say what exactly is that? So a Web Runtime is a set of JavaScript APIs satisfied in order to write an entire application in HTML, cascading style sheets, and JavaScript. It's currently a pseudo-standard in the W3C working group and they're working out exactly what you need to satisfy to be a Web Runtime. You can sort of think of these types of applications as the apps that run inside of Palm's Web OS. They're very heavy duty web pages that can make local function calls via JavaScript. And when someone says Qt Web Runtime, what they really mean is a web runtime engine written with Qt as the back-end library. So the calls you'd make would be standard w3c calls, but they would end up calling Qt. This is very interesting for developers of web and phone because this web runtime should be able to run everywhere that Qt runs, and Qt runs almost everywhere.

M: Okay, then obviously what you would do in this situation is to have the client code written in Qt WRT and that would help give it even another level of portability or customization on the device.

J: Exactly, some apps just tend to lend themselves to this type of programming, especially if you're heavily services based. For example, I can definitely see a Pandora application being written very quickly in a web runtime. Right now this isn't even in git yet. This is a tarball that you can download from labs.trolltech.com. I think they actually link back to somewhere in Forum Nokia. It only runs on the N900 right now, but eventually should run everywhere that Qt runs.

M: So what's this relationship between this and the WRT that we've been tracking for the last year or two?

J: That's a very good question because Nokia has had its very own web runtime for quite a while now. It seems to be a parallel project where the public interface in JavaScript is going to be roughly the same, but the back-end implementation is going to be different. I don't know exactly what Nokia's is written in. Right now it's not Qt. This one is the back-end that links it into the Qt libraries.

M: Yeah, it's been pretty clear that Nokia's viewed that there's one path which is down the Qt/C++ area. They've seen another path down this WRT for those types of applications. And then certainly, QML is yet another.

J: Yes, this seems where they might all come together because this is definitely Qt/C++ backend combined with the front-end of the web runtime engine.

M: So mobile developers keep an eye on this space.

J: Exactly. And if you're comfortable with writing for things like Web OS, then you'll be comfortable here. In fact, if you're comfortable writing web pages, you'll be comfortable with this. So Qt 4.7 is quickly coming up on the horizon. We're hoping to see this sometime before Dev Days, maybe at Dev Days. It was just announced that there was a string freeze. What a string freeze means is that all the user visible strings to be presented to the user are no longer going to change. They need to announce that because they need to get all the community translators to go ahead and translate all these strings to all the different languages that community translators support. They have just announced this, so translators out there start your engines. If you look at the community-supported translations of Qt and you find that your favorite language is not supported, feel free to start one.

M: Okay, good. That's another sign that 4.7 is just about done.

J: Exactly. The fact that a little more is frozen means that the release is likely. Nokia has launched in the beta format the Qt Ambassador Program. This is for people who have their own Qt projects that want to sort of strut their stuff and show their zeal for Qt. You can apply to be an ambassador at qt.nokia.com. It's a bit of an honor to be listed as an ambassador - a little bit of resume fodder, I suppose. And there are some benefits and the benefits are kind of being worked out right now in the beta, but right now you get a t-shirt, and you also have the ability to apply to speak at Dev Days. It seems to be a requirement that for community people to be able to speak at Dev Days, they must be an ambassador. It sort of gets you certified as an insider.

M: Okay, so we need to get David to submit his QBrew application so he can be an ambassador for beer making with Qt, right?

J: Exactly. Open-source brewing - my favorite kind. So finally, there's a Dev Days t-shirt contest. If you've gone to Dev Days in the past, you may have noticed that they always give out t-shirts with catchy slogans and/or fancy graphics that usually have something to do with Qt. Something like, may the source be with you. Or f-i-v-e spelled out in ASCII for their 5th anniversary conference. So if you have an idea for a catchy graphic and slogan, you can go to qt.nokia.com and you can find the link to the t-shirt contest and submit it. The prize for the t-shirt contest is free tickets to Dev Days, and I hope to see you guys there - hopefully with catchy new t-shirts.

M: Well at least ones that the rest of us can figure out what they mean this time around. I remember seeing the ASCII one in Munich and then going to California and still not getting it right. We have one thing to announce too that I observed this week. Actually one of the engineers here spotted it because I hadn't seen it directly. MeeGo has another design win, if you will. There is this in-vehicle infotainment consortium.

J: Yeah, that was those Genivi guys.

M: The Genivi guys have announced that they're going to use MeeGo for distribution for open source in-vehicle infotainment and one of their members is a favorite of yours, right?

J: Oh yes, BMW. So these guys posted on their website a really cool interview-type of video with a bunch of their engineers and leadership talking about the future of what they call non-differentiating automotive software - things that would run entirely on the back-end and they the manufacturers could put something branded on the front-end. It's an industry consortium, so there are all sorts of manufacturers involved in this, which makes it sound like it might actually going to get somewhere.

M: If this was actually going to happen, it would be a huge change there. Right now, a lot of these infotainment systems are Qnix with Flash. That's how they tend to be running at the moment. That should change this tremendously. Who knows, maybe we'd have touch screens or web runtimes or something else there. QML is among these.

J: Yes, and I think that making the back-end the commodity is going to be a huge benefit to all the MeeGo projects if it gets picked up, but the manufacturers themselves, like most of the parts in automotive cars are a commodity. They're made by companies like Bausch and Borg Warner where they just buy the same u joints over and over again and their used by n number of cars by n number of manufacturers, so it would be interesting if they had some commodity software in there as well.

M: Yes, you know one of things that's amazing as I'm looking back over the years, and I see all these different lines of development suddenly emerging and with some of them you start to get the feeling that there are some dotted lines emerging. You have the whole Mobility API initiative, which I don't think most of us were aware of a year ago and now we're already talking about a 1.1 release, QML which has amazing possibilities, and Web Runtime coming from a whole different direction. The old Trolltech guys were doing a great job in their development, but I'm getting the feeling now that we're starting to see Nokia putting their shoulder against the wheel here and really starting to get things done. We're seeing a lot of major enhancements here coming at us pretty quickly. It's pretty exciting.

J: It's definitely going to be an interesting year.

M: That's for sure. So again, this is Mark Hatch. Thank you for joining us, and Justin, I appreciate your help and insight here. And we'll see you the same time next week.

J: Yep, same time, same channel.