MeeGo

We've all written our own small toolkits, and the like in the past, and today I revisited my glory days: I made a button.Actually, it was a bit more involved.Some of you might have heard of a nifty thing called a QGraphicsScene (and friends), a ... [More] fairly useful tool to allow for complex rendering/manipulating of 2D objects, animations, all the rest of the bling. It's been used for a lot of things over time, and recently I've been getting to know it in my copious "free time" over this weekend.I decided to see how difficult it would be to create my own button inside a QGraphicsScene (yes, I know QGraphicsProxyWidget exists, but it is fairly slow, so using it isn't the best for many situations), so while I was at it, I decided to make it blend in with the rest of the widgets on my desktop too.This is more a proof of concept than anything, but in case anyone else ever wants to write their own widgets and render them in a QGraphicsScene, here's a bit of a pointer in the right direction. ;)#include <QApplication>#include <QGraphicsWidget>#include <QPainter>#include <QStyleOptionGraphicsItem>class AButton : public QGraphicsWidget{public: AButton() : QGraphicsWidget(), m_isPressed(false) { } QRectF boundingRect() const { // TODO: fetch QRectF from text() + icon() and cache return QRectF(0, 0, 40, 40); } void paint(QPainter *painter, const QStyleOptionGraphicsItem *option, QWidget *widget = 0) { QStyleOptionButton opt; // TODO: QStyleOption::initFrom overload for QStyleOptionGraphicsItem would be nice //opt.initFrom(this); opt.state = (m_isPressed ? QStyle::State_Sunken : QStyle::State_Raised) | QStyle::State_Enabled; opt.text = text(); opt.icon = icon(); opt.rect = option->rect; opt.palette = option->palette; QApplication::style()->drawControl(QStyle::CE_PushButton, &opt, painter); } QString text() const { return "hi"; } QPixmap icon() const { return QPixmap(); } void mousePressEvent(QGraphicsSceneMouseEvent *event) { m_isPressed = true; update(); } void mouseReleaseEvent(QGraphicsSceneMouseEvent *event) { m_isPressed = false; update(); }private: bool m_isPressed;};#include <QApplication>#include <QGraphicsView>int main(int argc, char *argv[]){ QApplication a(argc, argv); // set up scene QGraphicsScene scene; AButton button; scene.addItem(&button); // add a view QGraphicsView view(&scene); view.setRenderHint(QPainter::Antialiasing); view.resize(200, 100); view.setBackgroundBrush(QApplication::palette().background()); view.show(); return a.exec();} [Less]

In a closed environment you use what's in the SDK and you get your own little space; talking to others is discouraged and sharing and re-use outside the blessed area is frowned upon. This dictatorial style has the advantage of making life easier for ... [More] the vendor. In an open world we have more interactions... and as students of networks know: increased connectivity brings increased complexity as well as increased benefits.  So this is an initial proposal for the organisation of OBS build projects and packages to support a QA process into an app-store / Extras or garage-like environment.  I'll introduce some basic OBS concepts and then describe how this might work. I would like this to raise awareness of some potential complexities that we may face and get some thoughts on how to deal with them. ...... Oh, and this is about both Maemo and MeeGo.First an OBS Intro It's a build system (fully local) and a build service (like the autobuilder). You put source into it and say "use this repository" and it spits binary packages out. It builds a minimal and "clean" SDK using the repository you told it to use It has packages - a package corresponds to a tarball and a spec/dsc It has projects - a project is like a directory with packages Packages are 'published' into a corresponding repository (which can be shared with others) The published repositories can also be used by devices to download binary packages.There is a lot more to it; scheduling, dependency based building, multiple architecture support, home projects, package signing...The 'trick' then, is to set up a structure of projects that we can use to support the publishing and sharing activities that we need.So What are our Goals?We want: to allow freedom for developers to develop; to provide a great build service and SDK to work with the core distro as much as possible to provide excellent quality assured applications for our "app store"; and for MeeGo, to extend the core distro with a community supported area for libraries and packages that are depended upon by more than one application. First thing we get: Individual Homes and PPAsYou'll start by uploading and building a package in your "home" directory (which can have a structure underneath it for multiple projects). This will allow you to build against any of the main distros; any group/community projects or even any other community member home projects. Oh, and they can use your code as a baseline too. Once built your code is automatically published to a repo on thecommunity downloads server.This is a lot like the Ubuntu PPA solution.At that point you can stop if you want. You have a complete set of repositories (1/subproject). No painful QA processes. No 'fragmentation'. But equally your repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc.A huge benefit here is that to get at a development version of an application you use a specific repository, not a mishmash of randomly unstable packages like Extras-devel.For the pros: Community QA'ed Repository - ExtrasIf you'd like your application to appear in the Extras repo which is pre-installed on devices then you can submit to the QA process.First you register for the package name, then submit your code to the distro promoter; there it is QA checked, copied to Extras:Testing, built, QA'ed again and becomes available in the Testing repository.<here be dragons> The community testers then approve your code. </dragons>(I know that's a contentious point - and I don't have an answer. I do however have confidence that we can solve the problem through collaboration and co-operation.)Once approved the code is copied to the Extras:Stable repository for publication.ConclusionMuch of this text is online at: http://wiki.maemo.org/OpenSuse_Build_Service(I really hate it when things get locked up in blog posts and forums)How can you help?Some tasks needed to get the OBS running: OBS Installation - a detailed guide on how the system was setup. Application QA Process on the OBS - a proposal Setting up Fremantle - WIP - post to follow Fixing the Fremantle SDK - mmmm Setting up cross-building - started, not imported yet An OBS Autobuilder queue - not started Reporting - not started Also see: http://wiki.meego.com/Proposal_for_Community_Application_Support http://wiki.meego.com/Proposal_for_a_Repository_working_group [Less]

