Re: [Development] wince and openssl

2015-07-30 Thread Gunnar Roth 

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, that's 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" 
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, that's 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 that's 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) GmbH&Co 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] QString behavior change

2015-07-30 Thread Matthew Woehlke 
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] QString behavior change

2015-07-30 Thread Thiago Macieira 
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] QNoDebug - available but undocumented

2015-07-30 Thread Olivier Goffart 
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

[Development] QNoDebug - available but undocumented

2015-07-30 Thread Tomasz Siekierda 
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

Re: [Development] QtWebEngine and VS 2015

2015-07-30 Thread Allan Sandfeld Jensen 
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

Re: [Development] QtWebEngine and VS 2015

2015-07-30 Thread Gunnar Roth 


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] QString behavior change

2015-07-30 Thread Olivier Goffart 
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

2015-07-30 Thread 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

2015-07-30 Thread Gunnar Roth 

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 

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

[Development] QString behavior change

2015-07-30 Thread Gerhard Scheikl 
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] wince and openssl

2015-07-30 Thread Andrew Knight 
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 :
>>
>> 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] QtQuick TestCase with other top windows

2015-07-30 Thread Filippo Cucchetto 
yes i'm

2015-07-30 8:49 GMT+02:00 Curtis Mitch :

>  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 
> *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
> 
> 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 :
>
>*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