MeeGo

After the publication of Nokia's 2010 Q4 results, there has been much fevered discussion across the Internet about why Nokia, with (ex-)Microsoft's Stephen Elop at the helm, may turn to other operating systems for its phones. The alternative ... [More] operating systems in the spotlight being Android (Q4's biggest seller) and Windows Phone 7. Here at All About Symbian, we have been considering these options and finding that they just do not stand up to a reasoned analysis. An article entitled "Should Nokia Be Looking At Android or WP7? Not Yet", over at Gigaom, broadly agrees with our appraisal of the options.Here are some highlights: "It’s clear that Nokia is need of help, but I’m just not convinced that Windows Phone 7 or Android is the answer, not at this point at least. If things keep going down and Nokia can’t get its act together this year, I reserve the right to change my mind. But here’s why both options don’t work for me: Windows Phone 7 is still a very new OS, and early shipment figures have not indicated how well it’s actually being adopted by end users. There are still some rough edges being smoothed out as well, like fixing the lack of cut-and-paste and multitasking support. WP7 does have a decent-sized application market, but larger developer support will lag as developers sort out how much traction the platform has. To pin Nokia’s smartphone strategy to WP7, even if it’s just for North America, doesn’t guarantee a major reversal in fortunes. Meanwhile, Android is also not a great fit. There is so much competition among manufacturers that it’s going to be hard for Nokia to stand out. Yes, Nokia has some of the best hardware around, but HTC, Motorola , Samsung and others are putting out top-notch Android devices. Nokia becomes just another Android vendor and will have to compete against not only the big boys, but a host of cheap Asian manufacturers looking to churn on low-cost Android devices." "The fact is, Nokia has a plan and though its pretty late in coming, it should try to execute that before it looks elsewhere. High-end devices running MeeGo are set to appear later this year, while Symbian will serve mid-range smartphones. Both will be tied together in the QT software development framework that will allow developers to write applications once for both platforms. Going with another platform will only confuse developers who are being courted to QT right now. Nokia should see its strategy through first and try as hard as it can to get it done in-house. The smartphone game, despite its massive growth, is still in its early days. We’re going to be talking about smartphones for some time to come."   It's certainly a refreshing change to see an article out there that is looking at things objectively, and resisting the urge to jump on the popularist band wagon. There'll be more coverage coming from All About Symbian on this subject in the coming weeks, but in the meantime, I recommend you our editorials: Nokia Q4 2010 results, What we've learned about Nokia from yesterday's results, and a listen to AAS Insight #151 David Gilson for All About Symbian, 31st January 2011 [Less]

For the last six months, we have been building a set of UI components for Qt Quick. This has been done completely out in the open, with both project content and progress reflected in our Jira instance [1], developing using the gitorious repo [2] ... [More] , hanging out in #qt-components on freenode [3] and emailing [4]. We have been having a lot of fun, and it’s starting to become feature complete. For a while we will not be pushing changes to the MeeGo style branch of Qt components, as we are busy finalizing it and are unable to make certain pieces of the final user experience public. Bear with us for a while, the code will be released upstream as soon as we can. We will of course continue to reflect API changes in both Symbian style (which is starting to form in src/symbian) and the custom style branch – as well as in our project on bugreports [1]. We are very aware of the fact that this is a suboptimal solution, but this is the only way we are able to work with the efficiency we need while at the same time keeping certain aspects of upcoming platform look and feel under wraps. If you have a business need to contribute actively to development of Qt Quick components for MeeGo, please contact me. [1] http://bugreports.qt.nokia.com/browse/QTCOMPONENTS-200 [2] http://gitorious.org/qt-components [3] irc://irc.freenode.net/qt-components [4] http://lists.qt.nokia.com/mailman/listinfo/qt-components [Less]

So... lets say we have some device that run MeeGo; what else canit do? Where are the apps?Apps - the area formerly known as "Extras"Borrowing Andrew Flegg (Jaffa)'s mission statement for MeeGo CommunityApps: we need to ensure a vibrant and quality ... [More] area for community opensource software. So MeeGo Apps is the community app store and follows on from thesuccesful Maemo Extras. It allows app developers to build MeeGo compliant (and other) apps anddistribute them to users. What makes Apps different from a 'random repository' is the communityQA process that is applied; the objective of this QA process is topermit users to trust the apps and to deliver a collection of appsthat a commercial vendor could enable on a shipping device (as Nokiadid with 'Maemo Extras' on the N900). Clearly then, there needs to be some processes (and automation) todefine how QA checks are carried out and what to do when certainevents occur. We already have a process automation sytem (called BOSS- it's is being developed by Nokia and is essentially an integrationof various OSS libraries) - now we need to decide what processes andcriteria we use to manage and promote apps. Initially I suggest westart with the Maemo Extras process and refine that. When we talk about process we are also talking about policy. I'vediscussed this below and quite a few of the points apply to Apps.Now, it's not yet clear what OBS targets Apps should buildagainst. Currently we have: MeeGo:1.1:Core MeeGo:1.1:Core:Handset MeeGo:1.1:Core:IVI MeeGo:1.1:Core:NetbookThese correspond to the MeeGo Core and then a number of UXes. Howeverthere are plans to consolidate them in the main MeeGo OBS - but howshould the Apps area look? Should a handset user be presented with appswhich were only intended to run on a netbook? OTOH is this anything todo with the repo and build target - should it be determined bymetadata and selectively presented by the download application?Well, until this is resolved, an app developer simply needs to enableeach target that the app supports to make it available in thatrepository.I think the discussion up to this point is fairly simple anduncontentious; we can start to address the issues mentioned and just get on with it and start to deliver MeeGo Apps :)However, as mentioned, the Apps area allows both MeeGo-compliant andMeeGo-extra applications. MeeGo-compliant apps are those which onlyuse libraries in MeeGo core/UX; MeeGo-extra apps have a little extraopen-source goodness sprinkled in... Surrounds.MeeGo: The Linux DistroBefore I tackle 'Surrounds' lets step back a little:Since MeeGo was announced around a year ago I've been interested inhow development happens around MeeGo as well as in the centre. Thefollowing is intended to be a discussion document; there are clearlysome large gaps and I expect some of my proposals to be shot down -but I really hope that only happens when better ones are proposed!In order to address this I think it's important to ask... what is thepoint of MeeGo? Well, IMHO, MeeGo is primarily a modern linux baselineupon which commercial mobile computer products can be delivered.MeeGo's main customers are not end-users - they are device vendors;*they* should be the focus of our core engineering team's design,delivery and QA effort. So MeeGo clearly has a focused development area with the main OBSsupporting the development and delivery of the MeeGo core systemsoftware and reference UXes. Of course MeeGo is also capable of being a wonderful and open linuxdistro in its own right. However I personally think that to be asuccess, the MeeGo core needs to focus on the primary goal and allowmore of the "linux distro" side to be managed as a surroundingproject. Incidentally, in my day job I care a lot about how MeeGo presentsitself to us as a vendor. I think it would be a good thing for MeeGoto have it's own "reference product" built around the core that itoffers to vendors. This would expose issues like: How does MeeGo communicate significant upcoming changes to it'scustomers? How do we deal with package naming clashes? How much of MeeGo is needed for compliance vs the parts that areneeded to make a reference implementation? With more than one community product: how connected are devices?So, 'Surrounds' is a proposal that aims to provide a collection ofopen source libraries, tools and applications that support thebuilding of collaborative bazaar-style applications and yes, maybeeven MeeGo distributions. Whilst I don't think this is an immediate change, I do think it's aninteresting direction for MeeGo to take that may allow more focus onthe core deliverables.In the meantime lets look at this "extra open-source goodness" Ipromised:SurroundsAs we know, the open source world is a world of sharing; we regularlystand on the shoulders of our peers and it's considered very bad tasteto just 'bundle' a library into a monolithic application. (Notice howI didn't mention any kind of compliance programme by name - aren't Igood!) Surrounds provides a collection of libraries and tools that encouragesthis best practice way of working in MeeGo and delivers MeeGo-extraapps. The most obvious area would be for languages like perl, pythonand ruby. These languages have large numbers of useful libs thatclearly are not going to be present in core MeeGo. Of course therewill be many other tools and applications that would also be at homein Surrounds. Over time, packages may migrate into core MeeGo and equally, some aregoing to be deprecated. Hopefully Surrounds makes both of thoseactions a little easier but we do need to decide how we handledeprecation/promotion of applications/libs between core and Surrounds.There are many complexities when dealing with a collection of packageslike this:QA and ReleasesThe fundamental question is "How is Surrounds QA'ed and released?".This is a significant undertaking and needs a lot of resource andusers. This alone means that Surrounds should probably start offslowly and ramp up as MeeGo users and developers arrive in largernumbers. The important thing is to prepare for the main issues we'relikely to face.I propose that Surrounds is actually only populated on an "as needed"basis; tools can be submitted directly but libraries have to be neededby a tool or by an application submitted to the Apps area.Upgrades and concurrent installationsFor example: let's look at a device that has MeeGo 1.2 installed on itand an application "Wowee" built against an imaginary libvisual-1.0which is in the Surrounds-1.2-A stable release of Surrounds.9 months later many libraries have been updated and developerswant to use the latest versions... it's time to release a newversion of Surrounds-1.2. Sadly libvisual is up to version 1.0awith a minor tweak which would break Wowee; not only that butthe Wowee developer has gone awol (so there's no-one to testit) and no-one's stepped up to update it. Even worse there are50,000 users using Wowee which is working like a dream.Looking at the large number of apps in Maemo Extras I thinkproblems like this will arise and are beyond the resources ofthe community to handle at this point.A technical solution may be that when Surrounds-1.2-A is installed itgoes into /opt/surrounds/1.2-A/... and any apps use the appropriatepath to find their dependencies. This allows apps that use libraries from Surrounds-1.2-A andSurrounds-1.2-B to be installed concurrently even if they usedifferent versions.I'm not sure how Surrounds-1.2 handles upgrades from MeeGo 1.2 to 1.3.The message however is that there are many issues like this that itwould be good to identify in advance. Just ask a maemo developer aboutthe "optification" hack :)Porting vs Maintaining : A MeeGo partnerWhen it comes to populating Surrounds we need to look to the largerlinux ecosystem.Some tools and libraries will have comitted maintainers who have timeto monitor their packages and fix bugs and security issues in a timelymanner. This is the classic distribution 'maintainer'role. Some libraries won't. Developers will simply need a particular libraryand 'grab' a source rpm that looks like it's good-enough. They throwit at the OBS and a few minutes later have an installable package fortheir application. This is what happens in Maemo Extras. I call this activity 'porting'. The problem arises when another developer does the same thing afew weeks later with a slightly different version of thepackage. This may cause the original app to fail.Equally, none of those developers want to commit to maintainingthe library. So when a security issue arises, no-one is readyto update the package.I'm actually a little concerned about prolific porting - and sadlythis is the bit that gets the fame and glory : "look how many packageshe's ported". The truth is that this doesn't bode well for MeeGo inthe long run. My suggestion for this group of packages is to nominate an upstream orpartner distro with a good security record and a wide base ofpackages. Surrounds releases would closely track this distro (and willlikely differ from core MeeGo). Packages taken from this distro wouldbe fast tracked as 'ported' rather than 'maintained' and only minimalpackaging changes would be allowed. This would allow Surrounds toleverage the partner-distro's security efforts (and hopefully offerbenefits to the partner in return). For obvious reasons I propose openSuse as the partner distro. (For therecord I'm a Debian guy - but lets be sensible here!) For equally obvious reasons this is a political minefield :)Some random policy questions:There are a lot of policy considerations for the community; some Iwrote in a bit of rant (forgive me Shane). Some apply to Surrounds andApps, some to the OBS in general Licenses: OSI only licenses? GPL3 (considering the "promotionto core" target). People: What's the process for absent devs? If someone says"hey, lbt, let me upload a new version of that library Shaneuploaded" ... do I just let her? What if there's a securityissue in it? What if you've not been seen in 3 months? Domaintainers need to demonstrate reliability to handle timelyupdates? Legal : Do we accept mp3 players? libdecss? What about porn?What about apps with a rather rude splash screen? Any patentissues? (Don't forget the system physically lives in the"land of the free" so is subject to state seizure by theRIAA). Commercial: I've had commercial organisations enquire about usingthe community OBS. I've had them ask to sponsor it. How do we dealwith this? My first reaction is "no commercial work"... but why not? Quality: Do we insist on a valid bugtracker being identifiedfor all Surrounds packages? Must it proxy via a bmc#? Packages scope: Where's the ITP? Can we rebuild MeeGo with some different compiler flags (thinknon-ssse3 ... yay ... I can run MeeGo on my AMD desktop at last!) Do we sign any of the community repos? What does that mean? Acceptable Use Policy : at what point do we ask users to stopdoing what they're doing? Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow itto be a target?Again the message is "there's a lot to think about".The Community OBSWe have a MeeGo Community OBS already; and it builds apps for MeeGo.It is currently managed by Niels Breet (X-fade) and I (lbt) - but weneed more help. In part this whole post is a way to structure whatwe'd like to achieve and to make it easier to identify tasks.StructureSo what project structure do we need? We've not assumed MeeGo at thetop level namespace to allow us to support additional distros such asFremantle and hopefully others.One common use for structure is to provide a QA route. Packages gofrom some sub-project in a developer's home: area to a 'Team' area andthen into a Testing area. Each transition is subject to policy andquality checks. Defining these workflows and structures correctly willmake life easier.Team AreasIt makes sense for teams to have collaboration for things like KDE,Gnome, Python, LibreOffice, Emacs etc. This would allow more thoroughtesting to take place before releasing either to Surrounds or AppsHowever, what's needed to form a team? Can anyone just step up andclaim Team:KDE or should we ask for some relationship with upstream?Do we just want to assess a proposal? Who does the assesment? Do weannounce this and give time for the community to raise objections orconsiderations?PPAsThe general policy for *home* projects is "OSI, nothing illegal anddon't take the piss". We may (or may not) need a more formal one :)Certainly these PPAs offer developers a huge amount of freedom. Theycan start by uploading and building a package in a "home" directory(which can have a structure underneath it for multiple projects). Thiswill allow them to build against any of the main targets; anygroup/community projects or even any other community member homeprojects. Oh, and they can use each others code as a baselinetoo. Once built the packages are automatically published to a repo onthe community downloads server.AFAIUI this is a lot like the Ubuntu PPA solution (hence the heading).At that point developers can stop if they want. They have a completeset of repositories (1 per subproject). No painful QA processes forthem and no 'fragmentation' for the MeeGo community. But equally theserepo(s) will needed to be manually added to a device in order for itto appear in any apt-get/zypper/yum etc. Oh, and the Apps downloaderteam really should pay attention here.A huge benefit here is that to for a user to get at a developmentversion of an application they use a specific repository, not amishmash of randomly unstable packages (like the Maemo Extras-develarea).MeeGo TargetsWhat MeeGo targets do we support?MeeGo 1.0? Really? Does anyone use that?MeeGo 1.1 and above make sense. But what architectures? As released isfine - but what if there are community rebuilds of non-ssse3?Also, when MeeGo releases distro updates, do we just rebuild all apps?What happens to QA at this point?MeeGo SnapshotsOne area to look at is how often we import MeeGo snapshots - and incurthe rebuild cost for any projects targetting them.MeeGo RebuildsFrankly I'm a bit fed up that after a year I can't run MeeGo on mydesktop. It has an AMD phenom chip and an ATI card - both wellsupported in the opensource world. It's time to build a communityMeeGo :)Do we need a community version targetting the DublinBook? What aboutthe O2 Joggler? Are there any policy issues here? Can anyone ask forthis - there's potentially a lot of resource tied up doing this kindof rebuild.SurroundsWhat projects are needed in the Surrounds area? Certainly someunstable->testing->stable cycle makes sense; but this is not likely tobe finalised until the workflow is understood.FremantleThe Fremantle migration. Mmmm. Well it might happen at some point :)Actions and Ideas Establish a task-force/group to coordinate and deliver activity andto act as a communications hub. Design and implement OBS project structures and targets for Surrounds,Apps, Teams and (suggestions for) home areas Design and communicate process/policy for putting packages intothese projects and migrating them How do packages move from Community OBS into MeeGo core Implement and automate stuff Structure and enrich the outstanding issues outlined above Design project structures Work up a proposal which sees MeeGo split into Core and Distro Copy this list into a Wiki so it's actually useful [Less]

