Programming in groups requires you to use a source revision system. Its a fact; not doing it would be like crossing the north pole in your sunday clothes, it won’t be very successful. This shows; as long as people have collaborated in writing software, there have been systems to support this. I count 32 such systems on wikipedia .
Up until 2001 or so I used cvs exclusively. It did the job, more or less without loosing too much work. I started looking into distributed source revision systems, which looked a really cool idea that may give each individual programmer a lot more control over how he works, and how he can collaborate with his peers.
I went through TLA, got frustrated by the complexity, searched on and found Darcs. Fell in love quite quickly. Great idea, even better user interface. Unfortunately written in a language I never had the patience to go out an learn (haskell). Perfect romance setting, gives me what I need and I can never hope to fully understand it

Darcs was started initially with the idea that a distributed system doesn’t have to be more complex to use, just different from a centralized system. I have been part of the development of Darcs to the extend of working on user interface issues, writing clear language in the UI and other simple things like that.
Darcs has its share of technical problem, though. It doesn’t scale up well. Its basically unusable for bigger projects.

Flash back to the present. It feels like git is going to be the winner in this battle of programmer mindshare; on a technical level it certainly is the best there is. It scales up without effort and it is incredibly fast. Here at Trolltech various people are already using it every day. There is ongoing research to make it the default system in KDE as well.
Git, in my eyes, is the absolute opposite from Darcs, where one is bad the other rocks and vice versa. Git is technically superior; its basically the next generation in its field. Its got more features then you can wave a stick at, and its got mindshare and active development. The bad is that its reinvented the user interface, the in-line documentation is weak. The choice of command names arcane and inconsistent. Discoverability of features is basically a hit-and-miss.
Darcs, on the other hand, has not been strong technically but it has been developing a user interface (command line) over the last 4 years that is coherent+consistent, easy to learn, has lots of textual feedback while still being very feature rich.

Now, what to do! I like parts of both, but using either gives me headaces. The sum of the parts is a negative number in this case

So, like any good hacker, I started a new project to marry the two components. My project, which I call ‘VNG’ uses a normal git repository and expects git to be installed but using ‘vng’ you will find an interface designed much more coherently. Darcs users will feel right at home.
The project is very much in alpha right now; what is there works, but you’ll be using git for more advanced things. (and some not so advanced things).
I did find it time to make a nice announcement and call for developers that want to help out work on vng.

A short tutorial to get you started;

  $ mkdir ~/myproject
  $ cd ~/myproject
  $ vng init

