Re: [Development] Where is the QtLocation history?
On Fri, 27 Apr 2012 08:42:55 pm ext shane.kea...@accenture.com wrote: Not sure if it's what you're looking for, but some old history is in git://qt.gitorious.org/qt-mobility/qt-mobility.git in src/location. Not quite, the qt-mobility repository includes Qt Location source history which was imported into the Qt5 qtlocation repository in commit 336c5619c03cd338142f827ffcdaca855e35096c. On Fri, 27 Apr 2012 06:22:39 am ext Stephen Kelly wrote: I tried to help on this thread: http://thread.gmane.org/gmane.comp.lib.qt.user/1782 and found that most of the significant QtLocation history is squashed into a single commit 5f42e961560a54a2d3978b42478cd90bc8c6927d. That particular commit was the merging of the two development branches. Those branches included a lot of messy re-factoring and at the time it was decided that a squashed merge would be done. Cheers, -- Aaron McCarthy, Software Engineer Nokia, Qt Development Frameworks Level 1, 53 Brandl St, Brisbane Technology Park, Eight Mile Plains, QLD, Australia, 4113 http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On Apr 28, 2012, at 5:38 PM, ext John Layt wrote: Well I've tried doing this and ended up moving QCocoaPrinterSupport, QQMacPrintEngine and QCoreGraphicPaintEngine all into the the printsupport plugin as they are all only used by QtPrintSupport, and as the plugin returns the native QPrintEngine as its main purpose so it seems logical. Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa platform plugin to use classes/methods in QCocoaAutoReleasePool and QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and QtWidget both use these classes/methods as well, but I can't figure out how they are linking against the Cocoa plugin. Any hints on linking qtcocoa into cocoaprintersupport, or is that just not possible? That would be not possible. QtGui and Widgets loads the Cocoa backend as a plugin and does not link agains it. I think the only options are either duplicating the neccesary code to support QCoreGraphicsPaintEngine in printsupport, or let it live in the cocoa plugin and export it using QCocoaNativeInterface. I don't like duplicating code so we went with the latter approach. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing David Schulz as approver
On 20 Apr 2012, at 12:40, ext tobias.hun...@nokia.com wrote: Hello Everybody! David has been working hard on the Qt Creator editor functionality for the last months. For this reason I am proposing David Schulz as a approver in the Qt project. Seconded. -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtPrintSupport - Platform Support
On segunda-feira, 30 de abril de 2012 09.06.28, morten.sor...@nokia.com wrote: Unfortunately, QCoreGraphicsPaintEngine needs to link against the Cocoa platform plugin to use classes/methods in QCocoaAutoReleasePool and QCocoaHelpers, but I can't figure out how to do that in qmake. QtGui and QtWidget both use these classes/methods as well, but I can't figure out how they are linking against the Cocoa plugin. Any hints on linking qtcocoa into cocoaprintersupport, or is that just not possible? You can't link against a plugin. Looks like those classes should be in platformsupport instead. -- 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] Qt5 API change coming up: QObject::connectNotify(const char *) -- connectNotify(QMetaMethod)
On segunda-feira, 30 de abril de 2012 14.14.00, Kent Hansen wrote: Yes, it's late, but it's also one of the final nails in the const char *-based Q(Meta)Object introspection API coffin. [snip the rest] Needless to say, I support this change, even though SIC. So here's my maintainer stamp of approval for it. This is much cleaner than the previous implementation. -- 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] Qt5 API change coming up: QObject::connectNotify(const char *) -- connectNotify(QMetaMethod)
On 4/30/12 2:53 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 30 de abril de 2012 14.14.00, Kent Hansen wrote: Yes, it's late, but it's also one of the final nails in the const char *-based Q(Meta)Object introspection API coffin. [snip the rest] Needless to say, I support this change, even though SIC. So here's my maintainer stamp of approval for it. This is much cleaner than the previous implementation. +1 from my side as well (as discussed in private before). Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 API change coming up: QObject::connectNotify(const char *) -- connectNotify(QMetaMethod)
On segunda-feira, 30 de abril de 2012 14.53.49, Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 14.14.00, Kent Hansen wrote: Yes, it's late, but it's also one of the final nails in the const char *-based Q(Meta)Object introspection API coffin. [snip the rest] Needless to say, I support this change, even though SIC. So here's my maintainer stamp of approval for it. This is much cleaner than the previous implementation. BTW, I was about to suggest that QMetaMethod be passed by value. My investigations in the value of passing by value show that this class benefits from it. And it does. However, there's a catch: most QMetaMethod methods are non-inline. In order to call them, the compiler would need to spill the class to memory anyway. So there's no gain in passing by value, and it might even be worse because it needs to use more registers in the function call sequence. So the recommendation is: keep passing by const-ref. -- 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] When it coming about qbs plugin in Creator
It does not work. Show me a error message: Unknown property:qt.core.qtPath D:\qpSOFT\DEVx64qbs config --list local variables: global variables: defaults.platform: WinSDK7.1.7600.0.30514 modules.qbs.platform: WinSDK7.1.7600.0.30514 profile: qt4 profiles.qt4.qt.core.path: D:\qpSOFT\DEVx64\qt profiles.qt5.qt.core.path: D:\qpSOFT\DEVx64\qt5 profiles.qt5.qt.core.version: 5.0.0 D:\qpSOFT\DEVx64qbs platforms list Platforms: - WinSDK7.1.7600.0.30514 (default) Any commens? 2012/4/30 Joerg Bornemann joerg.bornem...@nokia.com Status of the thing is: It can - load a qbs project and display the project tree in the side bar - build a project - run a project -- Please don't ask where I come from, It's a shame! Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] D-Bus and (de-)marshalling of complex types (QDBusArgument)
On Thursday, April 26, 2012 12:19:14 Thiago Macieira wrote: On quinta-feira, 26 de abril de 2012 11.49.02, Alberto Mardegan wrote: Hi all! The current QtDBus implementation automatically marshals only the basic D-Bus types, and puts all the complex types into a QDBusArgument. Yeah, I called it the Pattern Buffer when I wrote that trick in 2006. Because I like Star Trek and I wanted a codename, since other technologies had them (Scribe, Interview, etc.). I've found a reason for this behaviour here: http://permalink.gmane.org/gmane.comp.freedesktop.dbus/5920 However, unless I'm missing something, this only explains why we cannot marshal for aggregate types (structures); we should still be able to marshal array and dictionary types. Not exactly... there are two reasons why this can't be done. The first is that QtDBus doesn't choose a container type for arrays and dictionaries. It works just fine with QList, QVector, QLinkedList, std::list, std::vector, etc. for arrays, as well as QHash, QMap, std::map, std::hash_map, std::unordered_map, etc. for dictionaries. It's up to the user of QtDBus to choose which one they want to use. The second is that each container is a different C++ type. QListint is wholly different from QListuint from C++'s perspective and from ours, even though they happen to have the exact same memory layout (which isn't true for other, more different types). We'd have to register as metatypes every single QList of the basic types, plus every single QMap of the permutations of possible basic type-dictionaries in D-Bus. So even if we don't include more complex types like arrays of arrays, arrays of dictionaries, dictionaries of arrays, we'd have 15 QList-types (including QStringList, QVariantList and QByteArray), 12 * 14 QMap types (including QVariantMap). I'm not going to register 179 types at QtDBus start up -- that's twice as many types than a typical Qt application has today, including the builtins! Still, QtDBus *does* register the basic QList types for convenience. And I suppose we can add some convenience elsewhere too. I've seen many projects that need to force an inclusion of a Q_DECLARE_METATYPE(QListint) to their generated C++ sources. Note that that will no longer be needed with Qt 5. You don't need to declare QListT as a metatype if T is a metatype (but you would still need to register it). This recurses too: https://codereview.qt- project.org/#patch,unified,24588,1,tests/auto/corelib/kernel/qmetatype/tst_qmetatype_compiletest.cpp Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] Deprecation warnings are enabled
On sexta-feira, 27 de abril de 2012 23.02.58, Thiago Macieira wrote: Just a notice to all devs: Since 0df1c9f1fa04c06d6105de3f312c6c752a58ad70 integrated on Wednesday, all Qt modules have deprecation warnings enabled now. That means that when you build your module, you'll get warnings about your using of deprecated classes or function. You should not ignore them. You should use the replacement functions / classes. The next step is to disable the deprecated methods. The change will be: https://codereview.qt-project.org/#change,24890 I will remove the WIP and stage that change in about two or three weeks, but before the beta. All uses of deprecated methods must be fixed by that date. -- 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] Deprecation warnings are enabled
On 30 April 2012 15:07, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 27 de abril de 2012 23.02.58, Thiago Macieira wrote: Just a notice to all devs: Since 0df1c9f1fa04c06d6105de3f312c6c752a58ad70 integrated on Wednesday, all Qt modules have deprecation warnings enabled now. That means that when you build your module, you'll get warnings about your using of deprecated classes or function. You should not ignore them. You should use the replacement functions / classes. The next step is to disable the deprecated methods. The change will be: https://codereview.qt-project.org/#change,24890 I will remove the WIP and stage that change in about two or three weeks, but before the beta. All uses of deprecated methods must be fixed by that date. Which brings me to the question: is QRegExp going to be deprecated entirely in 5.0? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On 4/30/12 4:10 PM, ext Giuseppe D'Angelo dange...@gmail.com wrote: On 30 April 2012 15:07, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 27 de abril de 2012 23.02.58, Thiago Macieira wrote: Just a notice to all devs: Since 0df1c9f1fa04c06d6105de3f312c6c752a58ad70 integrated on Wednesday, all Qt modules have deprecation warnings enabled now. That means that when you build your module, you'll get warnings about your using of deprecated classes or function. You should not ignore them. You should use the replacement functions / classes. The next step is to disable the deprecated methods. The change will be: https://codereview.qt-project.org/#change,24890 I will remove the WIP and stage that change in about two or three weeks, but before the beta. All uses of deprecated methods must be fixed by that date. Which brings me to the question: is QRegExp going to be deprecated entirely in 5.0? No. It's simply not doable to fix all it's usages. Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On sexta-feira, 27 de abril de 2012 23.02.58, Thiago Macieira wrote: You should not ignore them. You should use the replacement functions / classes. One more thing: if you see a qMalloc, qRealloc or qFree in a public header, please move the code to a .cpp. Or at least leave a // ### FIXME so we can fix it. -- 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] When it coming about qbs plugin in Creator
On 30/04/2012 15:52, ext Loaden wrote: It does not work. Show me a error message: Unknown property:qt.core.qtPath When building it's still using the old property names. Any commens? Yes. Be patient. Jörg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hug...@nokia.com wrote: Seriously? What about my comment (plea) to revert the change that enabled these warnings? As I mentioned before (and others in my team), these warnings are hurting more than helping, and our time is much better spent working on the desktop platform plugins than fixing warnings. Please, I hope you will reconsider, there's much more important things to be done. I'm not against postponing them. Really, if you need more time, then it's completely understandable and we should give you more time. I could certainly use more time because I have two high-importance tasks to do that need to be done in 5.0, plus maybe looking into QList. I'm acting on the belief that this is a beta-blocker task. If it is and you need more time, then we may have to delay the beta too. Or, I am mistaken and it is not a beta-blocker. I've already spent almost a week getting the QRegExp const change done because it seemed like the right thing to do and required for the beta. Given the choice, I wouldn't have spent any time on it. And I have a couple more tasks assigned to me that seem to be required for the beta, but I'll happily leave them for later instead. -- 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] Deprecation warnings are enabled
On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hug...@nokia.com wrote: Seriously? What about my comment (plea) to revert the change that enabled these warnings? As I mentioned before (and others in my team), these warnings are hurting more than helping, and our time is much better spent working on the desktop platform plugins than fixing warnings. Please, I hope you will reconsider, there's much more important things to be done. I'm not against postponing them. Really, if you need more time, then it's completely understandable and we should give you more time. I could certainly use more time because I have two high-importance tasks to do that need to be done in 5.0, plus maybe looking into QList. More time is something that we would all like, but it's not always realistic. My argument here is about how we effectively use our time. Given the average turn around time of CI, and the complexity that arises from maintaining multiple unrelated changes on-top of master, I think we're doing harming ourselves more than helping. When faced with two options, 1) fix deprecated warnings or 2) continue work to restore Qt 4 behavior in the platform plugins, I'm going to say we should be doing 2) and not do 1) at all (since there will be disruptions and distractions because of it). I'm acting on the belief that this is a beta-blocker task. If it is and you need more time, then we may have to delay the beta too. Or, I am mistaken and it is not a beta-blocker. I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left. I've already spent almost a week getting the QRegExp const change done because it seemed like the right thing to do and required for the beta. Given the choice, I wouldn't have spent any time on it. And I have a couple more tasks assigned to me that seem to be required for the beta, but I'll happily leave them for later instead. Likewise, I spent most of the day getting Qt Creator compiling again after the QRegExp change (instead of working on the QPA API changes that we need). Granted, not a week like you spent, but the point here is the interruption. Like you, I wouldn't have done the QRegExp changes given a choice, but when the stuff lands in master, we have no choice: drop what you were doing and fix the breakages instead. Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them). -- Bradley T. Hughes bradley.hug...@nokia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] API review - proposed renaming of QAbstractSocket::PauseOnNotify to PauseOnSslErrors
https://codereview.qt-project.org/24905 Although we created an enum for pause modes to make 5.x binary compatible with 5.0, the enum value is not well named. In 5.1, we propose to add PauseOnProxyAuthentication to the enum. PauseOnNotify is not clear what it means, while PauseOnSslErrors is. Any new notification in a minor release would need a new enum value otherwise applications would get pauses they did not expect. This is a new API in 5.0 so the change would be source incompatible with the alpha release, but not with any 4.x releases. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On segunda-feira, 30 de abril de 2012 17.57.46, bradley.hug...@nokia.com wrote: When faced with two options, 1) fix deprecated warnings or 2) continue work to restore Qt 4 behavior in the platform plugins, I'm going to say we should be doing 2) and not do 1) at all (since there will be disruptions and distractions because of it). Of course. It doesn't have to be you. I'm hoping that someone will, though. Fixing deprecation warnings is usually a task that many new-comer contributors can do and would be a great way for them to gain experience in developing Qt. I'm acting on the belief that this is a beta-blocker task. If it is and you need more time, then we may have to delay the beta too. Or, I am mistaken and it is not a beta-blocker. I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left. Indeed. Though I expect that we will only release if we have something we can be proud of. A brown-paper bag release that just inflames even more the community will do us no good. That's a subjective determination though. Still, I meant my own task: since these are API-level considerations, I was and still am under the impression that they are needed by beta time. Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them). Though it has just occurred to me that we have a way to accomplish both of our objectives: it's possible to make the Qt API clean for users by the beta release, yet not affect much of our internals. All I need to do is change the default in qglobal.h, like I've done, but ensure that all of Qt, including examples, is still compiled with 4.9 API. -- 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] Deprecation warnings are enabled
On Monday 30 April 2012 17:57:46 bradley.hug...@nokia.com wrote: On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hug...@nokia.com wrote: Seriously? What about my comment (plea) to revert the change that enabled these warnings? As I mentioned before (and others in my team), these warnings are hurting more than helping, and our time is much better spent working on the desktop platform plugins than fixing warnings. In which modules are all those warnings? For me, qtbase and few other modules compiles fine, without deprecated methods. Is it in a platform plugin? In that case, you may want to disable deprecated warnings in that plugin only. [...] I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left. Well, it is fine to disable the warnings only for the areas that you think can still use the deprecated method. I've already spent almost a week getting the QRegExp const change done because it seemed like the right thing to do and required for the beta. Given the choice, I wouldn't have spent any time on it. And I have a couple more tasks assigned to me that seem to be required for the beta, but I'll happily leave them for later instead. Likewise, I spent most of the day getting Qt Creator compiling again after the QRegExp change (instead of working on the QPA API changes that we need). Granted, not a week like you spent, but the point here is the interruption. That QRegExp change is unrelated. Personaly I think that changes break source compatibility for little gain. But now it's there. Peraps we could add back the const overload, but as deprecated? [...] Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them). Would it be ok for you to just enable the proper flags in the relevent platform plugin .pro in order to get rid of those warnings? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On Apr 30, 2012, at 8:43 PM, ext Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 17.57.46, bradley.hug...@nokia.com wrote: When faced with two options, 1) fix deprecated warnings or 2) continue work to restore Qt 4 behavior in the platform plugins, I'm going to say we should be doing 2) and not do 1) at all (since there will be disruptions and distractions because of it). Of course. It doesn't have to be you. I'm hoping that someone will, though. Fixing deprecation warnings is usually a task that many new-comer contributors can do and would be a great way for them to gain experience in developing Qt. But you're missing my point. I don't think anyone should be doing them. I don't think now is the time to have a lot of low-hanging fruit changes being pushed into to all the modules. I'm acting on the belief that this is a beta-blocker task. If it is and you need more time, then we may have to delay the beta too. Or, I am mistaken and it is not a beta-blocker. I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left. Indeed. Though I expect that we will only release if we have something we can be proud of. A brown-paper bag release that just inflames even more the community will do us no good. That's a subjective determination though. The amount of changes going into Qt 5 is certainly enough to be proud of, but there will be feature and behavior regressions on the desktop platforms, there's no avoiding that. We want to close that gap as much as possible, but disruptions will slow us down. Still, I meant my own task: since these are API-level considerations, I was and still am under the impression that they are needed by beta time. I'm not sure what you mean by this. Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them). Though it has just occurred to me that we have a way to accomplish both of our objectives: it's possible to make the Qt API clean for users by the beta release, yet not affect much of our internals. All I need to do is change the default in qglobal.h, like I've done, but ensure that all of Qt, including examples, is still compiled with 4.9 API. This option might work, but again I have to ask: why do anything at all? Doing nothing and keeping things as-is is an option as well, is it not? Why add entropy to the system? -- Bradley T. Hughes bradley.hug...@nokia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On Apr 30, 2012, at 8:50 PM, ext Olivier Goffart wrote: On Monday 30 April 2012 17:57:46 bradley.hug...@nokia.com wrote: On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hug...@nokia.com wrote: Seriously? What about my comment (plea) to revert the change that enabled these warnings? As I mentioned before (and others in my team), these warnings are hurting more than helping, and our time is much better spent working on the desktop platform plugins than fixing warnings. In which modules are all those warnings? I see warnings in all Qt modules. For me, qtbase and few other modules compiles fine, without deprecated methods. Interesting, I will have to rebuild and see what warnings are still remaining. Last I saw, there were several hundred new warnings for qtbase alone. Is it in a platform plugin? In that case, you may want to disable deprecated warnings in that plugin only. It is all of Qt. [...] I've always been under the impression that the desktop platform plugins won't block any release. The state they are in at release time is the state they are in… we will be constantly fixing and implementing both up to and and well beyond the 5.0 release. Postponing isn't feasible because it's impossible to say how much time is left. Well, it is fine to disable the warnings only for the areas that you think can still use the deprecated method. This doesn't help. The deprecated warnings from rebuilding most of Qt after changing the QPA API have been drowning out the real warnings. This may have changed recently, mind you, lots of stuff went in over the weekend. I will have to double-check on Wednesday. I've already spent almost a week getting the QRegExp const change done because it seemed like the right thing to do and required for the beta. Given the choice, I wouldn't have spent any time on it. And I have a couple more tasks assigned to me that seem to be required for the beta, but I'll happily leave them for later instead. Likewise, I spent most of the day getting Qt Creator compiling again after the QRegExp change (instead of working on the QPA API changes that we need). Granted, not a week like you spent, but the point here is the interruption. That QRegExp change is unrelated. Unrelated how? It was a disruption. I spent most of my day fixing Qt Creator after that change landed in qtbase. Personaly I think that changes break source compatibility for little gain. But now it's there. I agree. I was considering reverting the change at one point instead of having to change Qt Creator. Peraps we could add back the const overload, but as deprecated? Too late now. Change is already in qtbase and Qt Creator. Time has already been spent. Nothing we can do about that now. [...] Summing up, this is what I'm afraid of: we're going to end up wasting a lot of time fixing things that are in the way, not because they are important right now (note that I'm not saying they are unimportant altogether, just that there other things trump them). Would it be ok for you to just enable the proper flags in the relevent platform plugin .pro in order to get rid of those warnings? No, I'm not rebuilding just the platform plugin(s), this has to do with all of qtbase (mostly). I will double check this though, since things are constantly changing everyday. The situation may have improved (but that doesn't change my position, which is that we should not be worrying about compiler warnings when the platform plugins need much more work). -- Bradley T. Hughes bradley.hug...@nokia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On Monday 30 April 2012 19:55:25 lars.kn...@nokia.com wrote: On 4/30/12 9:07 PM, ext bradley.hug...@nokia.com bradley.hug...@nokia.com wrote: On Apr 30, 2012, at 8:50 PM, ext Olivier Goffart wrote: On Monday 30 April 2012 17:57:46 bradley.hug...@nokia.com wrote: On Apr 30, 2012, at 7:19 PM, ext Thiago Macieira wrote: On segunda-feira, 30 de abril de 2012 16.58.08, bradley.hug...@nokia.com wrote: Seriously? What about my comment (plea) to revert the change that enabled these warnings? As I mentioned before (and others in my team), these warnings are hurting more than helping, and our time is much better spent working on the desktop platform plugins than fixing warnings. In which modules are all those warnings? I see warnings in all Qt modules. For me, qtbase and few other modules compiles fine, without deprecated methods. Interesting, I will have to rebuild and see what warnings are still remaining. Last I saw, there were several hundred new warnings for qtbase alone. I think most of them were related to qimage.h producing warnings (unless you were using gcc 4.6 or 4.7). Ah, that could be.. then those will dispear when we start to build without deprecated function I suppose. Peraps we could add back the const overload, but as deprecated? Too late now. Change is already in qtbase and Qt Creator. Time has already been spent. Nothing we can do about that now. Agree that it's to late for this change. It is not too late. When we do a SIC change in the public API, the proplem we have within qt- project are not our main concern. The bigger concern is all the customers using it. They need to do it all at once, and they have a lesser knoweldge about the required changes than we. So we can still make it less intrusive for others. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5.0 beta and final timelines
Hi everybody, While I think it's very important to get Qt 5.0 out of the door as soon as possible, we should not release it without first getting it's quality to a very high standard. I think it has become rather clear that the original timeline of releasing Qt 5.0 by mid June is not doable anymore. There's still a lot of work to be done. I'll mention the three big items I see that are currently blocking us: * Get binary packages/installers working I'd like to see daily binary snapshots of Qt 5 that people can test for Windows, Mac and Linux. These need to be available when we start beta testing. We need to get daily source packages that actually build on all platforms even earlier than that. * Finish the documentation modularization This is progressing nicely, and the basic infrastructure is now in place for it. Currently we have modularized docs for QtCore, QtXml and QtSql. Try it out yourself by cd'ing into qtbase/src/corelib and running 'make docs'. You will see that there are still quite some warnings produced by qdoc, and this is a place where everybody can help. Casper will help us here to finish the modularization in qtbase, but we will then have some more work to do to get all other modules that are part of Qt Essentials into the same shape. * Further improve our platform plugins on Win, Mac and Linux Qt Creator runs against Qt 5 on all platforms, but there certainly are still more than enough bugs and glitches in the implementations. This will require some more focus and time to get into a more polished state. Please start looking for regressions compared to Qt 4.x on these platforms and actively use our bug tracker to report them. Another good area for testing is trying to port existing Qt 4.x apps over to Qt 5. Let's try to consolidate feedback on how it went on the wiki and actual bugs found while porting in the bug tracker. Bug wise things currently aren't looking to bad and numbers are starting to go down, and we are also getting our auto tests in shape with a lot less disabled/insignificant tests than what we had a couple of weeks ago. To accommodate for that I propose that we now rather accept a delay in our release schedules and work towards a new timeline that I believe we can meet. I'd like to aim for having the first beta (with a hard API freeze) our by the contributor summit. Depending on the feedback we will then add a second beta beginning of August and aim for a final release sometime mid to end of August. In the meantime we can/should think about doing another alpha. Thiago proposed that one option here could be to simply release the first source package that works on all platforms as the second alpha. Like that we don't use any additional resources and time on creating that second alpha. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecation warnings are enabled
On segunda-feira, 30 de abril de 2012 22.36.41, Olivier Goffart wrote: I think most of them were related to qimage.h producing warnings (unless you were using gcc 4.6 or 4.7). Ah, that could be.. then those will dispear when we start to build without deprecated function I suppose. Unfortunately, for the qimage.h case, the warning was there *because* qimage.h used the deprecated functions it defined itself. It was a constructor of a deprecated type, but we of course had to use the type somewhere. Lars fixed it properly by introducing a private and non-deprecated constructor that the deprecated code can use without triggering the warning. It's a much cleaner solution than the long pragma sections to disable the warning. That's why he gets the big bucks. I wish I had thought of that solution :-) -- 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] Deprecation warnings are enabled
On Monday 30 April 2012 21:34:45 lorn.pot...@nokia.com wrote: On 01/05/2012, at 12:07 AM, ext Thiago Macieira wrote: On sexta-feira, 27 de abril de 2012 23.02.58, Thiago Macieira wrote: Just a notice to all devs: Since 0df1c9f1fa04c06d6105de3f312c6c752a58ad70 integrated on Wednesday, all Qt modules have deprecation warnings enabled now. That means that when you build your module, you'll get warnings about your using of deprecated classes or function. You should not ignore them. You should use the replacement functions / classes. The next step is to disable the deprecated methods. The change will be: https://codereview.qt-project.org/#change,24890 I will remove the WIP and stage that change in about two or three weeks, but before the beta. Any way the warnings could include some kind of hint to what _should_ be used instead? That would be quite difficult. Thinking about it, i would maybe do it like this: QT_DEPRECATED void setOldString(const QString oldString, class use_setNewString_instead *=0); (But this trick cannot be used in a minor release as it changes the function signature) I donn't think it is worth it. The best way it to go have a look at the docs. And docs should include replacement info on any depreciated function. Yes they should :-) In general they do. If they don't feel free to fix it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QDBus on Windows
Hi, On 30 Apr 2012 00:17:53 +0200, Andreas Holzammer wrote: Installer can be found here: http://qt.gitorious.org/installer-framework Packaging of Qt5 is public in QtRepotools http://qt.gitorious.org/qt/qtrepotools In the subdirectory release-tools. But Qt4 is not published, if I got the right information. thank you for your information. However, that won't help me until Qt5 is around. Am 29.04.2012 23:37, schrieb Wolfgang Baron: Could the Qt project please: 1) include QDBus in the distribution 2) publish the exact procedure how to create Qt as being distributed is this the right list at all? Could anybody please tell me, whether inclusion is on its way or why it is not being worked on? Also, some information about the exact configuration options of the release could be very helpful for compiling stuff like QtCreator, QtCreator plugins, QDBus and other stuff with partial private information of the Qt Sources. If this is not the right list to ask questions like these, where should I ask then? Kind regards, Wolfgang Baron ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Poll] Which direction should Qt Quick 2.x development take?
I also want to highlight the upcoming Qt Contributor Summit (June 21-23, Kalkscheune, Berlin, Germany), which is the perfect environment for Qt 5.1 discussion. (It's why we have the event in the first place.) More details here http://qt-project.org/groups/qt-contributors-summit-2012/wiki -- .marius -Original Message- From: development-bounces+marius.storm-olsen=nokia.com@qt- project.org [mailto:development-bounces+marius.storm- olsen=nokia@qt-project.org] On Behalf Of Alpert Alan (Nokia- MP/Brisbane) Sent: Monday, April 30, 2012 9:02 PM To: development@qt-project.org Subject: Re: [Development] [Poll] Which direction should Qt Quick 2.x development take? On Tue, 1 May 2012 06:50:55 ext Davet Jacques wrote: Hi fellow Qt users, spread across various comment threads at the Qt developer forum, Qt Labs blogs, and Qt mailing lists, there has recently been quite a bit of discussion over the scope and priorities of Qt Quick, and whether or not Nokia's (and the other Qt contributor's) roadmap, focus and design choices align with the needs and preferences of the majority of Qt users. So I thought it might be interesting for everyone to get an overview over where exactly Qt users as a whole (or at least those who are active in Qt's online communities) would prefer Qt Quick 2.x to go (or not go) in the near- or mid-term future. So there is now a corresponding poll (link at the bottom of this mail) hosted at the Qt Developer forum. Completely unofficial, but still worthwhile I think. For those interested in the path forward for actively prioritizing or developing these features, I've replied in devnet with some notes on each. Link to the poll: http://qt-project.org/forums/viewthread/16693/ -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks ___ 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