It has been a long time since we wrote propaganda about the Tracker project. That has a lot to do with both the holiday-season and the fact that we’re preparing for a stable release. This means that we are increasingly reluctant to new features. We ... [More] still made quite some progress, though. We for example ported almost everything from dbus-glib and dbus-1 to GDBus and GVariant. This was quite a work; next few weeks will be used for cleaning up and regression fixing. Jürg decided that it was more easy to simply port ~ all of tracker-store to Vala than to port tracker-store’s dbus-glib and dbus-1 C code to GDBus. This should please contributors who will now have a much more easy to understand codebase. Tracker’s tracker-store is mostly an IPC layer above libtracker-data plus the signaling mechanism. The public libtracker-sparql is a API layer above the same private libtracker-data that protects you from doing things that you should not do. Like trying to do writes without going over the IPC layer. This week we’re working on transient properties and adding tracker:modified to the journal and backup file. The tracker:modified property is an auto-incremented value. It’s useful for synchronization purposes. Right now when you replay the journal or restore a backup, we reset the count. This means that in between journal replays and/or backup restores you wont have the same tracker:modified values for your resources. This is what we are changing. We plan to restore the tracker:modified value during journal replay and backup-restore. Transient properties are properties that are reset after restart of tracker-store (per Desktop session), they aren’t backed up (and therefor not restored either) and they aren’t journaled. They are useful for for example presence status of a contact. The nice guys and girls at the QSparql team are working on a simple cursor that doesn’t do any buffering nor uses any threads. This is useful for Qt applications that want maximum performance while reading the results of a query. Last week we introduced and ported to our newest location ontology, SLO. [Less]