You now have a Vng repository! Let’s do something with it:

    $ touch myfile
    $ vng add *
    $ vng  record -am "Initial import."
    Finished recording patch `Initial import.'

A simple ‘vng’ will give you the help output, which I’ll just paste here as a good overview what I already have;

Usage: vng COMMAND ...

vng version 0.22 (>2008-03-28)
Commands:
  help          Display help for vng or a single commands.
Changing and querying the working copy:
  add           Add one or more new files or directories.
  revert        Revert to the recorded version (safe the first time only).
  unrevert      Undo the last revert (may fail if changes after the revert).
  whatsnew      Display unrecorded changes in the working copy.
Copying changes between the working copy and the repository:
  record        Save changes in the working copy to the repository as a patch.
  unrecord      Remove recorded patches without changing the working copy.
Copying patches between repositories with working copy update:
  push          Copy and apply patches from this repository to another one.
Administrating repositories:
  initialize    Initialize a new source tree as a vng repository.

Want to help or try vng? The sources are on; http://repo.or.cz/w/vng.git
Either send me patches or upload them to the ‘mob’ branch (which requires no password) on repo.

Looking forward to your flames!

We have just passed the Easter holidays, which I spent quite relaxingly. And its been so cold I could go snowboarding last night, just outside of Oslo. Awesomeness!
Less then a year ago I lived in The Netherlands, where going snowboarding after work is basically unthinkable. I certainly don’t regret moving

Today is document freedom day, the idea is that you try to educate your peers and friends about the cool things that a document format based on open standards can bring. At first I was bit wary about the idea. I’m not much of an evangelist, myself.
Seeing that embracing change, like me moving to Oslo, can bring so much unexpected advantages and really just make you feel better that’s also very cool. And something I’d like to share with others.

With the OpenDocument Format it is possible to open your document in different applications, and on different platforms. So you can work together flawlessly with Windows and Linux users, some of which use KOffice, others use OpenOffice or one of the various other tools out there.
Having websites create documents you can read is also very easy to do. I remember when some webapp tried to generate xls files, it required the server to start excel for each user that tried to download the xls file with his data. It should be obvious that this doesn’t scale very well. If there were more then 10 people trying to download their data, it would take 10 minutes already.
Using the open document format instead would have allowed using a simple library to create such a document, and there are quite some already available for usage. No need to have a whole office suite installed, everyone can, and does, implement this open standard.

So, for everyone, go and evangelize the usefullness of open standards and the freedom that this gives developers, user and companies to get a richer selection of products to choose from and do more with less.

I’m sure that others found very different advantages to using and depending on ODF. Please share them in the comments!

History in a web browser has a number of challenges that make it a good demonstration of Qt’s model/view. The history is used in the url completer, the history dialog, the history menu and lastly by WebKit itself for determining if you have been somewhere before. And just to add to the mix it need to be able to scale. A year of history could easily be 20,000+ entries. The History component of the demo browser is more advanced then the examples in Qt and shows off some more the cool aspects of model/view and it has been suggested to me that writing up a little description of how it works might be useful to some developers looking to use model/view in their own applications.

I have spent time working on item view and know it pretty well (I put together the Modeltest and ItemView Tips) so the history component of the demo browser was fun to write. The source code for all the classes can be found in demos/browser/history*.

The first class is the history manager who’s data structure is optimized for history, not for dealing with item views. The class loads and stores the history, emits signals when there is a new entry or one is removed and that is about it. This class should be able to stand on its own if it was pulled out and used without itemview. I wanted to keep the memory usage down as much as possible. For 20K entries it was only using around 10MB of ram when I was done.

On top of the HistoryManager is the first model, a QAbstractTableModel (HistoryModel) who’s only job is to wrap the history model. It doesn’t do anything other then implementing functions such as rowCount(), flags(), and data(), matching up the itemview functionality with the corresponding functionality in the history model.

On top of that is a QAbstractProxyModel (HistoryFilterModel) who job it is to filter out duplicates. Looking at browsers I noticed that if you visit a link twice the browsers always hide everything, but the most recent visit. A hash is used to determine if a link has been visited along with the most recent location of the visit. This model has a convenience function that is used by WebKit to determine if a link has been visited.

On top of HistoryFilterModel is another QAbstractProxyModel (CompleterModel) that adds a new row for every entry stripping the front of the url so the completer can complete on “http://trolltech.com” or “trolltech.com”. This model is used by the QCompleter in the url line edit.

For the history menu and the history dialog the browser wants to display a tree based structure where each top level node is a Date with history entries for that date as the children. So on top of HistoryFilterModel I wrote a new QAbstractProxyModel (HistoryTreeModel) that converted the table into a tree. Converting the table into a tree was a little tricky, but the modeltest was very useful for detecting problems.

Before putting the HistoryTreeModel into the dialog I wrapped it one last time with a QSortFilterProxyModel so that the user can do on the fly searching. The searching (really filtering) is very fast. This is put into the HistoryDialog that has a EditTreeView which is a normal QTreeView, but with added support for the delete key to remove one row from the model.

On top of the HistoryTreeModel there is another QAbstractProxyModel (HistoryMenuModel) that slightly modifies the tree moving the most recent history entries inside of the root rather the first date folder. To do the mapping I translate each node in the tree all the way up to the table and back again to convert to the source index. This class was just a big pain to code and took a solid day to do. Looking back adding a hack to the menu rather then writing this class seems like a reasonable option given the effort.

Both history and bookmarks show up in the top level menu so I wrote a subclass of QMenu (ModelMenu) which can take a QAbstractItemModel and on the fly the ModelMenu will populate it with actions from the model. This is pretty straight forward and works very well.

Overall the History classes show off how you can use item view to to write some pretty cool stuff that scales too. History’s classes contains a wrapper, some classes that filter out items, some classes that add new entires, modify or even move items around and lastly some views the present the data in very different ways.

Using my inkscape skills (or lack of) here is a diagram of the classes to help make better sense of the relationships.

We use a lot of tools and applications when we develop Qt and Qtopia. Strangely enough, it turns out a lot of these tools are open source We’ve always been wanting to give something back to the talented developers of these tools, be it money or just praise. These tools make our working day better, more efficient and sometimes even FUN!

So, the engineers here are at Trolltech decided it’s time to have an annual award where we vote and select the best open source development tool available out there. In other words: The Trolltech Open source Development Award.

So here are the finalists for the 2008 awards. They’ve all been nominated by at least one Troll, so there is at least one person out there that loves your tool

The price will include money AND a signed T-shirt. But regardless who wins we’d like to thank the developers of the tools below: You make our day a little bit better. THANK YOU!

	Coding requires music. Music requires a player. This is the one.
	It’s everywhere. So are we. It’s a match made in well, maybe not heaven but pretty close?
	All the other revision control systems are easier to use - but this one is more powerful.
	When we don’t code we chat. But don’t tell management. (They use Mirc)
	Good looks and doesn’t nag you for every single thing.
	Editing for oldtimers. Some people just can’t move on
	Feature packed editing for Windows developers.
	Higher quality for the same bit rate. And you don’t have to pay royalties.
	Not everybody uses MySQL
	A must have if you work on several systems at the same time. Take your KVM switch outside, and put it out of it’s misery. We mean it.
	You can spend two days debugging, or you can just run Valgrind.
	Emacs sucks!
	Possibly the most beautiful way of comparing diffs on Windows.
	Why drive a Golf when you can drive a Ferrari ;D

The Trolls have already started voting, and there are two very strong candidates who are competing for the first place. Now all votes are not in yet, so keep your fingers crossed Btw. I’ve masked using patented superfancy GIMP filters, so don’t bother guessing which two it is

Once the voting is complete we’ll publish the winner here of course

The Qt 4.4 beta was released on February 26th, and, true to form, the corresponding Qt Jambi release comes a couple of weeks later.

In honor of the 4.4 release, we’d like to go through some of the new features you should look out for.

WebKit integration
WebKit is an open source web browser engine which is the basis of, among other things, the Safari web browser on Mac OS X. The engine has been integrated in Qt, and is available to Qt Jambi programmers in the package com.trolltech.qt.webkit. This means that you can easily integrate web content in your applications, and jump on the whole acronym-bandwagon by using AJAX methodology in your code. Håvard did a whole blog teasing this feature a while back, so instead of rewriting all that, we’ll just point you in the right direction. Benjamin wrote a blog a few days ago that goes into more detail, so take a look at that as well if you’re interested. On the WebKit Integration announcement page you’ll find lots more information, and some very cool videos that illustrate some of its awesome powers.

Multimedia framework
Qt and Qt Jambi 4.4 gets full-blown multimedia support through the Phonon framework adopted from KDE. This gives easy access to playing and manipulating movies and music in all the nice file formats for which the underlying media framework has codecs. The framework defaults to using Gstreamer (Linux), Microsoft DirectShow (Windows) and Quicktime (Mac OS X). There’s also this teaser blog about Qt Jambi and Phonon with an example for those interested.

New deployment system (Qt Jambi specific)
While we’ve always been recommending a .jar based deployment method, we’ve required people to build their own .jar files containing the necessary native libraries, and a meta-info approach to specifying which dependencies exists in a given project. This system has proven not only to be easy to misunderstand, but to have some fundemental flaws that could cause crashes and general discomfort if you did it wrong. In fact, in order to deploy previous versions on Mac, it was required that you were either Eskil, Gunnar, or someone with direct e-mail contact with either of us. In Qt Jambi 4.4 we’ve hopefully fixed this once and for all, by defining a default .jar based deployment system which avoids problems with mixing libraries and in which deploying to a different platform is as easy as replacing a single platform specific .jar file. In fact, if size is irrelevant, it’s possible to ship a single distribution of your application which will run on all platforms, as long as the platform .jar file for the given platform is in the class path when running the application.

If you are building from source and require extra libraries to be included, this can be achieved simply by editing the ant script.

JDBC support (Qt Jambi specific)
A drawback in our SQL framework in previous versions of Qt Jambi has been that you needed to have access to a Qt/C++ source distribution in order to use it. The reason was that we could not provide binaries that were compatible with all the different database drivers out there. In Qt Jambi 4.4 we support the Java DataBase Connectivity API which is the industry standard for database access in Java. This has been available on Trolltech Labs for a while, but now it has finally been integrated in Qt Jambi and is available in the com.trolltech.qt.sql package. Gunnar wrote a blog about it back when it was put up on labs.

XML patterns
XML support has been greatly improved in Qt and Qt Jambi 4.4. An example for this is the added support for XQuery 1.0 and XPath 2.0. In Qt Jambi, it is available in the package com.trolltech.qt.xmlpatterns. For more information, see Frans’s blogs about the C++ version of the API.

Qt Concurrent
One of the greater challenges in terms of mapping C++ to Java was the Qt Concurrent framework. This is a set of classes and functions that will help you parallelize tasks (e.g. to optimize for multicore cpus) without having to worry about many of issues the ordinarily related to multithreaded programming. In C++ it uses a lot of very language specific constructs, like templates and function pointers, making it hard to automatically map the API to Java. Indeed, we had to write part of the bindings layer by hand, replacing the use of function pointers with interfaces instead. We also implemented support in the Qt Jambi Generator for mapping C++ template classes to Java’s generic classes (under certain conditions) in order to get the correct API for classes such as QFuture. The underlying, generated code for binding this class uses a general, reference counting wrapper for java.lang.Object where the Java API (and the original C++ API) uses a generic parameter. Since generics in Java is a static, syntactic mechanism, there is no need to worry about it in the JNI code.

Other stuff
There are many more changes in Qt Jambi 4.4, bug fixes and new features. In order to get an overview of them all, you should see both the change logs for Qt Jambi 4.4 and Qt 4.4 (which will be out when the release is final.) From the top of our heads, we can mention an enhanced network API, QMetaObject introspection for Java objects, and numerous improvements to Designer.

–
Gunnar and Eskil

Announcing a new project on Trolltech Labs: Qt Script Generator. It’s a tool that generates Qt bindings for Qt Script. Finally your scripts can go “new QPoint()” without you having to manually bind the world first! You not only get the Qt API, but also the possibility to “subclass” in script code, e.g.:

var w = new QWidget();
w.keyPressEvent = function(e) { print(e.key()); }
w.paintEvent = function(e) { ... }

To use the bindings in your own app, you just compile the bindings plugins, put them in your library path and then go like this:

QScriptEngine eng;
eng.importExtension("qt.core");
eng.importExtension("qt.gui");
// also available: qt.sql, qt.xml, qt.svg, qt.network, qt.opengl

Have a look at the examples to get an idea of what you can do. More examples to come.

The generator itself is essentially the Qt Jambi generator with a Qt Script backend. (Great job, Jambi guys!)

Although this project is still very young, we’re interested in hearing about any issues (functionality / performance / whatever) you have with the bindings. Have fun!

In these ‘ownership-changing’ times, I just had to share a photo I took on my way to work. The glass building to the left in the picture is the BI building, where Trolltech HQ is located.

In 4.4 Qt is getting a new module, qtwebkit. I have been watching it develop over the past year and have been eager to play around with it in Qt. Shortly after the module was merged into the main Qt branch I began working on a small browser in my spare time. Something I could use for at least some of my daily browsing. By eating my own dogfood I could catch errors in WebKit, the new networking code, and especially spot trouble areas in the API before the release.

*Disclaimer: This is just a little demo project of mine, not a FireFox replacement.*

Startup speed
One nice feature of Qt4 over Qt3 is the startup speed. I have seen reviews of KDE4 that even mention the nice bump that KDE applications received, even application have have just been porting and no extra refactoring was done. When Zack was first working on the webkit Qt integration I noticed that his test application would launch near instantaneous when Qt was in memory already. So if WebKit can launch fast, and Qt can launch fast I was definitely going to make sure that some silly demo code didn’t make it launch slow. So even with an icon database, history, cookies, tabs, etc the demo can still launches quickly. So I think it is fast enough.

Networking
In 4.4 there are some new networking class built up around the new QNetworkAccessManager class. Check out Thiago’s recent blog entry One more piece falling into place: Network Access for some more information about all the new goodies included with it. On top of networking classes I created some gui components including a minimal download manager with the usual suspects such as a progress bar, download speed, etc. A nice little demo for the download manager in its own right. Something new that QNetworkAccessManager uses that not mentioned before is the QCookieJar that is included with Qt4. Wrapping it I added saving/loading, and the usual web browser features.

User Agent
Once the browser was in good enough shape to be use every day I setup Gnome and KDE to choose the demo browser as my preferred browser. So anytime I clicked on links from e-mail or from #qt on irc the demo browser would be used and in the server logs a new user agent would show up for the mysterious demobrowser/0.1. The default qtwebkit user-agent is constructed from QCoreApplication::applicationName and the new QCoreApplication::applicationVersion properties. So if you integrate QtWebKit in your application it will automatically include the application name and version in the user-agent. This is of course configurable. Because it is just a demo and for simplicity sake the demo behaves like a single application, when launched it will contact the already running browser and tell it to open the url from the command line arguments if there is one (configurable to open in new window or tab of course).

Session Managment
Developing the demo I knew that I typically leave my browser open for days at a time and loosing your open tabs (or anything really) in a crash is never good. Also while developing the demo I would want to quickly restart it as changes were made. With that in mind the demo contains is a little watch dog class that makes sure that at most you will only loose the up to the last three seconds in the event of a crash. Not just tabs, but history, cookies, and everything else is protected. Restarting the browser selecting History/Restore Last session will quickly re-open all the top level windows and their tabs from last time.

x-qt-plugin
QtWebKit include a plugin framework and QWebPage has extra built in support for one specific plugin type, x-qt-plugin which the demobrowser implements (see QWebPage::createPlugin) The demo browser lets you add any Qt widget into the webpage. Just like with QScript, signals, slots, properties are all fully accessible from JavaScript. You could even embed QWebView and make a browser in the browser if you wanted to. With the demo browser if you load up a webpage with the following code you will find a loading QProgressbar.
<object type="application/x-qt-plugin" classid="QProgressBar" name="progressbar" height=30></object>
<script>
function display(){
if (++document.progressbar.value != 100)
setTimeout("display()", 50)
}
display();
</script>

More than for a browser
Already there have been Qt developers blogging about their interesting QtWebKit projects such as Amarok and KDE Plasmoids. I am looking forward to see what everyone does with QtWebKit.

FAQ:
The demo can be found in the demos/browser directory of the Qt package. The browser in the 4.4 snapshots has more then the beta including proxy configuration, in page search, improved keyboard shortcuts and some of the features mentioned here.

• This is only a demo, I tried to not do anything that couldn’t be done with Qt easily, so adding bunzip, tar, and bittorrent support to the download manager wasn’t on my todo. There are plenty of neat things to do first such as bookmarks.
• Although plugin support was added to QtWebKit for 4.4, the official Adobe flash plugin support will have to wait for 4.5. Or more to the point the netscape plugin support wont be added until 4.5
• gmail currently does not work.
• There are no known crashes so please report any that you find.
• I plan on continuing to develop this demo, for example I have bookmarks mostly done in a branch and am am working on adding more autotests before merging.
• Many cookie issues can be worked around by turning on “Accept All Cookies” in the preference, the cookiejar has a few fixes that are not in yet.
• Feel free to check out the code for the demo. The total size is quiet small and I tried to keep the code clean.

A blog about a browser is only complete with a screenshot so here it is running on Windows (Vista), Linux (Gnome), and OS X (Tiger)

Having a cross platform browser who’s code base is small and completely open kicks ass.

A big thanks to Jen, Jens, Holger, Morten, Thiago, Simon, Jesper, Thomas, Paul, and everyone else who gave feedback/patches.

The Qt Jambi team has, as have all devs in Trolltech, been busy preparing two separate releases the past few weeks slash months (Qt Jambi 4.3.4_01 and Qt Jambi 4.4.0_01.)

In the midst of this, someone reminded me that I promised I’d post a blog when we added prebuilt Windows binaries to the repository for QtJambiAwtBridge. This has now been done (Gunnar actually added it a while ago), so it should be possible to use the bridge without having a Qt source package ready. It’s in QtJambiAwtBridge lab in the directory “prebuilt”. For maximum compatibility, please use the binary together with a Qt Jambi binary package.

As far as the code goes, not much has happened to the QtJambiAwtBridge, and there probably won’t be much time to work on it until the two upcoming releases are ready and out the door. At that point, I will sit down and see what I can do about the outstanding issues (mainly regarding focus handling and window activation as far as I know, please post a report if you find other problems.)

Since I’m already posting this, I might as well add that Qt Jambi JDBC has been target of a few bug fixes lately: The standard Java SQL types are now automatically displayable and editable in views of the database models, a bug has been fixed where the contents of cells in a view looking at a JDBC-based model would sometimes rearrange or blank out, and finally: We’ve added a few changes that greatly increase the number of JDBC drivers with which we are compatible. We previously required that the underlying driver supported returning autogenerated keys, which is optional in the JDBC specs, and there was also a bug with certain unforgiving drivers when trying to do random access on the result sets. One of the drivers for which these bug fixes adds compatibility is the pgsql one.

As far as Qt Jambi JDBC goes, the driver will be integrated into Qt Jambi 4.4 and become permanent part of the Qt Jambi library.

The former Release Manager here at Trolltech told me that the former former Release Manager had a saying:

The release is not out until you blog about it

So I’m doing a 3-in-1 blog!

Qt 4.3

A week and a half ago, we released Qt 4.3.4, containing some bug fixes to issues reported to us since 4.3.3 was released. It seems old news now (even though it’s only my last blog entry), but Qt 4.3.4 is also the first Qt 4 release under the GPL version 3. The snapshots were already under that license, but now system integrators and Linux distributions can upgrade their packages to an officially released version.

Qt 4.4

Then, one week ago, we released the long-awaited first beta for Qt 4.4, containing a lot of new features, like WebKit, Phonon & backends, network access, Qt Concurrent, Widgets on the Canvas, improved printing support, Patternist, Aliens, a new help system and a lot more that Trolltech developers have been blogging about. This release is so big that we could have split it in two or three and we’d still have enough to go around — note how there are 17 links to blogs about different features in the previous sentence alone! (We’re still writing the change log file for the release) It’s also very daring: who could have imagined a full web engine built in the toolkit a year ago? And just like Qt 4.3.4, the 4.4.0 beta 1 Open Source edition is licensed under the GPL versions 2 and 3.

The beta 1 also marks the first new platform for Qt in many years: Qt/Embedded for Windows CE. It’s now the fifth platform that Qt supports, after X11, Windows, Mac and Embedded Linux (QWS). It’s the result of a year and a half of work done mostly by the Trolltech Berlin office, trying to adapt our existing Windows code to a deceptively similar platform. If you have tried to develop for WinCE, you’ll have noticed that the APIs that are available in the Microsoft products are full of subtle differences and not-so-subtle omissions. Well, Qt brings you a unified, cross-platform API, across the board.

Qt 4.5… (not quite)

Talking about new platforms and deceptively similar platforms brings me to the Mac. Apple has not been afraid of changing their platform under you. The 10.5 (Leopard) release of MacOS X is full of those changes, including some that may break existing Qt applications. Qt 4.3.3 introduced initial support for Leopard and that was improved with 4.3.4, with a fix for OpenGL because Apple changed the typedef of a type.

And today we announced the first alpha of the Qt/Mac Cocoa port (hmm… can I call it the sixth platform?). It comes to emphasise our commitment to the desktop PCs, to our customers and providing them with an upgrade path to newer systems. (For those of you not following the Mac news, Apple decided to halt development of the 64-bit version of the base libraries that Qt depends on, called Carbon; so we had to rewrite a good portion of our code using the Cocoa libraries) As any other alpha, this release is expected to be full of bugs and missing functionality. Trenton has posted a list of what’s known to work and what isn’t in his blog. As soon as possible, we’ll make snapshots of the Mac Cocoa tree public so users can follow what’s going on. More news on snapshots at a later date.

Conclusion

So, that’s it: in the space of a week and a half, we have released three Qt versions, in three different minor series: 4.3, 4.4 and 4.5. And that’s not it: we’re scheduling a 4.3.5 and possibly a 4.3.6 release some time in the future, for those clients who cannot or will not upgrade to 4.4.0 when it’s out. And since no more betas for 4.4 are planned, the next release will be the first Release Candidate sometime in the next 3-5 weeks. (In fact, I wrote a rough initial timeline for a year and a half worth of releases. And no, I cannot share that document, since it’s pure speculation at this point)

I’d like to thank everyone involved in making those releases possible: the development team (the Windows CE and Mac Cocoa teams in particular), the support engineers, the Product Management team and all of our users and clients. Yeah, without the input and feedback from you, we wouldn’t have come up with the releases.

I couldn’t finish this blog without mentioning Nokia: while the planning of the integration is proceeding in several fronts, we continue to work. And quite hard. I hope three releases in a week in a half shows how committed we are to what we do. And we will continue to do what we do best: provide you with the best toolkit you can find. For all platforms: “Code once, deploy everywhere” (I think I have to pitch this slogan to Marketing…)