Category Archives: Qt


I just arrived at Porto Alegre for FISL. The atmosphere here is great, I just realized how much I missed this feeling. In a couple of hours I will give a talk about social games and the FLOSS-based infrastructure that is used to develop and deploy them. So it is not a KDE talk: I am going to cover mostly html5 and web technologies, ranging from REST API design to specific deployment scenarios using MongoDB, Memcache, Nginx…
There will be a couple of talks given by KDE people here at the event, and tomorrow (12:00) is the KDE-BR community event/meeting.
As a resolution for the next 12 months, I plan to slowly resume my history of contribution to FLOSS projects and maybe even KDE. This can be difficult, as I am mostly interested now in html5, js and collaborative platforms (games and education) that are browser-based. But let us see how it goes. One step at a time. KDE and Slackware however remain my DE/Distro of choice, of course πŸ™‚
Finally, good luck to all of you that are going to Akademy, have a nice event!

HTML5 apps on all platforms: can Qt help?

A couple of questions for my dear Qt friends: after a long winter, mostly devoted to building and deploying HTML5 games and educational apps, I find myself evaluating Qt again for a big project… It is an app to be used on schools: it must work online and partly offline as well. And it has to run on desktops (Linux/Win) and mobile (Android/iOS).

HTML5 apps have evolved a lot. We built very interesting collaborative things using it, and the team is already familiar with backbone.js and other goodies. But the requirement that part of the funcionality must be available offline is puzzling me for this particular project. HTML5 offline support will not cut it, as data to enable the features we need is not something that fits in the typical localstorage cache solution. So I was thinking about using something like Apache Cordova (previously phonegap) and its sqlite plugin. The thing is that I would very much wanted a single code base…

The research lead to interesting new projects, like node-webkit and chromium embedding framework. All have pros and cons, and none runs on all platforms we need to support.

And then yesterday I found that ICS was working on cordova-qt. So maybe it is possible to build such an app (HTML5 based with local fs support) and really deploy it worldwide from a single codebase? Apparently, not yet… the project appears to be a bit stale. Does anyone know why? Perhaps the announcement that Digia will work on native iOS and Android versions of Qt has made this a lower priority? It would be nice to use a C++ app with QtWebKit, but IIUIC this does not work for iOS and Android, so back to square one, right? Comments are welcome!

Talk about open source games at PUC-SP

Hi. Yesterday I talked a little bit about open source games and educational apps at the “Semana AcadΓͺmica PUC-SP”. This is a week-long event promoted by the computer science and digital games departments of one of the top universities in Brazil. Initially I was going to talk only to the students of the digital games course, but at the end the talk was transferred to the main auditorium, where the computer science students could also attend.
It was a very interesting talk: my initial goal was to present the idea that doing your final work for university inside an open source project (and in particular, KDE) was a very good thing. The labs at PUC-SP are already equipped with dual-boot machines, Windows and OpenSUSE. Last year, when I was helping one of the courses as part of my masters program, I could show students how satisfying it was to boot one of the machines into OpenSUSE, fire up KMahjongg, and check your name as one of the AUTHORS πŸ™‚
The end result was very good, there was genuine interest on the part of some students, and we had a very good conversation afterwards as well. Hopefully we will see some of them soon in the kde-br list!

Elop is after me

Back in 2005, my small company had an active customer base of more than 15,000 developers using our plugins. These were extensions (Xtras) for Macromedia Director, at the time the number one tool for authoring of CD-ROM and online games published via Shockwave. The global Director developers community was composed of 300,000+ professionals, not counting the illegal copies. Sure, Flash (also from Macromedia) was starting to become a powerhouse and was competing strongly with its older brother. But development of both software continued at a healthy pace, and the collaboration between both teams resulted in the opportunity to use Director as a container for Flash media, with a bright outlook for both. Director was still the tool of choice for 3D games, kiosks, CD-ROMS and lots of projects where the ability to extend the environment with C++ code was required, with embedded Flash elements providing the eye candy and an army of designers that were used to the platform.
Then Elop was elected CEO of Macromedia. And some months later, the company was sold to Adobe. A nice and stable transition was assured at the time. Director was not to be killed, like Freehand and some others. And it fact it wasn’t. The Director product team had a good channel of communication with the community at the time, and from them we were told that several options were being considered for the future, we just had to wait a bit for the dust to settle.
Looking back, it would have been better if the product was sold to another company, or it Adobe management had clearly stated from the start that no significant updates were planned. Instead, Director remained alive at Adobe as a cash cow, with a reduced team that was strangled slowly, always waiting for better news “in the near future”. It was planned obsolescence, and it continues until today: there were sporadic releases (to reap the upgrade fees) and this helped keep some content created in Director still alive. Nowadays the developer community consists mostly of old timers who are maintaining their legacy projects, and struggling against an aging code base that is minimally supported. There were more than 40 companies producing Xtras for Director circa 2002, and from these only 1 or 2 (including ours) is still active. This is mostly out of respect to the existing customers and the investment they have made on the “ecosystem”, as keeping this business alive (support and minimal maintenance costs) is something that has not generated a profit for me in the last two years.

