Hello Gerard! On Tue, 2010-06-22 at 04:22 +0100, [email protected] wrote: > By way of introduction, my name is Gerard Loughran and I am a senior > product manager at Nokia. My key responsibility is our Qt Mobility > program and the new APIs we are bringing to Qt developers. > I wanted to make this slightly formal introduction prior to involving > myself more on the lists.
Thanks for taking the time to introduce yourself. That's definitely useful. Using MeeGo as the main development platform is of course good news. FWIW, my own interest in QtMobility is primarily around PIM storage. As the author of SyncEvolution, I have worked with a variety of systems that handle PIM data - not just Evolution, as the name implies, but also Mac OS Addressbook, Akonadi, and now of course QtContacts and KCalExtended. Can you perhaps say a bit more about the QtMobility team's plan to add a calendar API? It is mentioned here http://qt.nokia.com/developer/qt-roadmap#calendar-api but without any further details. BTW, the link underneath for "How to contribute" leads to a "page not found" error. Is that meant to link to qt.gitorious.org? If you already have some API drafts for calendar, then I'd be interested to have a look at them. I could help review them. We also need a backend implementation for MeeGo. I have already been in touch with several of your colleagues in the QtContacts related projects. We are currently working towards including the latest code drops in MeeGo, see: http://bugs.meego.com/show_bug.cgi?id=2590 #qtcontacts-tracker on freenode is used to discuss issue live. For recording issues, as of today there is a component in bugs.meego.com for it, which also happens to be the first public bug tracker for qtcontacts-tracker, the main backend for QtContacts (at least in MeeGo): http://bugs.meego.com/enter_bug.cgi?product=OS%20Middleware&component=QtContacts There was some debate (http://bugs.meego.com/show_bug.cgi?id=3153) whether each individual component (QtMobility/Contacts, qtcontacts-tracker, ...) should get is own entry in the tracker. In the end we went for one component "QtContacts" because as a user of Bugzilla and of the API it is hard to tell the difference. Speaking of packaging QtMobility, there's one issue that was encountered in #2590 and also discussed recently here on the list ("Qt packaging"): what's the status of QtMultimedia? Qt and QtMobility provide conflicting (?) implementations of it. As Thiago pointed out, QtMultimedia is part of Qt and must stay there for API compatibility reasons. Is that the version of the API that applications should use until further notice? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