Canonical's Mark Shuttleworth has announced that Qt libraries will ship in the Ubuntu 11.10 CD. Ubuntu has always been a GTK based Linux distribution (not withstanding its Kubutnu sister distribution). The obstacle for Qt developers to write for a ... [More] GTK based operating system was because of the system settings framework, in the case of GTK this is the dconf system. Canonical are now funding work to crate Qt bindings for dconf. This will allow Qt applications to run in the GNOME desktop on Ubuntu without breaking the cohesive look and feel of the application set. Read on for more.Shuttleworth said in his post: "System settings and prefs, however, have long been a cause of friction between Qt and Gtk. Integration with system settings and preferences is critical to the sense of an application “belonging” on the system. It affects the ability to manage that application using the same tools one uses to manage all the other applications, and the sorts of settings-and-preference experience that users can have with the app. This has traditionally been a problem with Qt / KDE applications on Ubuntu, because Gtk apps all use a centrally-manageable preferences store, and KDE apps do things differently. To address this, Canonical is driving the development of dconf bindings for Qt, so that it is possible to write a Qt app that uses the same settings framework as everything else in Ubuntu. We’ve contracted with Ryan Lortie, who obviously knows dconf very well, and he’ll work with some folks at Canonical who have been using Qt for custom development work for customers. We’re confident the result will be natural for Qt developers, and a complete expression of dconf’s semantics and style." Furthermore, Ubuntu's community manager, Jono Bacon, added comments to the Ubuntu news site: "Why is Ubuntu shipping Qt on the CD in 11.10? – there are two drivers behind this decision. Firstly, the Ubuntu project is working to ensure that Qt application developers can write apps which fit into the Ubuntu desktop smoothly. It is important that Ubuntu, as a platform, address the needs of developers, giving them as much flexibility as possible while retaining a coherent standard experience for users. Secondly, giving developers the extra toolkit option should mean we end up with better apps all round as the range of apps for assessment and inclusion will be wider. The key criteria for evaluation of any app for inclusion are independent of the actual toolkit. We won’t ship an app by default that we don’t think offers a great experience, not just on a standalone basis but as part of the whole system." "Does this mean Qt apps could be included on the CD? – we’ll be open to Qt apps being included in Ubuntu if they are appropriately integrated. If an application integrates well into the Ubuntu experience, we would be open to its inclusion in a release to offer the best experience for Ubuntu users. By “integrates well” we mean things like: uses the dconf configuration system with live adoption of settings changes, follows Ubuntu font and theme settings automatically, uses our menu and indicator and notification system appropriately etc." This is good news from MeeGo's point of view for two reasons. Firstly, this shows that Nokia's mobile development platform is gaining even more traction. Secondly, since Ubuntu is going to be one of MeeGo's competitors in the netbook market (by using Unity), both operating systems should benefit by having a common development framework, allowing developers to write their applications once and push to both platforms. With the anticipated rise of MeeGo, and Nokia's initiative to encourage developers to write Qt applications for Symbian, Ubuntu could may be the bigger beneficiary out of this move. That is, activity in the Meego and Symbian scene will probably attract more developers to Qt than Ubuntu's adoption of the development framework. Still though, this is good news all-round. As another point of interest, for Ubuntu users to see an example of how well Qt applications can run on the GNOME desktop, take a look at the Clementime music player. Also of interest, the GNOME project has started taking "bids" for building GTK+ support in MeeGo as well. David Gilson for All About MeeGo, 24th January 2011 [Less]