So I was not happy to see Elop (after graduating from Adobe and Microsoft, which surely increased his business “skills”) took over the role of Nokia CEO. Oh, oh… spider sense ticked off. Luckily, the other shoe dropped almost as quickly, also in a matter of months, as we all know by now.

There is, however, a significant distinction between both scenarios. Director was never free software. There was no option: some from the community even tried the only possible route, which was to acquire the product, but Adobe did not want to let it go, probably out of fear that it will compete strongly again with Flash. So the “strangling” of the community succeeded. Qt, on the other hand, is free software. And KDE has also secured the FreeQt agreement. So, thanks to the L(GPL) and the efforts of the community, there is a way out.

I read several blogs asking for restrain and calling a fork “premature”. I respect those opinions, but having lived through a previous elopcalypse, I beg to differ. A small part of me hopes I am wrong, but I believe a fork is not only necessary, but inevitable. And I think KDE is the place where this fork should live, with kdelibs and qt forming an unified platform where truly free (in license, cost and development direction) software can be built. Everyone knows the problems KDE developers and the community have with their patches being integrated in Qt.: with a Qt tree living inside KDE we would be free to apply true open source principles to the development, and let it thrive in the way our software has. I understand Qt Software inside Nokia is implementing open governance and all, and I trust the people in charge of this initiative. But again, their power is limited. I respectfully must say that any initiative led by Nokia or their employees will never be truly open in the sense KDE is. And the axe might fall again in a couple of months, and then again. And the good people will be gone. Qt developers would have migrated to another environments. And the opportunity will be lost.

Some will say: but then we will loose the Nokia-sponsored development. This is true. But these are already gone, or will be gone soon, IMHO.

Well, we can check this in 2 years, and I will certainly buy a round of beer to everyone at the 2013 Desktop Summit if I am wrong. In fact, I will be happy to do so, and I would be happy to be wrong as it would mean less work for KDE. But I got tired of the “calm down” posts. Putting it in blunt words, we can no longer trust Nokia or depend on it for the core framework KDE needs. Even if most Nokians are very good guys, brilliant engineers and a joy to work with, the new management has shown its true face. Two months ago they were drafting developers in Dublin for Meego, and some people dedicated their time and resources to support the Qt-everywhere promise. This commitment has been broken, and it will not be the first one. Reading the join press release (Elop and Ballmer, come on) feels like an April’s Fool joke, honestly. Just stare at the photo for a while. We can not expect any FLOSS love from these guys, sorry. Like KDE, Meego is hurt, but it can also recover if Qt moves to a truly open upstream repository. Qt, imho, can no longer be controlled by Nokia: development has to happen in the open and be governed like a true community project, like KDE. I can imagine that such a move would make other Meego players happier as well.

Update on QtGStreamer

Due to personal issues I have not been able to be online much or work for the past two months. Things are starting to settle now, and while I am still not able to return to a full time work schedule just yet I would like to keep the blog minimally updated πŸ™‚

QtGStreamer had its first stable release! Congratulations to George for taking the flag to the finish line: he is an amazing coder and we are very lucky to have it in the KDE community. It is specially nice for me to read articles like this one from Jonathan, which validates much of the reasoning for QtGStreamer’s design choices (elegant API and no hard dependency on GStreamer libs, to name two core ones.)

KDE at Campus Party BR

Yesterday I gave a talk at Campus Party BR. Lots of people there (over 6800 registered campers according to the site). But it is a very different environment compared with the free software conferences I am used to attend. There were 8 areas, including robotics, games, science, security and others. I talked at the Free Software area stage, about “KDE: the software and the community”. It was well received, and compared with the first talk I gave at Campus Party (in 2008) I could see that the awareness for free software and KDE inside events like this grew a lot. Still, it was strange to be among almost 30 very young guys and girls all dressed as Microsoft Student Partners, whatever that is πŸ™‚

Still, the free software area was well organized, and I could reconnect with some friends like Cristiano and Gustavo. The talks there represented a good selection of the main free software projects and the organizers have scheduled a nice mix of talks and workshops, so people that are interested in free software can surely have a productive week while camped.

