 100 literally, but now we're currently just running the files off it on the laptop So you'll just have to trust me that this all works perfectly fine on the mobile device all right, so This is about too quick for mobile you on it. I'll start by quickly mentioning about me I'm a software engineer who was a troll tech which became Nokia and I've worked on started with Qtopia back in troll tech and I've been there for three years QML is about two and a half years old. That's mostly what I've been working on so far at Nokia Now about Qt, there's the possibility that some of you may not have heard of it before It's a cross-platform GUI toolkit. You'll probably recognize it as the GUI toolkit behind KDE and Which as you know, they popularly exist off environment But the other platforms that are going to be of interest here will be the mobile platforms like say me go and The main main mode running on the end 900 We have a Brisbane office where I work. This is the one responsible office responsible for QML and Qt mobility that's what we've been working on and You can be proud to know that those technologies have come out of Brisbane. So now let's go on to Qt quick So the background in for this is the Qt user interface construction kit and This is a set of technologies we've created for mobile UI development So one of the key parts of it is QML the Qt magic language a declarative language that you can use to specify your user interfaces The Qt declarative module, which is a C++ module part of Qt that pretty much interprets and compiles the QML language into a actual in-memory Object tree like you could have created with C++ and that's what ends up being displayed on screen and Also part of Qt quick is something that I won't be talking much about Because I'm not so much involved, but there is a lot of support for this in Qt creator There's support for editing QML files for visual design For on-device support and I hope that we can get something a lot better than the Android situation James was Lamenting about earlier So the whole reason that we created Qt quick and QML was to provide a solution for writing Mobile user interfaces and so that's what I'm talking about today about the design choices We made to try and make Qt quick really effective for writing Mobile user interfaces in particular in case no one of you have seen QML. I'll give you a quick example So this is QML there's a This rectangle here starts a rectangle element inside the curly braces you can set properties This might remind some of you of Jason And when you set these properties like color x y this goes through the Qt property system And it's the same as setting them the dynamic properties in C++ So while it's got a nice interpreted language that JavaScript people can quickly Recognize and use and it's fairly friendly by the end it does end up being in sort of the same Efficient in-memory structures as we use in C++ Also, we have the same signals and slots you might recognize from C++ this here Is a signal handler it executes this bit of JavaScript when that signal gets emitted so we're integrating well with the existing Here concepts now this presentation is written entirely in QML. So that example code is creates this and You can see it's got the specified geometry color the animations that we're putting here for the state change and it's all just Working there. That's what it does a more extensive example That I might not have time to share the code for is this same game is one of our oldest examples and It appears to be missing something from not being on the phone. Oh Right you the part uses a additional module Key extension modules are something easy in QML. Let's use an additional module that provides particle elements And that's a separate package. I forgot to install on someone else's computer. So Unfortunately, we have no particle effects in this presentation But that was the only part that required it so one of the sort of factors we've been focusing on is the UI split now With QML, it's very easy and it encourages you to have a clear separation of the UI parts of your application Now we can't actually force any developers to use good practices and split out their UI logic But we do really encourage it with the design and make that very easy for you So the QML files those declarative bits those can contain the user interface and all the user interface logic required to make that work and Then you can have the separate C++ or Javascript parts being called by user interface so there's opaque blocks to do the real data handling and logical part and This is really important for mobile UI development because there's a lot more Need for UI porting in mobile So if you're going from desktop to mobile is there's a lot more changes required to the UI Then if you're trying to port from desktop to desktop even if you're going between say Linux and Windows there it's a salt but the same computer it has the same user input devices the same monitor and human input devices Whereas between a desktop and a mobile device like this one a lot has changed It's the very rare mobile device to even have a keyboard. It's got a touchscreen with a different aspect ratio So it's really quite different to have a good UI you pretty much need to Rewrite it and that's why we really try to encourage and help the use case of having a separate UI Not that we completely different But you will need at least the human touch to create a separate UI that works well on the different platform And I believe this is what the K-mail people did when they wrote K-mail mobile with QML They I think were able to save up to 80% of their code with the same C++ library code Doing the stuff in the back end But when they rewrote just the mobile UI using QML that could hook in and use the same code And that really minimized the amount of rewriting they had to do to go to a completely different user interface platform But it's not just desktop to mobile There's a lot of differences between mobile devices and looking at just the Nokia devices even just Symbian Qt is supported on the N95 and the N8 and You'd probably need to write a different UI to get it running on both those devices I mean it's Qt you can write the code and it will compile and run on Linux and both the Symbian phones, but it in order to have a usable user interface between a keypad slider phone and a Capacity of touchscreen phone you're going to need to do some rewriting and so we really try and make with QML it easy To have the UI and one little part that you can tweak or rewrite as necessary for a different device And you're still calling the same C++ code that does the real data processing on all platforms because there you really can write ones to play everywhere And it works fine in the back end But another point sort of drive this home is that it really can be just little things that make you want to rewrite the UI if there's a change in just the DPI then Things like buttons that need to be touchable need to be resized And you might not want to truly that the computer as the layouts go everywhere trying to accommodate this It might just be easier to resize the buttons yourself to something that looks nice and fits on that screen so Another thing so that's a UI split make that easy another thing. It's a bit more mobile specific Though could also play desktop is performance, but you don't really run into performance constraints on desktop That's not very common. It's much more common on mobile devices to run into performance constraints where you just can't do everything fast enough to get a smooth user interface and It's important for the user interface to at least feel smooth and responsive No matter how pretty it is it needs to feel smooth and responsive to get that good user experience so once design choice we made with QML was to go with Primitives instead of widgets some of you may know the cute widgets They're very large blocks of functionality that pretty much do everything on every platform and On the desktop you can afford that and it's great convenience, but for the more performance Challenge mobile devices you can't really afford that so we have these sort of simple Primitives that just do one thing like the rectangle you saw back there that just draws a rectangle There was the mouse area primitive that just does the user input and by combining these simple and efficient Primitives you can still do everything you want, but it's so much easier to be done in an optimized fashion And that's why we have in some ways such a limited set of primitives That's why we don't just have particles in there by default for everyone to use is that we try and stick to the primitives that can really perform well on all the devices and That's a big performance challenge So we try and make so that the rectangle can draw the nice rectangle with all its features fast enough to be part of the UI without ruining the smooth user experience and that is Something that's led just to having just these relatively small set of primitives that just do one thing But they can do it quickly enough to have a responsive UI a good example This is the positioners so cute on the desktop has layouts that will resize items intelligently that will try and navigate size hints to get to the optimum size considering how much space it could fit in the other elements and I mean that's great, but it's expensive so with QML because we need to run smooth and responsive on mobile devices We just have positioners all they do is they position the x and y of the items to arrange them in a row or a grid because they can do that fast and they can do that fast enough to give you a responsive user interface on an embedded device and When we can do that with layouts, then layouts might join the Set as well, but for now we have to stick to what we can do fast enough for a good user experience And another point I'll address here is something some people have wondered about Why do we make the implementation of these primitives private so all the Implementations like rectangle and mouse area are private headers inside cute that we suggest you not Reimplement those type class and try and use modified versions of because we're not guaranteeing the C plus plus API And this gives us the flexibility We think we may need to really optimize things to get the performance to a great level Now cute has a decent track record on this in the past with The graphics scene improvements in 4.6. There really was a significant speed up But we're hoping to do even more than that with QML Because we can leave the QML API intact in public so all the stuff from QML once it gets Interpreted works fine But we can change the C plus plus structure so as to make it even faster an example of this is Switching out the back end. So one thing we're currently experimenting with is trying to put this on a completely new scene graph Now that's a massive implementation change and will probably affect the C plus plus APIs But if it works, then we'll get greatly improved performance and we can keep the QML API the same So that any of the QML applications like this presentation will still work just fine But faster Another thing that we think really helps with the mobile Application development is this sort of interpreted language now. It's not really interpreted It's more just in time compiled because as I said by the time your application is running The QML has been turned into an in-memory object tree like you could have gotten with C plus plus the same Q graphics objects have been instantiated But because it's written sort of an interpretive way that's this easy on device testing I didn't have to compile anything when testing this presentation on the end 900 I just copied the files over since it was net 900. I could even edit the files on it fairly easily with the keyboard so you can actually try it out on the target device easily without a long Compiled phase without say having go down to a lab if they're the only ones who can compile it for you The interpreted scripting language sort of nature really makes it possible to Try the UI on the target device and because all the devices are so different you really need to do this There's a completely different experience trying to use it on something like this with the touch screen compared to say my dual widescreen monitors that I normally develop on with massively powerful computer that can do all those particle effects in an instant so It really does help to be able to easily put it on device and Try it out in the right context because it's just interpreted when you launch it and Even if you have a C++ backend We support a notion of dummy data in the QML viewer And the way this works is that the variables you're accessing the C plus plus back in implementation with Can be redirected to some fake data You've written in another QML file and then you can try on device without having to do any compiling just copying files over You can try on device the actual UI with an actual data source being pulled from and You can try flicking your list of thousands of contacts or whatever Actually on the device just from copying files over and then when you switch from dummy data to the real data Once they've finally gotten it to compile for that device then there's no change to the QML files It's all exactly as you tested it with of course the possibility that your dummy data was not a good test case And this means it's prototyping friendly so you can actually start prototyping with QML on the device What you want your user interface to be you can try it on the device and unlike a purely prototyping language Once you finish your prototype decide that it's working. Well, you can then use that as the actual UI You don't have to say okay. This looks great. Let's try and re-implement it and see if we can do that in C plus plus You actually have the same prototype you've been working on On the device and you can just reuse that So this isn't just great for the developers if you have a separate designer this is even better, so if they Sorry, I pick on you if James gets his wish and gets a UI designer working on his application They're not going to write want to write code like Java or C plus plus to do the user interface They're going to want to mock something up in some other tool And we've tried to make QML friendly enough for them to do that You've seen the JavaScript like syntax web designers should feel comfortable enough to just go in there and do it And the designers we've been working with have had no problem with writing the QML themselves and this way They're not only prototyping and playing with the design they want Using a technology on the device, but they're doing it with a technology that can be used for the UI They don't have to go to the programmer and then say okay Reimplement this in C plus plus is how I want to look they've written the actual UI and they've tried it in a real context They will see okay. This effect is too slow to work. They will see oh on the touch screen The mouse wheel scrolling doesn't work as well so being able to actually write the UI for designers is something that we've been really aiming for with QML and To help make it even easier for them. There's an upcoming visual tool as part of Qt Creator Which will hopefully be up to the same sort of standards as Xcode where you just Can drag and drop the elements you want go lovely UI and then stick that in the application and a final point on the design for mobile which Sort of it is more in the evolutionary sense than where we were thinking initially But we have the Qt components project that's upcoming now. It's not done It's even pre alpha right now, but I mean it's open source. So you can still play with it and What this is doing is trying to get sort of the best of both worlds with the Components with all that sort of widget like functionality for each mobile device But still fast enough and still working integrated with QML To get you the native sort of feel and style So Mego is one thing that we're particularly trying to get this working for we hope then Mego will be as simple as say this to Get a button or a checkbox. I mean it's already even using the colors from New Bantu here, but Yes, the Qt components project aims to make it as simple as just writing button or checkbox to get those elements You then tweak them as you will with QML. They are designed for the platform So the Mego ones will be designed to be fast enough on the Mego devices to work well with the Mego Sort of user interface constraints and to fit in with the Mego style So there is an upcoming project that should really help for mobile UI development That we're working on with QQQ So I probably a good time now to bring up again that this is free and open source software The development and source code is all open it up on Gatorious So here's where you can get the code for Qt declarative and Qt quick is all part of Qt So that's with the main Qt repo Qt components is being done in a separate repo But that's also on Gatorious if you want to check out the latest code there And that's probably the only place you'll find Qt components at the moment because it's still well before release As regards to Qt quick and QML we noticed just now that it's Nicely packaged in Ubuntu. There are packages for the Qt and the declarative module and the QML viewer available on at least 10.10 today if you want to try that out and From memory I've also downloaded Fedora packages It should be in your distribution if you just want to play with QML and Qt quick on a desktop In case people missed it Qt is under LGPL available under LGPL now So we have three licensing options to cater for pretty much everyone. I'm sure you'll find something you like and The open governance project I will mention now. It's Moving slowly you may have heard about earlier, but we've been working with the community trying to find a best-in-class open governance model and when this finally gets Through and implemented. We're hoping to have a sort of best-in-class meritocracy Governance for Qt where it's the people who make contributions that help determine the direction it goes and then it will be a truly Free and open source project right now. It's just your own standard LGPL and GPL sort of thing But that still is open enough for any of you to have a look and play around with whatever you like So are there any questions? About Qt quick and or mobile device UIs all right. Well, I mean real devices it is on here This was it was good if we got it running off here Then which we only didn't because the audio visual setup didn't seem to want to take the component input If you want you can come down later and see it running on here This is running on here with the packages that are part of the MIMO distribution So if you want just a real phone here it is it's running and working there as for widespread distribution among multiple vendors Well, all I can say is that Nokia is currently focused on getting it running on Nokia platforms Mego and Symbian and we're running working on distributing it there As for other platforms some I place as a no key and say but it is free and open source software I've heard that there are Android and even iPhone ports of Qt and all you need to do to get Qt quick running on another device would be to port the C++ Qt library to run that device and Qt quick is basically only depends on the rest of Qt. It's should be fairly easy I don't know the status of those community ports, but for all I know they have gotten to that level and you can already Use this on your Android phone You'll have to look into the community ports for more details. I Don't know the status of Qt quick for Jambi though. So That's another community supported thing that I have not worked on Yes The JavaScript engine we're currently using is JavaScript core Note that we only really use a JavaScript engine for big sort of snippets of JavaScript So actually even something as simple as this We can take care of ourselves. You can embed full huge chunks or parse entire files of JavaScript That gets done with JavaScript core. We have our own engine for reading the QML syntax, which is JavaScript like in that it's reminiscent of it, but it's not actually JavaScript As a language. It's its own language. I beg your pardon I don't remember the numbers off top of my head, but that does come under performance Probably should have mentioned that we have been trying to keep it fairly lean the only the last Test we did that I remember was that we were a few megabytes smaller in runtime memory footprint Than the same application being run with Qt webkit. So It's not saying much, but at the very least we're leaner than HTML 5 well, so what happens is that the If I understand your question correctly, you're asking will there be a QML compiler to just get a binary out of it? Right. Well, basically what what we've got now is that the QML gets compiled into a sort of binary form When the application runs and we're looking into caching that it's will be theoretically possible for you to dump that out and then read it again yourself later, but we think the most the easiest thing for you and users would be if We just add the ability to transparently cache it the first time you run the application it does the compiling and then later it accesses the compiled cache Well, if you don't want anyone tampering with it Then the solution for that is to compile the QML files into the binary with the Qt resource system So it's just a couple of lines to create C++ application that loads a QML file for the UI and stuff and it's Well, maybe not even any lines really with your creator to get it To compile all the QML files and stuff into the binary with the Qt resource system And then you have to break up in the binary in order to edit those files There's one more question up there. May I install the particles plug-in so as to Yeah, well, I mean the same game is not the only you will need to do this, I think Well, maybe we should come see the same game on the phone. It's a little more impressive there I think because playing well, I'm sure we've already got a same game. We can play on this computer Sorry, I wasn't ready for I might need to restart the Application here Yeah Okay, let's see if it's working now there we go, so it's um was This one was sized for the end 900 screen so you can still actually tap on the individual objects, but This is entirely written with QML and JavaScript If we took out the high-score functionality that you won't be seeing here anyway It was under 300 lines Without that that functionality was to have web enabled pulling and pushing of high scores from a server But this this is entirely with Houston QML JavaScript for the game logic in a separate file There's the score Buttons and of course objects that you can interact with for the game part with complete particles and enemies So here's one example of something you can easily do with Qt Quick, and I'll be happy to show you one later that it works just fine on a mobile device And that's really the important thing Here, and you can also try and beat my high score, but that's All right, well, thank you very much