Questions have been raised in the MeeGo community recently over the support for Microsoft's NTFS. Clearly, support for this in end-user MeeGo netbooks would be expected as this is often the file system that external hard drives are shipped with. ... [More] Therefore, in the interests of interoperability, consumers should expect MeeGo to work with such devices. The lack of support was recently raised as a bug in the MeeGo community, to which the response that productised installs may have a licensed NTFS driver added on top of the open source core, but that NTFS support would not be added to MeeGo Core OS. Read on for more.The responses came from the MeeGo Core OS product manager, Gavin Hindman. On the bug report mentioned above, he initially responded by saying: "Seems a reasonable feature request, however MeeGo 1.1 is past feature-freeze. I will promote this forward for evaluation as a MeeGo 1.2 feature." However, later the same day, he then posted: "MeeGo Core lacks an open-source method of including NTFS support due to licensing restriction. Will not be supported. Products may add licensed NTFS support on top of the open-source core." This is somewhat puzzling as Tuxera, the company responsible for the open source NTFS-3G driver (see Wikipedia), have agreements with Microsoft. As quoted in this news article:  "We'll be licensing our Linux NTFS under the GPL, and we have an agreement with Microsoft. If you're a user, you don't need to worry about Microsoft. We'll deal with them directly" As stated in this MeeGo-pm mailing list post by Carsten Munk, some more transparency in the decision making is called for, as the answers given don't match with public knowledge on the status of open source NTFS drivers. "Would it be possible to counter that with an additional response by Core PM to the NTFS FEA# explaining: Technical reasons for NTFS not being able to go into MeeGo Core Legal reasons for NTFS not being able to go into MeeGo Core Organisational, if any, reasons for NTFS not being able to go into MeeGo Core .. and if those don't exist, to reconsider the FEA# to get at least basic NTFS support for 1.3, based on Tuxera's open source solution as listed.Best regards,Carsten Munk"   David Gilson for All About MeeGo, 24th January 2011 [Less]

