Re: [Development] QLatin1Constant and QtContacts / QtOrganizer
Hi, We're actually removing the usage of QLatin1Constant in QtContacts, QtOrganizer, and QtVersit. It's copied just as a temporary solution during the modularization of these modules. Xizhi Zhu (Steven) Software Engineer @ Qt Development Frameworks Nokia Mobile: +358 (0)50 480 1247 From: development-bounces+xizhi.zhu=nokia@qt-project.org [development-bounces+xizhi.zhu=nokia@qt-project.org] on behalf of ext Mathias Hasselmann [math...@openismus.com] Sent: Tuesday, December 20, 2011 12:08 AM To: Knoll Lars (Nokia-MP/Oslo) Cc: development@qt-project.org; Rose Todd (Nokia-M/Alpharetta) Subject: Re: [Development] QLatin1Constant and QtContacts / QtOrganizer Am Montag, den 19.12.2011, 19:18 + schrieb lars.kn...@nokia.com: > On 12/14/11 11:01 AM, "ext todd.r...@nokia.com" > wrote: > > >I'm in the early stages of trying to port a Qt4.7 app that uses > >qt-mobility to Qt5. Today I noticed compile errors caused by the > >duplication of qlatin1constant.h in both of these > > modules. > > > >The problem shows when you write an app that uses both the QtContacts and > >the QtOrganizer modules. Headers within the QtContacts module will > >sometimes include the QtOrganizer version of qlatin1constant.h (or > >vice-versa depending on the app's include path > > ordering). The use of namespaces in these headers is what leads to the > >errors. > > > >There's several solutions, and I guess it'd be best if the > >QLatin1Constant functionality was moved to a core library, but until then > >can we at least have the headers *within* the Contacts and Organizer > >modules include qlatin1constant.h in an unambiguous manner? > > I'm actually wondering whether this class still makes sense in Qt 5. We've > done some changes to QLatin1String to make it more suitable and have > QStringLiteral in addition. That should make the need for this class > mostly go away IMO. +1 - QLatin1String is painful to use: You cannot really store references to it, you constantly get trouble from C++ not being able to resolve which of its cast operators shall be used (QString vs. QLatin1String). Also I never really got is purpose: To enable comparison and hashing of QtContact's string keys, and to make sure those strings don't waste memory on heap, it would have been sufficient to use QString:: fromRawData() to initialize those constants. Ciao, Mathias -- Mathias Hasselmann http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLatin1Constant and QtContacts / QtOrganizer
Am Montag, den 19.12.2011, 19:18 + schrieb lars.kn...@nokia.com: > On 12/14/11 11:01 AM, "ext todd.r...@nokia.com" > wrote: > > >I'm in the early stages of trying to port a Qt4.7 app that uses > >qt-mobility to Qt5. Today I noticed compile errors caused by the > >duplication of qlatin1constant.h in both of these > > modules. > > > >The problem shows when you write an app that uses both the QtContacts and > >the QtOrganizer modules. Headers within the QtContacts module will > >sometimes include the QtOrganizer version of qlatin1constant.h (or > >vice-versa depending on the app's include path > > ordering). The use of namespaces in these headers is what leads to the > >errors. > > > >There's several solutions, and I guess it'd be best if the > >QLatin1Constant functionality was moved to a core library, but until then > >can we at least have the headers *within* the Contacts and Organizer > >modules include qlatin1constant.h in an unambiguous manner? > > I'm actually wondering whether this class still makes sense in Qt 5. We've > done some changes to QLatin1String to make it more suitable and have > QStringLiteral in addition. That should make the need for this class > mostly go away IMO. +1 - QLatin1String is painful to use: You cannot really store references to it, you constantly get trouble from C++ not being able to resolve which of its cast operators shall be used (QString vs. QLatin1String). Also I never really got is purpose: To enable comparison and hashing of QtContact's string keys, and to make sure those strings don't waste memory on heap, it would have been sufficient to use QString:: fromRawData() to initialize those constants. Ciao, Mathias -- Mathias Hasselmann http://openismus.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QtWebkit from gerrit (& qt5.git)
On 12/15/11 3:53 PM, "ext lars.kn...@nokia.com" wrote: > >On 12/12/11 6:21 PM, "ext Robin Burchell" wrote: > >>On Thu, Dec 8, 2011 at 12:20 AM, Rohan McGovern >> wrote: >>> Unfortunately the qtwebkit pointed at by qt5.git is outdated and known >>> not to work. >> >>Given that webkit is developed upstream inside webkit.org, I'd second >>that there's no reason having it there, aside perhaps from CI, though >>AFAIK they have their own infrastructure for this. >> >>As qtwebkit adds hugely to cloning qt5 (unless you remember to disable >>it), as well as the frequent build problems for people new to Qt 5 >>etc, is there any real objection to it being removed? Who can make >>that decision (I guess Lars?), and who would handle doing that? > >I don't have any fundamental issues with removing it, but would like to >hear some comments from people working on QtWebKit. Simon, any comments >from your side? Actually we can't easily remove it, as qttools (assistant) depends upon it. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLatin1Constant and QtContacts / QtOrganizer
On 12/14/11 11:01 AM, "ext todd.r...@nokia.com" wrote: >I'm in the early stages of trying to port a Qt4.7 app that uses >qt-mobility to Qt5. Today I noticed compile errors caused by the >duplication of qlatin1constant.h in both of these > modules. > >The problem shows when you write an app that uses both the QtContacts and >the QtOrganizer modules. Headers within the QtContacts module will >sometimes include the QtOrganizer version of qlatin1constant.h (or >vice-versa depending on the app's include path > ordering). The use of namespaces in these headers is what leads to the >errors. > >There's several solutions, and I guess it'd be best if the >QLatin1Constant functionality was moved to a core library, but until then >can we at least have the headers *within* the Contacts and Organizer >modules include qlatin1constant.h in an unambiguous manner? I'm actually wondering whether this class still makes sense in Qt 5. We've done some changes to QLatin1String to make it more suitable and have QStringLiteral in addition. That should make the need for this class mostly go away IMO. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On 12/16/11 10:10 PM, "ext morten.sor...@nokia.com" wrote: > >On Dec 16, 2011, at 1:37 PM, ext Jonas M. Gastal wrote: > >> On Friday 16 December 2011 08:40:24 morten.sor...@nokia.com wrote: >>> I think staggering of feature integrations is a very good idea in >>>general. >>> Qt 5.0 is a special case since we are looking at features that cannot >>>be >>> done for 5.1 due to BC reasons. >>> >>> Changing the topic slightly, what if we removed the need for common >>>feature >>> freezes? >>> >>> In the Chrome release process a new release cycle starts every 6 >>>weeks, and >>> both features and bug fixes are eligible. The release process consists >>>of >>> several channels that the release propagates through: new code spends >>>6+6 >>> weeks of testing and stabilization in Dev and Beta before being >>>released in >>> the Stable channel. (The channels overlap: there is always a release >>>in the >>> Beta channel for example.) >>> >>> This would remove the pressure to get a feature done in time for a >>>release. >>> If you miss a release cycle a new one starts 6 weeks later - no big >>>deal. >>> It also means that already finished features can be released in a >>>timely >>> manner and are not held up by other unfinished features that need to go >>> into the same release. >>> >>> Removing the difference between feature and patch releases is certainly >>> something we have to think carefully about, but I do think that the >>> benefits of having a "clockwork" release model wold be a benefit to Qt >>>as >>> it becomes an open project. >>> >>> (Presentation on the Chrome Release Cycle: >>> https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch) >>> >>> Morten >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> I don't see how to do that without breaking the source and binary >> compatibility promises, which I think are very important. > >Well, yes and no. If every release is a (potential) feature release you >do lose the ability to move to an earlier release without recompiling >(forward BC). I don't see any reason why backward BC and source >compatibility should be broken. IMO there is another problem with this. We'll get too many feature releases, making it hard for developers to keep track of the feature set that's available. In addition, it's difficult to implement that model until you reach a very high coverage with automated tests, as the 6 weeks don't leave you a lot of time for regression testing. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QLatin1Constant and QtContacts / QtOrganizer
I'm in the early stages of trying to port a Qt4.7 app that uses qt-mobility to Qt5. Today I noticed compile errors caused by the duplication of qlatin1constant.h in both of these modules. The problem shows when you write an app that uses both the QtContacts and the QtOrganizer modules. Headers within the QtContacts module will sometimes include the QtOrganizer version of qlatin1constant.h (or vice-versa depending on the app's include path ordering). The use of namespaces in these headers is what leads to the errors. There's several solutions, and I guess it'd be best if the QLatin1Constant functionality was moved to a core library, but until then can we at least have the headers *within* the Contacts and Organizer modules include qlatin1constant.h in an unambiguous manner? Maybe something like: #include "../QtContacts/qtlatin1constant.h" rather than the include-path-sensitive: #include BR, -Todd ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Monday, 19 de December de 2011 09.40.44, David Faure wrote: > > What should this do for something like 4.8.0c? Better to not confuse > > things > > and to leave the version number as it was. In practice, I'd be surprised > > if > > there was much confusion caused by Digia supplying a customised 4.8.0 > > which > > includes just fixes. If people are using Digia's 4.8.0 version, I suspect > > they are also likely to report bugs they find to Digia instead of to the > > general Qt bug tracker anyway. > > I disagree. > They will post questions to forums, to consultants, on blog posts, etc. etc. Anyone may produce a "vendor branch" and release it, so long as they clearly mark it as a patched version of the official Qt. "Qt Commercial 4.8.0" sounds to me like it's clearly marked. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
> From: David Faure >To: craig.sc...@csiro.au >Cc: development@qt-project.org >Sent: Monday, December 19, 2011 3:40 AM >Subject: Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version > >On Saturday 17 December 2011 09:01:35 craig.sc...@csiro.au wrote: >> On 16/12/2011, at 10:37 PM, David Faure wrote: >> > On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: >> >> So now there is total of 108 improvements and bug fixes available in Qt >> >> Commercial 4.8.0 that are not part of the LGPL release. >> > >> > While I understand the reasons, I want to state that this is going to make >> > support a mess. >> > >> > Both versions are called 4.8.0, but do not contain the same code. >> > >> > So when someone says "With Qt-4.8.0 I have the following issue", it will >> > never be clear which 4.8.0 this is about, we'll have to educate everyone >> > to say in addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't >> > the version number be different, when the code is different, instead? >> > E.g. 4.8.0c. That doesn't fit into the numerical QT_VERSION, but at least >> > qmake -query and every other location which shows a qt version number >> > (packages, qt creator, etc.) would show clearly 4.8.0c instead of 4.8.0. >> >> I'd actually prefer to *not* see fiddling with the version number format. >> That would just make it harder when creating automated scripts to build >> things and it can also break code that expects the Qt version number to be >> in the long established x.y.z form. Consider the common (recommended?) way >> to test for Qt versions in code: >> >> #if QT_VERSION > 0x040800 >> // >> #endif > >As I said, this doesn't affect QT_VERSION. > >I'm only talking about the string representation of the Qt version. > >> What should this do for something like 4.8.0c? Better to not confuse things >> and to leave the version number as it was. In practice, I'd be surprised if >> there was much confusion caused by Digia supplying a customised 4.8.0 which >> includes just fixes. If people are using Digia's 4.8.0 version, I suspect >> they are also likely to report bugs they find to Digia instead of to the >> general Qt bug tracker anyway. > >I disagree. >They will post questions to forums, to consultants, on blog posts, etc. etc. > I'd still agree that we should leave the Version number alone. And suggest two things: 1. Digia could add a secondary QT_COMMERCIAL definition to simply let people know the version they are using is the commercial version. 2. Places that show the Qt Version could use the QT_COMMERCIAL definition to add "Commercial" text or however else they want to show it. If Digia adds functionality - other than bug fixes - then it should probably be wrapped by #1 as well in case people want to build without it from the commercial source. It could piggy back on the license selection in configure for simplicity. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
On Saturday 17 December 2011 09:01:35 craig.sc...@csiro.au wrote: > On 16/12/2011, at 10:37 PM, David Faure wrote: > > On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote: > >> So now there is total of 108 improvements and bug fixes available in Qt > >> Commercial 4.8.0 that are not part of the LGPL release. > > > > While I understand the reasons, I want to state that this is going to make > > support a mess. > > > > Both versions are called 4.8.0, but do not contain the same code. > > > > So when someone says "With Qt-4.8.0 I have the following issue", it will > > never be clear which 4.8.0 this is about, we'll have to educate everyone > > to say in addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't > > the version number be different, when the code is different, instead? > > E.g. 4.8.0c. That doesn't fit into the numerical QT_VERSION, but at least > > qmake -query and every other location which shows a qt version number > > (packages, qt creator, etc.) would show clearly 4.8.0c instead of 4.8.0. > > I'd actually prefer to *not* see fiddling with the version number format. > That would just make it harder when creating automated scripts to build > things and it can also break code that expects the Qt version number to be > in the long established x.y.z form. Consider the common (recommended?) way > to test for Qt versions in code: > > #if QT_VERSION > 0x040800 > // > #endif As I said, this doesn't affect QT_VERSION. I'm only talking about the string representation of the Qt version. > What should this do for something like 4.8.0c? Better to not confuse things > and to leave the version number as it was. In practice, I'd be surprised if > there was much confusion caused by Digia supplying a customised 4.8.0 which > includes just fixes. If people are using Digia's 4.8.0 version, I suspect > they are also likely to report bugs they find to Digia instead of to the > general Qt bug tracker anyway. I disagree. They will post questions to forums, to consultants, on blog posts, etc. etc. -- David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
