Re: [Development] [Releasing] Including QTimeZone in Qt 5.1
On Wednesday 27 Feb 2013 13:49:48 Thiago Macieira wrote: On quarta-feira, 27 de fevereiro de 2013 20.57.22, John Layt wrote: Currently is now dropped, we'll wait and see if there's any demand later. It would actually be isDaylightTime(QDateTime::currentMSecsSinceEpoch()). Then please change to use QDateTime. OK, so you would prefer the API uses QDateTime everywhere instead of MSecs? That will make the QDateTime internal use less efficient with converting back and forth, but I guess I could make QDateTime a friend of the private so it directly accesses the MSecs methods. I'll just need to be careful about setting up circular dependencies. The thing with caching the System time zone is to prevent unexpected time zone changes. If the system time zone was to dynamically change then an app could be left in an inconsistent state, with QDateTime instances having changed but gui strings and other cached details or calculations still reflecting the old system time zone. My thinking was that we would have a QEvent::TimeZoneChange that the app would respond to by calling the reset. You're creating an API call to resolve a problem of the implementation. That sounds wrong. Instead, solve the problem of the implementation. OK, I'll talk to the PIM guys about how they would expect it to behave, but in the meantime I'll remove it from the public api. Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)
On 23 February 2013 00:16, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 22 de fevereiro de 2013 19.26.06, Sze Howe Koh wrote: Actually, I just realized that the open-source flavour of TBB is licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing). Doesn't that mean that Qt TBB, if it were to become reality, can't be licensed under the LGPL? It's GPLv2+exceptions: The source code of Threading Building Blocks is distributed under version 2 of the GNU General Public License, with the so-called runtime exception, as follows (or see any header or implementation file): As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. I believe it's the same exception as the one in GNU libstdc++ Apparently, one legal team out there came to the conclusion that, if a non-GPL project incorporates TBB, someone with access to the project's source could then re-release the whole project under GPL, even if it was proprietary [1] It sounds a bit far-fetched to me, but it would probably be prudent for us to get an official response from Digia's legal team before we go ahead, right? == (Splitting the discussion into a new thread [no pun intended] in case others have thoughts to add) To recap: - We want a high-level multithreading solution to replace/rewrite QtConcurrent [2] - Incorporating a third-party solution seems like a better idea than reinventing the wheel [2] The suggestions were: - Intel TBB [3] - KDE ThreadWeaver (which is Qt-based itself) [2] - OpenMP [4] Comparisons: - OpenMP is out of the question, as it's not supported by all Qt-supported compilers - ThreadWeaver specializes in task-oriented programming, so it's orthogonal to QtConcurrent - TBB includes container-based operations like QtConcurrent, but much more. So, TBB is the shiniest at the moment, as it can replace all of QtConcurrent's functionality and more. I'm happy to set up the project to Qt-ify TBB, if people think it's a good idea and if we get a legal green light. Regards, Sze-Howe [1] http://software.intel.com/en-us/forums/topic/292842 [2] http://lists.qt-project.org/pipermail/development/2012-November/007921.html [3] http://lists.qt-project.org/pipermail/development/2012-November/007901.html [4] http://lists.qt-project.org/pipermail/development/2013-February/009978.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Evolving Qt's multithreading API
On Tuesday 26 February 2013 20:02:31 Иван Комиссаров wrote: My 2 cents. I would like to see something similar to Qt Creator's functions implemented in runextensions.h in QtConcurrent module itself - methods that allows to manipulate future using QFutureInterface (progress notification, partial results). Anyway, i wasn't able to find Qt Concurrent problems, can anyone point them? Is it really should be replaced with other solution? This is just my opinion: From an API point of view, I think Qt concurrent is fine. One problem is that you cannot select a thread pool for your operations, so you are limited to the default thread pool, which means you really should only use it for CPU intensive operation. There are still problem on the implementation: - In the templated code: I think the abstractions are on the wrong place. This result in a lot of code duplication for the different cases and make also the code difficult to follow. (and difficult to modify) - In the 'engine': Let's say there is room for improvements to limit the overhead. Using lockfree data structures where it make sens, or optimize better the code. (at some point one does a median computation that uses a lot of CPU) All of this is fixable. QtConcurrent was released in a good finished state for a first stable version, but it is was still young in a way. Then it could have deserved a bit more love over the years. But it stayed as it. I personally think QtConcurrent should not be replaced. Just improved. For example, as you mentioned, incorporating the changes from QtCreator, after proper API review. QtConcurrent::run() (which i feel is what most of this thread is about) could possibly be replaced by API in QThread or QThreadPool, to fix the problem that it can only be run in the main thread pool. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform maintainers: changes to OpenGL context creation required
Il 23/02/2013 15:45, Giuseppe D'Angelo ha scritto: Hello, in a few days I would like to stage https://codereview.qt-project.org/48657 which will cause QOpenGLShaderProgram to ignore QT_OPENGL_ES (defined at build time) and rely on renderable type returned from the current context (via QOpenGLContext::format()). Unless someone objects, I'll stage it tomorrow. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, 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
Re: [Development] Qt Platform Extras
On 2/25/13 17:12 , Joerg Bornemann wrote:
On 25/02/2013 16:27, Jake Thomas Petroules wrote:
I'd prefer Qt namespace with no platform indicators, i.e.:
Qt::toHICON
Qt::toHBITMAP
Qt::toCGImageRef
Qt::toNSString
I'm probably missing something obvious here, but why are these not with
the class that they convert from?
- conversion operator (or toFoo function if expensive)
- constructor (explicit if expensive)
If it's not an expensive conversion, it should just be:
class QRect
{
#if defined(Q_OS_MAC)
QRect(const CGRect rect);
operator CGRect() const;
#endif
};
So that I can write code like this:
someQtFunction(someCGRect);
someCocoaFunction(someQtRect);
Without having to wrap it in QRect::to/from -- or even worse, some sort
of global namespace for all to/from conversion functions.
tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android: Merge or no merge?
On 2/21/13 4:59 PM, Eskil Abrahamsen Blomfeldt eskil.abrahamsen-blomfe...@digia.com wrote: On 02/21/2013 04:54 PM, Oswald Buddenhagen wrote: i'll simply block the merge, and i don't even need to resort to my pet process reasons for that. Ok, we will delay the merge/rebase until Lars is back and can resolve this conflict. Just FYI: We're working through this now. Basically it'll boil down to upstreaming all changes that can possibly affect other platforms independently, and then have one squashed commit that contains only the Android specific parts. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Actually, I would like Qt Addons to live in a namespace, esp. for new ones. The namespace name ought the be the same as the module's name. This is really there to avoid name clashes with other parts of Qt. With a namespace, you have all the freedom you want on how to name methods inside. developers using the module can simply use a using declaration, and then won't have to worry about long names. Cheers, Lars On 2/25/13 12:03 PM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (³Qt::toWindowsHBITMAP². ³Qt::toMacCGImageRef²) -OR- * QPlatform::toType(³QWindows::toHBITMAP², QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ 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] Qt Platform Extras
On Thu, Feb 28, 2013 at 2:08 PM, Knoll Lars lars.kn...@digia.com wrote: Actually, I would like Qt Addons to live in a namespace, esp. for new ones. The namespace name ought the be the same as the module's name. This is really there to avoid name clashes with other parts of Qt. With a namespace, you have all the freedom you want on how to name methods inside. developers using the module can simply use a using declaration, and then won't have to worry about long names. This recommendation seems to be more or less documented: http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#03fa1e2be330cf40074c0a55dafe27c4 Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Incorporating Intel Threading Building Blocks into Qt? (Was: Evolving Qt's multithreading API)
On quinta-feira, 28 de fevereiro de 2013 18.35.23, Sze Howe Koh wrote: On 23 February 2013 00:16, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 22 de fevereiro de 2013 19.26.06, Sze Howe Koh wrote: Actually, I just realized that the open-source flavour of TBB is licensed under GPLv2 (http://threadingbuildingblocks.org/Licensing). Doesn't that mean that Qt TBB, if it were to become reality, can't be licensed under the LGPL? It's GPLv2+exceptions: The source code of Threading Building Blocks is distributed under version 2 of the GNU General Public License, with the so-called runtime exception, as follows (or see any header or implementation file): As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. I believe it's the same exception as the one in GNU libstdc++ Apparently, one legal team out there came to the conclusion that, if a non-GPL project incorporates TBB, someone with access to the project's source could then re-release the whole project under GPL, even if it was proprietary [1] Some legal team does not help, of course. But I did a little more digging and it looks like the exception is not like libstdc++'s. The one there is a MUCH longer text. It's also not the short text found in GNU classpath. Moreover, I've just noticed it says you may use this file as part of a free software library. That means if you're not doing a free software library, it does not apply. It sounds a bit far-fetched to me, but it would probably be prudent for us to get an official response from Digia's legal team before we go ahead, right? Yup. Bit I can also check with Intel's legal team what the intention was. They may not give a legal opinion, but the people behind TBB might be able to say what their intention was. Also note that TBB is available under a commercial license too. So, TBB is the shiniest at the moment, as it can replace all of QtConcurrent's functionality and more. I'm happy to set up the project to Qt-ify TBB, if people think it's a good idea and if we get a legal green light. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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] Nominating Alan Alpert as QtDeclarative maintainer
It's been 15 working days, so I think it passed. I'll go update the wiki, and triage some declarative bugs ;) . -- Alan Alpert On Tue, Feb 5, 2013 at 1:47 AM, Bache-Wiig Jens jens.bache-w...@digia.com wrote: +1 from me as well. Alan has an excellent overview on everything going on in this module and is still actively following every aspect of its development. I also agree with Lars that we eventually will need to break this beast into smaller more manageable parts as its scope will only continue to grow in the future. Jens On Feb 5, 2013, at 9:02 AM, Sletta Gunnar gunnar.sle...@digia.com wrote: +1 Alan has done a lot of good stuff for QML so far. Looking forward to more good stuff coming :) cheers, GUnnar On Feb 4, 2013, at 6:28 PM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Feb 4, 2013 at 6:19 AM, Knoll Lars lars.kn...@digia.com wrote: Alan has been very proactive and is probably the best person we have for the job right now. So a +1 from my side. But the declarative repo is pretty big and very central to Qt moving forward. So I believe we will need to split up responsibilities further in the longer term. I would at the minimum like to split up on a per module basis, maybe even a bit more fine-grained. So one Maintainer for Qt QML, one for Qt Quick, etc. Agreed, QtQml and QtQuick are both separate modules that are full 'module' sized. As development ramps back up I hope we can find at least one maintainer per module (which is more important than maintainers 'per repository'). Finally, we also need to ask the person in question: Alan, are you willing to take that role, and will your responsibilities in you day job leave you with enough time to act as the maintainer? Yes, I'm willing to take that role. As you might have noticed, a significant part of my day job is working on QML already and my manager is supportive of my spending more time on it to fulfill the maintainer duties. -- Alan Alpert ___ 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 ___ 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] Nominating Andreas Hanssen as Approver
It's been 15 work days. Congratulations Andreas! PS: how does one get the necessary privileges in JIRA? Do we have to create a QTJIRA task? On quarta-feira, 6 de fevereiro de 2013 13.31.40, Thiago Macieira wrote: Hello Andreas is a long-time Qt developer. For those of you who haven't yet had the pleasure of meeting him, he's the brains behind the original implementation and maintenance of Graphics View. Before that, I remember working with him on the networking classes -- in fact, QSslSocket is also his and George Staikos's. His knowledge is invaluable. You can find him on IRC under the nickname bibr. His dashboards: https://codereview.qt-project.org/#dashboard,1000351 https://codereview.qt-project.org/#dashboard,1001692 More importantly, the list of reviews: https://codereview.qt-project.org/#q,reviewer: %2522Andreas+Aardal+Hanssen%2522,n,z -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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 Platform Extras
On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andreas Hanssen as Approver
Yes. See these for an examples: https://bugreports.qt-project.org/browse/QTJIRA-195 https://bugreports.qt-project.org/browse/QTJIRA-178 On Thu, Feb 28, 2013 at 8:09 PM, Thiago Macieira thiago.macie...@intel.comwrote: It's been 15 work days. Congratulations Andreas! PS: how does one get the necessary privileges in JIRA? Do we have to create a QTJIRA task? On quarta-feira, 6 de fevereiro de 2013 13.31.40, Thiago Macieira wrote: Hello Andreas is a long-time Qt developer. For those of you who haven't yet had the pleasure of meeting him, he's the brains behind the original implementation and maintenance of Graphics View. Before that, I remember working with him on the networking classes -- in fact, QSslSocket is also his and George Staikos's. His knowledge is invaluable. You can find him on IRC under the nickname bibr. His dashboards: https://codereview.qt-project.org/#dashboard,1000351 https://codereview.qt-project.org/#dashboard,1001692 More importantly, the list of reviews: https://codereview.qt-project.org/#q,reviewer: %2522Andreas+Aardal+Hanssen%2522,n,z -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] Qt Platform Extras
On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center 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 Platform Extras
On Mar 1, 2013, at 12:28 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. Which ones? It seems reasonable to divide the platform set in two then: 1) The platform can guarantee the presence of certain libraries at runtime. QtCore and QtGui can contain conversion functions to native types. 2) It's uncertain what libraries you'll find. No conversion functions. In other words, optimize for the capabilities of each platform instead of using the lowest common denominator. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Mar 1, 2013, at 2:21 AM, Sorvig Morten morten.sor...@digia.com wrote: On Mar 1, 2013, at 12:28 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. Which ones? It seems reasonable to divide the platform set in two then: 1) The platform can guarantee the presence of certain libraries at runtime. QtCore and QtGui can contain conversion functions to native types. 2) It's uncertain what libraries you'll find. No conversion functions. In other words, optimize for the capabilities of each platform instead of using the lowest common denominator. Morten ___ 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
[Development] QtDriveInfo module in Playground
Hello, i would like to request a repository in a playground for my QDriveInfo module. This class allows to retrieve information about a system volumes - like available size, filesystem, filesystem flags and so on. Right now, repo is located here https://gitorious.org/qdrive Also, i'm not sure about the name of a repo - should it be QtDriveInfo, or ышьздн QtDrive (as long as i also have QtDriveController class which can monitor/mount/unmount drives from userspace) PS: There's also exists issue about drive information https://bugreports.qt-project.org/browse/QTBUG-3780 Иван Комиссаров ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Creator build fails
I have recently updated my local repo for Qt Creator and its failing now, :-1: error: No rule to make target `../../../qt-creator/share/qtcreator/templates/wizards/bb-qt5-quick2app/bar-descriptor.xml', needed by `templates/wizards/bb-qt5-quick2app/bar-descriptor.xml'. Stop. Is there anything that I need to do in order to build it? It was building alright before this update, Last update before this was yesterday. -- Majid Khan http://www.icplusplus.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