Highlights of the day for me were the talk by Al Gore and Tim-Berners Lee (two “creators” of the internet in the same stage, hehe.) and the blackout near 6 PM, which lasted for almost two hours. It was very interesting to be there while the lights went out in a huge area of the city but the Campus Party place remained illuminated by thousands of LCD screens. Of course the net link went down, so after about 5 minutes people started to organize demonstrations and marches. Thirty minutes later forced socialization began, finally πŸ™‚ Thankfully the lights returned one hour before my scheduled slot, with plenty of time to get everything back on. The talk about the UCA project (one computer per student) that followed mine was also very interesting, specially because some schools are running ClassMates with KDE software.

PS: Huge thanks to Sandro Andrade and the LiveBlue website, as I could reuse almost 80% of a presentation Sandro prepared for ENSL. If it were not for this help I doubt I would be able to give this talk, as personal life issues are making it difficult for me to find time for coding and FLOSS. Thanks man!

Last week in QtGStreamer – week 9

Well, this week’s report is brief, and more technical. But first I would like to congratulate the GStreamer community for making 0.10.31 available. This is the version we are tracking for our initial stable release of QtGStreamer as well.

After the move to last week we were kept busy with code. George merged his initial GGlib::Value reimplementation, with the goal of making it at the same time more powerful and easier to maintain and use. I spent some days working on the Structure API to hopefully make it simpler: the StructureBase class was removed and SharedStructure was made private. StructurePtr was implemented, so now users only have Structure and StructurePtr, which is consistent with the rest of the API. This opens the door for additional improvements as well. The commit history with a log of the activity from the past 7 days is available here. You will see there that other items from the TODO list in the QtGStreamer wiki were also addressed.

Speaking of TODO lists… why every time we start to maintain one, it seems to grow faster then our ability to tame it?

Last week in QtGStreamer – week 8

This was a very productive week for the project, with a lot of of activity moving us closer to a first stable release. I worked mostly on refactoring the mechanism that tracks reference counts for miniobjects and caps, while George has been busy with a redesign of the QGlib::Value system that makes it really convenient to use it from Qt, much like QVariant.

Also, we are happy to announce that QtGStreamer is now a project, with the repository living at

Bug reporting is already integrated as a GStreamer component in Bugzilla.

These moves makes me very happy. QtGStreamer was started last year by George Kiagiadakis as a personal project and were previously hosted at Gitorious. With this move we are now effectively the “official” Qt bindings for GStreamer, living in the same repository tree and using the same bug reporting system. This makes it easier for us to tap into the knowledge of the existing GStreamer developer community (including people that are using other bindings, like PyGst). And the visibility of the project is increased, which is good in general as we really want to have more people hacking on and using it.

Last week in QtGStreamer – week 7

This week George merged some of the patches I have been working on to the QtGStreamer master repository, including support for Events. (*) He also wrote and committed a bunch of bugfixes and some improvements to the build files.

I started to work on some refactoring for our refCounted object, with an eye on addressing two issues that are common to other GStreamer bindings as well. So far things are promising, but this effort will take a little more time before it is ready to be merged.

And finally, the Kamoso team announced that they have completed the intial port to QtGStreamer. It is still a work in progress, but it is good to be able to collaborate on real world applications instead of just hacking on an “ideal” library API. We have already some adjustments in our long and public TODO list thanks to the input from Alex, and I wish the Kamoso team good luck with the project.

(*) As a comment to that, I still need to adjust my workflow to git: I use to prototype things and commit frequently in the local directory to avoid losing work, but this produces a not-so-good history as things are added and deleted… and do not end up in the final patch, just in the commit history. To avoid this I was rebasing and squashing, but the side effect of this for big changes (like the TagList support I was working on) is that it tends to be a very long and not-so-manageable merge request, which takes more time to process. I promised George I will send smaller, atomic patches from now on :). But generally I think that I am now finally getting into the git mode of thinking: it requires a mental adjustment for people like me that were used to CVS and SVN and were afraid of branching… Once you adjust there is no going back, I am glad KDE is migrating to it.

Last week in QtGStreamer – a recap (and an overview of GStreamer)

This is inspired by the ‘Last week in Krita’ and ‘Last week in KOffice’ series. Boud, the author of these series, mentioned that this is a nice way to “keep everyone who is interested, developers, contributors, users β€” everyone β€” up to date on what is happening in the […] community.” I do not promise I will be able to keep up with weekly updates AND still work on development :), but I will do my best to summarize what is happening on a frequent basis.

