Re: [Development] QNoDebug - available but undocumented
On Thursday 30. July 2015 13:33:28 Tomasz Siekierda wrote: Hi, just a quick observation: QNoDebug class can be used in code (compiles, works fine), but there is no documentation for it. Is that intentional? Shouldn't it be either hidden (made private) or documented? Although I have just learned about it's existence by accident, it looks like it can be quite useful, so I vote for adding some docs. It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is defined. That way the code compiles but is optimized away. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
On Thursday 30 July 2015 11:47:16 Olivier Goffart wrote: On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote: Hi The behavior of QString::trimmed has changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? This is caused by 54da2b2911ace652dbd2c8ea852c5b8c47ab09c8 in qtbase. I don't think it was intended. Actually, it was. Trimming a string that doesn't need trimming returns the original string. An empty string doesn't need trimming, therefore you get exactly what you had. But PLEASE stop relying on functions that mutate strings to reliably retain or fail to retain the nullness of a string. Unless the documentation for the particular function makes a distinction between null and not null, assume it will behave arbitrarily and will change in behaviour. By the way: the output of qDebug is not as expected: there are additional whitespaces before true/false and there is even another one before null at the first Before trim output. That is expected. qDebug automatically add spaces. It always did that and it is very convinient in must cases. Use qDebug().nospace() foo: foo; if you really don't want the spaces. -- 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
Re: [Development] QtQuick TestCase with other top windows
From: development-bounces+mitch.curtis=theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Filippo Cucchetto Sent: Wednesday, 29 July 2015 9:53 PM To: development@qt-project.org Subject: [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
I wrote that and i basically broke the one definition rule of C++ since in the .pro http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro file i added the plugin cpp files. This results in one definition of QQuickMenuBar inside the plugin and one inside the test. I think that this could be solved if we export those classes from the plugin and the test links to it (see the point (3) of my previous email). 2015-07-30 8:09 GMT+02:00 Curtis Mitch mitch.cur...@theqtcompany.com: *From:* development-bounces+mitch.curtis= theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis= theqtcompany@qt-project.org] *On Behalf Of *Filippo Cucchetto *Sent:* Wednesday, 29 July 2015 9:53 PM *To:* development@qt-project.org *Subject:* [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QString behavior change
Hi The behavior of QString::trimmed has changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? By the way: the output of qDebug is not as expected: there are additional whitespaces before true/false and there is even another one before null at the first Before trim output. Thanks Best regards Gerhard qDebug() String with space; QString my_string( ); qDebug() Before trim: empty: my_string.isEmpty() null: my_string.isNull(); my_string = my_string.trimmed(); qDebug() After trim: empty: my_string.isEmpty() null: my_string.isNull(); qDebug() \nEmpty string; my_string = ; qDebug() Before trim: empty: my_string.isEmpty() null: my_string.isNull(); my_string = my_string.trimmed(); qDebug() After trim: empty: my_string.isEmpty() null: my_string.isNull(); Output: String with space Before trim: empty: false null: false After trim: empty: true null: true Empty string Before trim: empty: true null: false After trim: empty: true null: false ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
On 2015-07-30 03:38, Gerhard Scheikl wrote: The behavior of QString::trimmed has changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? Whether or not it is¹ should not be relevant; QString has for a very long time (since mid-4.x at least if not 4.0 or even longer) STRONGLY discouraged differentiating between empty and null states. Don't do that :-). (¹ For a more literal answer, see Thiago's reply.) By the way: the output of qDebug is not as expected: there are additional whitespaces before true/false and there is even another one before null at the first Before trim output. qDebug() String with space; QString my_string( ); qDebug() Before trim: empty: my_string.isEmpty() null: my_string.isNull(); my_string = my_string.trimmed(); qDebug() After trim: empty: my_string.isEmpty() null: my_string.isNull(); Output: String with space Before trim: empty: false null: false After trim: empty: true null: true Your expectation that is wrong ;-). As noted, QDebug adds spaces between things, and you have a space in ' null:', so the expected output is two spaces between the previous item and null; one added automatically by QDebug, and one that you printed explicitly. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
I thought that you were writing tests within Qt? From: Filippo Cucchetto [mailto:filippocucche...@gmail.com] Sent: Thursday, 30 July 2015 8:41 AM To: Curtis Mitch mitch.cur...@theqtcompany.com Cc: development@qt-project.org Subject: Re: [Development] QtQuick TestCase with other top windows I wrote that and i basically broke the one definition rule of C++ since in the .prohttp://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro file i added the plugin cpp files. This results in one definition of QQuickMenuBar inside the plugin and one inside the test. I think that this could be solved if we export those classes from the plugin and the test links to it (see the point (3) of my previous email). 2015-07-30 8:09 GMT+02:00 Curtis Mitch mitch.cur...@theqtcompany.commailto:mitch.cur...@theqtcompany.com: From: development-bounces+mitch.curtis=theqtcompany@qt-project.orgmailto:theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtismailto:development-bounces%2Bmitch.curtis=theqtcompany@qt-project.orgmailto:theqtcompany@qt-project.org] On Behalf Of Filippo Cucchetto Sent: Wednesday, 29 July 2015 9:53 PM To: development@qt-project.orgmailto:development@qt-project.org Subject: [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQuick TestCase with other top windows
yes i'm 2015-07-30 8:49 GMT+02:00 Curtis Mitch mitch.cur...@theqtcompany.com: I thought that you were writing tests within Qt? *From:* Filippo Cucchetto [mailto:filippocucche...@gmail.com] *Sent:* Thursday, 30 July 2015 8:41 AM *To:* Curtis Mitch mitch.cur...@theqtcompany.com *Cc:* development@qt-project.org *Subject:* Re: [Development] QtQuick TestCase with other top windows I wrote that and i basically broke the one definition rule of C++ since in the .pro http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro file i added the plugin cpp files. This results in one definition of QQuickMenuBar inside the plugin and one inside the test. I think that this could be solved if we export those classes from the plugin and the test links to it (see the point (3) of my previous email). 2015-07-30 8:09 GMT+02:00 Curtis Mitch mitch.cur...@theqtcompany.com: *From:* development-bounces+mitch.curtis= theqtcompany@qt-project.org [mailto:development-bounces+mitch.curtis= theqtcompany@qt-project.org] *On Behalf Of *Filippo Cucchetto *Sent:* Wednesday, 29 July 2015 9:53 PM *To:* development@qt-project.org *Subject:* [Development] QtQuick TestCase with other top windows Hi everyone this is my first post on the mailing list so please bear with me. Currently i'm trying to create some tests for the qtquick menuba. For achieving this i need to create an ApplicationWindow and sending events to it. Currently the TestCase qml component sends all the events to the Test window. This obviously doesn't fit my use case. I investigated a little how to fix that: 1) Add a battery of overloads for the mouseClick and keyPress functions that take a QWindow* parameter. Pros: the current tests are not effected by the change and it's a more general approach (useful in some particular cases like mine). Cons: a new set of functions. In particular from the qml side we will have the pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc. 2) Make the TestCase send the events to the window where a particular item belongs. However this works with the functions that take a QQuickItem as a parameter (like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't have a QQuickItem argument. The idea is to forward the key events to the currently active window (so the one that has the keyboard focus). Pros: no API bloat Cons: i implemented it and a lot of test cases broke. Basically most of them rely to the current TestCase behaviour to send events to the testcase window. This change broke some test where we have popups, like in the ComboBox tests. 3) Make a standalone C++ app for making such tests without touching the TestCase code. Pros: Current tests are not effected. Cons: Some code duplication. Furthermore, currently, most of classes inside the QtQuickControls plugin aren't exported so even if my app is linked to it i cannot use them. To be honest, i basically tried all the previous 3 options and if i'm the one to choose i would go with the option (1) since i don't want to break everyone's code. -- Filippo Cucchetto I’m probably missing something, but what’s wrong with extending the existing tst_menubar? http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp -- Filippo Cucchetto -- Filippo Cucchetto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wince and openssl
On 07/30/2015 12:16 AM, Gunnar Roth wrote: My effect is that QT_NO_SSL is defined which leads to 100’s of errors. And i did pass -openssl to configure. I patched configureapp.cpp by removing that no’s for opens and ssl ( the result i can see tomorrow) and by the way i think the sse2/3/4 no’s are also incorrect, i think you guys only think arm when thinking about wince. So you also disable -sse2 flag to configure when i compile for a intel or and wec2013 platform. At least i know about this this now. When compiling crossplatform you should trust the configure parameters. Give this a shot: https://codereview.qt-project.org/122437 I don't know about the SIMD autodetection, but it's probably a similar case of removing some old lines in configure. Regards Gunnar Roth Am 29.07.2015 um 18:46 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 29 July 2015 18:17:38 Andreas Holzammer wrote: I can agree on that its just that the default is to off. You just need to pass -openssl to configure and be good with it. Its default is to no because a normal windows ce user does not use openssl, so its just taking care of the normal usecase and not the cornercases. The default would mean that every CE user will need to run the configure check if its there, you will most likely need to pass additional include and lib folders anyhow to configure in order to make openssl linking possible, so its I think ok to require to pass -openssl to configure in order to switch it on. I don't agree with that. Just leave the default to auto and it will change to yes if it finds the headers. The -openssl option changes it to yes without checking the headers, so the link may build later because it's missing compiler flags. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] wince and openssl
Hello Andreas,
maybe you read my mail to fast. Especially , you seem to have skipped the
SSL support.no
OpenSSL support.yes
and
I assume this this is with -openssl passed to configure? From my reading
of the code, thats the only possibility. Is openssl in your
parts.
So yes i actually did pass -openssl. But as you can learn from reading my mail carefully,
this does not work out as ssl is still NO. If i remove
dictionary[ SSL ] = no;
dictionary[ OPENSSL ] = no;
lines then it works and i get yes for openssl and yes for ssl, when passing -openssl.
Andy Shaw was so kind to make a patch at gerrit
https://codereview.qt-project.org/#/c/122437/
please have a look at it.
Regards,
Gunnar
Gesendet:Mittwoch, 29. Juli 2015 um 18:17 Uhr
Von:Andreas Holzammer andreas.holzam...@kdab.com
An:development@qt-project.org
Betreff:Re: [Development] wince and openssl
Am 29.07.2015 um 18:04 schrieb Andrew Knight:
Hi,
On 07/29/2015 06:49 PM, Gunnar Roth wrote:
Hi,
i am trying to make a wec2013 build with openssl support and got weird
errors.
What kind of errors?
then i just found this in configureapp.cpp
} else if (dictionary.value(XQMAKESPEC).startsWith(wince)) {
dictionary[ STYLE_WINDOWSXP ] = no;
dictionary[ STYLE_WINDOWSVISTA ] = no;
dictionary[ STYLE_FUSION ] = no;
dictionary[ STYLE_WINDOWSCE ] = yes;
dictionary[ STYLE_WINDOWSMOBILE ] = yes;
dictionary[ OPENGL ] = no;
dictionary[ SSL ] = no;
dictionary[ OPENSSL ] = no;
Why is that? Why did configure not warn me?
Hmm ok now i found:
SSL support.no
OpenSSL support.yes
in my output... thats strange. ..
I assume this this is with -openssl passed to configure? From my reading
of the code, thats the only possibility. Is openssl in your
config.summary or the contents of mkspecs/qconfig.pri?
but hmm then i saw:
if (dictionary[SSL] == auto) {
if (platform() == WINDOWS_RT) {
dictionary[SSL] = yes;
} else {
// On Desktop Windows openssl and ssl always have the same
value (for now). OpenSSL is
// the only backend and if it is available and should be
built, that also means that
// SSL support in general is enabled.
if (dictionary[OPENSSL] == auto)
dictionary[OPENSSL] = checkAvailability(OPENSSL) ?
yes : no;
dictionary[SSL] = dictionary[OPENSSL];
}
}
and i found that the default is:
dictionary[ SSL ] = auto;
dictionary[ OPENSSL ] = auto;
so fo any mkspec which start with wince ssl is set from auto to NO.
But why? And why is there no error when is goive openssl option to
configure?
Bug?
Not necessarily, because FWICT it is just defaulting to no instead of
auto. Maybe thats just a bad default, or maybe OpenSSL is (or was)
known to not work properly on WEC.
I can agree on that its just that the default is to off. You just need
to pass -openssl to configure and be good with it. Its default is to no
because a normal windows ce user does not use openssl, so its just
taking care of the normal usecase and not the cornercases. The default
would mean that every CE user will need to run the configure check if
its there, you will most likely need to pass additional include and lib
folders anyhow to configure in order to make openssl linking possible,
so its I think ok to require to pass -openssl to configure in order to
switch it on.
Thank you
Andy
--
Andreas Holzammer andreas.holzam...@kdab.com Senior Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
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] QtWebEngine and VS 2015
Hmmm ok, but for me it looks lije it is supported in master,
https://chromium.googlesource.com/chromium/src/+/master/build/vs_toolchain.py
1. def_VersionNumber():
2. Gets the standard version number ('120', '140', etc.) based on
3. GYP_MSVS_VERSION.
4. ifos.environ['GYP_MSVS_VERSION']=='2013':
5. return'120'
6. elifos.environ['GYP_MSVS_VERSION']=='2015':
7. return'140'
8. else:
9. raiseValueError('Unexpected GYP_MSVS_VERSION')
Regards,
Gunnar
Am 30.07.2015 um 11:43 schrieb Allan Sandfeld Jensen:
On Thursday 30 July 2015, Gunnar Roth wrote:
Hello,
does anybody now if and when QtWebEngine will build with VS1025?
When Chromium starts supporting building with VS2015. So far it doesn't looks
like it will be in 5.6
`Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebEngine and VS 2015
They are working on it. The first step in working on it is detecting it.
`Allan
On Thursday 30 July 2015, Gunnar Roth wrote:
Hmmm ok, but for me it looks lije it is supported in master,
https://chromium.googlesource.com/chromium/src/+/master/build/vs_toolchain.
py
1. def_VersionNumber():
2. Gets the standard version number ('120', '140', etc.) based on
3. GYP_MSVS_VERSION.
4. ifos.environ['GYP_MSVS_VERSION']=='2013':
5. return'120'
6. elifos.environ['GYP_MSVS_VERSION']=='2015':
7. return'140'
8. else:
9. raiseValueError('Unexpected GYP_MSVS_VERSION')
Regards,
Gunnar
Am 30.07.2015 um 11:43 schrieb Allan Sandfeld Jensen:
On Thursday 30 July 2015, Gunnar Roth wrote:
Hello,
does anybody now if and when QtWebEngine will build with VS1025?
When Chromium starts supporting building with VS2015. So far it doesn't
looks like it will be in 5.6
`Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QtWebEngine and VS 2015
Hello, does anybody now if and when QtWebEngine will build with VS1025? I build Qt 5.5.0 for win32 64 bit but in th ened there was no qtwebengine build. I discovered qtwebengine\tools\qmake\mkspecs\features\functions.prf and added win32-msvc2015 to the line linux-g++*|win32-msvc2013|macx-clang: return(true) so it trys to start the build but fails in gyp. using python: c:\python27\python.exe version: 2.7.9 Using extra options found in c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\core\qtwebengine_extras.gypi Updating projects from gyp files... Traceback (most recent call last): File C:/RTIL/Shared/Qt/5.5.0/qt-src/qtwebengine/tools/buildscripts/gyp_qtwebengine, line 167, in module sys.exit(gyp.main(args)) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py, line 525, in main return gyp_main(args) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py, line 510, in gyp_main generator.GenerateOutput(flat_list, targets, data, params) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 2 420, in GenerateOutput config_name) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 2 325, in GenerateOutputForConfig target = writer.WriteSpec(spec, config_name, generator_flags) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 4 71, in WriteSpec spec) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 8 70, in WriteSources precompiled_header, spec) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 9 41, in WriteSourcesForArch for i in include_dirs]) File c:\rtil\shared\qt\5.5.0\qt-src\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py, line 3 12, in GypPathToNinja assert '$' not in path, path AssertionError: $(VSInstallDir)/VC/atlmfc/include Project MESSAGE: Running gyp_qtwebengine C:/RTIL/Shared/Qt/5.5.0/bld/WIN32-VS14-64/qtwebengine/src/core -D qt_cross_co mpile=0 -D qt_os=win32 -I config/windows.gypi -D qtwe_chromium_obj_dir=C:/RTIL/Shared/Qt/5.5.0/bld/WIN32-VS14-64/qtwe bengine/src/core/Debug_x64/obj/src/3rdparty/chromium -D perl_exe=perl.exe -D bison_exe=bison.exe -D gperf_exe=gper f.exe --no-parallel -D qt_gl=opengl -D disable_nacl=1 -D remoting=0 -D use_ash=0 -D disable_glibcxx_debug=1 -D remove _webcore_debug_symbols=1 -D win_release_extra_cflags=-Zi -D target_arch=x64... Project ERROR: -- running gyp_qtwebengine failed -- What to do here? $(VSInstallDir)/VC/atlmfc/include is there i even set VSINSTALLDIR by hand without success. Regards, Gunnar Roth ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QString behavior change
On Thursday 30. July 2015 09:38:12 Gerhard Scheikl wrote: Hi The behavior of QString::trimmed has changed from 5.3.2 to 5.5. .trimmed() on an empty string ( ) makes it null .trimmed() on an empty string () doesn't make it null Is this intended or a bug? This is caused by 54da2b2911ace652dbd2c8ea852c5b8c47ab09c8 in qtbase. I don't think it was intended. By the way: the output of qDebug is not as expected: there are additional whitespaces before true/false and there is even another one before null at the first Before trim output. That is expected. qDebug automatically add spaces. It always did that and it is very convinient in must cases. Use qDebug().nospace() foo: foo; if you really don't want the spaces. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebEngine and VS 2015
On Thursday 30 July 2015, Gunnar Roth wrote: Hello, does anybody now if and when QtWebEngine will build with VS1025? When Chromium starts supporting building with VS2015. So far it doesn't looks like it will be in 5.6 `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QNoDebug - available but undocumented
Hi, just a quick observation: QNoDebug class can be used in code (compiles, works fine), but there is no documentation for it. Is that intentional? Shouldn't it be either hidden (made private) or documented? Although I have just learned about it's existence by accident, it looks like it can be quite useful, so I vote for adding some docs. T. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
