Re: [Development] Fixing the DLL/shared/static mess
On 13/07/2012 05:43, ext Loaden wrote: This changed broken qbs build on Windows (MSVC2010SP1): 96166fa56abb52157387c4911efbd4e5e6beee93 After change CONFIG += staticlib to CONFIG += static (src\lib\lib.pro http://lib.pro) still can't solved the build issue. Any comments? This has nothing to do with Qt. Like Qt Creator, qbs copied some files from QtConcurrent. The culprit is src/lib/qtconcurrent/qtconcurrent_global.h in qbs. Will fix it. BR, Jörg -- Joerg Bornemann Senior 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] Fixing connecting to private signals
On sexta-feira, 13 de julho de 2012 08.33.42, Girish Ramakrishnan wrote: Hi, On Wed, Jul 11, 2012 at 10:40 PM, Olivier Goffart oliv...@woboq.com wrote: On Wednesday 11 July 2012 18:50:15 Stephen Kelly wrote: So, either the code should stay as is - leaving the signals private and making function pointer connects not work, or the patches should be applied, making function pointer connects work. Making the signals public is not an option for me. I personally beleive allowing the new syntax is more important than keeping those signal private. Anyway, i'm quite happy with the current implementation in moc. Is this really important given that we are in feature freeze? Changes to moc, however small, is not advisable at all. As I wrote in the change, this breaks if there are overloads to the signal: signals: void somethingChanged(); void somethingChanged(int, QPrivateSignal); You can't connect to the private signal because the type QPrivateSignal is private. -- 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] Experimental Qt 5 installers by Digia
On sexta-feira, 13 de julho de 2012 01.20.07, Leandro Melo de Sales wrote: Hi, This was with my own source code, that it compiles nicely with my own Qt5 compilation that I did following the guide available here: http://qt-project.org/wiki/Building-Qt-5-from-Git Send us the output from qmake -d -d when running in your project. And the output from qmake -E. You have to run it twice. -- 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] Fixing connecting to private signals
On Friday 13 July 2012 09:30:44 Thiago Macieira wrote: On sexta-feira, 13 de julho de 2012 08.33.42, Girish Ramakrishnan wrote: Is this really important given that we are in feature freeze? Changes to moc, however small, is not advisable at all. This is why we brought the subject on the mailing list. As I wrote in the change, this breaks if there are overloads to the signal: signals: void somethingChanged(); void somethingChanged(int, QPrivateSignal); You can't connect to the private signal because the type QPrivateSignal is private. Yes that's right. But signal overload should be avoided. -- 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] Fixing connecting to private signals
On sexta-feira, 13 de julho de 2012 10.07.04, Olivier Goffart wrote: signals: void somethingChanged(); void somethingChanged(int, QPrivateSignal); You can't connect to the private signal because the type QPrivateSignal is private. Yes that's right. But signal overload should be avoided. Maybe moc should even warn if the signal overload another function. That's too late for that. http://qt-project.org/doc/qabstractsocket.html#error http://qt-project.org/doc/qabstractsocket.html#error-2 One of them is a signal. I actually think the warning would be a good idea, but we need a way to tell moc not to print it because we know about it already. -- 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] Experimental Qt 5 installers by Digia
Which compiler will be used for windows? MinGw or MSVC? On Fri, Jul 13, 2012 at 9:31 AM, Thiago Macieira thiago.macie...@intel.com wrote: On sexta-feira, 13 de julho de 2012 01.20.07, Leandro Melo de Sales wrote: Hi, This was with my own source code, that it compiles nicely with my own Qt5 compilation that I did following the guide available here: http://qt-project.org/wiki/Building-Qt-5-from-Git Send us the output from qmake -d -d when running in your project. And the output from qmake -E. You have to run it twice. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mit freundlichen Grüßen Greetings Daniel Kreuter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing connecting to private signals
On Friday, July 13, 2012 09:30:44 Thiago Macieira wrote: On sexta-feira, 13 de julho de 2012 08.33.42, Girish Ramakrishnan wrote: Hi, On Wed, Jul 11, 2012 at 10:40 PM, Olivier Goffart oliv...@woboq.com wrote: On Wednesday 11 July 2012 18:50:15 Stephen Kelly wrote: So, either the code should stay as is - leaving the signals private and making function pointer connects not work, or the patches should be applied, making function pointer connects work. Making the signals public is not an option for me. I personally beleive allowing the new syntax is more important than keeping those signal private. Anyway, i'm quite happy with the current implementation in moc. Is this really important given that we are in feature freeze? Changes to moc, however small, is not advisable at all. As I wrote in the change, this breaks if there are overloads to the signal: signals: void somethingChanged(); void somethingChanged(int, QPrivateSignal); You can't connect to the private signal because the type QPrivateSignal is private. I added some unit tests for this case: https://codereview.qt-project.org/30762 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] Fixing connecting to private signals
On Friday, July 13, 2012 08:33:42 Girish Ramakrishnan wrote: Hi, On Wed, Jul 11, 2012 at 10:40 PM, Olivier Goffart oliv...@woboq.com wrote: On Wednesday 11 July 2012 18:50:15 Stephen Kelly wrote: So, either the code should stay as is - leaving the signals private and making function pointer connects not work, or the patches should be applied, making function pointer connects work. Making the signals public is not an option for me. I personally beleive allowing the new syntax is more important than keeping those signal private. Anyway, i'm quite happy with the current implementation in moc. Is this really important given that we are in feature freeze? Changes to moc, however small, is not advisable at all. This wasn't a new feature. It was fixing an existing feature, and the fix couldn't wait for Qt 5.1. We only found out about this issue because someone evaluating Qt 5 told us about it a week ago on IRC. I haven't seen the IRC handle before or since, so this was the kind of person who would give us feedback on a beta for example. We will probably get more such feedback once the beta is released (I hope we will anyway - I'm glad we found out about this issue now and not a week before 5.0 release), and we need to be able to fix issues like that which can't be fixed after 5.0. Otherwise there would be no point in the beta at all. 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] Fixing connecting to private signals
On sexta-feira, 13 de julho de 2012 11.51.07, Stephen Kelly wrote: You can't connect to the private signal because the type QPrivateSignal is private. I added some unit tests for this case: https://codereview.qt-project.org/30762 Why did the change have to be in Q_OBJECT? Couldn't it be done for this one class that requires private signals only? -- 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] Fixing connecting to private signals
On Friday, July 13, 2012 12:00:07 Thiago Macieira wrote: On sexta-feira, 13 de julho de 2012 11.51.07, Stephen Kelly wrote: You can't connect to the private signal because the type QPrivateSignal is private. I added some unit tests for this case: https://codereview.qt-project.org/30762 Why did the change have to be in Q_OBJECT? Couldn't it be done for this one class that requires private signals only? 3 classes require it - QAbstractItemModel, QAbstractTransition and QAbstractState. Initially I had it as a private struct in QAbstractItemModel, but ossi suggested to put it in QObject because moc needed knowledge of what it was called anyway. I agree with ossi on that. 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] QtCore is 2 MB larger in Qt 5
It was on linkonce sections. The attached script improves on it. Unfortunately, those sections are unpredictable, since they depend on the compiler's mood in inlining or not inlining some things. For example, QList is mostly unchanged in Qt 5, but this shows up: you may want to experiment a bit with `gcc --pram=large-function-growth=X` that can change the mood of gcc quite a bit. This message has no opinion or intention in this topic other than let know this parameters exist and can be used for experimetation. gcc --help=param [...] max-inline-insns-single The maximum number of instructions in a single function eligible for inlining max-inline-insns-auto The maximum number of instructions when automatically inlining max-inline-insns-recursive The maximum number of instructions inline function can grow to via recursive inlining max-inline-insns-recursive-auto The maximum number of instructions non-inline function can grow to via recursive inlining max-inline-recursive-depth The maximum depth of recursive inlining for inline functions max-inline-recursive-depth-auto The maximum depth of recursive inlining for non-inline functions min-inline-recursive-probability Inline recursively only when the probability of call being executed exceeds the parameter max-early-inliner-iterations The maximum number of nested indirect inlining performed by early inliner comdat-sharing-probability Probability that COMDAT function will be shared with different compilatoin unit partial-inlining-entry-probability Maximum probability of the entry BB of split region (in percent relative to entry BB of the function) to make partial inlining happen max-variable-expansions-in-unroller If -fvariable-expansion-in-unroller is used, the maximum number of times that an individual variable will be expanded during loop unrolling [...] inline-unit-growth How much can given compilation unit grow because of the inlining (in percent) ipcp-unit-growthHow much can given compilation unit grow because of the interprocedural constant propagation (in percent) early-inlining-insnsMaximal estimated growth of function body caused by early inlining of single call large-stack-frame The size of stack frame to be considered large large-stack-frame-growthMaximal stack frame growth due to inlining (in percent) [...] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Contributing to the Qt Project behind a hefty firewall and proxy server
Hi, There are certain situations out there, when it is currently not so simple to contribute to the Qt Project. One typical use case, if there is a proxy server without using socks, just plain http. In those cases, ssh tunneling does not work either properly. Imagine that, the ports 80 and 443 are allowed only. What one can do for instance in the KDE project is simpler since git.kde.org does listen via ssh on the port 443, so that establishment can be used for cloning and pushing to the KDE repositories. Unfortunately, this is not the case with the Qt Project currently. As far as I have been told, the port 443 is used for the Gerrit webinterface. What one could do is to use a gateway server listetning on port 443 via ssh. Unfortunately, many people do not have such an ability. Furthermore, I do think it is suboptimal, if each contributor in this situation should solve the issue in question on their own. Many people cannot just unfortunately use the port 29418 recommended. Hence, I am now asking, if it is possible to find a solution for people willing to contribute to the Qt Project with these conditions. One option is an outside proxy on the port 443, but any solution is welcome. Thank you in advance. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Porting my Qt4 application to Qt5 fails because qtmaind.lib not found (windows)
Hi, I'm porting my application to Qt5, but when compiling with msvc, he complains that he cannot open qtmaind.lib. I used the latest build from Digia for compiling. -- Mit freundlichen Grüßen Greetings Daniel Kreuter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Porting my Qt4 application to Qt5 fails because qtmaind.lib not found (windows)
Hi. It appears that the experimental Qt 5 installers from Digia only contain release binaries. Try release build instead of debug build. -Miikka -Original Message- From: development-bounces+miikka.heikkinen=digia@qt-project.org [mailto:development-bounces+miikka.heikkinen=digia@qt-project.org] On Behalf Of Daniel Kreuter Sent: 13. heinäkuuta 2012 14:57 To: development@qt-project.org Subject: [Development] Porting my Qt4 application to Qt5 fails because qtmaind.lib not found (windows) Hi, I'm porting my application to Qt5, but when compiling with msvc, he complains that he cannot open qtmaind.lib. I used the latest build from Digia for compiling. -- Mit freundlichen Grüßen Greetings Daniel Kreuter ___ 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] QtCore is 2 MB larger in Qt 5
On Friday 13 July 2012 13:11:15 Giuseppe D'Angelo wrote: Random thoughts: On 11 July 2012 20:22, Thiago Macieira thiago.macie...@intel.com wrote: That's 63% bigger. Top 20 culprits: 251684 .obj/release-shared/qrc_mimetypes.o:.rodata 0x3d724 0x0 Are the mimetypes alwasy included, even on GNU/Linux systems that are supposed to have them around (in a standard location)? That is: is there a way to build QtCore w/o the mimetype data? It is a huge xml file that is embedded on that resource. Maybe we could just store it compressed. (and uncompresed with QByteArray::uncompress). It would be slower, but that file is only used when it is not found on the system. We could also store a pre-parsed version. Another option would be to ship it with Qt, but as a separate file, not in the resource. Could be done in Qt 5.1 157528 .obj/release-shared/pcre16_exec.o:.text 0x26758 0x0 113101 .obj/release-shared/pcre16_jit_compile.o:.text 0x1b9cd 0x0 60384 .obj/release-shared/pcre16_ucd.o:.rodata 0xebe0 0x0 43088 .obj/release-shared/pcre16_compile.o:.text 0xa850 0x0 26408 .obj/release-shared/pcre16_dfa_exec.o:.text 0x6728 0x0 This is indeed something (~400K!). Unfortunately PCRE uses its own set of unicode tables (_ucd.o) fine tuned for what it does, i.e. it doesn't support (for now) ICU or any similar library. The good news is that QtCore will dynamically link to PCRE if it's found on the OS, thus not having this code size increase. (Note that we require quite a recent version, so only a few systems already provide the one we need). Distributions will upgrade their PCRE version as they upgrade Qt. 57900 .obj/release-shared/qeuckrcodec.o:.rodata 0xe22c 0x0 134944 .obj/release-shared/qbig5codec.o:.rodata 0x20f20 0x0 133792 .obj/release-shared/qjpunicode.o:.rodata 0x20aa0 0x0 117842 .obj/release-shared/qgb18030codec.o:.rodata 0x1cc52 0x0 Codecs linked in instead of in plugins or what? Yes. https://codereview.qt-project.org/#change,12955 The problem is that codecs in plugin do not really work as we need codecs to load plugin (in order to convert the paths, and so on) What Qt did is to consider everything as latin1 before they were loaded. But this was not working well. In the long term, Qt should not have its own code for all those codecs, but rely on the platform libraries. 51877 .obj/release-shared/qsortfilterproxymodel.o:.text 0xcaa5 0x0 36993 .obj/release-shared/qitemselectionmodel.o:.text 0x9081 0x0 Move from QtGui, i.e. QtGui decreased :-) 26803 .obj/release-shared/qmimeprovider.o:.text 0x68b3 0x0 20335 .obj/release-shared/qregularexpression.o:.text 0x4f6f 0x0 16649 .obj/release-shared/qstandardpaths_unix.o:.text 0x4109 0x0 New public API... Exactly... Bigger is Better, right? ;-) No idea about the remaining parts, but thank you for the stats. It's something interesting to talk about. -- 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] Contributing to the Qt Project behind a hefty firewall and proxy server
On 13/07/2012 06:42, ext Laszlo Papp wrote: There are certain situations out there, when it is currently not so simple to contribute to the Qt Project. One typical use case, if there is a proxy server without using socks, just plain http. In those cases, ssh tunneling does not work either properly. Imagine that, the ports 80 and 443 are allowed only. What one can do for instance in the KDE project is simpler since git.kde.org does listen via ssh on the port 443, so that establishment can be used for cloning and pushing to the KDE repositories. Unfortunately, this is not the case with the Qt Project currently. As far as I have been told, the port 443 is used for the Gerrit webinterface. What one could do is to use a gateway server listetning on port 443 via ssh. Unfortunately, many people do not have such an ability. Furthermore, I do think it is suboptimal, if each contributor in this situation should solve the issue in question on their own. Many people cannot just unfortunately use the port 29418 recommended. Hence, I am now asking, if it is possible to find a solution for people willing to contribute to the Qt Project with these conditions. One option is an outside proxy on the port 443, but any solution is welcome. I think we could do the same setup as GitHub, and simply have port forwarding from ssh.qt-project.org:443 to codereview.qt-project.org:29418. That should enable most people to work behind corporate firewalls. -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCore is 2 MB larger in Qt 5
On sexta-feira, 13 de julho de 2012 13.34.32, viv...@gmail.com wrote: you may want to experiment a bit with `gcc --pram=large-function-growth=X` that can change the mood of gcc quite a bit. This message has no opinion or intention in this topic other than let know this parameters exist and can be used for experimetation. That doesn't help unless we force that argument on everyone. If wanted to compare code size per file, I could just compare the size of the .o files (without debugging info) :-) -- 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] QtCore is 2 MB larger in Qt 5
On sexta-feira, 13 de julho de 2012 14.38.09, Olivier Goffart wrote: On Friday 13 July 2012 13:11:15 Giuseppe D'Angelo wrote: Random thoughts: On 11 July 2012 20:22, Thiago Macieira thiago.macie...@intel.com wrote: That's 63% bigger. Top 20 culprits: 251684 .obj/release-shared/qrc_mimetypes.o:.rodata 0x3d724 0x0 Are the mimetypes alwasy included, even on GNU/Linux systems that are supposed to have them around (in a standard location)? That is: is there a way to build QtCore w/o the mimetype data? It is a huge xml file that is embedded on that resource. Maybe we could just store it compressed. (and uncompresed with QByteArray::uncompress). rcc already compresses and QResource uncompresses. The original file is 1.7 MB. It's a trade-off: we save 1.4 MB in the size of the library (and the size of flash or installed size), but we increase the heap memory usage by 1.7 MB if we do need this file. That's unsharable, swap-backed RAM. If the file were not compressed, it would be sharable, clean and discardable RAM. We could also store a pre-parsed version. David can comment, but this looks like a good idea. Another option would be to ship it with Qt, but as a separate file, not in the resource. That's also an idea. Distributions will upgrade their PCRE version as they upgrade Qt. That means the QtCore size decreases again, but the total VSZ required to run Qt is still the same. Then again, VSZ doesn't matter. 57900 .obj/release-shared/qeuckrcodec.o:.rodata 0xe22c 0x0 134944 .obj/release-shared/qbig5codec.o:.rodata 0x20f20 0x0 133792 .obj/release-shared/qjpunicode.o:.rodata 0x20aa0 0x0 117842 .obj/release-shared/qgb18030codec.o:.rodata 0x1cc52 0x0 Codecs linked in instead of in plugins or what? Yes. https://codereview.qt-project.org/#change,12955 The problem is that codecs in plugin do not really work as we need codecs to load plugin (in order to convert the paths, and so on) What Qt did is to consider everything as latin1 before they were loaded. But this was not working well. In the long term, Qt should not have its own code for all those codecs, but rely on the platform libraries. That's the plan for Qt 5.1. We need to replace those codecs with ICU. -- 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] QtCore is 2 MB larger in Qt 5
On sexta-feira, 13 de julho de 2012 13.11.15, Giuseppe D'Angelo wrote: 51877 .obj/release-shared/qsortfilterproxymodel.o:.text 0xcaa5 0x0 36993 .obj/release-shared/qitemselectionmodel.o:.text 0x9081 0x0 Move from QtGui, i.e. QtGui decreased :-) Indeed it did. But comparing QtGui is quite a different beast, since it was split in two (QtGui and QtWidgets), it got new API, and it also got part of QtOpenGL merged in. -- 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] Contributing to the Qt Project behind a hefty firewall and proxy server
On sexta-feira, 13 de julho de 2012 12.40.12, marius.storm-ol...@nokia.com wrote: I think we could do the same setup as GitHub, and simply have port forwarding from ssh.qt-project.org:443 to codereview.qt-project.org:29418. That should enable most people to work behind corporate firewalls. I think we should try that. However, note that this could be a violation of the terms of use of that corporate network since the traffic is not web. Circumventing the protection is not a good idea. So I also think that the IT departments of those companies need to do their job. If there's a legitimate reason for a developer working behind the corporate firewall to contribute to Qt, then this developer should use the Qt methods and simply get their IT people to provide an approved and supported way of doing so. IT is a supporting organisation, they are there need to make sure that the other functions can do their jobs and that the integrity of the network is maintained. They are not there to dictate how those other functions should do their jobs. So I suggest that each developer behind such a firewall open an IT ticket and request a proxy to reach ports 9418 and 29418. If necessary, escalate to the managers and and stop working when the firewall prevents work from getting done. -- 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] State of the Qt Solutions Archive
On sexta-feira, 13 de julho de 2012 14.33.18, Lukas Geyer wrote: I've fixed QtSingleApplication for Qt5 and created a merge request, just to find out that it's quite quiet there, with merge request beeing not seen (?) or at least discussed and merged for months. We're in feature freeze and have been since March. The next opportunity to merge the feature is in Qt 5.1. -- 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] Using Qt 5 with C++11/Clang 3.1?
On 7/7/12 4:32 PM, Thiago Macieira wrote: On sábado, 7 de julho de 2012 11.17.58, Stephen Chu wrote: /Qt/5.0/qtbase/include/QtCore/../../src/corelib/global/qflags.h:51:7: note: 'QFlag' is not literal because it is not an aggregate and has no constexpr constructors other than copy or move constructors class QFlag ^ Adding Q_DECL_CONSTEXPR to QFlag constructor fixes it: Q_DECL_CONSTEXPR inline QFlag(int i); I don't know if if is another Clang bug. No, that looks like a real issue, Please submit the patch for the QFlag constexpr constructor. I couldn't setup my Mac right to submit patch. Some SSH issue I can't figure out how to get around. But I see it's been fixed a couple days ago. So thank whoever patched it. I also updated MacPorts clang 3.2 to a later version containing the fix for the constructor issue and it compiles without modifying the code. However, 3.2 (trunk 160101) generates the following warning: /Qt/5.0/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer_impl.h:613:49: warning: field is uninitialized when used here [-Wuninitialized] inline QWeakPointer(X *ptr, bool) : d(ptr ? d-getAndRef(ptr) : 0), value(ptr) ^ The warning makes sense to me on the appearance. Don't know enough about internal stuffs to be sure though. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
I think we should try that. However, note that this could be a violation of the terms of use of that corporate network since the traffic is not web. Not necessarily, no. The Qt Project would not be in charge of such decisions, anyway. Nothing to violate in the Qt project itself, so is this not a violation in the aforementioned examples: github, KDE, and so forth. Circumventing the protection is not a good idea. It indeed is, if it is done for good. It is like when you have a sanity bot when it defends against the most cases, but makes zero sense in certain. One will send patches to the mailing list, and someone else will go through gerrit? So I also think that the IT departments of those companies need to do their job. If there's a legitimate reason for a developer working behind the corporate firewall to contribute to Qt, then this developer should use the Qt methods and simply get their IT people to provide an approved and supported way of doing so. Qt methods could help the people better instead of blocking the new contributions. Also, changing very old company policies, for instance as a new employer, is just almost impossible even if your project depends on Qt, and you fix an upstream issue needed for your project (or implement a new feature). Not upstreaming that could actually be a violation against the Qt Project, so what? Keep sending attached patches to the mailing list? IT is a supporting organisation, they are there need to make sure that the other functions can do their jobs and that the integrity of the network is maintained. They are not there to dictate how those other functions should do their jobs. So I suggest that each developer behind such a firewall open an IT ticket and request a proxy to reach ports 9418 and 29418. If necessary, escalate to the managers and and stop working when the firewall prevents work from getting done. Are you serious? You have worked in a big company, so you do know that such changes can be /very/ long, if it gets through at all. Many supervisors would just say, attach a patch please to the mailing list (if they do not have other opportunities over 80 and 443) since it is simpler than changing the company policies upside down, so they do not stress. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] OpenGL Support in Qt5
Hi,
I have pushed the following WIP patch for review:
https://codereview.qt-project.org/#change,30554
The idea of this is to provide a set of classes that expose the OpenGL
functions specific to the version and profile of the corresponding
QOpenGLContext.
This means that it is no longer necessary to use GLEW or similar or to
manually resolve OpenGL entry points by hand. This allows developers using
these classes to get per-context entry points easily and to also get compiler
errors rather than runtime errors if they try to use a function not supported
by that {version, profile} of OpenGL.
The set of QOpenGLFunctions_Major_Minor_Profile classes are generated
directly from the official OpenGL spec files as published by the Khronos
group. As such we could potentially make the generation of these classes part
of the qtbase bootstrap process. This would require importing the OpenGL spec
files into the qtbase repo along with the code generator.
The current WIP patch exposes the version specific functions via
QOpenGLContext::versionFunctions() at present as there already exists a
function QOpenGLContext::functions() which returns a pointer to a
QOpenGLFunctions object.
QOpenGLFunctions provides basically the same as the new classes but for the
common subset of Desktop OpenGL 2 and OpenGL ES 2 as this is what is required
by Qt itself (e.g. in QQ2).
Another motivation for these new classes is that the existing QOpenGLFunctions
is not enough to support modern OpenGL on the desktop. It cannot answer
questions such as are geometry shaders supported?. Geometry shaders are
available in Qt4's QGLShaderProgram but are disabled in Qt 5's
QOpenGLShaderProgram at present.
If we combine these proposed classes with the extension resolved (which should
be improved and made public) then we would able to easily check for support
(either as a core feature or via an extension) and also be able to easily get
access to resolved function entry points in the implementation.
It would be a fairly simple job to extend the code generator to create classes
for OpenGL extensions too (they are also in the spec files). I am currently
thinking that the extension matcher can be used to query the available
extensions and then as a factory to a family of classes that each represent
one extension.
I would like to seek opinion on whether people are happy with this general
approach and how it should be placed in relation to the existing
QOpenGLFunctions::functions(). Alongside it? Replace it?
I do worry about the number of added symbols to QtGui though - OpenGL is not a
small API. Perhaps adding these classes as plugins would be a good idea?
I believe that such a framework coupled with QWindow would make Qt5 an
excellent platform for OpenGL development as it would allow us to develop
additional OpenGL enabler classes easily e.g. QOpenGLVertexArrayObject.
Comments/thoughts/flames?
Cheers,
Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
In addition to my previous reply, it can be a legit use case to make a network establishment (not just corporate, but even personal), where you would not like to open a port up globally just because of one project, if not necessary. The only drawback I could mention from my point of view for the Qt Project, is the additional maintenance, which should not be significant. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) Why open the port up globally with its own drawbacks just because of one project? If this can get fixed, and the circumventing (communicating with patches good for a company over 443) is accepted in a network (let it corporate or personal), I do not see the problem and the reason to change the existing practicies. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
On Friday 13 July 2012 16:10:22 Laszlo Papp wrote: He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) Why open the port up globally with its own drawbacks just because of one project? If this can get fixed, and the circumventing (communicating with patches good for a company over 443) is accepted in a network (let it corporate or personal), I do not see the problem and the reason to change the existing practicies. If it is for a personal network (as you now seem to be hinting at) then what is the issue with opening up said ports for outbound traffic? If you are really that bothered then only open up the ports for outbound traffic when you need to use them and then close them again after. You could even place restrictions on the allowed source and destination IPs etc if desired. Why would opening these ports for outbound traffic be any more risky than any other existing ports. For corporate networks I agree that the proposed solution is fine to help get around overly restrictive IT policies. I know first hand from previous experience that these can take a long time and the patience of a saint to get changed. Kind regards, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contributing to the Qt Project behind a hefty firewall and proxy server
If it is for a personal network (as you now seem to be hinting at) is the issue with opening up said ports for outbound traffic? Perhaps I associate the word corporate distinctly due to my language difficulties. :) In any case, what I mean is that, It is all policy (regardless company or personal) after all. It may be a valid use case in my opinion not opening a port globally everywhere needed in this situation, but solved centrally in one place. If I had to use the same port at many places, sure. Perhaps it is better to consider, but that is not the situation anyway. If you are really that bothered then only open up the ports for outbound traffic when you need to use them and then close them again after. You could even place restrictions on the allowed source and destination IPs etc if desired. Again, I prefer doing this in one centralized place instead of X separate where this need arises just for this project. Why would opening these ports for outbound traffic be any more risky than any other existing ports. There might be valid reasons for that, why two are only open. It is the same at a few big companies I worked with except that certain proxy servers use socks which allow easier treatment without the need for this request. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using Qt 5 with C++11/Clang 3.1?
On sexta-feira, 13 de julho de 2012 15.58.20, Olivier Goffart wrote: On Friday 13 July 2012 09:44:05 Stephen Chu wrote: On 7/7/12 4:32 PM, Thiago Macieira wrote: However, 3.2 (trunk 160101) generates the following warning: /Qt/5.0/qtbase/include/QtCore/../../src/corelib/tools/qsharedpointer_impl. h: 613:49: warning: field is uninitialized when used here [-Wuninitialized] inline QWeakPointer(X *ptr, bool) : d(ptr ? d-getAndRef(ptr) : 0), value(ptr) ^ The warning makes sense to me on the appearance. Don't know enough about internal stuffs to be sure though. getAndRef is static, so it does not matter. But it is true the code should be changed to Data::getAndRef(ptr) And it's fixed. -- 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] Contributing to the Qt Project behind a hefty firewall and proxy server
On sexta-feira, 13 de julho de 2012 15.04.36, marius.storm-ol...@nokia.com wrote: Ok, you guys just misunderstand each other. Thiago says we should do it, to ensure that the Qt Project is accessible behind badly configured corporate firewalls. He also says that you should at the same time have a discussion with Corporate Security to make them understand that the current situation is hurting the organization, and try to get it changed so you _don't_ have to circumvent Corporate Security. (Normally it's grounds for getting the pink slip immediately.) So, I think we'll go ahead and get a port forward setup. Yeah. But let's make sure that we are NOT recommending that people circumvent IT network policies. If the IT infrastructure blocks the traffic, then they must have a reason for it. It can be because: 1) the block is overly broad and shouldn't be there or 2) the block is intentional and the Git/Gerrit/SSH traffic should not be permitted We simply don't know which it is. The use by that user of the SSH server running on port 443 could lead to a violation of the corporate network security policy. We must make it clear that we are not responsible and that the user must figure that out with their people. Which leads me to my suggestion: if your firewall blocks the traffic to port 29418, create the IT ticket now and get an approved way of doing Gerrit traffic. Follow the company's procedures. And the best way to ensure that it gets done is to prove that you cannot work without the solution. Prove it by spending a week idling because you could not do your work. That's also valid for consultants. Yes, I have worked for big companies and I still do. In both Nokia and Intel, there are approved ways of accessing those ports that don't involve circumventing the security policy. -- 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] State of the Qt Solutions Archive
Am 13.07.2012 15:29, schrieb Thiago Macieira: On sexta-feira, 13 de julho de 2012 14.33.18, Lukas Geyer wrote: I've fixed QtSingleApplication for Qt5 and created a merge request, just to find out that it's quite quiet there, with merge request beeing not seen (?) or at least discussed and merged for months. We're in feature freeze and have been since March. The next opportunity to merge the feature is in Qt 5.1. It might have been badly worded on my end. It is not a patch which integrates QtSingleApplication into Qt5, but rather a set of patches for QtSingleApplication in the qt-solutions repository (http://qt.gitorious.org/qt-solutions), which allows for using QtSingleApplication with Qt5 (http://qt.gitorious.org/qt-solutions/qt-solutions/merge_requests/7). However, there seems to be no activity when it comes to reviewing and approving merge request for this repository. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] State of the Qt Solutions Archive
Hello everybody. As for me, i would like to see QtSingleApplication integrated into QCoreApplication, if that possible. Having QtSingleCoreApp and QtSingleApp (and maybe QtSingleGuiApplication in qt5) in a library looks quite awkward for me. Locked file can be introduced as a private class. And on the side of a QCoreApp, we just need to add couple of public methods 13.07.2012, в 19:58, Lukas Geyer написал(а): Am 13.07.2012 15:29, schrieb Thiago Macieira: On sexta-feira, 13 de julho de 2012 14.33.18, Lukas Geyer wrote: I've fixed QtSingleApplication for Qt5 and created a merge request, just to find out that it's quite quiet there, with merge request beeing not seen (?) or at least discussed and merged for months. We're in feature freeze and have been since March. The next opportunity to merge the feature is in Qt 5.1. It might have been badly worded on my end. It is not a patch which integrates QtSingleApplication into Qt5, but rather a set of patches for QtSingleApplication in the qt-solutions repository (http://qt.gitorious.org/qt-solutions), which allows for using QtSingleApplication with Qt5 (http://qt.gitorious.org/qt-solutions/qt-solutions/merge_requests/7). However, there seems to be no activity when it comes to reviewing and approving merge request for this repository. ___ 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] Contributing to the Qt Project behind a hefty firewall and proxy server
But let's make sure that we are NOT recommending that people circumvent IT network policies. If the IT infrastructure blocks the traffic, then they must have a reason for it. It can be because: 1) the block is overly broad and shouldn't be there or 2) the block is intentional and the Git/Gerrit/SSH traffic should not be permitted We simply don't know which it is. The use by that user of the SSH server running on port 443 could lead to a violation of the corporate network security policy. We must make it clear that we are not responsible and that the user must figure that out with their people. Which leads me to my suggestion: if your firewall blocks the traffic to port 29418, create the IT ticket now and get an approved way of doing Gerrit traffic. Follow the company's procedures. +1 And the best way to ensure that it gets done is to prove that you cannot work without the solution. Prove it by spending a week idling because you could not do your work. That's also valid for consultants. I personally believe that, this is not the good practical approach of achieving those goals or getting a good impression at the company, but it depends on the supervisor and management as well, I guess. :-) Yes, I have worked for big companies and I still do. In both Nokia and Intel, there are approved ways of accessing those ports that don't involve circumventing the security policy. The situation is simpler with big companies like Nokia and Intel since they work on open source projects as well, and some of those are hosted publically using Git, SSH, and so forth as you enumerated. Therefore, it is quite reasonable to have that internal support in place by default. This is unfortunately not the case for many big companies. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Experimental Qt 5 installers by Digia
Ok... thanks. 2012/7/13 marius.storm-ol...@nokia.com When using the links below, please ensure that you are not redirected to URLs which has “origin.” prefixed. If you are on a http://origin.releases.qt-project.org/... URL, you are downloading from the “master” machine, and it will be slow. Simply remove the “origin.” prefix, and you should be using the CDN, and download the packages much much faster. ** ** We are not quite sure why this redirect is happening. ** ** -- .marius ** ** *From:* releasing-bounces+marius.storm-olsen=nokia@qt-project.org[mailto: releasing-bounces+marius.storm-olsen=nokia@qt-project.org] *On Behalf Of *ext Turunen Tuukka *Sent:* Thursday, July 12, 2012 9:00 AM *To:* releas...@qt-project.org; development@qt-project.org *Subject:* [Releasing] Experimental Qt 5 installers by Digia ** ** ** ** Hi All, ** ** As you know we have been working in close co-operation in the Qt Project for making the installers for Qt 5 as well as the tools to create these.** ** ** ** If you wish, you can take a look on the experimental installers we create at: http://releases.qt-project.org/digia/ ** ** Currently the installers are built each night from the latest stable Qt 5 and placed to the above mentioned location. If the build or packaging fails, then that installer is omitted. Though called beta1, these are currently made with the latest Qt 5, which as we know has not yet reached beta maturity. ** ** These are additional to the ones you can get from http://releases.qt-project.org/qt5.0/beta-snapshots/ In essence these should be identical. While we cook with the same recipes, these are baked in our kitchen that has some differences to the Qt Project build machines. So sometimes there are differences in the created installers as well. Having two different setups is good in verifying that the recipes really work and that there are not too many 'secret ingredients' in either one of the cookings. ** ** Unfortunately we can not yet provide build logs or release test results, so it may be hard to determine what is wrong based on just these. Also we are not running any automated tests to these installers like we do for the Qt 4.8 ones, so there may well be whatever regressions in these. So please regard these as experimental installers that they are. ** ** Yours, ** ** -- Tuukka Turunen Director, Qt Commercial RD Digia Plc Piippukatu 11, 40100 Jyväskylä, Finland Visit us at: www.digia.com or qt.digia.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
