Hi Robin, We thought that having an integer QContactLocalId is a bit too restricting. E.g. if you have a uuid as backend contact id (as the case is in JsonDb backend), it's lot simpler to treat it as a string than as an integer. Changing QContactLocalId to QString was the first step in trying to make contact ids a bit more flexible.
Another step towards that direction would be to hide the internal format of backend contact id by providing a wrapper class for backend ids. This pattern has been used in Organizer, see http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemengineid.h and http://qt.gitorious.org/qt/qtpim/blobs/master/src/organizer/qorganizeritemid.h. Any other ideas about how to make handling of backend contact ids both flexible and efficient are welcome. About source-compatibility... As a Qt5 AddOn module QtPim has little less restrictions regarding source-compatibility than Essential modules, see e.g. http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition. While we try not to break source-compatibility if it's not necessary, we also see moving from QtMobility to QtPim as a good opportunity to simplify QtPim APIs a bit and to make some other changes, which might be more difficult later. Some of the changes are already visible in qtpim repository, some are still in the planning phase. We will tell more about the changes and reasoning behind them in the near future. Br, Päivi -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext Robin Burchell Sent: 27. lokakuuta 2011 10:18 To: Knoll Lars (Nokia-MP-Qt/Oslo) Cc: [email protected] Subject: Re: [Development] Keep dependent projects in mind when approving changes Hi Lars, On Thu, Oct 27, 2011 at 8:21 AM, <[email protected]> wrote: > In addition, I'd like to be added as a reviewer for changes that break > source compatibility with the public API of Qt 4.x. Please also add > some comment in the changes file in this case. Following up on this, do you have any information about this source-incompatible change: http://lists.qt-project.org/pipermail/development/2011-October/000030.html Other reasons why I'd like this change justified: - It's also going to be a lot less efficient to have a QContactLocalId as a QHash key in Qt5 - QString keys are naturally less memory-efficient. BR, Robin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