I guess starting the series with a recap is good. I have worked in this project for a little more than 5 weeks now, so this is going to be the “Week 1-6” edition. Two weeks ago I posted an introduction to the project, and the reaction so far has been mostly positive. I know of at least one KDE project that is trying QtGStreamer already, and this is good because it lets us tweak the API to real-world applications easily, as no official release has been done and there is still flexibility to do so. And because it is important for us to get more people on board we are usually hanging out in the #gstreamer IRC channel on Freenode: please join us there if you have a question, want to help us with development or just need a hand trying QtGStreamer in your application.

Since that last update we have added some of the basic blocks from the GStreamer API that were still missing, including support for Events, Buffers and TagLists. Some of these are already in the master repository and some are still in review, but we are generally in good shape and ready for prototyping. The plan is to work on the next two weeks on stabilizing what is already added and refactoring some of the code that deals with the bridge between Glib/GObject and Qt. George and I have some interesting ideas on how to deal with some of the challenges that face every GStreamer-binding project, as there are a lot of special cases and design choices in the framework that require authors of bindings to be creative and decide where to draw the line: we can give users full access to the engine at expense of making the API complex, or we can hand-hold the developer and maybe limit the inherent flexibility of the engine. It is a tenuous line, but by now we *think* we have a pretty good overview of the main use cases, and are in a good position to try some things.

I realized after reading the paragraph above that it might not make more sense to people not familiarized with how GStreamer is designed, so I will write a “5 minute overview” of the technology. If you have more time I recommend reading the first chapter of the online docs instead. But, in short, the GStreamer framework is pipeline based. The pipeline is composed of different elements, which are GStreamer’s building blocks. See the image below for the pipeline that can be assembled for a simple ogg player:

Simple Player
A simple GStreamer pipeline

In this example each block is a GStreamer element. An element in its simplest form is a box that generates, processes or outputs data: it can have one or more “pads”, which are the ports that make the connections so data can flow from one element to the other. Pads can be source pads (produce data) or sink pads (consume data). There are over 1000 elements in a typical GStreamer installation, dealing with everything from getting data from cameras (a v4l2 element with a single source pad) to decoding VP8 streams (a vp8 decoder element) to displaying data on the screen (several specialized elements that only have one sink pad, including for example the xvvideosink one).

The pipeline concept is what makes GStreamer so flexible. It is not that different from Unix pipelines in design: the idea is that you build complex solutions starting from simple and discrete elements. As this is supposed to be a 5-minute introduction I will not get into much more detail, but it is important to mention that in GStreamer communication events between elements can flow upstream and downstream, and there are facilities that let the elements communicate back to the application and vice-versa using messages and queries, as well for assembling pipelines dynamically.

So in QtGStreamer we give you all the power to link these GStreamer elements as you wish. A real world example might help: let us say you want to display the image of your webcam in a Qt application window. In Linux you can do this by linking the v4l2src to a qwidgetsink, which as the name implies is a QtGStreamer element that can display images and inherits from QWidget.. Actual code for this is something like:

//Creates the pipeline
m_pipeline = QGst::Pipeline::create();
//Construct the source Video for Linux element
QGst::ElementPtr src = QGst::ElementFactory::make(“v4l2src”);
//Construct the QWidget sink element
m_sink = QGst::ElementFactory::make(“qwidgetvideosink”);
//Add both to the pipeline
//Link the source to the sink
//Tell the sink to use one widget defined in our UI file
//Start the pipeline

That’s it: video should now be flowing from your v4l2 drivers directly to your screen. The example above can be expanded: it is typical to include an element called “ffmpegcolorspace” in between the v4l2src and the qwidgetvideosink, to handle color space conversion if necessary. You could also add an element that duplicates the data before it reaches the qwidget, followed by a VP8 encoder element, a Matroska muxer and an element that writes data to a file, and your application would already compress and record WebM video. But this is a quick tutorial, so we will not expand on that right now. The idea is to show that you have a lot of flexibility and QtGStreamer already lets you construct any pipeline you wish using the make and link functions.

But constructing pipelines manually can be complex. This is where higher-level objects come handy: next week I plan to continue this series with an update on the progress of the project and at the same time will write about how GStreamer’s pre-made bins (which are complex elements that internally have their own collection of elements) can be used to easily play/decode/capture almost any kind of media on several platform, as they auto-discover the elements that need to be used and connect them automatically for you.

Disclaimer: the above description of GStreamer’s design is extremely simplified of course, so I recommend checking the documentation if you are really interested in finding out more about its internals.