Front Page Gtk+ on MeeGo Handset bidders selected by GNOME FoundationFollowing a donation of a large sum of money by Nokia, the GNOME Foundation have selected Igalia to conduct the work: "We received a number of very interesting bids for the ... [More] project, but Igalia's bid was the one that focused the most on integrating elements of Hildon into GTK+ upstream. This should mean easier porting of older Hildon/Maemo applications to the new MeeGo Handset platform, as well as easier porting of existing desktop GTK+ applications to the handset." Claudio Saavedra, one of the developers working on the project, said "will spend the next months trying to bring the best from the Hildon user experience to upstream GTK+, to make sure that the good old Maemo applications can be easily ported to GTK+".Read more Qt SDK 1.1 (Tech Preview) has Qt Quick/QML, Symbian, Maemo & desktop app supportNokia's Qt strategy take a step forward with a preview release of Qt SDK 1.1, which merges the numerous separate SDKs into a single install bundle: "The new SDK is a merge of the Nokia Qt SDK 1.0 and the last Qt SDK, based on Qt 4.7. [...] The new Qt SDK 1.1 Technology Preview enables developers targeting desktop platforms to use the same setup, features and environment as developers targeting [mobile] platforms. This eases the migration of desktop applications to mobile platforms." With installers for Windows, Linux (32- & 64-bit x86) and Mac OS X, and the integration of cutting edge Qt technologies and fully supported Maemo development this is what Maemo's been waiting for. Unfortunately, it's a few years late, but hopefully will put MeeGo (if/when Nokia release a handset running it) in a better position.Read more In this edition (Download)...Front PageGtk+ on MeeGo Handset bidders selected by GNOME FoundationQt SDK 1.1 (Tech Preview) has Qt Quick/QML, Symbian, Maemo & desktop app supportApplicationsBeat Maker - call for testers for drum sequencerStatus of PlayStation emulatorsQt-based TwimGo 2.5 runs "smoothly" on Symbian N8 "as it does on N900"Open Media Player gets playback and seeking supportDevelopmentOvi Store requirements vs. maemo.org Extras QANTFS MeeGo feature and conspiracy theoriesDesaturate, rather than blur, to emphasise UI contextCommunityMeeting log for MeeGo Community Office catch-upDevicesFixing prioritisation of Application manager slowness & Media player choppinessPrototype MeeGo Nokia device photos?AnnouncementsPingus (Lemmings clone) released for N900Blobby Volley 2 updated from N8x0 to N900TxPad code editor [Less]