...and not only is the Shadow War over but it looks like we will have a community OBS thanks to the team formerly known as maemo.org infrastructure :)I'm really excited as I see this as a way for the Maemo and Moblin development communities to ... [More] transition smoothly into a MeeGo future; we should eventually be able to offer an easy way to build applications for Fremantle, Harmattan, MeeGo and future device OSes too.So what's happened?A while ago the RWG proposal was begun and we've been pushing it ever since. Tero, Mike, Neils and others have been working on the CAT proposal as well as the RWG. We got together on irc and had a chat about the scope and how to proceed.Last week the TSG agreed we need something (kinda!) - so we decided that we'd go ahead and do it.We now (thanks to Tero & Nokia?) have a test machine behind a firewall and I've setup an OBS (more than you ever wanted to know... but you said to work in the open, right?) to prototype how we'd deploy it for community use. This has a link to the MeeGo OBS and successfully builds MeeGo packages.Where are we going?I don't know yet; but here's what I'm proposing (my ideas tempered with some input from others):Initially we should offer a MeeGo OBS and a Maemo OBS. There are corporate issues around this and whilst my personal aim is a single build system able to build debs and rpms against any M[aemG]*o distro, that isn't the first step.The MeeGo OBS will probably offer home directories and a way to build against the MeeGo weekly snapshots. We may be able to offer a 'live' feed if some OBS bugs are resolved and we have the build resources.The Maemo OBS will provide an alternative to the autobuilder for Fremantle and, eventually, for Harmattan. This makes sense as our longer term future with MeeGo is clearly the OBS.One thing I dread is having to go to each device vendor's build system to make build my app for their community app store; so maybe off into the future we'll even provide a neutral place where we can support multiple vendors: a single build system that can build community MeeGo apps for devices from any vendor that participate.Another area of interest to me is something I call "Surrounds" (yes, Quim, I know... it needs work). This isn't my idea... lots of software products and distros have it. It's that chaotic area around a product where 'outsiders' or community people contribute their "unsupported" bits and pieces. Actually this deserves a post on its own. Anyhow, I think the OBS will make managing this a lot easier for the community.There is still a lot to do...We've asked a few community devs to join (and please come and talk to us if you feel you can help - bear in mind that we need documentation and build system process experience more than development skills).A big task is the setup of an OBS build system for Fremantle. I managed to get this 80% done a while ago so that work needs digging up and finishing off. Once that's done we will need a lot of help validating all the Extras apps.Yet more work is required on my cross-compilation system used by the OBS. That was deployed for Mer and we need to redeploy it for Fremantle too.There is work on reporting systems and QA automation systems going on that we can re-use which will help in transforming the autobuilder promotion type processes and figuring out what is and isn't needed in the OBS world.Speaking of which ... do we take this opportunity to tweak the Extras promotion policy?I think we need something like the Devel->Testing->Stable process for Maemo apps - but maybe we should be working with the CAT guys to figure this one out?Finally please don't ask me when you'll get to use it, we don't have a schedule yet :(However, do feel free to ask me what we're working on or what we've done or what you can help with. [Less]

It's been quite a while since the Qt code was opened up now.With the changing of development model and licensing, one would think that there was a lot of potential to nurture and grow a Qt hacker community, but at least in my mind, this hasn't taken ... [More] off quite like I'd hoped it would, although things have been steadily improving, through things like the #qt-labs channel on freenode.After  some recent chatter with a few people on #qt-chat, I started reflecting on just how things are, how they could be, and what could be done to help get them there, and so I'd like to reflect on how to best encourage new development on Qt: the best approach, I think, is to lead by example.Join #qt-labs on freenode and talk about what you're doing! We're all interested.Start reviewing merge requests! Don't just leave this to the Nokians - the more eyes, the better.Submit your own merge requests, if you've got an idea. It doesn't matter if you're not sure about some things, getting the code in the open is the first step - it can always be improved later.Look into JIRA for things you can do.Find (and fix) things in the Qt API that annoy you...And if all else fails and you're really bored, you can always write test cases. ;)Yes, you. For all those of you out there who haven't become involved yet: now is as good a time as any.Don't be scared off by the complexity of Qt. It's a cool library, a cool set of people, and awesome fun to hack on. You may not be perfect, but nobody is, and you can learn. You beginners of today are the hackers of tomorrow.If you don't know what you could be doing, feel free to ask me, or one of the many other friendly folk on #qt-labs - I'm sure someone can find something to keep you busy. :)Why, I hear some of you ask, is this important? Well, it's fairly straightforward.Qt as an application development platform is growing and growing and growing - not just inside the mobile world - and this shows no signs of slowing. This is great news.Not all Qt application developers will work on Qt itself - but it is something that we should work to encourage as much as is possible in order to match the above growth. The more skilled platform hackers we have, the more application developers we can support. Think of it as a pyramid: you can't have a stable structure without a solid base.How, then, do we nurture and grow our platform hackers? How do we encourage growth of the community around the code? There isn't a simple, single, answer to this, but I think there is plenty we can do, and the above is a very good step.However, some of us with a corporate affiliation are already contributing to Qt, and there are a few things that would help encourage more community growth.Firstly, it would be much better if the community had merit to provide review of what goes into Qt itself, both merge requests and from internal work too. Currently, we can provide review, but it isn't a replacement for internal review.Not only is this creating a bottleneck, but (somewhat obviously) it doesn't encourage others to take part and become the hackers of tomorrow.Secondly, everyone should be going through the same processes. A code review in #qt-labs is still a code review, but when some people are made to jump through the hoops of filing a merge request, this leads to a two tier system.A much better way of doing this, IMHO, is to stick with the idea of having a few reviewers who know specific subsystems, and can accept patches for their 'area' (be it networking, QML, or whatever) - and all patches, no matter their origin, go through merge requests.Lastly, the remaining private infrastructure should be opened up as much as possible. No private pastebins, no private test server, publish the results of the integration runs and test suites on platforms. (note: I believe that work is underway on this, I'm just including it for the sake of completeness.)There are other points here which are useful for an open future, but I've deliberately kept the list short - walk, before you can run. :)Finally, I'd like to thank Nokia for purchasing Trolltech, and starting the road to opening Qt development. You've started something very cool and awesome here, and I'm excited to play my role in this. I hope that some of the ideas and points I raise here can prove useful to moving forward to a bigger, better, more awesome future.[I'd also like to thank the following people for their time and feedback on this post:John Brooks Thiago Macieira from QtBradley Hughes from QtRevdKathy from Maemo] [Less]

I've been meaning to write this up for a while, but (due to one thing and another) it's taken a little longer for me to write than I'd have liked. But, better late than never, eh? :)This is a short note that Facebrick will have a pair of helping ... [More] hands for 2010, in the form of Kamilla Bremeraunet, a keen Norwegian studying at the University of Hull, in the UK.A brief list of what she'll be working on (possibly more, if I whip her enough!): A more useful replacement for the Nokia Facebook Desktop widget, which is scrollable,and links to the individual items instead of to www.facebook.comInbox support: view, send and receive messagesChange text size using the volume buttons: at the moment FaceBrick’s font size can’t be changed, and some of the users from the Maemo Community have requested a way of doing so.I'm sure she'll be a useful help, and that you, the Maemo/MeeGo and Facebrick user community will make her feel more than welcome. You'll be hearing more about her and her intentions in the near future once she finishes up the remainder of her coursework for this semester. [Less]

Yes, they suck, we all know it. Yes, they're boring to write, and annoying when they break, and generally - the bane of every developer's existence.But please, write them. A lot.I've worked on a lot of projects during my life (especially if I count ... [More] ones I just throw a patch at and never look at again), but one thing that often runs true is that they usually don't have enough unit tests written. This is of perhaps because they don't have enough anal-retentive people like me badgering other people to write unit tests.Humour aside, unit testing is important, especially when you're working on a library. Bugs are natural, and will happen, but unit tests help to catch bugs (so you don't release horribly broken code), and to prevent the same bugs happening in the future, which is also quite possible.I was wandering around Qt's code the other week, and was a bit astonished to notice just how few tests some of the base parts of Qt had (QList, QVector, etc.) Now, it's perfectly possible to argue that due to the very fundamental nature of those classes, any breakage would be caught pretty much immediately when compiling Qt itself, but I personally feel it's a lot nicer having proper tests that validate the way your API is supposed to function, *especially* when it's for something that low level and important.So, I did something about it, and QList and QVector are now fully covered test-wise. Hoorah!There are still plenty of other areas that could probably use some test loving, so why not check out Qt from git and lend a hand today? :) [Less]

Nokia Could Introduce MeeGo-based iPad Rival At the beginning of April, a Reuters article speculates that Nokia could be planning a MeeGo tablet in a form factor similar to that of Apple’s iPad. MeeGo Support Grows MeeGo backing received a massive ... [More] boost on April 12th, when the Linux Foundation announced supporting statements from Acer, Amino, Asianux, Asus, BMW Group, Collabora, Ltd., CS2C, DeviceVM, EA Mobile, Gameloft, Hancom, Linpus, Maemo Community Council, Mandriva, Metasys, Miracle, MontaVista Software, Novell, PixArt, Red Flag, ST-Ericsson, Tencent, TurboLinux, VietSoftware, Wind River, WTEC, and Xandros. More information about MeeGo at the Linux Collaboration Summit is available from Ars Technica. Intel Demo MeeGo on Netbook In mid-April, Engadget reported on Intel’s MeeGo netbook demo at the Intel Developer Forum. The UI is still looking very moblin-esque, it will be interesting to see how similar or different the user interface ends up being between MeeGo netbook and mobile devices. MeeGo for Laptops and Desktops? An article on Yahoo! News says that Intel are looking at MeeGo for entry-level atom-based desktops, but that it would also run on more mainstream laptops and desktop systems. LG GW990 Scrapped Engadget reports that one of the first rumoured MeeGo mobile devices, the LG GW990 has been ditched. This leaves only Nokia’s MeeGo compatible “Harmatten” device as a MeeGo phone we know is development. [Less]

Nokia Could Introduce MeeGo-based iPad Rival At the beginning of April, a Reuters article speculates that Nokia could be planning a MeeGo tablet in a form factor similar to that of Apple’s iPad. MeeGo Support Grows MeeGo backing received a massive ... [More] boost on April 12th, when the Linux Foundation announced supporting statements from Acer, Amino, Asianux, Asus, BMW Group, Collabora, Ltd., CS2C, DeviceVM, EA Mobile, Gameloft, Hancom, Linpus, Maemo Community Council, Mandriva, Metasys, Miracle, MontaVista Software, Novell, PixArt, Red Flag, ST-Ericsson, Tencent, TurboLinux, VietSoftware, Wind River, WTEC, and Xandros. More information about MeeGo at the Linux Collaboration Summit is available from Ars Technica. Intel Demo MeeGo on Netbook In mid-April, Engadget reported on Intel’s MeeGo netbook demo at the Intel Developer Forum. The UI is still looking very moblin-esque, it will be interesting to see how similar or different the user interface ends up being between MeeGo netbook and mobile devices. MeeGo for Laptops and Desktops? An article on Yahoo! News says that Intel are looking at MeeGo for entry-level atom-based desktops, but that it would also run on more mainstream laptops and desktop systems. LG GW990 Scrapped Engadget reports that one of the first rumoured MeeGo mobile devices, the LG GW990 has been ditched. This leaves only Nokia’s MeeGo compatible “Harmatten” device as a MeeGo phone we know is development. [Less]

Nokia Could Introduce MeeGo-based iPad Rival At the beginning of April, a Reuters article speculates that Nokia could be planning a MeeGo tablet in a form factor similar to that of Apple’s iPad. MeeGo Support Grows MeeGo backing received a massive ... [More] boost on April 12th, when the Linux Foundation announced supporting statements from Acer, Amino, Asianux, Asus, BMW Group, Collabora, Ltd., CS2C, DeviceVM, EA Mobile, Gameloft, Hancom, Linpus, Maemo Community Council, Mandriva, Metasys, Miracle, MontaVista Software, Novell, PixArt, Red Flag, ST-Ericsson, Tencent, TurboLinux, VietSoftware, Wind River, WTEC, and Xandros. More information about MeeGo at the Linux Collaboration Summit is available from Ars Technica. Intel Demo MeeGo on Netbook In mid-April, Engadget reported on Intel’s MeeGo netbook demo at the Intel Developer Forum. The UI is still looking very moblin-esque, it will be interesting to see how similar or different the user interface ends up being between MeeGo netbook and mobile devices. MeeGo for Laptops and Desktops? An article on Yahoo! News says that Intel are looking at MeeGo for entry-level atom-based desktops, but that it would also run on more mainstream laptops and desktop systems. LG GW990 Scrapped Engadget reports that one of the first rumoured MeeGo mobile devices, the LG GW990 has been ditched. This leaves only Nokia’s MeeGo compatible “Harmatten” device as a MeeGo phone we know is development. [Less]

I've had a fun weekend.Carsten Munk, of Mer and other fame got me interested in insane schemes (once again): this time playing around with libdui (or libmeegotouch, as it is now apparently known), as we had repeatedly heard from many sources that it ... [More] relied on GL, which meant that it couldn't be used with devices that require software rendering. Having found the -software flag to widgetsgallery, and poked around the source of DUI in the past, I thought this was a bit of a funny claim to make, until we actually used it and found out how horribly slow it was. Maybe they had a point?Why was it slow? Well, it happened again. Not completely the same, of course, but this is a very similar issue to one I wrote about recently in Qt on Maemo. Something that a lot of developers, particularly ones working in higher level libraries or languages like C# or Qt forget from time to time is that image (or pixmap) scaling - in particular, smooth scaling - is generally not a fast operation.DUI did a lot of scaling.DUI has a class called MScalableImage, the purpose of which is to draw (and scale) a pixmap as needed, which is a good enough reason to have a class. MScalableImage is passed a pixmap, and stores it.So far, so good.Now, onto the details of scaling. When being asked to draw, QPainter pointer is passed, as well as an x, y, width and height. The width and height are checked against the stored pixmap's width and height, and if they match, it's drawn instantly, no questions asked.So far, so good.What happens, though, in the case where they don't match?Oops.DUI currently copies and rescales the stored pixmap to the target width/height, and then proceeds to draw as normal.This behaviour is obviously wasteful. In the (frequent) case of GL acceleration, this doesn't really matter so much, because scaling on GL hardware - abstracted away by Qt - isn't all that slow, which is why this problem was probably not noticed previously. In the case of software rendering, though, that's a whole different story.Patching this away to use the application-wide QPixmapCache drastically improves the performance of software rendering. My laptop isn't exactly slow, and I still ended up with a boost from an (unusable) 5-6 FPS to around 170-180 FPS.Hopefully this post serves as an educational warning to help prevent future such mistakes.(Oh, and the conclusion? No, DUI doesn't require GL. It helps, obviously, but it's not required.) [Less]