MeeGo

This is me normally: This is me on MeeGo: Thanks, Texrat!

Front Page Playing DVDs on N900 with USB hostmodeNormally videos don't make the front page, especially when the topic is covered by number of items. However, in the case of Mohammad Abu-Garbeyyeh's latest video - demonstrating USB hostmode - we've ... [More] made an exception. Joerg Reisenweber's announcement on maemo-developers is covered in the `Devices' section. Mohammad's video shows him "playing DVDs on the N900 with a modified kernel and a custom mplayer build. [...] (Note: video is playing solely on CPU power, mplayer is not accelerated by the PowerVR, which explains the framedrops)" More information on USB hostmode is later in the issue.Read more Saturday before MeeGo conference: team-based lollipop stick bridge buildingWith a week to go to the start of the first MeeGo Conference, the community have been organising events (beyond spodding and drinking) for the prior weekend, for those arriving early. Dave Neary is organising a "Maker's Contest" where, instead of building funky Qt applications, teams have to build a pretty, load-bearing bridge out of lollipop sticks: "Each team will get 100 lollipop sticks and a glue gun with one glue stick. No other materials may be used for the bridge. Teams will have 1 hour to make a bridge which should span a 40cm gap." Dave is looking for local logistical assistance (including weights and rope for testing the bridges); so start forming your teams now!Read more In this edition (Download)...Front PagePlaying DVDs on N900 with USB hostmodeSaturday before MeeGo conference: team-based lollipop stick bridge buildingApplicationsUse MaePad on Nokia N8 via mobile web interfaceDevelopmentQt on Google's "Skia" graphics engineDevicesRunning MeeGo in Maemo chroot (part 2)MeeGo 1.1 on a HTC Nexus OneUSB hostmode on N900Indamixx announces a MeeGo-based multi-touch tablet for music applicationsAnnouncementsPeregrine is VoIP/video/IM chat for Qt & MeeGoRadio RDS driver & decoder for N900 [Less]

The astute, regular readers I manage to have might have wondered why I have recently been playing with Skia, Google's 2D graphics rendering library, notably used in Chromium and Android. Well, now that my experiment is in a semi-usable state, I ... [More] decided that it's probably about time I let the cat out of the bag and started talking about what I've been doing.Over the past week, I've been diving into the Qt graphics stack a bit, for my own fun and amusement, to learn more about how it works and what makes it tick. This has been my first dive into graphics, so it's been a bit of a learning curve containing many gems like:"transform? what's a transform""clipping? I know I need a haircut, but...""oh, you mean I actually have to store ARGB values for everything, and the order differs from toolkit to toolkit, and in some cases, from big/little endian?"But I think I've made some progress in figuring things out slowly. And getting my project of choice, Qt rendering using Skia, to work, slowly but surely - a picture is worth a thousand words, so without further ado:(Qt's demos/browser/, using Skia rendering)Of course, it's still not done. There's a lot to implement (proper text rendering not using paths, clipping, supporting QBrush formats other than solid color fills...) and a lot of bugs to fix, as is visible in the screenshot above - and then the work starts in earnest to make this fast, but I'm happy with the progress so far over the past week.As for my intentions? Well, I don't know. First, we'll have to see if I can get it finished, then, see how it performs vs Qt's own internal raster engine. If it's faster, then perhaps there's reasons to talk to the Qt graphics folks about whether it's worthwhile to include in Qt or not.Even if this code doesn't make its way into Qt, I'm confident that there will be some valuable lessons and contributions from it. I do plan to write up another post on how to introduce a new graphics system into Qt, and I also have some notes to improve documentation for things like QPaintEngineEx.If you're interested in tracking my progress, keep an eye on my skia-master branch on Gitorious. Note that if you want to try it yourself, for now you'll need the Qt branch of my Skia clone on github (note that this will only work on x86 with SSE2 support for now), because Skia's upstream SVN repository doesn't have an up to date/working buildsystem, and also contains a few problems that block compilation. I'm aware that this isn't really end-user-friendly, or a very sensible approach, but it will do for the short term. Just build it and copy libskia.a into /src/plugins/graphicssystems/skia/.I'd like to thank a few people for their assistance:Andreas Kling, for nudging me to indulge my insane self and actually try thisJohn Brooks, for giving me a crash course on how images are actually stored in memorySamuel Rødal, for walking me through the internals of Qt's graphics gutsZack Rusin, for his discussion/help with implementing complex non-joined sub-paths in QSkiaPaintEngine::fill()I'll leave you with some screenshots showing the earlier work at getting things rendered, just for fun. the first thing Qt on Skia drew, a test circle and a border. getting somewhere more useful, we rendered some blocks! Qt on Skia manages to draw shapes in mostly the right place! Qt on Skia draws pixmaps for the first time [Less]

Front Page PR1.3 for N900 finally releasedThe latest update to Maemo 5 has been rolling out to N900s around the world. Largely expected to be the final big update from Nokia for the N900, it "adds Ovi Suite support to your N900 and makes it even ... [More] easier to access and sync files and messages between your device and your desktop. In addition, we’ve added hundreds of tweaks and fixes that will make your N900 run faster and smoother than ever." It also ships with Qt 4.7 (including Qt Mobility), which will be important for developers wanting to deliver applications across MeeGo, Maemo and Symbian. Criticism has been forthcoming for seemingly valid patches from the community being ignored (see bug #7190) and the latest versions of key software like hildon-desktop languishing on gitorious, rather than being shipped in this (almost certainly) final update.However, the community (mainly in the form of Mohammad Abu-Garbeyyeh) has already stepped up with a "community update" repository which brings in further updates on top of PR1.3. Mohammad is in final testing (having liaised with Niels Breet to get it set up on maemo.org) and should be announcing something this week.Read more MeeGo 1.1 releasedQuality, time, features. Agile methodologies tell you to pick two because one has to vary in the Real World. MeeGo have chosen the first two and so, their first six monthly release has come out for netbooks, handsets and in-vehicle devices (IVI). Rafe Blandford of All About MeeGo opens his in-depth article; with screenshots from each "UX": "The MeeGo project reached an important milestone today with the release of MeeGo 1.1. It aims to create a solid baseline for both manufacturers and developers to devices and software across a broad range of categories (netbook, handset, and IVI) across both the ARMv7 and Intel Atom chipset architectures. The current MeeGo releases remain mainly of interest to device manufacturers, developers and those wishing to take an early look at MeeGo before it arrives on commercial devices."Read more In this edition (Download)...Front PagePR1.3 for N900 finally releasedMeeGo 1.1 releasedDevelopmentAutobuilder updated to PR1.3 SDKNokia tidies up developer story: Qt Quick & ComponentsReady to kick tires of MeeGo app development? QtComponents for MeeGo on Ubuntu...and 3 moreCommunitybugs.maemo.org/id working as URL shortcutHelp ensure the MeeGo community (and project) is on the right trackDevicesDemo of MeeGo/Maemo dual-bootMaemo in the WildSprint (US mobile network) supporting MeeGoNokia's end-user focused blog on MeeGo 1.1Qt Quick proof-of-concept on iOS 4AnnouncementsMaePadWeb for editing MaePad entries from PCs [Less]

After recently writing about the broken contribution process in Qt, I got a little bit inspired to see what the current 'lay of the land' of the Qt contribution ecosystem looks like. So, I did what any self-respecting hacker would do, and wrote a ... [More] quick script over the course of a few hours to generate the statistics I wanted. Beware, gitstats takes a long while to run over repositories with a big history. If you want to skip the work of running it over Qt yourself, grab a copy of the CSVs I generated.Before I go any further, I'd like to emphasise the following from gitstats' README:The information gitstats generates is in two primary facets: which individualsare doing the work, and which organisations do those individuals come from.The raw output from gitstats isn't perfect (obviously) as some individualschange email addresses, etc, but gitstats does make some effort to try keeptrack of people.Usual disclaimer about raw data applies, you should have insight into the realsituation behind the figures before trying to apply any sort of realinterpretation to it.There are a few ways in particular that gitstats' information is flawed. The biggest being that the 'organisation' an individual belongs to is generated from the first component of their email address.The problems here:Wth people contributing from email addresses like [email protected] (who is, by the way, a very prolific external Qt contributor): gitstats lumps them into an organisation like 'gmail'.This isn't bad for the *majority* of contributors, but obviously for those from free mail domains, it's not really correct.This also results, in some cases, in an extra 'organisation' being created, when someone who is already contributing to Qt switches to another mail address, as can be seen in the data with e.g. 'abecasis', created by João Abecasis, a Nokian, who has occasionally committed from [email protected] can't really be fixed in a satisfactory way automatically, as e.g. you may very well have people who move from one company to another, but keep contributing to Qt.The not so obvious problem with this is that contributions go to the organisation that user is in when they made that particular commit, so João's commits under abecasis.name go (incorrectly) to abecasis instead of to Nokia.The OrganisationsNotes when interpreting this graph:I had to cap the LOC added by Nokia, because it was off the scale. Part of this is because of updates to /src/3rdparty/ (think things like Webkit updates) by @nokia.com addressesFor all intents and purposes, Trolltech and Nokia can be lumped together, I didn't do so because of the previous note'gmail', as noted above, is actually a group of lots of individual contributors. There's some more of these (like 'users', which is people with email addresses from users.sourceforge.net)Some of the large contributions (gmail, archlinux, holodeck1, seznam, ostash) are bulked out because they include translation updatesOf interest to me when looking at this graph:Nokia is the elephant in the room. This is not unexpected, given that they have some 130 folk contributing to Qt. They are undoubtedly the largest single contributing organisation by a very, very long way.It looks like there are companies other than Nokia interested in contributing to Qt at a fairly large scale, for example, accenture, sosco, and digia. I'd presume that these are contractors. (I wonder how they get their work integrated, as I don't think it's through the merge request system)There is a large impact thanks to individual contributorsThere is a big KDE presence. This is not unexpected. :)There are a number of smaller companies in the Qt ecosystem, such as Codethink, my own employer, Collabora, Blankpage basyskom, and medical-insight.The IndividualsNotes when interpreting this graph:I chose to cut out Nokia/Trolltech, because otherwise, it would have been pretty pointless. They contribute a lot, and there are a lot of them. Besides, for me at least, it's more interesting seeing the individual contributors.There is at least one ex-Nokian in here (Anders Bakken). I have left him in because he still occasionally contributes to Qt for his new employer (I think). But part of his number will of course come from his time at Nokia.Of interest to me when looking at this graph:Contractors seem to be doing quite a bit (Shane Kearns, Mikka Heikkinen). Not surprising.Ritt Konstantin is a hero.There are a lot of people working on translations outside of Nokia (Ritt Konstantin, Laszlo Papp, Jure Repinc, Victor Ostashevsky), and just like we saw on the organisations graph, the numbers get a bit skewed as a resultThe numbers drop off very quickly, especially if you were to disqualify translations from these figures. This is a bit disappointing, but not surprising, given the hurdles to contributing to Qt. [Less]

After recently writing about the broken contribution process in Qt, I got a little bit inspired to see what the current 'lay of the land' of the Qt contribution ecosystem looks like. So, I did what any self-respecting hacker would do, and wrote a ... [More] quick script over the course of a few hours to generate the statistics I wanted. Beware, gitstats takes a long while to run over repositories with a big history. If you want to skip the work of running it over Qt yourself, grab a copy of the CSVs I generated.Before I go any further, I'd like to emphasise the following from gitstats' README:The information gitstats generates is in two primary facets: which individualsare doing the work, and which organisations do those individuals come from.The raw output from gitstats isn't perfect (obviously) as some individualschange email addresses, etc, but gitstats does make some effort to try keeptrack of people.Usual disclaimer about raw data applies, you should have insight into the realsituation behind the figures before trying to apply any sort of realinterpretation to it.There are a few ways in particular that gitstats' information is flawed. The biggest being that the 'organisation' an individual belongs to is generated from the first component of their email address.The problems here:Wth people contributing from email addresses like [email protected] (who is, by the way, a very prolific external Qt contributor): gitstats lumps them into an organisation like 'gmail'.This isn't bad for the *majority* of contributors, but obviously for those from free mail domains, it's not really correct.This also results, in some cases, in an extra 'organisation' being created, when someone who is already contributing to Qt switches to another mail address, as can be seen in the data with e.g. 'abecasis', created by João Abecasis, a Nokian, who has occasionally committed from [email protected] can't really be fixed in a satisfactory way automatically, as e.g. you may very well have people who move from one company to another, but keep contributing to Qt.The not so obvious problem with this is that contributions go to the organisation that user is in when they made that particular commit, so João's commits under abecasis.name go (incorrectly) to abecasis instead of to Nokia.The OrganisationsNotes when interpreting this graph:I had to cap the LOC added by Nokia, because it was off the scale. Part of this is because of updates to /src/3rdparty/ (think things like Webkit updates) by @nokia.com addressesFor all intents and purposes, Trolltech and Nokia can be lumped together, I didn't do so because of the previous note'gmail', as noted above, is actually a group of lots of individual contributors. There's some more of these (like 'users', which is people with email addresses from users.sourceforge.net)Some of the large contributions (gmail, archlinux, holodeck1, seznam, ostash) are bulked out because they include translation updatesOf interest to me when looking at this graph:Nokia is the elephant in the room. This is not unexpected, given that they have some 130 folk contributing to Qt. They are undoubtedly the largest single contributing organisation by a very, very long way.It looks like there are companies other than Nokia interested in contributing to Qt at a fairly large scale, for example, accenture, sosco, and digia. I'd presume that these are contractors. I'm informed that contractors generally work from the Nokia offices, which would explain why I hadn't seen much of them in Gitorious. (They still go through a code review process, as do other Nokia employees.)There is a large impact thanks to individual contributorsThere is a big KDE presence. This is not unexpected. :)There are a number of smaller companies in the Qt ecosystem, such as Codethink, Collabora (my own employer), Blankpage basyskom, and medical-insight.The IndividualsNotes when interpreting this graph:I chose to cut out Nokia/Trolltech, because otherwise, it would have been pretty pointless. They contribute a lot, and there are a lot of them. Besides, for me at least, it's more interesting seeing the individual contributors.There is at least two ex-Nokian/TT people here:Anders Bakken, whom I have left in because he still occasionally contributes to Qt for his new employer (I think). But part of his number will of course come from his time at Nokia.Benjamin Meyer is an ex-TT guy, who left a few years ago. Since he never committed from either a TT or Nokia address, there's not much point to removing him, I think.Of interest to me when looking at this graph:Contractors seem to be doing quite a bit (Shane Kearns, Mikka Heikkinen). Not surprising.Ritt Konstantin is a hero.There are a lot of people working on translations outside of Nokia (Ritt Konstantin, Laszlo Papp, Jure Repinc, Victor Ostashevsky), and just like we saw on the organisations graph, the numbers get a bit skewed as a resultThe numbers drop off very quickly, especially if you were to disqualify translations from these figures. This is a bit disappointing, but not surprising, given the hurdles to contributing to Qt. [Less]

We had a session about application QA in last weekend's GSoC Mentor Summit. I explained how the Maemo Downloads approval process works in a completely open, crowdsourced way. This differs from many distributions where approval of new packages ... [More] involves obscure decisions and secret handshakes. Some guidelines: Separate your core distribution and application packages Approval process should have three layers: development, testing and stable, individually for each application targeting a particular distribution version Anybody can upload packages to development status, and then promote them to testing On their way from development to testing packages should pass automated tests Anybody can install and test packages that are in testing, and vote for them Testing guidelines should be clear and easily available to anybody interested in testing Quarantine period for applications being tested (ten days in case of Maemo) When quarantine has passed and application has enough positive votes, developer can promote the package to stable Hopefully these ideas will prove helpful for other distributions like MeeGo, Ubuntu or Debian. See also my slides from an earlier talk on the same subject. [Less]

This week I am in Cambridge getting to know my colleagues at Collabora Multimedia and attending both the ELC and the GStreamer Conference, which were co-locating. ELC was interesting. There were a lot of talks dealing with user interface and ... [More] multimedia issues, and I was pleasantly surprised to find out several presenters mentioning Qt, usually in conjunction with MeeGo. I remember that four or five years ago Qt was relatively unknown, at least in the free software events I used to attend. Nowadays this is clearly not the case: a presenter from Alcatel had a lecture where he compared the available solutions for embedded Linux products. It was a nice presentation, covering all the different SoC architectures as well as the frameworks and toolkits. When he reached the toolkit section there was a big chart with 7 or 8 different solutions, and Qt was clearly a contender for the top position. The GStreamer conference was a pleasant surprise for me as well, as I was not expecting that many developers. There were at least 150 people there from different projects and companies, and the quality of the presentations was great. I was very pleased to meet another Brazilian developer, Luciana Fujii from Holoscopio. She presented about Landell, a GStreamer-based recording and streaming solution that was used for the last FISL conference in Brazil. It looks very interesting and could possibly help us solve some of the challenges related to recording and streaming content for the next Desktop Summit. On-the-fly camera switching and titling are possible, as well as recording and streaming using different settings. It is Python-based and seems very simple to operate. I also met several other developers working with GStreamer either professionally or in their pet projects. One I found particularly interesting to watch in action was Stefan Kost’s Buzztard: a pretty impressive music composition environment. I recommend a visit to the site: it can work with both samples and generated sounds, has a built-in sequencer/tracker and can even work with legacy Buzz Windows plugins. For some songs Stefan told me that the internal GStreamer pipeline created by Buzz uses up to 500 elements! (mixers, effects, sound generators…) And it all runs at real time: in his machine this was using 25% of the CPU, but of these only 5% were really being used to play the track, as the rest was mostly consumed by the GUI. Finally, I collected some initial feedback about the current QtGStreamer implementation and possible use cases. I think we are in the right track so far, and I hope we can see the results of this work pretty soon in the form of applications as cool as the ones I have seen in this conference. [Less]