Nokia today announced the release of the Qt 1.1 SDK Technology Preview. The new SDK, based on Qt 4.7, is a merge of the Nokia Qt SDK 1.0 and the previous Qt SDK. The release gives developers an early opportunity to familiarise themselves with the ... [More] next version of the SDK. A key theme of the release is to allow developers to easily get started with Qt Quick development on Symbian, Maemo 5 and the desktop. The new SDK also makes it easier for Symbian developers to use native APIs in their code.The SDK includes: Qt Creator 2.1 RC, which includes the first iteration of tooling support for Qt Quick.   Qt 4.7.1 for Symbian (Symbian^1 and Symbian^3), in both the tool chain and as sis packages (for installation to a device).    Qt Mobility 1.1 for Symbian (Symbian^1 and Symbian^3).   N900 (Maemo) target allows development with Qt 4.7.   Qt Simulator uses Qt 4.7.1 and Qt 1.1.     The 1.1 release of the Qt SDK is particularly important because it marks the inclusion of Qt Quick/QML technology tooling for the first time. The Qt Quick Designer, part of the Qt Creator IDE, is a WYSIWYG editor, which allows for the rapid creation and iteration of QML based user interfaces, animations, transitions and other visual elements.  The Qt Labs blog notes that, in response to developer feedback, support for using native Symbian APIs has been improved. It is now possible to optionally enable the use of native Symbian APIs; this can be done via the installer or the maintenance tool. The SDK also updated the remote compiler functionality, allowing developers to use the updated version of this service with the Qt and Qt Mobility releases. The remote compiler allows developers to remotely compile their project on a remotely hosted server; this allows developers on Linux and Mac computers to more easily create applications that will run on Symbian devices. In addition, the recently announced Notifications API is now supported in experimental form. Developers should note that, while it is possible to deploy to development devices using the SDK, it is not possible to use it for production releases as Ovi Store will not accept these applications until the SDK goes final. The SDK is available for Microsoft Windows (XP SP2 or later), Linux (Ubuntu 8.04 or later) and Mac OS-X (10.6 or later) and can be downloaded from Forum Nokia. Bug reports can be filed on the Qt bug tracker. More details on the release are available on the Qt Labs blog.    Developer competitions Also of interest to Qt mobile developers are two recently announced competitions: The 'Qtest Mobile App Port' competition, which is offering a €10,000 prize for the best Qt app ported from the desktop to mobile. There are also 5 Nokia N900 phones in the prize pool. More details are available here.   Forum Nokia is running a competition to celebrate the release of the new SDK and encourage developers to explore QML technology. They are asking developers to create a new Forum Nokia Project (with a Qt Quick element) or add a new article (e.g. tutorial with code) to the Forum Nokia Wiki. The winners will receive a Nokia E7-00. More details are available here. Rafe Blandford, AAS, 20 Jan 2011 [Less]

Engadget reported today, via respected Finnish tech magazine Prosessori, that the Nokia N9 will launch with a 1.2GHz Atom processor. Even better news is that it could be announced at Mobile World Congress next month in Barcelona. Anyone else ... [More] getting excited? Nokia N9 leaked prototype Nokia does not appear to be in the MWC 2011 [...]Continue reading Nokia N9 to Launch with 1.2GHz Processor at Mobile World Congress? at The Nokia Blog [Less]

I stumbled across a website talking about GNOME 3 today, with a few screenshots. It's not really my first exposure to gnome-shell and friends, but it's the first time I sat down and really looked at it, and imagined myself trying to work with ... [More] it.(Disclaimer: I haven't actually tried GNOME 3 as a user yet. Thus, quite a lot of my opinions might be completely off the mark, but I'm not going to be biased by having actually used it.Disclaimer #2: I decided to write down my immediate thoughts, to offer ideas to people working on UI things as much as possible. I like to think that my ideas and points are good ones, but they are, at the end of the day, opinions. Please respect that.Disclaimer #3: I'm syndicating this entry on the basis that UI design is an interesting topic that doesn't get discussed all that often, please don't shoot me for going off-topic a little.)First of all, let's take a look at the 'banner' image.Good:Visually appealingNice contrasting coloursFairly consistent icons stylingAppealing widget stylingBad:The 'inactive' window isn't so visible. It needs to be subtle to not grab attention, but at the same time, not difficult to read.The icon under 'Image Viewer' is just weird. Why is it zoomed in? It's also, I imagine, going to be really bad for contrast. I would just remove that (and the "Image Viewer" text) from the bar entirely, it seems out of place.Why is the wifi icon not monochrome, like the rest? Use colours, or don't. Mixing them just leads to a mess.Next up, the overview image:Good:Pervasive search is a useful featureEasy to see what windows are openDistinctive use of contrast, very visually appealingBad:Why is there a wifi icon up the top, and another (or at least, what looks like one) down the bottom?Why does the search box have a caret visible with no text entered? That looks ugly.Websites get this right: guide text when nothing entered, not explicitly focused - but grab text if needed. Clear guide text when text is grabbed, or when focus is explicitly granted, add caret.What are the three boxes (two mostly transparent) at the bottom center?I presume this is some kind of pagination thing but that isn't immediately clear.Why does the central view have a scrollbar?Typical users don't have that many windows open; while I understand the need to scale to power users (the people presumably developing the environment), I don't think scrolling is a very nice mechanism to do it with.The left pane is appalling. So many ellipses.One thing that many modern UI implementations have done away with is text from the task bar, dock, whatever you want to call it, and this is a very good example of why that isn't such a bad idea.It's hard enough fitting the text in on a horizontal panel, but a vertical one has even less horizontal real-estate for horizontal text."Windows" and "Applications" look like they are made to switch state, but it isn't immediately obvious what they do. Will they function like tabs, and change the content of the center panel?"Activities" in top left seems to be a state switcher. I'm unsure if the naming is very descriptive of what it does. It could also use some mechanism to stand out more, if it will be used to switch windows a lot as this appears.The size of the captions of the windows seems to have a bug. Notice "Spiral_by_firas.jpg" has a lot more room on the right hand side than the left.The bottom right hand icon (next to the wifi icon) is really, really hard to figure out just by looking at.Next up, instant messaging.Good:I love integrated IM. It is one thing I adore about my Nokia N900, apart from Qt.The use of gradients to differentiate sender is intriguing, subtle, and I like itThe scrollbar is gentle, and beautifulBad:Why is the icon in Vincent's chat window the same as on the bar at the bottom? Why not use Vincent's avatar, or something.Why is there a large chunk of empty space on the left side of the chat dialog? I think it's quite unbalancing.The effect of having a zoomed icon (under "File Manager") still looks weird.The purpose of the bottom right is now more clear: it's a replacement for the system tray?Okay, I can go with that. Splitting system and applications makes some sense.I'm not sure if this is the best way to position and display it, though, and to me, I think IM almost belongs as part of the system, not in the application 'systray'.Lack of timestamps on the IM dialog is a little anoying.One interesting effect to minimise effect on dialog space might be to only timestamp conversations after a reasonable (>1-2 minute) delay with no conversation.And last, but by no means least...Good:Nifty integration of different types of thingsGood demonstration of searchBad:The problem of using text as opposed to icons once again rears its ugly head. This really needs fixing. So many ellipses.Searching for other things here might be nice. Open windows? A document I've been working on? My web history? People I talk to?How are items sorted? Alphabetically? Not sure that's a great idea.Giving them in some form of contextual usage (most often used, most recently used) would be a lot more useful. At least a favourite/'pin' option like the MeeGo netbook UI.Why on earth is 'wo' matching 'Chess', etc?Showing the number of items: reasonable.Displaying them on the right hand side of the screen, as far away from everything else as possible isn't so reasonable.I'd just not display it at all. It doesn't convey useful information that the user cannot distil by looking at the icons, if they really need to know how many items are in their boxes. [Less]