Re: [Development] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Kurt Pattyn]

Marc,

It is clear that your main concern is performance (needless conversions) and 
convenience (being able to work efficiently with 3rd party libraries).
Regarding performance, I think it would be good if we could come up with some 
numbers. How 'bad' is the current implementation compared to an 'ideal' 
situation? And then define some acceptable target keeping into account 
convenience. Otherwise I am afraid that discussions can keep going forever over 
1 instruction more or less.
Regarding convenience, and that is what Qt is all about, I think you made a 
tremendous proposal that can really bring Qt a big step forward. The idea is 
very sound and clear. Of course, there are technical challenges, but that is 
what we are supposed to solve.

I also agree that we should aim for simplicity. QString and QStringView is 
simple to understand, iff we can get rid of all other string related classes. 
The ideal case would be just to have one QString class, although I doubt that 
is achievable.

I think it would be good to come up with some real-world use-cases that show 
how a Qt user and a Qt application could benefit from your proposal. 
Personally, I never experienced a performance problem with QString; but then 
the applications I write are not very string oriented. I am a QString 
aficionado :-)

After all, what I really like about Qt is convenience, simplicity and 
portability. I think this should be the main focus of Qt, and that also implies 
smooth collaboration with the outside world.

Cheers,

Kurt

> On 16 Oct 2015, at 21:47, Marc Mutz  wrote:
> 
>> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
>> The conversion from one to the other is one instruction.
> 
> Which is one instruction too much for tail-call optimisation, e.g.
> 
> But the point was about std::string_view binary compatibility. As basically a 
> C struct with no ownership semantics, it would be a perfect vehicle to pass 
> strings around different programming languages and compilers, but only if the 
> ABI (ie. the data members) were specified.
> 
> -- 
> Marc Mutz  | 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] RFC: Proposal for a semi-radical change in Qt APIs taking strings

[Kurt Pattyn]

graphics stack is more a 
bottleneck than string handling.
> 
> And please don't forget that QString fanboys can continue to massacre the 
> heap 
> if they so wish. After all, we've had QStringRef for a long time now, but 
> most 
> people still write str.mid(n).toInt() instead of str.midRef().toInt(). 
> QStringView won't change that: A function taking QStringView accepts a 
> QString, too (either by implicit conversion, or where it makes sence, by 
> QString overload).
The word 'fanboys' disturbs me (I know you don't mean it that way) because 
there are no 'hard' numbers on how 'bad' the current situation really is.
It would really be helpful to have an idea how 'real-world' applications suffer 
from the current implementation of QString. That would give a very good context 
to decide how Qt can help to leverage these problems.

That said, I like the idea of QStringView.

Cheers,

Kurt
> 
> Thanks,
> Marc
> 
>> On Friday 16 October 2015 21:42:23 Kurt Pattyn wrote:
>> Marc,
>> 
>> It is clear that your main concern is performance (needless conversions)
>> and convenience (being able to work efficiently with 3rd party libraries).
>> Regarding performance, I think it would be good if we could come up with
>> some numbers. How 'bad' is the current implementation compared to an
>> 'ideal' situation? And then define some acceptable target keeping into
>> account convenience. Otherwise I am afraid that discussions can keep going
>> forever over 1 instruction more or less. Regarding convenience, and that
>> is what Qt is all about, I think you made a tremendous proposal that can
>> really bring Qt a big step forward. The idea is very sound and clear. Of
>> course, there are technical challenges, but that is what we are supposed
>> to solve.
>> 
>> I also agree that we should aim for simplicity. QString and QStringView is
>> simple to understand, iff we can get rid of all other string related
>> classes. The ideal case would be just to have one QString class, although
>> I doubt that is achievable.
>> 
>> I think it would be good to come up with some real-world use-cases that
>> show how a Qt user and a Qt application could benefit from your proposal.
>> Personally, I never experienced a performance problem with QString; but
>> then the applications I write are not very string oriented. I am a QString
>> aficionado :-)
>> 
>> After all, what I really like about Qt is convenience, simplicity and
>> portability. I think this should be the main focus of Qt, and that also
>> implies smooth collaboration with the outside world.
>> 
>> Cheers,
>> 
>> Kurt
>> 
>>>> On 16 Oct 2015, at 21:47, Marc Mutz <marc.m...@kdab.com> wrote:
>>>> On Friday 16 October 2015 19:31:50 Thiago Macieira wrote:
>>>> The conversion from one to the other is one instruction.
>>> 
>>> Which is one instruction too much for tail-call optimisation, e.g.
>>> 
>>> But the point was about std::string_view binary compatibility. As
>>> basically a C struct with no ownership semantics, it would be a perfect
>>> vehicle to pass strings around different programming languages and
>>> compilers, but only if the ABI (ie. the data members) were specified.
> 
> -- 
> Marc Mutz <marc.m...@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

[Development] Which branch to commit patch

[Kurt Pattyn]

Hi,

I have resolved a DoS vulnerability in the Qt WebSockets module (see 
https://bugreports.qt.io/browse/QTBUG-48123).
Which branch should I commit this patch to: 5.3, 5.4, 5.5, 5.6 or dev?
This issue is present from the very first version (since Qt 5.3).

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Avoid overloading of 'error'

[Kurt Pattyn]

Well,

you can also think of “on” + event, like in: onWindowClosed, onMouseClicked, 
onBytesReceived, …
In the same analogy, you could have onErrorOccurred.

Seems very intuitive to me.

It depends if you want to react to a state or to the event causing that state.

Cheers,

Kurt

 On 11 Jun 2015, at 20:29, Alan Alpert 4163654...@gmail.com wrote:
 
 On Thu, Jun 11, 2015 at 7:11 AM, Hausmann Simon
 simon.hausm...@theqtcompany.com wrote:
 Hi,
 
 I agree about the inconsistency in tense, that is a good argument against 
 error(),
 although it is similarly unfortunate that the inconsistency in tense is more 
 widespread than
 assumed.
 
 I'm not sure onErred or onErrored is any better, to be honest. I think it's 
 more likely
 to result in a typo than the most basic form of the word - error - instead 
 of some conjugation.
 
 In the light of that I think I'd prefer onFailed or onFailure - but I think 
 it would perhaps be
 a mistake to make our existing APIs more inconsistent than necessary. It 
 seems like an
 unfortunate choice, but I think it's better to stick to error() than to have 
 some QML types
 have onError and some have onFailure.
 
 I strongly advocate against replacing onError with onFailure. The
 issue as I see it is a conflict between classic (perhaps BASIC
 derived?) convention of handlers being on + state noun versus our
 convention of on + past tense verb. Failure, Error (and success,
 completion etc.) are all the old convention so it's not worth moving
 from Error just to another word in the same convention that we're
 trying to escape from. I also don't like to conceptually pin error to
 failure, because in rare cases you can still have a partial success
 despite an error condition.
 
 Since there is this other convention that uses onError a lot (at
 least in XMLHttpRequest), I can see how a similar (but past tense)
 word would be confusing to many developers. So now we're weighing the
 cost of confusing both new and old developers just to make the
 refactoring support work better. I'm no longer convinced it's
 worthwhile, so I'm with Simon on that it's better to stick to error()
 for now. At least for the QML exposed APIs.
 
 If I break out the thesaurus, then we also have
 
  errorBefell
 
 If we want to sound fancy, we can use an obscure language and then it
 can be shorter too: tokFeil . Also solves the problem of looking like
 other APIs, as they limited themselves to English.
 
 --
 Alan Alpert
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Module for Serial Buses

[Kurt Pattyn]

I wonder if you also need hot-plug detection?

 On 29 May 2015, at 11:43, Viironen Kalle kalle.viiro...@theqtcompany.com 
 wrote:
 
 
 
 On 28/05/15 09:22, Knoll Lars lars.kn...@theqtcompany.com wrote:
 
 On 26/05/15 20:14, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote:
 On 26/05/15 19:42, Thiago Macieira thiago.macie...@intel.com wrote:
 
 
 On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
 
 Good point :)
 I was under the assumption that the concepts are too different, but
 if
 they
 aren't then maybe a joint module would make sense.
 
 
 At the very least it's a superset and QtSerialPort (the library)
 should
 be 
 moved into the new module. It's just two classes anyway.
 
 
 I fully agree. At some point QtSerialPort should be moved under this
 new
 module. Problem with QtSerialPort is that it’s so tightly tied into
 RS-232
 functionality that its extension to support other serial buses isn’t
 feasible.
 
 Fair enough.
 
 Can you give an overview of what classes you'd like to have and how
 QSerialPort and QSerialPortInfo would fit into the naming scheme?
 
 I’m all for having a new module and would prefer Qt SerialBus over Qt Bus.
 
 Grouping QSerialPort under it would make sense, but we’d need to
 reconsider the naming of these classes in this case. If we have a couple
 of different new implementations for other things such as CAN, i2c etc, we
 might need slightly less generic class names for them.
 
 So I’d also appreciate a quick overview over the new classes you’d like to
 add, and how we could get the overall class naming to work out.
 
 In the first mail there is an pdf attachment that describes the high level
 structure as it’s planned. So the architecture would be pretty much like
 what’s used in qtsensors module.
 
 The core classes in QtSerialBus would be something like:
 - QSerialBus
 - QSerialBusDeviceBackend
 - QSerialBusPluginInterface
 - QSerialBusPluginFactory
 
 - QSerialBusDevice (inherits QIODevice)
 - QSerialBusDeviceFilter
 
 All bus specific functionality would be in backend plugins and in bus
 specific classes inherited from QSerialBusDevice and
 QSerialBusDeviceFilter.
 
 So the idea is not to hide the actual bus from application developer but
 rather to provide an easy to use core architecture that can be used when
 developing support for different serial buses.
 
 -Kalle
 
 ___
 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] Binary compatibility issue 5.4.1?

[Kurt Pattyn]

Hi,

we compiled a project using Qt 5.4.1 (Windows 7 64-bit MSVS 2013) and then 
tried to run it on a computer with Qt 5.3.2 installed.
We received the following popup:



Is there any chance that this is still a binary compatibility problem?
Of so, I will enter it into the bugreports.

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5

[Kurt Pattyn]

 On 11 Dec 2014, at 08:30, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Wednesday 10 December 2014 17:42:06 Thiago Macieira wrote:
 Explanation:
 * runtime: dynamically open libdbus-1 at runtime
 * linked: link to libdbus-1
 * configure1: check at configure time if libdbus-1 is present in the
 system  and then enable runtime mode
 * configure2: check at configure time if libdbus-1 is present in the
 system; if it is, enable linked mode, otherwise runtime
 
 In other words: starting with Qt 5.4.1, QtDBus will be enabled FOR ALL
 BUILDS. 
 
 Clarifying after question on IRC: will be enabled by default for all builds 
 on 
 all OS. Unless you pass -no-dbus, of course.
Will it be enabled using configure1 or configure2?

 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiler warnings

[Kurt Pattyn]

Leaving out the parameter name is not a problem. A better approach is marking 
the parameter as unused. But, the potential problem lays in breaking semantic 
compatibility.
A very nice example is: http://en.m.wikipedia.org/wiki/Cluster_(spacecraft)
Interfaces were compatible, semantics were not. That's why I said before that 
in such a case binary compatibility must be broken. That's also why Lars once 
rejected a patch of mine where I replaced float comparisons with qFuzzyCompare.

As we are developing for aerospace, avionics, defence and healthcare, we are 
confronted on a daily basis with a lot of very stringent rules that we have to 
comply with (irrespective if some people might find these rules outdated, 
stupid, ridiculous or not). That's why we always compile with as much compiler 
warnings as possible. Our code must be audited by an external office anyways, 
so we better make sure we can avoid a bad report as soon as possible.
Some examples of 'stupid' rules (which after second consideration aren't that 
stupid after all):
- a switch statement must always have a default statement (also all cases must 
be handled)
- always use curly braces with blocks (if, for,while, ... statements), even if 
it is only one line.
- never interchangeably use signed and unsigned variables
- never leave commented out code in the source
- ...

Because we use Qt in a lot of our software (not aerospace and avionics where 
Ada is king), it is in our interest to have warnings of the public API be 
reduced to a minimum.
Nothing more, nothing less.

I want to contribute patches, but if people find it nitpicking and not worth 
the effort, then it is useless to spend my precious time on it.

Cheers,

Kurt

 On 16 Oct 2014, at 21:04, Kevin Kofler kevin.kof...@chello.at wrote:
 
 Kurt Pattyn wrote:
 On second thought, I think this is a very bad example. Even while you keep
 binary compatibility, you break semantics here. This is typically a case
 where one should break binary compatibility.
 I am sure (or at least I hope so) that Qt does not allow these kind of
 things.
 
 Qt also tries to maintain partial source compatibility with previous 
 versions, so, e.g., Qt 4 has these Qt3Support members of QWidget:
 
 void QWidget::repaint ( bool b )
 The boolean parameter b is ignored. Use the no-argument overload instead.
 
 void QWidget::repaint ( int x, int y, int w, int h, bool b )
 The boolean parameter b is ignored. Use the four-argument overload instead.
 
 void QWidget::repaint ( const QRect  r, bool b )
 The boolean parameter b is ignored. Use the single rect-argument overload 
 instead.
 
 void QWidget::repaint ( const QRegion  rgn, bool b )
 The boolean parameter b is ignored. Use the single region-argument overload 
 instead.
 
 void QWidget::setBackgroundMode ( Qt::BackgroundMode widgetBackground, 
 Qt::BackgroundMode paletteBackground = Qt::PaletteBackground )
 Sets the color role used for painting the widget's background to background 
 mode widgetBackground. The paletteBackground mode parameter is ignored.
 
 
 I also remember having encountered other functions where parameters were 
 documented as no longer used, and even functions documented as having no 
 effect anymore, but those were probably in KDE libraries, not in Qt itself.
 
Kevin Kofler
 
 ___
 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] Compiler warnings

[Kurt Pattyn]

 On 17 Oct 2014, at 10:15, Christian Kandeler christian.kande...@digia.com 
 wrote:
 
 On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
 As we are developing for aerospace, avionics, defence and healthcare, we are 
 confronted on a daily basis with a lot of very stringent rules that we have 
 to comply with (irrespective if some people might find these rules outdated, 
 stupid, ridiculous or not). That's why we always compile with as much 
 compiler warnings as possible. Our code must be audited by an external 
 office anyways, so we better make sure we can avoid a bad report as soon as 
 possible.
 Some examples of 'stupid' rules (which after second consideration aren't 
 that stupid after all):
 - a switch statement must always have a default statement (also all cases 
 must be handled)
 
 Doesn't this actually make the code *worse* when using enums? Adding a 
 default statement when you handle all possible values will inhibit 
 genuine compiler warnings when you forget to add a case for a newly 
 added enum value. In fact, this is almost guaranteed to happen in a 
 non-trivial project, so this rule seems almost absurdly wrong to me.
Regulations are usually not an example of common sense :-) Maybe version 
2020-TR/A-99576-37A-ammendment37bis will remove this :-) Sigggh
 
 
 Christian
 
 ___
 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] Compiler warnings

[Kurt Pattyn]

 On 17 Oct 2014, at 12:54, Sean Harmer sean.har...@kdab.com wrote:
 
 On 17/10/2014 11:44, Bo Thorsen wrote:
 Den 17-10-2014 12:22, Julien Blanc skrev:
 On 17/10/2014 10:15, Christian Kandeler wrote:
 On 10/17/2014 08:48 AM, Kurt Pattyn wrote:
 As we are developing for aerospace, avionics, defence and healthcare, we 
 are confronted on a daily basis with a lot of very stringent rules that 
 we have to comply with (irrespective if some people might find these 
 rules outdated, stupid, ridiculous or not). That's why we always compile 
 with as much compiler warnings as possible. Our code must be audited by 
 an external office anyways, so we better make sure we can avoid a bad 
 report as soon as possible.
 Some examples of 'stupid' rules (which after second consideration aren't 
 that stupid after all):
 - a switch statement must always have a default statement (also all cases 
 must be handled)
 Doesn't this actually make the code *worse* when using enums? Adding a
 default statement when you handle all possible values will inhibit
 genuine compiler warnings when you forget to add a case for a newly
 added enum value. In fact, this is almost guaranteed to happen in a
 non-trivial project, so this rule seems almost absurdly wrong to me.
 That one is always subject to debate. There is one thing not to forget
 in favor of this rule : enums are *not* guaranted to have a value
 amongst the defined ones. Undefined behaviour in that case is not an option.
 
 I wish i could have both a default statement and my compiler warning…
 switch (enumValue) {
 case E1: ...; break;
 case E2: ...; break;
 
 case Nope1:
 case Nope2:
// Intentionally not handled
break;
 }
 
 Boom. Can I invoice you for this now? :)
 
 See also, Q_UNREACHABLE().
Indeed, but the main reason that all cases must be handled is to avoid 
arbitrary crashes of an application.
And handling does not mean just adding comments. We cannot afford that an X-Ray 
scanner crashes while beaming its X-rays onto a patient.
We cannot afford that a Boeing goes down because the software just crashes.
We speak of life critical applications here; in all other cases, most of these 
measures are merely overkill.
Q_UNREACHABLE() is fine if we can *prove* that indeed it will never be reached; 
the latter being nearly impossible.

 
 Cheers,
 
 Sean
 
 -- 
 Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
 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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Compiler warnings

[Kurt Pattyn]

Christian,

the problem is often when your software has to be integrated into other 
software and systems, which is almost always the case in life-critical systems.
If your software is controlling a critical component like an X-ray beamer for 
instance, you’d better be prepared for all kinds of rubbish that can enter your 
software.
The same holds for cockpit displays for instance; they need to take in a lot of 
external signals, and that can go wrong.
It is more like ‘Be prepared for the worst and nothing will happen’.

Cheers,

Kurt

 On 17 Oct 2014, at 13:10, Christian Kandeler christian.kande...@digia.com 
 wrote:
 
 On 10/17/2014 01:06 PM, Milian Wolff wrote:
 I think you are missing something:
 
 enum Foo {
 Bar = 1, Baz = 2
 };
 
 Foo foo = static_castFoo(3);
 
 If you start to guard against this kind of stuff, where does it end?
 
 void f(void *p);
 
 f(reinterpret_castvoid *(5));
 
 Is f supposed to catch that?
 
 
 Christian
 
 ___
 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] Compiler warnings

[Kurt Pattyn]

On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote:

 Kurt Pattyn pattyn.k...@gmail.com wrote:
 On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote:
 
 Den 14-10-2014 08:59, Kurt Pattyn skrev:
 how do these applications comply with MISRA?
 
 MISRA is impossible to comply with for a framework. For example, 
 consider the required rule 0-1-11: There shall be no unused parameters 
 (named or unnamed) in non-virtual functions.
 
 With this, void f(int /*no_longer_used*/) is illegal. For any
 non-trivial framework that keeps binary compatibility, this will over time 
 be hit.
 
 On second thought, I think this is a very bad example. Even while you keep
 binary compatibility, you break semantics here. 
 This is typically a case where one should break binary compatibility.
 
 Are you seriously asking for a new major Qt release just because a 
 new implementation of some function does not require some parameter 
 anymore? 

Yes, if the semantics of the method changes. I can hardly imagine that
obsoleting a parameter from a method does not have any behavioural impact
in the calling application. This even holds for the case when the signature of
the method does not change at all, but the semantics do.
I remember once having replaced strict floating point compares with 
qFuzzyCompares.
Although this was internal to Qt this change was - correctly - rejected.

Cheers,

Kurt

 
 Andre'

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Branching scheme bugs

[Kurt Pattyn]

Hi,

After a long time, I finally found time again to help Qt forward (at least that 
is what I hope :-) ).
I have a few questions regarding the 'new' branching scheme:
1. Is this somewhere documented?
2. Where do bug fixes go? I talked to Peppe regarding this, and according to 
him, bugs should be committed to branch of the version the bug first manifested 
itself. Is this correct, as to my knowledge the 5.3 branch is read-only?
3. Where do new features go?

Kind regards,

Kurt

PS: It was nice meeting you guys at QtDD14.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Compiler warnings

[Kurt Pattyn]

Hi,

This has already been brought up before: when compiling an application/library 
using Qt and setting compiler warnings to comply with e.g. the Misra C++ rules, 
Qt generates a lot of warnings.
I already did some work on eliminating some of the warnings, but there are 
still quite a lot left.
A number of these changes never got through, having forced me to locally patch 
Qt to avoid them.

Now my questions:
1. Is it worth the (big) effort to try to remove these warnings from the public 
part of Qt?
2. Are there other people, esp. working in strongly regulated environments that 
have the same problem? I see that Qt is used a lot in the automotive industry: 
how do these applications comply with MISRA? 

Cheers,

Kurt


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QVariant with custom type to QML

[Kurt Pattyn]

Hi,

supplying a QVariant property containing a custom type towards QML does not 
work (even if it is registered as a metatype).

Currently I am explicitly converting the custom type to something QML 
understands, like:

if (variant.canConvertMyCustomType1()) {
MyCustomType1 t = variant.valueMyCustomType1();
//stream as QVariantMap
} else if (variant.canConvertMyCustomType2() {
MyCustomType2 t = variant.valueMyCustomType2();
//stream as QVariantMap
} …


Is there a conversion method available that makes it possible to 
‘automagically’ convert the custom type to a type suitable for QML?
Something like: MyCustomType1::toQmlType() …

Or can I use one of the QMetaType::registerConverter() to define a conversion 
from a POCO to a QML type?

Note: the custom types are currently only containing data; so, no methods need 
to be proxied or marshalled to QML.


Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Two-minute(!)-survey on motivation and free time contribution of open source developers

[Kurt Pattyn]

Hi Stefan,

I would appreciate if you could give a small explanation of what your research 
is about. People get bothered with surveys much too often.

Cheers,

Kurt


 On 22 Aug 2014, at 23:54, Stefan Kullack stefankull...@web.de wrote:
 
 Dear all,
  
 for a university research project at the Technical University Berlin 
 (Germany) I would like to gather some original input from open source 
 software developers. I kept the length of the survey to an absolute minimum!!!
  
 It would be fantastic if you could spend two minutes on three simple 
 questions!
  
 Here is the link to the survey: https://de.surveymonkey.com/s/MFKXYLP
  
 I highly appreciate the time you take for filling it out!
  
 Best regards,
  
 Stefan Kullack
  
 Master student of Innovation Management and Entrepreneurship at TU Berlin
  
 ___
 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] [HEADS UP] new branching scheme: 5.3 branches created, stable deprecated

[Kurt Pattyn]

 On 06 Jun 2014, at 12:23, Oswald Buddenhagen oswald.buddenha...@digia.com 
 wrote:
 
 On Fri, Jun 06, 2014 at 11:38:34AM +0200, Kurt Pattyn wrote:
 Just for clarity:
 * Is the release branch gone for developers?
 it's gone for everyone. it has been deleted.
 the next release branch will be 5.3.1, and you will push for it if you
 have critical changes for that release. just as before.
 
 * And is there only one dev branch? Suppose 5.4 is in the make and meanwhile 
 a 5.3.x patch release is being worked upon,
 where will the dev branch end up? Or should we just push our patches to the 
 5.3.x in that case?
 uhm ... huh?
 
 i'm amazed by what twisted ideas people come up, given that we are
 switching to a branching model which almost every other project on the
 planet uses, including qt creator ...
Well, a picture says more than a thousand words. A simple drawing with a Qt 5.x 
and Qt 5.x+1 branch and a 'future' Qt 6.x branch, together with stable and dev 
branches would clarify a lot. Suppose we want to work on a maintenance release 
of 5.x while 6.x is in the field: how will the branches look like?
 
 now on to hacking the wiki ...
 
 Cheers,
 
 Kurt
 
 On 06 Jun 2014, at 08:37, Knoll Lars lars.kn...@digia.com wrote:
 
 On 06/06/14 08:20, Thiago Macieira thiago.macie...@intel.com wrote:
 
 Em sex 06 jun 2014, às 14:00:19, Yuchen Deng escreveu:
 I'd say, the 'dev' even does not be a complete words.  so run a poll
 sounds
 be fair.
 
 Let's run at QtCS next week. I don't think we'll ever get a better
 sampling of 
 people involved in Qt development.
 
 Someone who feels strongly about the renaming should conduct a quick show
 of 
 hands during the plenary session.
 
 I don’t see why we’d need to rename dev. Nothing has changed for that
 branch. It has exactly the same meaning as before, and the same workflow.
 
 We have changed the other ones because we have a different scheme how we
 create these branches and merge between them.
 
 And for those confused where to push their changes:
 
 * If you were before pushing to dev, continue to do so.
 * If you were pushing to stable, push to 5.3 (Later on, you might have a
 choice of pushing to 5.3 or 5.4 depending on whether it’s critical enough
 to do another release of 5.3 as well once we have 5.4 out).
 * If we have a 5.x.y branch available (because we’re in the process of
 preparing a release), and you have a fix for a showstopper for that
 release, push to the 5.x.y branch.
 
 Cheers,
 Lars
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [HEADS UP] new branching scheme: 5.3 branches created, stable deprecated

[Kurt Pattyn]

Just for clarity:
* Is the release branch gone for developers?
* And is there only one dev branch? Suppose 5.4 is in the make and meanwhile a 
5.3.x patch release is being worked upon,
where will the dev branch end up? Or should we just push our patches to the 
5.3.x in that case?

Cheers,

Kurt

On 06 Jun 2014, at 08:37, Knoll Lars lars.kn...@digia.com wrote:

 On 06/06/14 08:20, Thiago Macieira thiago.macie...@intel.com wrote:
 
 Em sex 06 jun 2014, às 14:00:19, Yuchen Deng escreveu:
 I'd say, the 'dev' even does not be a complete words.  so run a poll
 sounds
 be fair.
 
 Let's run at QtCS next week. I don't think we'll ever get a better
 sampling of 
 people involved in Qt development.
 
 Someone who feels strongly about the renaming should conduct a quick show
 of 
 hands during the plenary session.
 
 I don’t see why we’d need to rename dev. Nothing has changed for that
 branch. It has exactly the same meaning as before, and the same workflow.
 
 We have changed the other ones because we have a different scheme how we
 create these branches and merge between them.
 
 And for those confused where to push their changes:
 
 * If you were before pushing to dev, continue to do so.
 * If you were pushing to stable, push to 5.3 (Later on, you might have a
 choice of pushing to 5.3 or 5.4 depending on whether it’s critical enough
 to do another release of 5.3 as well once we have 5.4 out).
 * If we have a 5.x.y branch available (because we’re in the process of
 preparing a release), and you have a fix for a showstopper for that
 release, push to the 5.x.y branch.
 
 Cheers,
 Lars
 
 ___
 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] Modules in qtbase (was: Re: new debugsupport module and API)

[Kurt Pattyn]

 On 13 May 2014, at 08:01, Knoll Lars lars.kn...@digia.com wrote:
 
 On 12/05/14 22:40, Thiago Macieira thiago.macie...@intel.com wrote:
 
 Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu:
 On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote:
 Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu:
 The following changes create a debugsupport module with public API
 in
 
 qtbase:
 Please create a new module. This doesn't need to be in qtbase.
 
 given that the two quick implementations will depend on it, it makes
 little sense to split it out, given what else is in qtbase.
 
 Neither implementation is in qtbase, so I don't see the logic in that
 argument. Yes, it *can* be in qtbase, but I don't see why it *should* be.
 
 I want to hear a reason of why it should.
 
 Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard
 enough to work with as it is.
 
 In that light:
 
 QtXml is there for historical reasons: there was code that needed it
 (including QtDBus). It can probably be moved out now.
 
 QtOpenGL and QtConcurrent are also historical and can probably be moved
 out 
 too. Especially since those three aren't getting almost any updates, it
 makes 
 sense to do it.
 
 QtDBus needs to stay because the XCB plugin needs it for some D-Bus
 protocols 
 (notifications, the new systray protocol, etc.)
 
 The rest of the libraries in qtbase are really base stuff.
 
 Actually I was thinking about splitting a few more things out. In addition
 to the ones mentioned above, I believe we would benefit from splitting
 QtNetwork out into it’s own module. The reason is that QtNetwork is
 responsible for many of the failing CI runs due to the inherent
 instability on the network tests. Splitting out the module should help
 make many of the qtbase integrations go more smoothly.
This makes sense. Maybe the WebSockets module can be integrated into the 
network module in that case?
I would also propose to move some code into qtbase: e.g. the matrix classes 
that are now in QtGui.

Cheers,

Kurt
 
 From what I can see nothing else in qtbase (apart from the bearer plugins)
 depends on qtnetwork, so a split should be possible.
 
 Cheers,
 Lars
 
 ___
 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] CMake integration and system headers

[Kurt Pattyn]

On 06 May 2014, at 11:40, Mikołaj Siedlarek msiedla...@nctz.net wrote:

 Hi,
 
 I’m on a quest to enable hack-free all-warnings-enabled building of my 
 project using, among others,
 Qt and CMake. This requires that compiler treat Qt headers included in my 
 code as “system headers”
 and not warn me about constructs used in them.
 
 I already contributed -iframework (Apple frameworks counterpart to -isystem) 
 flag support to CMake
 (https://github.com/Kitware/CMake/pull/100), so with 3.0 version it should 
 correctly handle properly
 marked include directories on all systems.
 
 The only problem is current CMake integration in Qt uses 
 INTERFACE_INCLUDE_DIRECTORIES
 target property, when to be provide a system include directory it should use
 INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. On compilers that do not support 
 -isystem flag
 CMake falls back to -I, so compatibility would not be a problem.
 
 The problem is current CMake integration in Qt requires version 2.8.3, but
 INTERFACE_SYSTEM_INCLUDE_DIRECTORIES is only available since 2.8.12. Before I 
 propose
 a patch I’d like to consult a maintainer of this system, or at least someone 
 more familiar with
 Qt release process, whether it’s best to add some CMake version checks or 
 version requirement
 can be bumped with next release.
 
 Please direct me to someone I can discuss this with, or tell me directly that 
 my idea is bad.
It is a very good idea to have the Qt files treated as system files. I’ve gone 
to great lengths to
filter out the warnings from Qt in our CMake files. It would be nice if this 
was included out-of-the-box.
One problem that is not fixed by the system flag, is the auto-generated files 
(moc files).
For those I have submitted a patch that should appear in Qt 5.3.1.
Personally I would not force version 2.8.12 as AFAIK that version is not 
available out-of-the-box on Debian
for instance.

Cheers,

Kurt
 
 Thanks,
 Mikołaj Siedlarek
 ___
 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] CMake integration and system headers

[Kurt Pattyn]

On 07 May 2014, at 11:15, Robert Knight robertkni...@gmail.com wrote:

 It is a very good idea to have the Qt files treated as system files.
 I’ve gone to great lengths to filter out the warnings from Qt in our CMake 
 files
 
 I would caution against that. Could we just fix the warnings in Qt
 headers instead?
That is of course the ideal way. A number of developers, including myself, are 
already looking to remove warnings from the public facing API of Qt. But this 
takes time. In the mean time, treating those headers as system headers lets 
developers build their applications with the -Werror flag.
As I understand it, these headers will not be added per default. One would 
still need the include-directories(SYSTEM) directive. Is that correct Mikolaj?
 
 I enabled suppression of warnings in Qt headers for a project a while
 back and ended up suppressing
 a real and serious warning that occurred when a generic class in Qt
 was instantiated with a particular
 type in my code. IIRC I was using QSharedPointerT with a 'T' which
 was only forward-declared at the point where
 ~QSharedPointerT ended up being instantiated. The normal warning got
 suppressed because it occurred in the
 Qt template class header even though the error was actually in
 relation to my code.
 
 Regards,
 Rob.
 
 
 On 7 May 2014 10:09, Mikołaj Siedlarek msiedla...@nctz.net wrote:
 On 07 May 2014, at 10:59, Kurt Pattyn pattyn.k...@gmail.com wrote:
 On 06 May 2014, at 11:40, Mikołaj Siedlarek msiedla...@nctz.net wrote:
 
 Hi,
 
 I’m on a quest to enable hack-free all-warnings-enabled building of my 
 project using, among others,
 Qt and CMake. This requires that compiler treat Qt headers included in my 
 code as “system headers”
 and not warn me about constructs used in them.
 
 I already contributed -iframework (Apple frameworks counterpart to 
 -isystem) flag support to CMake
 (https://github.com/Kitware/CMake/pull/100), so with 3.0 version it should 
 correctly handle properly
 marked include directories on all systems.
 
 The only problem is current CMake integration in Qt uses 
 INTERFACE_INCLUDE_DIRECTORIES
 target property, when to be provide a system include directory it should 
 use
 INTERFACE_SYSTEM_INCLUDE_DIRECTORIES. On compilers that do not support 
 -isystem flag
 CMake falls back to -I, so compatibility would not be a problem.
 
 The problem is current CMake integration in Qt requires version 2.8.3, but
 INTERFACE_SYSTEM_INCLUDE_DIRECTORIES is only available since 2.8.12. 
 Before I propose
 a patch I’d like to consult a maintainer of this system, or at least 
 someone more familiar with
 Qt release process, whether it’s best to add some CMake version checks or 
 version requirement
 can be bumped with next release.
 
 Please direct me to someone I can discuss this with, or tell me directly 
 that my idea is bad.
 It is a very good idea to have the Qt files treated as system files. I’ve 
 gone to great lengths to
 filter out the warnings from Qt in our CMake files. It would be nice if 
 this was included out-of-the-box.
 One problem that is not fixed by the system flag, is the auto-generated 
 files (moc files).
 
 I thought about that and I believe it could be fixed in CMake’s AUTOMOC 
 functionality. I’ll look into it.
 
 For those I have submitted a patch that should appear in Qt 5.3.1.
 Personally I would not force version 2.8.12 as AFAIK that version is not 
 available out-of-the-box on Debian
 for instance.
 
 Yes, it seems stable Debian has just been released with CMake 2.8.9, so it’s 
 gonna be here for a while.
 A version check then and fallback to INTERFACE_INCLUDE_DIRECTORIES.
 ___
 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] qDebug, qWarning, qCritical, qFatal in Qt source code

[Kurt Pattyn]

Hi,

I would like to know if there are any guidelines about using qDebug and friends 
in Qt source code?
Recently I had to remove qWarning statements from a submit (for very plausible 
reasons), but a quick search through qtbase revealed a lot of qWarning 
statements.

So are there any rules of thumb?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt WebSockets

[Kurt Pattyn]

 On 01 May 2014, at 22:31, Steve Gold steveg2...@gmail.com wrote:
 
 I just tried to run the echo client and server examples using 
 qt-opensource-windows-x86-android-5.3.0-RC_2014-04-29_22-03-28-79.exe and 
 MinGW on Windows 8 64 bit from Qt Creator. The server displays
 QIODevice::read: device not open
 QIODevice::read: device not open
 SSL Echo Server listening on port 1234
 when it runs but the client has a blank window and “Websocket connected” is 
 never shown.

If I understand correctly, you are running the example in an Android simulator 
running on W8 64-bit.
It is difficult to say what the problem could be. Can you debug into it?

Cheers,

Kurt
  
 It looks like there may be a problem here.
  
 Steve
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] No SSL on iOS ?

[Kurt Pattyn]

Could this be a solution: https://github.com/x2on/OpenSSL-for-iPhone ?
This project provides a script to make a static build of OpenSSL to be used on 
iOS 4.3 - iOS 7.1.

Cheers,

Kurt

On 02 May 2014, at 10:16, Jeremy Lainé jeremy.la...@m4x.org wrote:

 On 05/01/2014 03:51 PM, Jeremy Lainé wrote:
 One problem I am going to run into is that Apple's API doesn't seem to 
 provide error
 details when a certificate check fails (SecTrustEvaluate), so I don't think 
 we'll get as
 fine-grained QSslError's as when using OpenSSL. I have however managed to 
 implement the
 pattern used in the OpenSSL implementation:
 
 - start handshake
 - emit sslErrors if appropriate
 - allow ignoring the errors using ignoreSslErrors
 - complete handshake
 
 OK it looks as though I was overly optimistic, I just realised I was relying 
 on some
 functions only available on OS X, not iOS.
 
 From what I can tell, we can't even do subject / alternative subject name 
 validation
 ourselves, as SecCertificateCopyValues is not exposed on OSX. So, it looks as 
 though we
 can either:
 
 - let secure transport do all the checks (name, trust chain, ..) which will 
 result in
 either success or a failure, with no ability to ignore SSL errors when they 
 occur
 
 - disable checks altogether before starting the handshake = totally insecure
 
 Bottom line: connecting to hosts with valid certificates is OK, connecting to 
 anything
 else (self-signed certs, name mismatches) basically nullifies the security 
 promise as we
 can't check the errors. Is it worth continuing, to at least support the happy 
 path?
 
 Cheers,
 Jeremy
 ___
 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] No SSL on iOS ?

[Kurt Pattyn]

 On 29 Apr 2014, at 13:31, Richard Moore r...@kde.org wrote:
 
 
 
 
 On 29 April 2014 12:13, Sorvig Morten morten.sor...@digia.com wrote:
  What would the best course of action be to add support for secure 
  websockets
  on iOS?
 
  Probably to add a new QSslSocket backend that uses the Apple API.
 
 QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make sure 
 you are aware of the scope of the project and remember you have to maintain 
 it :)
 
 I actually started thinking about how a smaller API for some of this could 
 look. Basically with the idea being that for many applications only a subset 
 of the full QSslXX apis mattered. If you want me to post my notes (such as 
 they are) then I'm happy to do so.
  
 Another option is to skip QSslSocket and implement a direct backend for 
 QWebSocket using a native API, for example the SocketRocket project.
 
 I'm not sure that the design of the QWebSocket module really allows this kind 
 of plugability. Perhaps Kurt can comment?
Currently QSSLSocket is tightly integrated into the code. But, it should be 
fairly easy to integrate another iOS specific SSL socket implementation if the 
interface is the same as QSSLSocket.
 
 Cheers
 
 Rich.
  
 I used this approach to implement an iOS backend for the QNAM rest API 
 (using NSurlConnection).
 
 Morten
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] No SSL on iOS ?

[Kurt Pattyn]

Maybe writing an OpenSSL compatibility layer over Apple's API is also an option?
Does anyone has an idea where OpenSSL is used in Qt? Definitely for SSL 
sockets, but maybe also for generating ciphers, hashes, aso?

Cheers,

Kurt

 On 29 Apr 2014, at 14:21, Jeremy Lainé jeremy.la...@m4x.org wrote:
 
 On 04/29/2014 01:13 PM, Sorvig Morten wrote:
 QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make sure 
 you are aware of the scope of the project and remember you have to maintain 
 it :)
 
 I definitely realise implementing the whole of the API is a large task.
 However, just getting a basic QSslSocket to work seems doable. So far I
 have been able to get as far as a successful client handshake with few
 lines of code using Apple's Secure Transport API:
 
 https://developer.apple.com/library/ios/documentation/Security/Reference/secureTransportRef/Reference/reference.html
 
 For now I am implementing a rough proof of concept (attached) outside Qt
 by subclassing QTcpSocket the way QSslSocket does .
 
 Cheers,
 Jeremy
 foosocket.h
 foosocket.mm
 ___
 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] No SSL on iOS ?

[Kurt Pattyn]

Nice work!

I suppose you just want to replace the private implementation of QSSLSocket 
leaving the QSSLSocket header intact?
QWebSockets depends further on the OpenSSL macro (can't remember the exact name 
now) to decide whether SSL sockets are supported. I think we also need another 
macro that indicates whether SSL is supported or not (and not just OpenSSL).
If I can help, just let me know. I cannot test on an iOS device though.

Cheers,

Kurt

 On 29 Apr 2014, at 18:36, Jeremy Lainé jeremy.la...@m4x.org wrote:
 
 On 04/29/2014 02:39 PM, Sorvig Morten wrote:
 This aproach looks promising. If we can get basic QSslSocket working (enough 
 for say QNAM and QWebSocket) then retiring the NSUrlConnection backend and 
 focusing on QSslSocket is a possibility.
 
 OK I have moved my proof of concept code here:
 
 https://github.com/jlaine/qsslsocketios
 
 I provided a demo app : a very naive HTTPS client which fetches
 https://www.google.com and dumps it to standard out.
 
 You can run this on any OSX machine with Qt installed.
 
 I'll start looking how hard it would be to actually integrate this into
 qtbase.
 
 Cheers,
 Jeremy
 ___
 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] No SSL on iOS ?

[Kurt Pattyn]

 On 29 Apr 2014, at 00:16, Jeremy Lainé jeremy.la...@m4x.org wrote:
 
 On 04/28/2014 11:44 AM, Nichols Andy wrote:
 It is possible still in the packaged versions of Qt for iOS to make 
 connections using SSL via QNetworkAccessManager as there is a backend that 
 uses Apples crypto API, but without OpenSSL support you can’t use any of the 
 API’s in Qt that use OpenSSL directly (like QSSLSocket).
 
 Ouch I just realised that most likely means QWebSocket on iOS does not 
 support secure
 websockets!
Yes, unfortunately. QWebSockets uses QSSLSocket and hence is not supported on 
iOS.
 
 What would the best course of action be to add support for secure websockets 
 on iOS?
 
 Cheers,
 Jeremy
 
 
 ___
 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] Question about Qt's future

[Kurt Pattyn]

 On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
 
 On 27.04.2014 22:40, Thiago Macieira wrote:
 Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu:
 On 26.04.2014 17:39, André Pönitz wrote:
 You could have made the point declarative structures are good for GUI
 description for Qt Widget's .ui files, after all, .ui files contents
 pretty much _is_ declaring layout nesting and property values.
 
 Just an idea:
 Declarative-only QML files could be translated to C++ by a tool similar
 to uic, and then used by a C++-only successor of QtWidgets.
 
 Or are there any technical reasons why all the state-of-the-features
 provided by QML v2 could not be implemented on the C++ side assuming
 there is a QML-to-C++ code generation step?
 
 It's possible, but there's no API in the C++ side to create the graph. Until
 such an API exists, you can't write the generator.
 
 I know that currently there is no support for this in Qt, also no plans
 to add it, all I wanted to hear is It's possible.
 
 I assume it would be only a community-driven long-term project, which takes
 years until it is on par with QtWidgets. But hey, I'm fascinated by the idea,
 and maybe I'm not alone.
 
 ATM the problem is to get started because I don't know much about the
 current architecture of the graphic stack.
 Any hints where to start for a first hello world?

Maybe a translation from QML to a .ui file could be a first step? That could 
work if you use QtWidgets in the QML file.
 
 
 
 Care to contribute the C++ side, including passing all the reviews? Note that
 this is a major undertaking and will probably take two or three releases to
 get a minimal functional API out there. Plus the maintenance effort.
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Jake Petroules as approver

[Kurt Pattyn]

 On 15 Apr 2014, at 21:25, Jake Petroules jake.petrou...@petroules.com wrote:
 
 On 2014-04-15, at 01:13 PM, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 
 Hello
 
 I'd like to nominate Jake Petroules as approver. He's been very active in 
 the 
 Mac port in the recent months, helping out with issues like adding support 
 for 
 the CoreFoundation types in QtCore, among other tasks. He's located in the 
 US 
 West Coast, which helps me with reviews in late afternoons.
 
 Here's a link to his submissions
 https://codereview.qt-project.org/#q,owner:jake.petrou...@petroules.com,n,z
 
 Reviews:
 https://codereview.qt-project.org/#q,reviewer:jake.petrou...@petroules.com,n,z
 
 And dashboard:
 https://codereview.qt-project.org/#dashboard,1000530
 
 -- 
 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
 
 
 Thank you for the nomination, Thiago! Just one small correction: I'm actually 
 located on US East Coast... for now. :)

Not on the West Coast?!? This changes things completely :-)
++1 because of his OS X contributions and because he cares about Mac.

Cheers,

Kurt

 -- 
 Jake Petroules
 Chief Technology Officer
 Petroules Corporation · www.petroules.com
 Email: jake.petrou...@petroules.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

Re: [Development] Nominating Sze Howe Koh as approver

[Kurt Pattyn]

Go Sze-Howe, go!

 On 11 Apr 2014, at 16:36, Blasche Alexander alexander.blas...@digia.com 
 wrote:
 
 Approver rights have been set in Jira and Gerrit. Congratulations to Sze-Howe.
 
 --
 Alex
 
 
 From: development-bounces+alexander.blasche=digia@qt-project.org 
 [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of 
 Thiago Macieira [thiago.macie...@intel.com]
 Sent: Sunday, March 23, 2014 00:50
 To: development@qt-project.org
 Subject: [Development] Nominating Sze Howe Koh as approver
 
 Hello
 
 I'd like to nominate Sze Howe Koh as approver. You must have seen the number
 of contributions already done in the mailing list discussions, but you may not
 have seen the contributions done to Qt documentation.
 
 Here's the link to the submissions made:
https://codereview.qt-project.org/#q,owner:szehowe@gmail.com,n,z
 
 And reviews made:
https://codereview.qt-project.org/#q,reviewer:szehowe@gmail.com,n,z
 
 And here are Sze's dashboard:
https://codereview.qt-project.org/#dashboard,1002192
 
 --
 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

[Development] math3d in gui module

[Kurt Pattyn]

Hi,

is there any reason why math3d is in the QtGUI module on not in the QtCore 
module?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] clang warning

[Kurt Pattyn]

Hi,

when compiling an application, I get a lot of these warnings:

Qt5.3.0/5.3/clang_64/lib/QtGui.framework/Headers/qquaternion.h:145:12: warning: 
'qIsNull' was marked unused but
  was used [-Wused-but-marked-unused]
return qIsNull(xp)  qIsNull(yp)  qIsNull(zp)  qIsNull(wp);

Qt5.3.0/5.3/clang_64/lib/QtGui.framework/Headers/qquaternion.h:268:12: warning: 
'qFuzzyCompare' was marked unused
  but was used [-Wused-but-marked-unused]
return qFuzzyCompare(q1.xp, q2.xp) 

Does anybody has an idea what this means?

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Deprecated warnings in public API

[Kurt Pattyn]

When compiling applications on OSX 10.9 with clang,
I encounter quite a lot of deprecated warnings like this:

qbytearray.h:496:22: warning: definition of implicit
  copy constructor for 'QByteRef' is deprecated because it has a 
user-declared copy assignment operator [-Wdeprecated]
inline QByteRef operator=(const QByteRef c)

Should this be fixed, or isn’t it worth the effort?

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] 5.3 beta: QtWebSockets examples missing

[Kurt Pattyn]

Hi,

I noticed that in the beta release of Qt 5.3 for Mac OSX Clang from March 19th, 
the examples are missing for the Qt WebSockets module.
I assume I missed something in the configuration of the documentation.
How can the examples of that module be included in the examples section that is 
visible in Qt Creator?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.3 beta: QtWebSockets examples missing

[Kurt Pattyn]

Thanks both for the patch and the wiki page!

Cheers,

Kurt

 On 19 Mar 2014, at 16:51, Koehne Kai kai.koe...@digia.com wrote:
 
 
 
 -Original Message-
 From: development-bounces+kai.koehne=digia@qt-project.org
 [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
 Behalf Of Kurt Pattyn
 Sent: Wednesday, March 19, 2014 4:33 PM
 To: development@qt-project.org
 Subject: [Development] 5.3 beta: QtWebSockets examples missing
 
 Hi,
 
 I noticed that in the beta release of Qt 5.3 for Mac OSX Clang from March
 19th, the examples are missing for the Qt WebSockets module.
 I assume I missed something in the configuration of the documentation.
 How can the examples of that module be included in the examples section
 that is visible in Qt Creator?
 
 I started a wiki page a while ago describing the exact process:
 
 http://qt-project.org/wiki/Qt-Creator-Qt-Examples
 
 It comes down to
 - examples- manifest.xml is parsed must be in docs/*/ folder
 - examples entry must be valid
 --  projectPath must resolve e.g. against Examples\Qt-5.3 dir
 -- entries must have an imageUrl, docUrl
 
 
 Your examples-manifest.xml actually looks fine, but the examples are 
 misplaced: , The actual examples paths miss a 'websocket' subdirectory, e.g. 
 it's Examples\Qt-5.3\sslechoclient.
 
 So s.th. like https://codereview.qt-project.org/81365 should hopefully fix it.
 
 Regards
 
 Kai 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Inline method convention

[Kurt Pattyn]

Hi,

Recently I came across Effective C++ again and saw a chapter regarding inline 
methods.
In short, Scott Meyer argued against it, because of potential binary 
compatibility problems, code bloat, and so on.

My question is: is there any convention within Qt about inline methods?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Problem with QOpenGLContext?

[Kurt Pattyn]

Hi,

as I understand correctly the ‘old’ QGLxxx classes will be replaced by new 
QOpenGLxxx classes.
I tried the following code below, and found out that QGLContext is correctly 
setting the color depth,
while QOpenGLContext always defaults to 8.

QSurfaceFormat ogfrmt;
ogfrmt.setRedBufferSize(6);
ogfrmt.setGreenBufferSize(6);
ogfrmt.setBlueBufferSize(6);
QOpenGLContext *oglc = new QOpenGLContext;
oglc-setFormat(ogfrmt);
oglc-create();
qDebug()  QOpenGLContext red buffer size:  
oglc-format().redBufferSize();

QGLFormat gfrmt;
gfrmt.setRedBufferSize(6);
gfrmt.setBlueBufferSize(6);
gfrmt.setGreenBufferSize(6);
QGLContext *glc = new QGLContext(gfrmt);
glc-create();
qDebug()  QGLContext red buffer size:  glc-format().redBufferSize();


Is this a known bug, or is the above code simply wrong?

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem with QOpenGLContext?

[Kurt Pattyn]

Some more information.

I work on OSX.
When digging into the platform specific implementation, I detected that in the 
method qcgl_createNSOpenGLPixelFormat()
the color depth nor the alpha depth is not set. If it is not set, it defaults 
to the screen color depth, which is 8-bit in my case.
I will file a bug report for that.

Cheers,

Kurt

On 11 Mar 2014, at 11:28, Kurt Pattyn pattyn.k...@gmail.com wrote:

 Hi,
 
 as I understand correctly the ‘old’ QGLxxx classes will be replaced by new 
 QOpenGLxxx classes.
 I tried the following code below, and found out that QGLContext is correctly 
 setting the color depth,
 while QOpenGLContext always defaults to 8.
 
 QSurfaceFormat ogfrmt;
 ogfrmt.setRedBufferSize(6);
 ogfrmt.setGreenBufferSize(6);
 ogfrmt.setBlueBufferSize(6);
 QOpenGLContext *oglc = new QOpenGLContext;
 oglc-setFormat(ogfrmt);
 oglc-create();
 qDebug()  QOpenGLContext red buffer size:  
 oglc-format().redBufferSize();
 
 QGLFormat gfrmt;
 gfrmt.setRedBufferSize(6);
 gfrmt.setBlueBufferSize(6);
 gfrmt.setGreenBufferSize(6);
 QGLContext *glc = new QGLContext(gfrmt);
 glc-create();
 qDebug()  QGLContext red buffer size:  
 glc-format().redBufferSize();
 
 
 Is this a known bug, or is the above code simply wrong?
 
 Cheers,
 
 Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

 On 09 Mar 2014, at 22:46, Richard Moore r...@kde.org wrote:
 
 
  IIRC SSL sockets had the same issue when SSL errors are raised. Has
  it been solved there? How?
 AFAIK, it has not been solved. The problem is the same.
  
 It has been partially solved, in recent versions you can set the socket to 
 pause when ssl errors occur which avoids the need to use a nested event loop, 
 see https://codereview.qt-project.org/#change,13834 We want this to be 
 supported for authentication and also for ssl when there are no errors. It is 
 being tracked as QTBUG-19032.

Is the documentation on the signal sslErrors() still correct then: Note: You 
cannot use Qt::QueuedConnection when connecting to this signal, or calling 
QSslSocket::ignoreSslErrors() will have no effect. ?

Do you think this mechanism should also be added to QWebSockets, or leave it as 
it is?

Personally, I think that the delegate approach is a nicer and for the 
end-programmer a less error prone solution. It could even be combined with the 
pause/resume functionality: when a delegate is provided, pause the socket, 
asynchronously invoke the delegate and resume the socket when the delegate 
throws a signal.
I know this would be for a next major release, but is it worth trying this out 
and propose it as an extension to the API?

Cheers,

Kurt
 
 Rich.
  
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

 On 10 Mar 2014, at 08:37, Giuseppe D'Angelo dange...@gmail.com wrote:
 
 On 10 March 2014 07:43, Kurt Pattyn pattyn.k...@gmail.com wrote:
 Is the documentation on the signal sslErrors() still correct then: Note:
 You cannot use Qt::QueuedConnection when connecting to this signal, or
 calling QSslSocket::ignoreSslErrors() will have no effect. ?
 
 I presume it's still correct in order to retain compatibility with Qt
 4. The new pausing mechanism is opt-in: you need to call
 setPauseMode(QAbstractSocket::PauseOnSslErrors) in order to make the
 socket pause when emitting sslErrors(). Once that signal gets emitted,
 the socket pauses and will not proceed further unless the user then
 calls ignoreSslErrors() + resume() or so.

But we can use a QueuedConnection if the PauseMode is set to PauseOnSslErrors, 
or can't we?
 
 To me this mechanism seems flexible enough to be coupled with anything...
 
 -- 
 Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

Currently, QNAM stalls when authentication is required (also see: 
https://bugreports.qt-project.org/browse/QTBUG-16251).
Also, the connection between the authenticationRequired signal and the slot 
must be a direct connection.
This is problematic when an application wants to show a login dialogbox for 
instance.

I propose to change this implementation by using a delegate authenticator 
instead.

class QAuthenticator
{
…
protected Q_SLOTS:

//this method should be called asynchronously from QNAM
void authenticate(QNetworkReply *reply) {
if (doAuthenticate(reply))
Q_EMIT authenticated();
else
Q_EMIT authenticationFailed();
}
...

protected:
//return false if the request should be stopped (authentication denied)
//return true if authentication should continue
virtual bool doAuthenticate(QNetworkReply *reply) = 0;
...
}

//example use
class MyAuthenticator: public QAuthenticator
{
bool doAuthenticate(QNetworkReply *reply) {
setUser();
setPassword();
setOption();

//whatever is required

return true;
}
}

The QNetworkRequest class would be extended with a setAuthenticator() method, 
as follows:

class QNetworkRequest
{
...
void setAuthenticator(QAuthenticator *authenticator);
...
}

Usage:
MyAuthenticator *auth = new MyAuthenticator;
networkRequest.setAuthenticator(auth);

Another option is to add the setAuthenticator() method to the QNAM class.

When this would be implemented, the authenticationRequired() signal would 
become obsolete.


What are your opinions on this?


Note: QWebSocketServer uses the same blocking signal for CORS authentication
(this was merely done to be inline with the QNAM way of working).

Cheers,

Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

On 09 Mar 2014, at 17:16, Konstantin Ritt ritt...@gmail.com wrote:

 
 2014-03-09 16:10 GMT+02:00 Kurt Pattyn pattyn.k...@gmail.com:
 Currently, QNAM stalls when authentication is required (also see: 
 https://bugreports.qt-project.org/browse/QTBUG-16251).
 Also, the connection between the authenticationRequired signal and the slot 
 must be a direct connection.
 This is problematic when an application wants to show a login dialogbox for 
 instance.
 
 
 QAuthenticator doesn't seem to make any difference in this case. Am I missing 
 something?
Well, QAuthenticator would have to be extended with a slot and 1 or 2 signals.
 Anyways, this sounds more convenient than the current behavior. 
  

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

On 09 Mar 2014, at 19:32, Olivier Goffart oliv...@woboq.com wrote:

 On Sunday 09 March 2014 15:10:02 Kurt Pattyn wrote:
 Currently, QNAM stalls when authentication is required (also see:
 https://bugreports.qt-project.org/browse/QTBUG-16251). Also, the connection
 between the authenticationRequired signal and the slot must be a direct
 connection. This is problematic when an application wants to show a login
 dialogbox for instance.
 
 I propose to change this implementation by using a delegate authenticator
 instead.
 ...
 What are your opinions on this?
 
 1) Your suggested change would be binary incompatible.  You would need to 
 pick 
 another class name than QAuthenticator
 
 2) Your change does not seem to fix the problem at all.  You get a blocking 
 virtual function instead of a blocking signal.
 
 
 Here is my suggested API change:  adding  QNetworkReply::pause and 
 QNetworkReply::resumeAuthentication,  to be used as this.
 
 
 QObject::connect(qnam, QNetworkManager::authenticationRequired,
 [](QNetworkReply * reply, QAuthenticator * authenticator) {
  reply-pause(); // New slot: when we return this function it won't continue
  auto dialog = new MyPasswordDialog();
  dialog-open();
  QObject::connect(dialog, MyPasswordDialog::done, reply, [=]{
authenticator-setUser(dialog-user);
authenticator-setPassword(dialog-password);
reply-resumeAuthentication(authenticator); //new slot;
  });
 });
 
 
 Alternative: adding those function to the QAuthenticator itself.

I think it does solve the problem if QNAM would be changed like this:

if (networkRequest-hasAuthenticator())
connect(networkRequest-authenticator(), QAuthenticator::authenticated,
this, QNAM::goToNextStep);
...

if (authenticationNeeded)
if (networkRequest-hasAuthenticator())
QMetaMethod::invoke(“authenticate , networkRequest, ..., 
QueuedConnection);
else
//authentication failed
else
goToNextStep();
...

Q_SLOTS:
void goToNextStep() {
   ...
}

The handling of incoming data would basically be split in two parts. When 
authentication is needed,
a queued metacall is invoked which makes it asynchronous.

 
 -- 
 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] [API Change] New authentication method in QNetworkAccessManager

[Kurt Pattyn]

On 09 Mar 2014, at 21:02, Giuseppe D'Angelo dange...@gmail.com wrote:

 On 9 March 2014 15:10, Kurt Pattyn pattyn.k...@gmail.com wrote:
 Also, the connection between the authenticationRequired signal and the slot
 must be a direct connection.
 
 IIRC SSL sockets had the same issue when SSL errors are raised. Has
 it been solved there? How?
AFAIK, it has not been solved. The problem is the same.
 
 -- 
 Giuseppe D'Angelo

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding 10-bit OpenGL support in QML

[Kurt Pattyn]

Thanks for the reply.

On 25 Feb 2014, at 23:22, Gunnar Sletta gunnar.sle...@jolla.com wrote:

 On 26 Feb 2014, at 00:42, Kurt Pattyn pattyn.k...@gmail.com wrote:
 
 We are currently looking into a way to render a 10-bit image in QML.
 
 I'm going to assume we're talking about Qt Quick 2.0.
Yes, indeed.
 
 As in 10-bit grayscale or GL_UNSIGNED_INT_10_10_10_2?
Yes, both grayscale and color 10-bit.
 In any case, you can create a custom QSGTexture class which defines the 
 format and contents of your texture and display that in the scene graph using 
 a QSGSimpleTextureNode. If something more specific is needed, write your own 
 material to do exactly what you want.
Is it correct that we can subclass a QQuickItem and return a subclassed 
QSGSimpleTextureNode object from the updatePaintNode() method?
 
 Our first idea is to create an OpenGL context in C++ and use that in QML.
 
 You cannot create the OpenGL context for QQuickWindow, but you can request 
 the format it should take via QQuickWindow::setFormat().
 
 QML must be able to overlay text on this 10-bit OpenGL context.
 
 What is the best approach for this? Is it possible at all?
 Can we expose a QGLWidget, or something similar?
 
 QQuickWindow has an QOpenGLContext and does not use QGLWidget.
So, as I understand this is what should be done:
QSurfaceFormat surfaceFormat;
surfaceFormat.setRenderableType(QSurfaceFormat::OpenGL);
//set bitDepth on surfaceFormat
QQuickView * view = new QQuickView();
view-setFormat(surfaceFormat);

And then use a subclassed QQuickItem together with a subclassed 
QSGSimpleTextureNode.

Is this correct?

Cheers,

Kurt
 
 
 cheers,
 Gunnar
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Adding 10-bit OpenGL support in QML

[Kurt Pattyn]

We are currently looking into a way to render a 10-bit image in QML.
Our first idea is to create an OpenGL context in C++ and use that in QML.
QML must be able to overlay text on this 10-bit OpenGL context.

What is the best approach for this? Is it possible at all?
Can we expose a QGLWidget, or something similar?

Cheers,

Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Marketing] Qt Contributor Summit 2014 dates?

[Kurt Pattyn]

On 17 Feb 2014, at 08:18, Kojo Tero tero.k...@digia.com wrote:

 Hi Thiago (and all),
 
 Yes, we have a date for the Contributor Summit. June 10-11, and the location 
 this time will be Berlin.
 I'll post more information as soon as we have more details to share.
 
 Tero Kojo
 Qt Online Community Manager - Digia
 
 P.S. I'll use this as a chance to say hi to all the people on these mailing 
 lists too. I started three weeks back at Digia as an Online Community 
 Manager. My short introduction letter on the forums: 
 http://qt-project.org/forums/viewthread/37732/
 I'll be around at least on the forums, IRC and these mailing lists, feel free 
 to 
Welcome to Qt!

 
 -Original Message-
 From: marketing-bounces+tero.kojo=digia@qt-project.org 
 [mailto:marketing-bounces+tero.kojo=digia@qt-project.org] On Behalf Of 
 Thiago Macieira
 Sent: 15. helmikuuta 2014 3:04
 To: development@qt-project.org; market...@qt-project.org
 Subject: [Marketing] Qt Contributor Summit 2014 dates?
 
 Hello
 
 Do we have potential dates for QCS this year? I'm being asked to fill in my 
 Q2-2014 travel already...
 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 
 ___
 Marketing mailing list
 market...@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/marketing
 ___
 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] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 15 Feb 2014, at 20:38, Laszlo Papp lp...@kde.org wrote:

 I have not read this thread through, but it is long for me now, but I
 would like to note one suggestion from my side:
 
 Make 1-2 unstable releases or a new add-on module. Unfortunately, we
 have not done that, and we are now stuck with a couple of bad API
 issues for a few years. This could have been avoided with 1-2 unstable
 releases because the user feedback began to come once it had been
 released and out.
QtWebSockets currently is an add-on module.
 
 Such a disclaimer could be done as part of Qt 5.3, etc. I think it is
 unpleasant for the end users, but if the communication is clear
 between the developer(s) and end users why it is so, I think this will
 serve good.
Not a bad idea at all.
 
 That being sad, I may be totally wrong, and websockets has already
 received a lot of end-user feedback with thorough API usage than
 QtSerialPort when it was first released as part of Qt. In that case,
 feel free to ignore me. I am just trying to help.

Your help is definitely appreciated.
QtWebSockets is a different beast than QtSerialPort I think.
It is kind of a socket, and as such has been modelled after the well-established
QAbstractSocket API. The server part is modelled after the well-established
QTcpServer API. Besides that there are 2 RFCs: one describing the protocol
itself and one describing the JavaScript API. So, we know what is to be
expected from a web socket.

Cheers,

Kurt

 ___
 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] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 11 Feb 2014, at 17:15, Thiago Macieira thiago.macie...@intel.com wrote:

 Em ter 11 fev 2014, às 09:04:39, Konrad Rosenbaum escreveu:
 Please don't go there. AFAIK qrand() is a function meant to be equivalent to
 the ANSI-C rand() function. I.e. it is supposed to be used by simple
 simulations, be fast and produce reproducable random numbers when seeded
 with the same value.
 
 Fast? yes.
 
 Needs to produce reproduceable sequence? Yes, but only because of unit 
 testing.
 
 Equal to rand()? I'm not sure we need to keep that.
 
 My idea was to simply securely pre-seed the PRNG before you had a chance to 
 use it, in each thread. If you need to seed it to something constant to get 
 constant results, you'd still be able to.
Or you could keep the qsrand() method. When qsrand() is not called qrand() 
produces the same sequence.
As part of the QtWebSockets module, I created a random generator that is fast 
and that has reproducible sequences. 
But it is based on std::random only. 
Code will be checked in soon. I will add you to the reviewers. 

Cheers,

Kurt
 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 11 Feb 2014, at 19:14, Thiago Macieira thiago.macie...@intel.com wrote:

 Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu:
 http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
 
 No doubt. And we should have a more secure generator, at least until we can 
 rely on std::random.
We can always 'duplicate' some code from the std::random library :-)
How 'secure' should this be? Is a Mersenne-Twister for instance 'secure' enough?
 
 Anyone up for creating a nice function for Qt 5.4?
 
 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 11 Feb 2014, at 19:21, Giuseppe D'Angelo dange...@gmail.com wrote:

 On 11 February 2014 19:14, Thiago Macieira thiago.macie...@intel.com wrote:
 
 Anyone up for creating a nice function for Qt 5.4?
 
 I *cough* volunteered some time ago, but I'm going to miss the 5.3 deadline.
I can help you with you that if you want.

Cheers,

Kurt
 
 -- 
 Giuseppe D'Angelo
 ___
 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] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 09 Feb 2014, at 23:57, Olivier Goffart oliv...@woboq.com wrote:

 On Sunday 09 February 2014 22:40:22 Kurt Pattyn wrote:
 
 I think you are making it more complicated than it  need to be.
 It turns out 32 bit entropy is enough because that's the size of your mask, 
 so 
 just use qrand with a decent proper seed:
 
 #if has_std_randrom_device
 return qsrand(std::random_device()());
you still need to check for the entropy and must be prepared to catch
std::exception
 #else
 static QElapsedTimer t;
 return qsrand(t.nsecsElapsed());
 #endif
Well, I can simplify to
   quint32 seed = 0;
   try {
   std::random_device seeder;
   if (seeder.entropy() = 0.5) {
   seed = seeder();
   success = true;
   }
   } catch (const std::exception ) {
   //fall through
   }
   if (!success) {
  //need to do something here
  //it is known that the MingW version of GCC 4.8 has a bug
  //in std::random_device
  //in that case, we can fall back to the Windows CryptoAPI
  //or we can make our live easy and fall back to some low entropy
  //source (also for the cases where std::random_device fails)
  //using std::seek_seq can then partially obscure the low entropy
   }

 -- 
 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] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 10 Feb 2014, at 08:58, Konrad Rosenbaum kon...@silmor.de wrote:

 Hi,
 
 I'll have to read and analyze this code in more detail to give you a 
 qualified 
 opinion. I'll do this later...
 
 On the surface it looks a bit complicated and I'm not entirely sure about the 
 seeding, but I'll have to study the API first to make sure.
 
 On Sunday, Sunday 09 February 2014 at 22:40, Kurt Pattyn wrote:
 If the above implementation suffices, then a virtual method would not be
 needed anymore.
 
 Please use the virtual method anyway. Yes, it adds about two more 
 instructions 
 and a memory access for every call to this method, but security-wise it is 
 worth it.
Well, this is what I propose: use a delegate class that handles the creation of
a random 32-bit number. This would avoid having to subclass QWebSocket
just to overwrite the randomiser.

class QWebSocket
{
…
void setRNG(const QRng rng);
};

When setRNG is not called before opening the socket, a default implementation
will be used, based on std::random_device and std::mt19937.
This avoids a virtual method AND gives complete control over the RNG to the
user of the class.

class QRng
{
…
virtual quint32 nextNumber() const;
};

A user that wants some very specific randomiser functionality, can subclass
QRng and override the nextNumber() method.

What do you think? I will work out a proposal.
Thiago do you think QRng would be a good name? I can imagine that sooner or
later Qt will provide a generic (P)RNG implementation, and then QRng could be
a good candidate for one or the other class name.

 
 You can never assume code to be absolutely secure, just secure enough for a 
 particular purpose that you can envision under the constraints of the 
 knowledge you currently possess. Providing an overridable virtual method 
 gives 
 users with stronger requirements (or with more paranoid bosses) sufficient 
 freedom to implement those requirements.
 
 Incidentally it gives you an excuse to cop out of security discussions... ;-)
THAT is what I call an argument! J
 
 Should I fall back to the ordinary qrand() when the other methods fail?
 
 Yes.
 
Cheers,

Kurt
 
 
 
   Konrad

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 29 Jan 2014, at 09:45, Konrad Rosenbaum kon...@silmor.de wrote:
  
 1) create a fresh TCP connection for each Websocket, this way it is not 
 possible to combine a previous HTTP request and a socket in an attack; 
 consequently: if the handshake fails: terminate the TCP connection!
This is already happening in the implementation.
  
 2) when faced with an explicitly configured proxy: ALWAYS use the CONNECT 
 method before sending the actual socket request - proxies do not care about 
 the socket content after a CONNECT is through - additionally there are 
 probably close to zero deployed proxies that even understand the semantics of 
 Upgrade: websocket.
  
 Unfortunately 2) does not help with broken transparent proxies, since by 
 their nature you cannot detect them easily and it is not a good strategy to 
 send a CONNECT just in case…
The implementation uses the QNetworkProxy implementation.
  
 3) implement masking properly.
  
 The latter can be done in stages, I'd propose this plan:
  
 First: implement websockets, get them into Qt. For the mask generation create 
 a virtual protected method QByteArray getNextMaskValue(int numbytes)const 
 and implement it using qrand()0xff for each byte - please note that you have 
 to initialize with qsrand in each thread.


If I use std::random as Thiago proposed (see 
http://en.cppreference.com/w/cpp/numeric/random), like:

//one time initialisation
Q_CONST_EXPR std::size_t numSeeds = 13; //arbitrary number
quint32 seeds[numSeeds] = { 0 };
bool success = false;

try {
std::random_device seeder;  //supported since MSVS 2008, 
since GCC 4.5
if (seeder.entropy() = 0.5) {
std::generate_n(seeds, numSeeds, seeder);
success = true;
}
} catch (const std::exception ) {
//fall through
}
#ifdef Q_OS_WIN  //the MinGW implementation of GCC 4.8 has a known bug in 
std::random_device
if (!success) {
HCRYPTPROV hp = 0;
BYTE rb[4];
if ((success = CryptAcquireContext(hp, 0, 0, PROV_RSA_FULL, 
CRYPT_VERIFYCONTEXT)) == TRUE)
for (std::size_t i = 0; i  numSeeds; ++i) {
if ((success = CryptGenRandom(hp, sizeof(quint32), seeds + i) 
!= TRUE)
break;
}
CryptReleaseContext(hp, 0);
}
#endif
if (!success) {
qsrand(static_castuint(QDateTime::currentMSecsSinceEpoch()));
for (std::size_t i = 0; i  numSeeds; ++i) {
const qreal multiplier = qreal(std::numeric_limitsquint8::max()) 
/ qreal(RAND_MAX);
const quint32 byte1 = quint32(qrand() * multiplier)  0xFF;
const quint32 byte2 = quint32(qrand() * multiplier)  0xFF;
const quint32 byte3 = quint32(qrand() * multiplier)  0xFF;
const quint32 byte4 = quint32(qrand() * multiplier)  0xFF;
seeds[i] = byte1 | byte2  8 | byte3  16 | byte4  24;
}
}

std::seek_seq seedSequence(seeds, seeds + numSeeds);
std::mt19937 randomiser(seedSequence);
//std::uniform_int_distributionstd::uint32_t dist;//range from 0 
to UINT_MAX


//somewhere else
return randomiser();//no need to use a distribution function as 
mt19937 outputs 2^32


Would this already be more acceptable?
Of course, this implementation requires C++11 support.
An interesting presentation about std::random can be found here: 
http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful

If the above implementation suffices, then a virtual method would not be needed 
anymore.

Should I fall back to the ordinary qrand() when the other methods fail?

 Document the shortcoming with something like this:
  
 This implementation of WebSockets uses cryptographically weak random numbers 
 during communication. If you allow user generated or downloaded scripts to 
 access WebSockets, then malicious scripts could abuse this implementation to 
 attack some vulnerable web proxy servers (e.g. for cache poisoning). In this 
 case it is recommended that you reimplement getNextMaskValue to use 
 cryptographically strong random numbers.
 (maybe add a link to the paper)



Cheers,

Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de wrote:

 Depends. What is it used for? Is it just obfuscation or is it supposed to be 
 real security?

Well, there are 2 places where random numbers are used:
1. During the handshake phase
Client sends a handshake request containing a 128-bit random number converted 
to a string hex representation (Sec-WebSocket-Key).
The server appends a well-known UUID (published in the RFC) to that number and 
calculates a SHA-1 hash.
This hash in sent to the client, which in its turn appends the same UUID to the 
random number it sent before, and calculates a SHA-1 hash. If both the 
server-sent hash and the client calculated hash match, the handshake succeeds.

2. When sending data from client to server (not the other way)
The client generates a 32-bit random number.
This random number is stored in plain text in the header of each frame.
The data is XOR-ed with that 32-bit random number.

The server takes the 32-bit random number from the header and XORs it with the 
payload to get to the original data.

I really fail to see what the intention is of this mechanism. I really fail to 
see what could make this communication ‘secure’.

The masking key needs to
 be unpredictable; thus, the masking key MUST be derived from a strong
 source of entropy, and the masking key for a given frame MUST NOT
 make it simple for a server/proxy to predict the masking key for a
 subsequent frame.  The unpredictability of the masking key is
 essential to prevent authors of malicious applications from selecting
 the bytes that appear on the wire.”

Why should the masking key be unpredictable if it is send unencrypted along 
with the masked data?
Why would a server/proxy predict the masking key if it can just fetch it from 
the header?
To me it looks like having a locked door with the key in the keyhole. Why would 
a burglar use a crowbar if he has the key?

 If the latter: is it the only way to generate security? (If so: in all 
 likelyhood you are affixed by an inclined plane wrapped helicly around an 
 axis. In laymans terms: screwed.)
 
 If the former: unless it is absolutely necessary for understanding the other 
 side of the communication channel - don't bother implementing it. Obscurity 
 is no security.

Well, the standard requires the frames that go from client to server to be 
masked.
So yes, it is absolutely necessary, but in my opinion complete overkill.

 
 I'd like others with more experience in this area to chime in though.
 
 Getting milliseconds since Epoch gives you less than one bit of random 
 (entropy), if and only if nobody can predict precisely when you'll call for 
 the current time. Calling it several times does not increase entropy unless 
 there are sufficiently random intervals between calls and nobody can observe 
 you calling (i.e. you are working on a perfectly secured system). Micro- and 
 Nano-Seconds are slightly more random, but not much (fractions of bits).
 
 You need about 128 bits of entropy for good security. After you've got that 
 you can stretch those with a secure random number generator. The q(s)rand 
 functions can be safely assumed to be completely insecure on most operating 
 systems and inadequate on all the others. Don't use them for security.
 
 I would not recommend trying to implement your own PRNG either - getting it 
 right is horribly difficult. Getting the entropy gathering right in a cross-
 platform way is much worse effort…

I wouldn’t even dare :-) This is a research field on its own.

 
 I wonder whether it would be possible to expose the low-level APIs of 
 OpenSSL to Qt, it has quite a good random number generator and it is used 
 for QSslSocket already.

Indeed, I planned to use the OpenSSL RNGs (the library has FIPS approved RNGs),
but that library is not available on all platforms I think.
Besides that, I am afraid this is a very expensive operation, certainly because 
another masking key
has to be calculated for every frame.

Konrad, reading the cases where random numbers are used, do you think it is 
worth the effort?
I am even considering to calculate the masking key just once and use it for 
every frame (would speed up the communication).

Cheers,

Kurt

 
 
   Konrad
 ___
 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] Prettier printing of Unicode strings

[Kurt Pattyn]

On 21 Jan 2014, at 01:05, Thiago Macieira thiago.macie...@intel.com wrote:

 I was writing a test today and QtTest told me:
 
   Actual   (s) : ?12???
   Expected (s2): ?12???
 
 So I went, duh, ok, it looks the same to me but what's behind those question 
 marks.
 
 After a bit of changes [https://codereview.qt-project.org/76100], it now 
 prints:
 
   Actual   (s) : \u221212\u20A0\uD800\uDC00
   Expected (s2): \u221212\u20AC\uD800\uDC00
 
 Which tells me what I got wrong.
 
 Ok to submit this change then? It will make all toString(QString) print
 
 - all backslashes as \\
 - the following characters as their escape sequences: \r, \n, \t, \b, \f
 - all other control characters (including 0x7f) as \u00XX
 - all other characters with \u, including text otherwise readable in the 
   terminal in the locale

But the number 12 is still displayed as 12. Shouldn’t that also be converted to 
the \u00XX format (\u0031\u0032)?

 One major advantage of this is that it does not depend on the locale codec 
 being set up or even working, as the previous code did. So we get consistent 
 results even if there's a bug in that.
 
 Is this ok?
Yes, very okay. It makes QString contents ‘diagnosable'.
 
 Should I also print quotes as \ ? And should I surround the string with 
 quotes?
I would prefer to output everything in \u format and to surround the entire 
output with quotes (to distinguish strings from byte arrays).
 
 Should I also do the same for QByteArray? Reading hex dumps isn't very nice.
Personally, I don’t have a problem with hex dumps. But, if the byte array 
contains text data, then it is worth considering.

Cheers,

Kurt
 -- 
 Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 26 Jan 2014, at 19:12, Konrad Rosenbaum kon...@silmor.de wrote:

 Hi,
  
 [wow, I had a good laugh!]
  
  
 On Sunday 26 January 2014, Kurt Pattyn wrote:
  On 26 Jan 2014, at 11:31, Konrad Rosenbaum kon...@silmor.de wrote:
   Depends. What is it used for? Is it just obfuscation or is it supposed
   to be real security?
  
  Well, there are 2 places where random numbers are used:
  1. During the handshake phase
  Client sends a handshake request containing a 128-bit random number
  converted to a string hex representation (Sec-WebSocket-Key). The server
  appends a well-known UUID (published in the RFC) to that number and
  calculates a SHA-1 hash. This hash in sent to the client, which in its
  turn appends the same UUID to the random number it sent before, and
  calculates a SHA-1 hash. If both the server-sent hash and the client
  calculated hash match, the handshake succeeds.
  
 And this is sent in the open? On an unsecured connection?
This is sent in the header of an HTTP request, fully readable.
Of course, WebSockets also supports SSL.
  
 This is the most elaborate scheme of a not-so-secret handshake that I've read 
 so far! The only thing that is more hilarious is the Big Bang Theory scene in 
 which Sheldon lectures his friends on the secret knock before Leonard's 
 birthday party...
  
 My personal opinion on unencrypted connections: don't sweat it. Use whatever 
 is available. qrand is as secure as the rest of the connection (i.e. not 
 secure at all). Using secure random does not change a thing in this case 
 (only CPU cycles wasted on the client).
  
 On encrypted (SSL) connections: if this covers several HTTP(S) requests and 
 not a simple non-interrupted socket then this should better be some secure 
 128 bits. Although it is beyond me why you would hash them again and again - 
 they could be used as a cookie…
It is one request/response for the handshake and, if successful, the connection 
stays open.

  
 [See bottom of my response for some more elaborate argument on this.]
  
  2. When sending data from client to server (not the other way)
  The client generates a 32-bit random number.
  This random number is stored in plain text in the header of each frame.
  The data is XOR-ed with that 32-bit random number.
  
  The server takes the 32-bit random number from the header and XORs it
  with the payload to get to the original data.
  
  I really fail to see what the intention is of this mechanism. I really
  fail to see what could make this communication ‘secure’.
  
 I seem to remember that a certain Julius Caesar had a similarly clever idea 
 for securing his correspondence. Of course Julius had the excuse that 
 advanced math-based cryptography was not available in his time...
  
 (https://en.wikipedia.org/wiki/Caesar_cipher)

Given the time and the context, this was far better, because it least he didn’t 
specify how to decipher the text :-)
  
  
  The masking key needs to
   be unpredictable; thus, the masking key MUST be derived from a strong
   source of entropy, and the masking key for a given frame MUST NOT
   make it simple for a server/proxy to predict the masking key for a
   subsequent frame.  The unpredictability of the masking key is
   essential to prevent authors of malicious applications from selecting
   the bytes that appear on the wire.”
  
 My above statement about the handshake was wrong. Enormously so.
 This statement tops all the comedy in in my sizable DVD collection!
  
  Why should the masking key be unpredictable if it is send unencrypted
  along with the masked data? Why would a server/proxy predict the masking
  key if it can just fetch it from the header? To me it looks like having
  a locked door with the key in the keyhole. Why would a burglar use a
  crowbar if he has the key?
  
 Exactly. This toy-cipher and its description is equivalent to triple-ROT13 
 (triple for more security…)
I’m glad you mentioned ‘triple’...
  
  
 #-(
  
   If the latter: is it the only way to generate security? (If so: in all
   likelyhood you are affixed by an inclined plane wrapped helicly around
   an axis. In laymans terms: screwed.)
   
   If the former: unless it is absolutely necessary for understanding the
   other side of the communication channel - don't bother implementing
   it. Obscurity is no security.
  
  Well, the standard requires the frames that go from client to server to
  be masked. So yes, it is absolutely necessary, but in my opinion
  complete overkill.
  
 I agree with you. The only thing this defends against is absolutely clueless 
 IT people (pointy haired boss types) who have read access to network logs, 
 but whose 8 year old kids refuse to help with a simple script.
  
 Use any source of (weak) random (e.g. qrand) and ignore this bullshit about 
 strong source of entropy.
  
 If anyone asks you why you are using insecure random:
  
 a) on unsecured connections it is pointless to get secure random and then 
 transmit it in the open together

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

 When websockets becomes part of a Qt module you can consider using 
 QObjectPrivate which makes the d pointer implementation slightly cleaner and 
 removes the need for duplicate d pointers (one from qobject one for the 
 class's own implementation.
I tried to use QObjectPrivate, but then I cannot connect to slots within the 
QObjectPrivate derived class.
Statements like 'connect(object, signal, THIS, slot)’ fail because THIS is not 
derived from QObject.
Have you an idea how to solve this?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 17 Jan 2014, at 19:46, Frederik Gladhorn frederik.gladh...@digia.com wrote:

 Just another remark which I'm not sure about:
 In section 5.2 of rfc 6455 randomness is mentioned. I didn't read up on the 
 background but currently there is only a call to initialize qsrand with 
 QDateTime::currentMSecsSinceEpoch() which is probably not quite according to:
 
   The masking key needs to
   be unpredictable; thus, the masking key MUST be derived from a strong
   source of entropy, and the masking key for a given frame MUST NOT
   make it simple for a server/proxy to predict the masking key for a
   subsequent frame.  The unpredictability of the masking key is
   essential to prevent authors of malicious applications from selecting
   the bytes that appear on the wire.

Date and time are quite predictable :-)
Creating random numbers with a high entropy is quite expensive (if not cached 
beforehand).
This can be problematic, as a new mask has to be calculated for every frame.

What I do find strange though, is that the masking key is sent along 
unencrypted with the frame header and is thus readable by everyone (if not sent 
over secure websockets).
The messages can thus be perfectly decoded, and as the server is not checking 
for the source, a malicious application can invent his own masking keys or 
intercept the message and repackage it (the server just takes whatever masking 
key that is in the header).
I honestly don’t see how this mechanism can protect against malicious 
applications.

So, I wonder if it is worth the effort.

Cheers,

Kurt

 I'd like others with more experience in this area to chime in though.
 
 Greetings,
 Frederik

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remove OSX 10.6 Build?

[Kurt Pattyn]

 On 23 Jan 2014, at 21:16, Jan Farø jan.fa...@gmail.com wrote:
 
 I don’t think anybody has mentioned the lack of ability to upgrade hardware - 
 mostly because of financial issues, I suppose. 10.6 is as far as I know the 
 last Mac OS to support 32 bit systems. Previous versions of my own software 
 supported PPC and down to Mac OS 10.4, which gave me a considerable user base 
 from that segment. Percentages aside, there’s still a LOT of people sitting 
 with old hardware, simply because they cannot afford to upgrade.
 
 XP was introduced in 2001. It’s still supported. Mac OS 10.6 was introduced 
 in 2009. I understand the desire to get rid of the messiness under the hood, 
 but I think it should be considered that it cuts out users on hardware 
 platforms not so much up to date.

Support for XP stops at end 2014: 
http://www.microsoft.com/en-us/windows/enterprise/endofsupport.aspx.
And Microsoft Visual Studio 2012 cannot be installed on XP, but you can target 
XP (and that was already in 2012).

Why not just freeze the Qt development for 10.6? After all, developing for 10.6 
will still be possible with Qt 5.3. I don’t see any problem here. It’s not that 
the code will get removed from the repo; it is only that no new developments 
will take place for that platform.
In the meanwhile, development energy can go into new territories like mobile 
and embedded devices (internet of things). Personally, I'd rather use Qt for 
developing an app for Android or iOS, than developing one for Windows XP or OS 
X 10.6. It is true that there is still a huge install base of 'legacy' OSs. 
Besides limited financial reach, there is also another reason: certification. 
In the medical market for instance, we see figures of 90% and up of Windows XP 
installations. But then on these systems no new applications are installed, nor 
is it expected that new applications are installable on those platforms. IT 
departments more and more switch to VDI to support these legacy systems.

So, +1 for freezing development for OSX 10.6.

—Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebSockets as add-on: current voting status

[Kurt Pattyn]

Great, thanks for the effort.

/Kurt
On 22 Jan 2014, at 11:13, Oswald Buddenhagen oswald.buddenha...@digia.com 
wrote:

 On Mon, Jan 20, 2014 at 01:15:46PM +0100, Kurt Pattyn wrote:
 The majority seems to agree that this should NOT go into the QtNetwork 
 module, but should be an add-on.
 
 the repository was now moved to qt/qtwebsockets.
 - you need to adjust your git remotes (just edit .git/config)
 - when you deem it to be in a reasonable state, you need to integrate
  the repo into qt5.git
 
 ___
 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] QtWebSockets as add-on: current voting status

[Kurt Pattyn]

Hi,

The majority seems to agree that this should NOT go into the QtNetwork module, 
but should be an add-on.
Votes so far:

Peter Hartmann: +1 - add-on
Richard Moore: +1 - add-on
Konstantin Ritt: +1 - add-on
Frederik Gladhorn: +1 - add-on
Lars Knoll: +1 - QtNetwork

Simon Hausmann has questions regarding the QML component:
Given that there exists a web idl for Web sockets, I suggest the qml api to 
consist of a QML element and a Javascript constructor. The prototype and the 
qml element should probably have the same api, the web Standard one.
It is in our interest that third-part JS code out there using web sockets can 
be used seamlessly in qml.”

Maybe it is interesting to know that the API of QML module evolved from 
‘function-based’ to ‘declarative-based’ after discussion with Alan Alpert. To 
me, the module feels fine, but there is of course much to say about the 
standard Web Sockets API as described in http://www.w3.org/TR/websockets/. I 
really don’t have an opinion here.
Of course, for a first version the QML module can be left out until the 
direction is clear on this.
What are your thoughts?

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Remove OSX 10.6 Build?

[Kurt Pattyn]

The CI system is still building for OSX 10.6.
Given the fact that OSX is at version 10.9 now, shouldn’t the build for 10.6 be 
removed, and ideally replaced with a build for OSX 10.9?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remove OSX 10.6 Build?

[Kurt Pattyn]

On 20 Jan 2014, at 18:52, André Somers an...@familiesomers.nl wrote:

 Hi,
 
 Op 20 jan. 2014 om 17:36 heeft Kurt Pattyn pattyn.k...@gmail.com het 
 volgende geschreven:
 
 The CI system is still building for OSX 10.6.
 Given the fact that OSX is at version 10.9 now, shouldn’t the build for 10.6 
 be removed, and ideally replaced with a build for OSX 10.9?
 Why should it be one to the exclusion of the other? Imho, it would make sense 
 to test against both the oldest and the newest version supported... The 
 again, I am not a test engineer.
Okay, it should not be one or the other. It is just that 10.6 is quite old.
However, I just found out that you can still order this version from the Apple 
Store: http://store.apple.com/us/product/MC573Z/A/mac-os-x-106-snow-leopard.

Cheers,

Kurt

 
 André
 ___
 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] Missing builds on the CI server?

[Kurt Pattyn]

Following is an overview of the officially supported platforms for Qt (see 
http://qt.digia.com/Product/Qt-Core-Features-Functions/Supported-Platforms/).
I also added an indication whether the platform is currently built on the CI 
infrastructure (see 
http://testresults.qt-project.org/ci/Qt5_release_Integration/build_00295/).

Primary supported platforms for Qt5.x  Built on CI?
--
Windows 7 32-bit with VS 2010  Y
Windows 7 32-bit with MinGW 4.7Y
Windows 7 64-bit with VS 2010  N
Windows 7 64-bit with VS 2012  N
Windows 8 64-bit with VS 2012  Y
Ubuntu 11.04 32-bit with gcc 4.4.3 N
Ubuntu 11.10 32/64-bit with gcc 4.6.1  Y (no clue about the gcc 
version)
Ubuntu 12.04 64-bit with gcc 4.6.3 Y (no clue about the gcc 
version)
OS X 10.6 32/64-bit with Apple gcc compilerY
OS X 10.7 32/64-bit with Apple clang compiler  Y
OS X 10.8 64-bit with Apple clang compiler Y
Windows Embedded Compact 7 (ARM  x86) with VS 2008N (but there is a 
WindowsCE build)
Windows Embedded Standard 7 (x86) with VS 2008 N (but there is a 
WindowsCE build)

Secondary supported platforms for Qt5.x:
--
Windows XP 32/64-bit with VS 2010  N
Windows XP 32/64-bit with VS 2012  N
Windows XP 32/64-bit with MinGW 4.7N
Windows Vista 32/64-bit with VS 2010   N
Windows Vista 32/64-bit with VS 2012   N
Windows Vista 32/64-bit with MinGW 4.7 N
Windows 7 32-bit with VS 2012  N
Windows 7 64-bit with VS 2012  N
Windows 8 32-bit with VS 2010  N
Windows 8 32-bit with VS 2012  N
Windows 8 32-bit with MinGW 4.7N
Windows 8 64-bit with VS 2010  N
Windows 8 64-bit with MinGW 4.7N
Embedded Linux (x86, MIPS, PowerPC) with
arm-none-linux-gnueabi-gcc 4.4.1   Y (ARM only)
QNX with vendor supplied gcc   N
iOS with Apple CompilerY
Android with gcc   Y

As can be seen, there is no build for Windows 7 64-bit, no build for Ubuntu 
11.04 and no builds for Windows Embedded 7.
I was wondering if this is something that should be added to the CI, or if it 
has been left out on purpose?
Also, for the secondary platforms, only iOS, Android and Embedded Linux on ARM 
are built; all other platforms are not built.

Cheers,

Kurt___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [BUG] QEvent::WindowActivate and QEvent::WindowDeactivate are not triggered .

[Kurt Pattyn]

On 19 Jan 2014, at 14:18, iMath 2281570...@qq.com wrote:

 when the widget is Activated or Deactivated ,QEvent::WindowActivate and 
 QEvent::WindowDeactivate are not triggered 

Please create a bug report  at https://bugreports.qt-project.org.
 .
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

On 17 Jan 2014, at 08:54, Knoll Lars lars.kn...@digia.com wrote:

 From a feature point of view it would fit best into Qt Network. But it's a 
 sizeable piece of code added to Qt Network. Do you have any numbers on how 
 this changes the size of Qt Network?

The binary release library on OSX is 197 KB (against 1.5MB for the QtNetwork 
library). There are around 7000 lines of code, 16 header files, 13 source files 
(these include the QML module), 3 public C++ classes and 1 public QML component.

Cheers,

Kurt
 
 Peter and Rich, and comments from your side?
 
 Cheers,
 Lars
 
 On 16/01/14 19:41, Steve Gold steveg2...@gmail.com wrote:
 
 I recommend that it be included in Qt 5.3 as part of the QtNetwork module.
  
 Regards,
  
 Steve
  
 From: Kurt Pattyn
 Sent: Thursday, January 16, 2014 6:51 AM
 To: development@qt-project.org
 Cc: Heikkinen Jani ; mailto:thiago.macie...@intel.com ; richmoor...@gmail.com 
 ; releas...@qt-project.org
 Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
  
 I would like to propose the QtWebSockets module as a new feature for Qt 5.3 
 (see https://qt.gitorious.org/qtplayground/websockets/source/master)
  
 There are a number of requests in Jira: 
 https://bugreports.qt-project.org/issues/?jql=labels%20%3D%20websockets 
 asking to include web socket functionality in Qt, so maybe it is a good time 
 to include it now.
 Besides that, EnginIo could make use of this module as well (currently it 
 uses an own implementation of web sockets).
  
 QtWebSockets is fully RFC6455 compliant (see 
 http://tools.ietf.org/html/rfc6455) and is successfully tested against the 
 latest Autobahn TestSuite. Performance is OK as well (test report is not 
 included because of too big).
  
 There is a C++ interface as well as a QML module.
 The C++ API consists of the following classes:
 QWebSocket
 QWebSocketServer
 QWebSocketProtocol
  
 The QML API consists of the following component:
 WebSocket (included in the Qt.WebSockets 1.0 module).
  
 I see 2 options: either add the functionality to the QtNetwork module, or add 
 it as a Qt add-on.
 Maybe adding it to QtNetwork would be a ‘natural’ place: QWebSocket would 
 then live besides QTcpSocket, QWebSocketServer would live besides QTcpServer.
  
 The module compiles on all reference platforms, has automated unit tests and 
 manual unit tests (against Autobahn TestSuite), is fully documented, and has 
 a number of examples.
 The module is included in the CI system of Qt (see 
 http://testresults.qt-project.org/ci/WebSockets_master_Integration/).
  
  
 Please raise your votes.
  
 Cheers,
  
 Kurt
  
  
  
 On 16 Jan 2014, at 09:28, Heikkinen Jani jani.heikki...@digia.com wrote:
 
 Hi all,
  
 I want to remind you all that Qt 5.3 feature freeze is coming pretty soon. 
 Feature freeze for Qt 5.3 is 14th Feb 2014 so there is only 4 weeks left for 
 implementing new features.
  
 Qt 5.3 schedule can be found here: http://qt-project.org/wiki/Qt-5.3-release 
 . There is also link to the Qt 5.3 new features page 
 (http://qt-project.org/wiki/New-Features-in-Qt-5.3). You can start 
 collecting list of new features there…
  
 Note: Let’s keep the feature freeze date! If your feature isn’t ready at 
 that point let’s then move it to Qt 5.4 release instead of taking in it in 
 Qt 5.3 and fighting with it whole release time…
 This is also action point for each maintainer: Make sure your component is 
 ready for feature freeze at that date.
  
 Just a reminder:
 In the feature freeze all new functionality must
  
 - Compile on all reference platforms (If a module/feature is only for one 
 platform, make sure qmake/make does nothing on the other platforms)
 - Have tests. Automated tests should cover as much as possible of the new 
 functionality. If certain areas are not covered by automated tests, there 
 must be clarification how testing will be done for those
 - Have documentation. No undocumented public API. Basic docs have to be 
 there, only polishing should still be required after the freeze
 - Have examples. Have some examples showing how to use the API. Examples 
 need to be linked to from documentation.
  
 In addition, new modules need to
  
 - Follow the branching scheme. dev/stable/release should be there. A new 
 module can be ok to only have dev, with stable being created at branching 
 time.
 - Have a CI system. New modules that are going to be part of Qt releases 
 need to have a CI system set up
  
 Br,
 Jani
 ___
 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] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

On 17 Jan 2014, at 10:01, Peter Hartmann phartm...@blackberry.com wrote:

 On 01/17/2014 08:54 AM, Knoll Lars wrote:
 From a feature point of view it would fit best into Qt Network. But
 it's a sizeable piece of code added to Qt Network. Do you have any
 numbers on how this changes the size of Qt Network?
 
 Peter and Rich, and comments from your side?
 
 Size-wise I think it is ok; we could add QT_NO_WEBSOCKETS defines or so if 
 somebody wants to exclude it. Also the API looks clean and very similar to 
 our current socket APIs; IIRC Shane did some review already, I did not look 
 into it closely.
 
 One thing I have been wondering about wrt web sockets is: Where are they 
 actually used? I am not saying they are not, but I have never come across a 
 big site (Facebook, Twitter etc.) that offered clients to use it. The only 
 thing I have found is this rather outdated discussion, which mentions a few 
 sites:
 http://www.quora.com/Which-sites-are-using-websockets-right-now

Well, EnginIo for instance is using it :-)
Besides that, there are more and more people using node.js with web sockets or 
even socket.io for their applications (both Amazon EC2 and Azure are providing 
node.js services).
Services like Pusher use it to deliver real-time notifications.
I think that QML could benefit also. The web sockets component opens up a 
bi-directional way for communication with backend services.

 
 Again, I am not saying we don't want it; I just want to gain some more 
 understanding on whether we want it directly in QtNetwork...
 
 Another thing: Kurt, would you be willing to maintain this part of the code? 
 I probably will not be looking into it too much until it benefits my employer 
 (i.e. if some BlackBerry app is using it).
I am certainly willing to maintain this. No problem.
 
 Peter
 
 -
 This transmission (including any attachments) may contain confidential 
 information, privileged material (including material protected by the 
 solicitor-client or other applicable privileges), or constitute non-public 
 information. Any use of this information by anyone other than the intended 
 recipient is prohibited. If you have received this transmission in error, 
 please immediately reply to the sender and delete this information from your 
 system. Use, dissemination, distribution, or reproduction of this 
 transmission by unintended recipients is not authorized and may be unlawful.
 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

On 17 Jan 2014, at 10:30, Simon Hausmann simon.hausm...@digia.com wrote:

 
 (removing releasing and other dev subscribed folks from CC)
 
 On Thursday 16. January 2014 12.51.28 Kurt Pattyn wrote:
 I would like to propose the QtWebSockets module as a new feature for Qt 5.3
 (see https://qt.gitorious.org/qtplayground/websockets/source/master)
 
 There are a number of requests in Jira:
 https://bugreports.qt-project.org/issues/?jql=labels%20%3D%20websockets
 asking to include web socket functionality in Qt, so maybe it is a good
 time to include it now. Besides that, EnginIo could make use of this module
 as well (currently it uses an own implementation of web sockets).
 
 QtWebSockets is fully RFC6455 compliant (see
 http://tools.ietf.org/html/rfc6455) and is successfully tested against the
 latest Autobahn TestSuite. Performance is OK as well (test report is not
 included because of too big).
 
 There is a C++ interface as well as a QML module.
 The C++ API consists of the following classes:
 QWebSocket
 QWebSocketServer
 QWebSocketProtocol
 
 The QML API consists of the following component:
 WebSocket (included in the Qt.WebSockets 1.0 module).
 
 I see 2 options: either add the functionality to the QtNetwork module, or
 add it as a Qt add-on. Maybe adding it to QtNetwork would be a ‘natural’
 place: QWebSocket would then live besides QTcpSocket, QWebSocketServer
 would live besides QTcpServer.
 
 The module compiles on all reference platforms, has automated unit tests and
 manual unit tests (against Autobahn TestSuite), is fully documented, and
 has a number of examples. The module is included in the CI system of Qt
 (see http://testresults.qt-project.org/ci/WebSockets_master_Integration/).
 
 
 Please raise your votes.
 
 I think it would be a great feature to have in Qt.
 
 I've had a brief look at the API and I have a few comments:
 
 * qwebsocketprotocol.h:
   * V_Unknow should probably be V_Unknow_n_ :)
   * CC_GOING_AWAY, etc: This should probably use camel casing instead of all 
 upper case, in order to be consistent with the rest of the Qt API.
Agree.

   * I suggest to remove inline Version currentVersion() { return V_LATEST; } 
 - the function adds no value IMHO as the latest enum value will always be 
 that.
Or maybe make it an ‘outline’ function, in case there comes a newer version of 
web sockets.
 
 * qwebsocket.h:
 
  * qint64 QWebSocket::write(const char *message)
This function appears to send message as a text message and expects 
 utf-8 encoding. But unfortunately I think it looks misleading because 
 QIODevice::write has the same signature and means binary content - no 
 assumption about encodings are done. I suggest to rename the
 method to writeTextMessage(const QString ) and just writeBinaryMessage(const 
 QByteArray ) - without any const char * overloads. It makes it very easy to 
 understand the client code when reading it (ahh, it's sending a text 
 message or ahh, it's sending a binary message”).
Indeed. Is is better to remove the (const char *) methods as this can be 
confusing. I am not sure whether the functions should be renamed to 
writeTextMessage and writeBinaryMessage. I am following the QIODevice API here.

 
   * The API appears to miss a complete the notion of fragments. writeMessage 
 appears to always send a frame, but on the receiving end the concept of 
 fragments appears - this looks inconsistent. I'll elaborate a bit more about 
 that separately.
The reason the textFrameReceived and binaryFrameReceived signals are there, is 
to let the receiving application start processing the message as soon as a 
fragment arrives. This can be interesting in case of large payloads.
 
 I can think of two different ways of using web sockets:
 
 1) Sending/receiving messages of a given protocol
 2) Sending/receiving streams
 
 It appears that the web socket protocol encapsulates both, with the notion of 
 messages consisting of a variable (potentially unlimited) number of 
 fragments. I think it is important to make both use-cases very easy. When I'm 
 implementing
 a message based protocol (for example chat client), I really want the 
 underlying framework to deal with fragments and only deliver entire frames to 
 me. When implementing for example a video streaming service, I need full 
 control (on both ends)
 over fragmentation.


 And to make it worse, it seems that over the same connection I could be 
 sending a stream (variable fragments of the same frame) intermixed with 
 single fragments. Is my interpretation of the spec correct here?
With web sockets you can intermix text and binary messages, but you have no 
control over the ‘fragments’ (frames in web socket lingo). These frames are 
comparable to TCP or UDP packets. Web sockets is splitting ‘large’ messages 
into frames ‘under the hood’, where the first frame indicates that it is the 
first frame, subsequent frames indicate that they are continuation frames and 
the last frame indicates it is the final one

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 17 Jan 2014, at 14:10, Gladhorn Frederik frederik.gladh...@digia.com wrote:

 Hi Kurt,
 
 I'm quite impressed with the state of the websockets module.
Thanks!
 I tried reviewing the code, but I have to admit that I just started reading 
 the RFC a bit, so here are some first random notes.
 
 When websockets becomes part of a Qt module you can consider using 
 QObjectPrivate which makes the d pointer implementation slightly cleaner and 
 removes the need for duplicate d pointers (one from qobject one for the 
 class's own implementation.
Okay, will fix that.
 
 In the public interface I'd generally declare signals with const refs, alone 
 for consistency.
Done. Your patch has been reviewed and merged (thanks for that).
 
 While not really harmful there is generally no point in explicitly 
 initializing empty strings, I'd personally remove the QString() calls from 
 the class initialzers just to remove a few lines.
 
 qsslserver newEncryptedConnection is never emitted, I didn't look into what 
 it means though.
Hmmm, I’ll have a look at that one.
 
 qwebsockethandshakeresponse: m_acceptedExtension doesn't seem used, instead 
 there is a string list passed through, I suppose it can simply be removed, it 
 also has a getter that will always return an empty string.
Will check this also.
 
 
 I was reading the RFC a bit, in section 9.1 there are some notes about the 
 extensions:
 
 const QListQString matchingExtensions =
 
 supportedExtensions.toSet().intersect(request.extensions().toSet()).toList();
 
 does no longer guarantee the order of extentions - according to sec 9.1. this 
 is important.
Right. Will fix this.
 
 The same seems to go for matchingProtocols - the first one is picked, since 
 QSet doesn't guarantee any order it is basically chosen by random.
 I don't know how significant that is but I assume the client's first choice 
 (?) should be taken.
Hmm, the list is sorted in descending order, and the server picks the latest 
protocol version that it supports. That seems fine to me, but I’ll double-check 
the RFC.


Cheers,

Kurt
 
 Greetings,
 Frederik
 
 From: development-bounces+frederik.gladhorn=digia@qt-project.org 
 [development-bounces+frederik.gladhorn=digia@qt-project.org] on behalf of 
 Kurt Pattyn [pattyn.k...@gmail.com]
 Sent: Thursday, January 16, 2014 12:51 PM
 To: development@qt-project.org
 Cc: Heikkinen Jani; 'thiago.macie...@intel.com' (thiago.macie...@intel.com); 
 richmoor...@gmail.com; releas...@qt-project.org
 Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
 
 I would like to propose the QtWebSockets module as a new feature for Qt 5.3 
 (see https://qt.gitorious.org/qtplayground/websockets/source/master)
 
 There are a number of requests in Jira: 
 https://bugreports.qt-project.org/issues/?jql=labels%20%3D%20websockets 
 asking to include web socket functionality in Qt, so maybe it is a good time 
 to include it now.
 Besides that, EnginIo could make use of this module as well (currently it 
 uses an own implementation of web sockets).
 
 QtWebSockets is fully RFC6455 compliant (see 
 http://tools.ietf.org/html/rfc6455) and is successfully tested against the 
 latest Autobahn TestSuite. Performance is OK as well (test report is not 
 included because of too big).
 
 There is a C++ interface as well as a QML module.
 The C++ API consists of the following classes:
 QWebSocket
 QWebSocketServer
 QWebSocketProtocol
 
 The QML API consists of the following component:
 WebSocket (included in the Qt.WebSockets 1.0 module).
 
 I see 2 options: either add the functionality to the QtNetwork module, or add 
 it as a Qt add-on.
 Maybe adding it to QtNetwork would be a ‘natural’ place: QWebSocket would 
 then live besides QTcpSocket, QWebSocketServer would live besides QTcpServer.
 
 The module compiles on all reference platforms, has automated unit tests and 
 manual unit tests (against Autobahn TestSuite), is fully documented, and has 
 a number of examples.
 The module is included in the CI system of Qt (see 
 http://testresults.qt-project.org/ci/WebSockets_master_Integration/).
 
 
 Please raise your votes.
 
 Cheers,
 
 Kurt
 
 
 
 On 16 Jan 2014, at 09:28, Heikkinen Jani jani.heikki...@digia.com wrote:
 
 Hi all,
  
 I want to remind you all that Qt 5.3 feature freeze is coming pretty soon. 
 Feature freeze for Qt 5.3 is 14th Feb 2014 so there is only 4 weeks left for 
 implementing new features.
  
 Qt 5.3 schedule can be found here: http://qt-project.org/wiki/Qt-5.3-release 
 . There is also link to the Qt 5.3 new features page 
 (http://qt-project.org/wiki/New-Features-in-Qt-5.3). You can start 
 collecting list of new features there…
  
 Note: Let’s keep the feature freeze date! If your feature isn’t ready at 
 that point let’s then move it to Qt 5.4 release instead of taking in it in 
 Qt 5.3 and fighting with it whole release time…
 This is also action point for each maintainer: Make sure your component is 
 ready

Re: [Development] Text to Speech classes (tts)

[Kurt Pattyn]

To me an add-on is fine and the name is fine as well as it covers exactly what 
it does.
+1 for the add-on.

On 17 Jan 2014, at 14:21, Frederik Gladhorn frederik.gladh...@digia.com wrote:

 Hi,
 
 I recently worked on a few small classes that wrap native TTS frameworks (for 
 now SAPI5 on Windows, the Cocoa API on Mac, speech-dispatcher on Linux and 
 the 
 native Android tts framework).
 
 Since I have the very basics working on all platforms mentioned above I'd 
 thought it's a good time to create a playground repo and put the code there.
 
 So this is a request for a repository, playground/qspeech (?). And I'm also 
 open for a name for the repo and module.
 
 Currently it's a self contained C++ only module (QT += speech).
 
 -- 
 Best regards,
 Frederik Gladhorn
 Senior Software Engineer - Digia, Qt
 Visit us on: http://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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Kurt Pattyn]

On 17 Jan 2014, at 17:56, Kurt Pattyn pattyn.k...@gmail.com wrote:

 
 On 17 Jan 2014, at 14:10, Gladhorn Frederik frederik.gladh...@digia.com 
 wrote:
 
 Hi Kurt,
 
 I'm quite impressed with the state of the websockets module.
 Thanks!
 I tried reviewing the code, but I have to admit that I just started reading 
 the RFC a bit, so here are some first random notes.
 
 When websockets becomes part of a Qt module you can consider using 
 QObjectPrivate which makes the d pointer implementation slightly cleaner and 
 removes the need for duplicate d pointers (one from qobject one for the 
 class's own implementation.
 Okay, will fix that.
 
 In the public interface I'd generally declare signals with const refs, alone 
 for consistency.
 Done. Your patch has been reviewed and merged (thanks for that).
 
 While not really harmful there is generally no point in explicitly 
 initializing empty strings, I'd personally remove the QString() calls from 
 the class initialzers just to remove a few lines.
 
 qsslserver newEncryptedConnection is never emitted, I didn't look into what 
 it means though.
 Hmmm, I’ll have a look at that one.
This signal is emitted (see line 82): 
   connect(pSslSocket, QSslSocket::encrypted, this, 
QSslServer::newEncryptedConnection);

 
 qwebsockethandshakeresponse: m_acceptedExtension doesn't seem used, instead 
 there is a string list passed through, I suppose it can simply be removed, 
 it also has a getter that will always return an empty string.
 Will check this also.
This variable is used (see line 172 and following):
   if (!matchingExtensions.isEmpty()) {
   m_acceptedExtension = matchingExtensions.first();
   response  QStringLiteral(Sec-WebSocket-Extensions: ) % 
m_acceptedExtension;
   }

But extensions are currently not supported by the QWebSocketServer, so that 
member variable will always be empty.
Once the server supports extensions, this variable will not be empty, and the 
header will be correctly filled in.
Since this is an internal class, I propose to leave it in.

 
 
 I was reading the RFC a bit, in section 9.1 there are some notes about the 
 extensions:
 
 const QListQString matchingExtensions =
 
 supportedExtensions.toSet().intersect(request.extensions().toSet()).toList();
 
 does no longer guarantee the order of extentions - according to sec 9.1. 
 this is important.
 Right. Will fix this.
 
 The same seems to go for matchingProtocols - the first one is picked, since 
 QSet doesn't guarantee any order it is basically chosen by random.
 I don't know how significant that is but I assume the client's first choice 
 (?) should be taken.
 Hmm, the list is sorted in descending order, and the server picks the latest 
 protocol version that it supports. That seems fine to me, but I’ll 
 double-check the RFC.
The RFC doesn’t say anything about the ordering, so I think taking the most 
recent protocol version that both parties support should be fine.
 
 
 Cheers,
 
 Kurt
 
 Greetings,
 Frederik
 
 From: development-bounces+frederik.gladhorn=digia@qt-project.org 
 [development-bounces+frederik.gladhorn=digia@qt-project.org] on behalf 
 of Kurt Pattyn [pattyn.k...@gmail.com]
 Sent: Thursday, January 16, 2014 12:51 PM
 To: development@qt-project.org
 Cc: Heikkinen Jani; 'thiago.macie...@intel.com' (thiago.macie...@intel.com); 
 richmoor...@gmail.com; releas...@qt-project.org
 Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
 
 I would like to propose the QtWebSockets module as a new feature for Qt 5.3 
 (see https://qt.gitorious.org/qtplayground/websockets/source/master)
 
 There are a number of requests in Jira: 
 https://bugreports.qt-project.org/issues/?jql=labels%20%3D%20websockets 
 asking to include web socket functionality in Qt, so maybe it is a good time 
 to include it now.
 Besides that, EnginIo could make use of this module as well (currently it 
 uses an own implementation of web sockets).
 
 QtWebSockets is fully RFC6455 compliant (see 
 http://tools.ietf.org/html/rfc6455) and is successfully tested against the 
 latest Autobahn TestSuite. Performance is OK as well (test report is not 
 included because of too big).
 
 There is a C++ interface as well as a QML module.
 The C++ API consists of the following classes:
 QWebSocket
 QWebSocketServer
 QWebSocketProtocol
 
 The QML API consists of the following component:
 WebSocket (included in the Qt.WebSockets 1.0 module).
 
 I see 2 options: either add the functionality to the QtNetwork module, or 
 add it as a Qt add-on.
 Maybe adding it to QtNetwork would be a ‘natural’ place: QWebSocket would 
 then live besides QTcpSocket, QWebSocketServer would live besides QTcpServer.
 
 The module compiles on all reference platforms, has automated unit tests and 
 manual unit tests (against Autobahn TestSuite), is fully documented, and has 
 a number of examples.
 The module is included in the CI system of Qt (see 
 http://testresults.qt-project.org/ci

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

So, based on the feedback, can everybody agree on QtWebSockets being an add-on?
It keeps the core as is, and provides an opt-in for applications that need it.

Cheers,

Kurt

 On 17 Jan 2014, at 12:25, Richard Moore richmoor...@gmail.com wrote:
 
 On 17 January 2014 07:54, Knoll Lars lars.kn...@digia.com wrote:
 
 From a feature point of view it would fit best into Qt Network. But it's a 
 sizeable piece of code added to Qt Network. Do you have any numbers on how 
 this changes the size of Qt Network?
 
 Peter and Rich, and comments from your side?
 
 Given that the websocket code contains both C++ networking stuff and
 also QML it cannot all go into qt network as this would introduce a
 circular dependency on the qtdeclarative module. This would mean
 splitting it into two one part in qt network and another in qt
 declarative which I think would be a bit confusing for users.
 
 On the other hand as an addon module the dependency problem is gone
 and it can be available as a single self-contained module (with
 unified documentation) which I suspect would be easier on those using
 the module. I don't think adding QT += websockets to the pro file
 would be a barrier for adoption.
 
 Given the above (and ignoring the issue of code-size etc.) my initial
 feeling is that an addon module is probably a better choice for users
 of the module.
 
 Cheers
 
 Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

 On 17 Jan 2014, at 12:13, Blasche Alexander alexander.blas...@digia.com 
 wrote:
 
 
 
 --
 Alex
 
 On Fri, Jan 17, 2014 at 10:49 AM, Pau Garcia i Quiles pgqui...@elpauer.org
 wrote:
 
 
Hello,
 
If it's currently a separate module, which compiles by itself and can be
 used by itself, why not adding it as an add-on?
 
I have started to use Qt on mobile and while 200 more KB is nothing on
 desktop, on mobile, 200 KB here and 200 KB there is a lot on mobile.
 
I think it's best if a pattern is created: the more functionality that 
 can be
 provided as add-ons, the better (which is in fact what KDE has been doing 
 with
 the split of kdelibs in KF5: define the dependencies of search add-on, and 
 you are
 fine to use only this or that).
 
 I agree with this statement. I fail to see a good reason why it must be 
 joined. Sure there I is a spiritual one but is that really sufficient 
 argument? We have to burden just about every Qt user with it. In my opinion 
 it is common if you do something related to browser development but I can 
 also think of plenty of apps which would never require it. Over time these 
 things tend to add up as well (200k here and another 50k and viola you have a 
 lib that's 0.5MB larger).
 
Yes, I know, I can use the QT_NO_WEBSOCKETS as Simon suggested but
 wouldn't it be easier if nobody has to care about that? Don't want 
 websockets?
 Don't use the add-on. Or is there anything fundamental that will be gained by
 having QtWebsockets be part of QtNetwork and I have missed it?
 
 Qt's past has shown that such defines have a very short lifetime as virtually 
 nobody compiles the myriads of define combinations.
 
 Apart from that we create two incompatible versions of the same library. This 
 may work if you have obscure features which really only a minority of users 
 requires but that cannot be said either in this case. 
 
 If you have your own module you don't have to split the QML code out into a 
 totally different git repo/module either. LBNL the code is already separate. 
 You safe doing the merge and it proved that it doesn't require some deep 
 hidden internals from QtNetwork .
 
These arguments make complete sense. The mobile use case is a very good 
example. For embedded devices this shouldn't be a problem, as normally Qt gets 
built from the sources anyway. Of course, one could always buy a commercial 
license ;-) (I am not affiliated with Digia).
I proposed the add-on choice as the way to go.

Cheers,
Kurt


 --
 Alex
 
 ___
 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] Fwd: Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

 On 17 Jan 2014, at 21:01, Matt Broadstone mbroa...@gmail.com wrote:
 
 I'm inclined to agree with Rich, opting for keeping this as an addon.. for 
 now. It's a 7k loc codebase that was mostly written in the past 1-3 months.
The code is actually older than the 3 months it is on the playground.
 How much has it been tested in the real world? Do you have examples of people 
 using it in production?
Well, this is one product: 
http://www.barco.com/en/products-solutions/software/medical-calibration-and-qa-software/automated-quality-assurance-of-medical-displays-in-private-practices.aspx/.
I received mails from people asking when this would be included in Qt, because 
they are hesitant to use a non-official module. It's a chicken-and-egg problem.
I know of 2 high-end products that are including this into their next release 
(cannot disclose now). I used it in several projects, one of which was a server 
delivering big DICOM files to browsers. Furthermore, I can imagine Enginio 
using it (Frederik or Jedrzej could you shed some light on this?).

 It also seems like actual review of the module has just begun in this very 
 email thread.
There were already quite some reviews. But now it got renewed attention. There 
is nothing fundamentally wrong with the code; here and there some minor 
adaptations, but nothing fundamental to the API. The QML component has been 
reviewed by Alan.
 
 There's likelihood that the API is going to change (perhaps dramatically) 
 based on actual usage, and you would be limiting your ability to make those 
 changes by moving it into the core module.
The API is stable and has been reduced to its bare minimum. Some methods have 
been removed, because it is easier to add them then to remove them, if ever 
needed.
 
 tl;dr: wouldn't it be better to maintain it as an add-on for now and let it 
 mature a little bit, rather than rush to judgement for this release?
No rushing here. The feature list of 5.3 gets closed soon, so it's a good time 
to propose.
The problem with an add-on on the playground is the build system. Some people 
on Windows are complaining that they have to install Perl in order to compile. 
Others don't like compiling 3rd party modules and prefer binaries.
The code has been extensively tested with the Autobahn TestSuite and was tested 
with XCode Instruments for memory leaks. I am quite confident that the code is 
mature enough.
Besides that, there are requests in Jira asking for web socket functionality. 
So, at least 3 people would be made happy :-)

Cheers,
Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Kurt Pattyn]

I would like to propose the QtWebSockets module as a new feature for Qt 5.3 
(see https://qt.gitorious.org/qtplayground/websockets/source/master)

There are a number of requests in Jira: 
https://bugreports.qt-project.org/issues/?jql=labels%20%3D%20websockets asking 
to include web socket functionality in Qt, so maybe it is a good time to 
include it now.
Besides that, EnginIo could make use of this module as well (currently it uses 
an own implementation of web sockets).

QtWebSockets is fully RFC6455 compliant (see 
http://tools.ietf.org/html/rfc6455) and is successfully tested against the 
latest Autobahn TestSuite. Performance is OK as well (test report is not 
included because of too big).

There is a C++ interface as well as a QML module.
The C++ API consists of the following classes:
QWebSocket
QWebSocketServer
QWebSocketProtocol

The QML API consists of the following component:
WebSocket (included in the Qt.WebSockets 1.0 module).

I see 2 options: either add the functionality to the QtNetwork module, or add 
it as a Qt add-on.
Maybe adding it to QtNetwork would be a ‘natural’ place: QWebSocket would then 
live besides QTcpSocket, QWebSocketServer would live besides QTcpServer.

The module compiles on all reference platforms, has automated unit tests and 
manual unit tests (against Autobahn TestSuite), is fully documented, and has a 
number of examples.
The module is included in the CI system of Qt (see 
http://testresults.qt-project.org/ci/WebSockets_master_Integration/).


Please raise your votes.

Cheers,

Kurt



On 16 Jan 2014, at 09:28, Heikkinen Jani jani.heikki...@digia.com wrote:

 Hi all,
  
 I want to remind you all that Qt 5.3 feature freeze is coming pretty soon. 
 Feature freeze for Qt 5.3 is 14th Feb 2014 so there is only 4 weeks left for 
 implementing new features.
  
 Qt 5.3 schedule can be found here: http://qt-project.org/wiki/Qt-5.3-release 
 . There is also link to the Qt 5.3 new features page 
 (http://qt-project.org/wiki/New-Features-in-Qt-5.3). You can start collecting 
 list of new features there…
  
 Note: Let’s keep the feature freeze date! If your feature isn’t ready at that 
 point let’s then move it to Qt 5.4 release instead of taking in it in Qt 5.3 
 and fighting with it whole release time…
 This is also action point for each maintainer: Make sure your component is 
 ready for feature freeze at that date.
  
 Just a reminder:
 In the feature freeze all new functionality must
  
 - Compile on all reference platforms (If a module/feature is only for one 
 platform, make sure qmake/make does nothing on the other platforms)
 - Have tests. Automated tests should cover as much as possible of the new 
 functionality. If certain areas are not covered by automated tests, there 
 must be clarification how testing will be done for those
 - Have documentation. No undocumented public API. Basic docs have to be 
 there, only polishing should still be required after the freeze
 - Have examples. Have some examples showing how to use the API. Examples need 
 to be linked to from documentation.
  
 In addition, new modules need to
  
 - Follow the branching scheme. dev/stable/release should be there. A new 
 module can be ok to only have dev, with stable being created at branching 
 time.
 - Have a CI system. New modules that are going to be part of Qt releases need 
 to have a CI system set up
  
 Br,
 Jani
 ___
 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] Development Digest, Vol 28, Issue 32

[Kurt Pattyn]

I had some changes but unit tests are failing with
FAIL!  : tst_QTcpServer::linkLocal(WithoutProxy) 
'socket-waitForConnected(5000)' returned FALSE. ()
 Loc: [../tst_qtcpserver.cpp(929)]

Is there a problem with the test servers?

see: https://codereview.qt-project.org/#change,73476 and
https://codereview.qt-project.org/#change,73486

These are 2 unrelated changes, but the unit tests fail at the same place.

Best regards,

Kurt


On 13 Jan 2014, at 15:07, development-requ...@qt-project.org wrote:

 From: Paaso Matti matti.pa...@digia.com
 Subject: Re: [Development] HEADS UP: Qt 5.2.1 - merge stable into release
 Date: 13 Jan 2014 12:03:56 GMT+1
 To: Paaso Matti matti.pa...@digia.com, development@qt-project.org 
 development@qt-project.org
 Cc: releas...@qt-project.org releas...@qt-project.org
 
 
 Hi,
  
 Just a reminder: stable-release merge is ongoing. Still waiting for last 
 staged changed to be integrated, and after that we can proceed with the merge.
 There seems to be some changes in stable which are not staged, so those 
 changes has to be submitted into release –branch if change needs to be in 
 5.2.1.
 BR,
 Matti Paaso

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] #pragma or xxx_s functions

[Kurt Pattyn]

On 19 Dec 2013, at 02:31, Thiago Macieira thiago.macie...@intel.com wrote:
 
 I especially like memcpy_s, which takes an extra argument which is most often 
 the exact same value you were already passing anyway[1]. Too bad they didn't 
 make memcmp_s, that would have been funny, returning EDOOFUS if you passed 
 the 
 wrong args :-)
Maybe Qt can add #error EDOOFUS when an MSVC compiler is detected J

 
 [1] http://msdn.microsoft.com/en-us/library/wes2t00f.aspx
 [2] http://fxr.watson.org/fxr/ident?i=EDOOFUS
  See also the suggested replacements at [3], of which I like EEK best
 [3] 
 https://groups.google.com/forum/?hl=en#!msg/fa.freebsd.hackers/V7cWmQeWVfg/IIjCCbdz4BEJ
 
 -- 
 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] Let's get rid of qDebug/qWarning/qCritical!

[Kurt Pattyn]

On 08 Jan 2014, at 10:12, Koehne Kai kai.koe...@digia.com wrote:

 
 You can then use it like that:
 
 If (qtCoreIo().isDebugEnabled()) {
QString x = expensive();
qCDebug(qtCoreIo)  Expensive:   x;
 }
 
 Anyhow, note that qCDebug(qtCoreIo) expands to
 
 for (bool enabled = qtCoreIo().isDebugEnabled(); Q_UNLIKELY(enabled); enabled 
 = false)
  QMessageLogger(__FILE__, __LINE__, Q_FUNC_INFO, 
 qtCoreIo().categoryName()).debug() 
 
Out of curiosity: is there a reason you use 'for' and not an 'if' statement?

 so this should be needed only if your 'expensive' operations aren't behind 
 the  anyway.
 
 Also, what's the overhead of a qCDebug for a disabled category? Qt should
 never emit debug warnings in its default configuration, so we're talking 
 about
 many hits to that.
 
 The overhead for a non-enabled qCDebug is basically a function call + one 
 boolean check (isDebugEnabled() will be inlined).
 
If code size or performance is a problem for certain critical code sections, 
you could also use a full macro, like:
qCDebug(category, a  b  some string);

This construct looks rather strange or even ugly, but has the advantage that it 
can be completely compiled away.

Regards,

Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Cleanup open requests in Gerrit?

[Kurt Pattyn]

Hi,

I noticed that the oldest open item in Gerrit dates back to 7 October 2011. 
There are around 2000 items still open. I suppose a lot of them are not 
relevant anymore.

Wouldn’t it a good idea that the maintainers of the different modules in Qt go 
through them and either discard them or merge them?

Cheers
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Proposal] Replace size related parameters with size_t

[Kurt Pattyn]

QString, QByteArray, QList, aso often use sign integers to store sizes, 
indexing, aso.
This often leads to signed/unsigned mismatches and is not really according 
standard practice.
Also, this restricts the indexes, sizes, aso to 32-bit.
One solution to resolve the signed/unsigned mismatch is to cast the types to 
the appropriate type, but this can be dangerous, and hides the real problem.

A better approach would be to use std::size_t.

My proposal is to replace all int types with size_t where appropriate.

I realise that this has a major impact on compatibility, but it is certainly 
something that should be considered.
A solution to the compatibility problem could be to duplicate the methods and 
mark the old ones as obsolete.

What are your thoughts?

/Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Request] Add Info to QDebug

[Kurt Pattyn]

On 23 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:

 From: Alejandro Exojo s...@badopi.org
 Subject: Re: [Development] [Request] Add Info to QDebug
 Date: 22 Dec 2013 19:01:51 GMT+1
 To: development@qt-project.org
 
 
 El Saturday 21 December 2013, Kurt Pattyn escribió:
 Qt currently supports the following ‘severity’ levels for logging: Debug,
 Warning, Critical, Fatal and System.
 
 I propose to add the following levels: Info and Error, with associated
 methods qInfo() and qError(). Particularly, the Info severity can be
 interesting to have applications output log messages that are not
 warnings, but also not debug messages. Error would fit between Warning and
 Critical.
 
 While not a terrible thing to have, I fail to see what's exactly the use 
 case. 
 I think it would even cause some confusion.
 
 The info level doesn't make much sense for a class that outputs to stderr. 
 If you want to inform the user with text, you probably want the standard 
 output, isn't it?

Debug messages are for debugging purposes. These types of messages can be 
redirected to an attached debugger if wanted.
In a released applications, debug messages are supposed to be suppressed.
However, some applications do want to log informational messages that are not 
warnings.
Currently, there is no way to do this through the QDebug class. 

 
 About error, I don't see when you would use it instead of the other or 
 which 
 advantadge it gives. I see it this way:
 
 - Debug: almost everything goes there. Since it can grow messy quickly, you 
 have the categories to filter things easily. Is disabled by 
 QT_NO_DEBUG_OUTPUT 
 since users might be spared of those messages.
 
 - Warning: is a notice that something went wrong, but it might not affect the 
 application. You can disable it with QT_NO_WARNING_OUTPUT since is not that 
 important.
Warnings are not errors, and do not require immediate action; example: file 
system is 80% full.
They normally indicate that something might go wrong in the future if no action 
is taken.

Errors are conditions in an application that do not need urgent attention, but 
should be resolved as soon as possible.
The application keeps working, possibly with reduced functionality or 
performance.

 - Critical: something serious really happened, so the message can't be 
 disabled. You really want to print something because something critical is 
 happening.
Critical conditions make the application loose essential functionality. The 
application cannot be used anymore for its intended purpose.

 - Fatal: same as above, but the application even aborts afterwards.
Fatal conditions affect not only the application, but also the surrounding 
system. The application and possibly the whole system should be shutdown 
immediately.
A good example is loss of control of an X-ray beam in an X-ray scanner. Even in 
this situation, just kicking out the application is very often not a good 
option. It often should start an emergency procedure.

 
 The Error level would only make sense if for whatever reason you want to 
 follow Unix syslog, but we are not going to get it right at this point IMHO, 
 since syslog has a lot of levels that are just numerical behind the scenes. 
 From syslog(2) manpage:
 
   #define KERN_EMERG0  /* system is unusable   */
   #define KERN_ALERT1  /* action must be taken immediately */
   #define KERN_CRIT 2  /* critical conditions  */
   #define KERN_ERR  3  /* error conditions */
   #define KERN_WARNING  4  /* warning conditions   */
   #define KERN_NOTICE   5  /* normal but significant condition */
   #define KERN_INFO 6  /* informational*/
   #define KERN_DEBUG7  /* debug-level messages */
 
 That would make necessary to create Alert and Emergency too. That's quite 
 overkill IMHO.

The proposal is not to mimic the syslog events, but at least to have a more 
fine-grained control over the log messages.
Most logging systems have the info and error severity levels. Here is a small 
overview together with a potential mapping to qDebug, qInfo, …:

Microsoft (see 
http://msdn.microsoft.com/en-us/library/ff604025(v=office.14).aspx):
---
Information  = qInfo
Warning   = qWarning
Error   = qError
Critical Error= qCritical

No Fatal severity here.

BlackBerry (see 
http://www.qnx.com/developers/docs/qnxcar2/index.jsp?topic=%2Fcom.qnx.doc.neutrino.utilities%2Ftopic%2Fs%2Fslogger2.html):

SLOG2_DEBUG2= qTrace (I know, does not exist)
SLOG2_DEBUG1= qDebug
SLOG2_INFO  = qInfo
SLOG2_NOTICE

Re: [Development] [Request] Add Info to QDebug

[Kurt Pattyn]

On 23 Dec 2013, at 17:38, development-requ...@qt-project.org wrote:

 From: Andreas Aardal Hanssen andr...@hanssen.name
 Subject: Re: [Development] [Request] Add Info to QDebug
 Date: 23 Dec 2013 15:17:06 GMT+1
 To: development@qt-project.org
 
 FTR, I’m completely -1 for touching QDebug and friends, and +1 for adding a 
 proper logging framework. QDebug, qWarning, qCritical and qFatal are for 
 programmers, not administrators who want app log output for system 
 maintenance.
 
I think that QDebug can be a sound foundation for a ‘proper’ logging framework.

 In our app environment, we have (as many else!) added our own LogInfo()  
 “bar”, which formats the log output according to our system-wide standard. 
 That makes the logs parseable to all our internal tools. We also override 
 Qt’s debug handlers to ensure that any use of qDebug, warning, critical or 
 fatal ends up properly formatted. I.e. the the debug handler uses our Log 
 thing.

So, programmers log messages do finally end up in the logs. By using 
qSetMessagePattern it is possible to format the log output as well. By only 
using q(C)Debug(), q(C)Info(), … there is a single API to do logging.
By implementing a proper logging backend, Qt could have plugins to log to 
(r)syslog(-ng), Windows Event Log, slog2, aso, and then there would be an 
almost perfect fit for qDebug(), qInfo(), ...

Kurt

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Request] Add Info to QDebug

[Kurt Pattyn]

On 22 Dec 2013, at 05:51, development-requ...@qt-project.org wrote:

 From: Thiago Macieira thiago.macie...@intel.com
 Subject: Re: [Development] [Request] Add Info to QDebug
 Date: 21 Dec 2013 17:15:20 GMT+1
 To: development@qt-project.org
 
 
 On sábado, 21 de dezembro de 2013 14:23:10, Kurt Pattyn wrote:
 Qt currently supports the following ‘severity’ levels for logging: Debug,
 Warning, Critical, Fatal and System.
 
 I propose to add the following levels: Info and Error, with associated
 methods qInfo() and qError(). Particularly, the Info severity can be
 interesting to have applications output log messages that are not warnings,
 but also not debug messages. Error would fit between Warning and Critical.
 
 See the Gerrit submissions for the logging framework.

Can you be more precise what you mean? I have been looking into Gerrit, but 
have found nothing regarding info and error severities.
The logging framework is making use of the QMessageLogger class. Having an info 
and error severity, would benefit the logging framework as well (and make it 
more syslog-alike).
I’ve already submitted a patch on the dev branch 
(https://codereview.qt-project.org/#change,74338) with the required changes.

I am also wondering what the best way is to make use of ‘facilities’ in the 
logging framework. Some applications need a clear separation between auditing 
logs (read security related events) and normal application events.
 
 -- 
 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] [Request] Add Info to QDebug

[Kurt Pattyn]

Qt currently supports the following ‘severity’ levels for logging: Debug, 
Warning, Critical, Fatal and System.

I propose to add the following levels: Info and Error, with associated methods 
qInfo() and qError().
Particularly, the Info severity can be interesting to have applications output 
log messages that are not warnings, but also not debug messages. Error would 
fit between Warning and Critical.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Feature Request] Add QtWebSockets to Qt

[Kurt Pattyn]

Hi,

I propose to move QtWebSockets from the playground 
(https://qt.gitorious.org/qtplayground/websockets/) to the official Qt 
repository as an add-on.
As there is a need for a websockets implementation in Qt (see 
https://bugreports.qt-project.org/browse/QTBUG-26300 and 
https://bugreports.qt-project.org/browse/QTBUG-26298), QtWebSockets could be a 
welcome addition.

The module only depends on Qt (core and network, and Qml for the Qml component).
It supports the ws and wss schemes, and can be used as a client and server 
component.
The API is modelled after QAbstractSocket and QTcpSocket, and hence should be 
familiar for Qt developers. The Qml module has been reviewed by Alan Alpert, 
and is considered 'QML-worthy'. Currently, the module builds as a Qt add-on, 
and can be used by adding QT += websockets.

QtWebSockets passes the Autobahn Testsuite (see http://autobahn.ws/testsuite/), 
has extensive unit tests, and builds successfully on the Qt CI infrastructure. 
Performance has also been tested with AutoBahn TestSuite, and is up-to-par with 
all current browsers and websocketpp (even slightly faster).

Please cast your votes.

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] #pragma or xxx_s functions

[Kurt Pattyn]

 On 19 Dec 2013, at 02:05, Nicolás Alvarez nicolas.alva...@gmail.com wrote:
 
 2013/12/18 Kurt Pattyn pattyn.k...@gmail.com:
 For a lot of the standard C functions, Microsoft has implemented safe 
 versions.
 Functions like sprintf, scanf, strcpy, aso have safe counterparts with an 
 _s suffix: sprintf_s, scanf_s, aso
 When the non-safe functions are used, the Microsoft compiler generates a 
 warning that these functions should be replaced by their safe counterparts.
 There are 3 ways to get rid of these warnings:
 1. replacing those functions,
 2. using a #pragma
 3. using a compiler flag
 
 What is the recommended way to get rid of these warnings in the Qt sources?
 
 I solved these warnings by replacing the calls with the safe versions, but 
 the patch was rejected because it was recommended to use #pragmas.
 Before proceeding and going through the sources again, I would like to know 
 the recommended practice within Qt.
 
 The so-called safe functions with the _s are Microsoft extensions and
 don't exist in other platforms. Changing to the recommended safe
 functions makes the code only compile and work on Windows.

Yes, I am aware of that. Those functions are put within #ifdef statements.
 
 I don't know how Qt handles this, but in other projects the solution
 I've seen is to just define _CRT_SECURE_NO_WARNINGS globally.
Qt uses qXXX() functions for a lot of those function: qstrcpy, qstrcmp, aso. 
Those functions expand to the safe counterparts when using MSVC. Some 
functions like strerror() cannot be simply replaced by such a wrapper, because 
their signature is too different.
Defining _CRT_SECURE_NO_WARNINGS is an option as far as only the private code 
would be affected, but this cannot be guaranteed. If an unsecure method is 
used in a public file, users of the API don't have the option to detect those 
warnings.

In some regulatory markets, people can be forced to actually do something about 
those warnings, and not just hide them. After all, if Microsoft says it's 
unsafe, then it must be really unsafe, isn't it ;-) In the regulatory case, 
people need to patch Qt by removing all suppressions and fix the warnings (and 
that's a huge undertaking).

That's why I want to know what the 'official' statement is from the Qt 
community regarding this issue. I replaced the unsecure functions with their 
secure counterparts, but that patch was rejected. Now, before going through 
the code again, I want to be sure that I am doing it right this time.
 
 -- 
 Nicolás
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] #pragma or xxx_s functions

[Kurt Pattyn]

For a lot of the standard C functions, Microsoft has implemented safe 
versions.
Functions like sprintf, scanf, strcpy, aso have safe counterparts with an _s 
suffix: sprintf_s, scanf_s, aso
When the non-safe functions are used, the Microsoft compiler generates a 
warning that these functions should be replaced by their safe counterparts.
There are 3 ways to get rid of these warnings: 
1. replacing those functions, 
2. using a #pragma
3. using a compiler flag

What is the recommended way to get rid of these warnings in the Qt sources?

I solved these warnings by replacing the calls with the safe versions, but the 
patch was rejected because it was recommended to use #pragmas.
Before proceeding and going through the sources again, I would like to know the 
recommended practice within Qt.

Cheers,
Kurt


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Development Digest, Vol 27, Issue 28

[Kurt Pattyn]

On 10 Dec 2013, at 03:40, development-requ...@qt-project.org wrote:

 win32-msvc2010_developer-build_qtnamespace_Windows_7
 ===
 jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release
 [.obj\release\qquickdroparea.obj] Error 2 
 
 Error 2 means the command above exited with error 2, please look above”

That is really all that is in the logs. No further clues.
There are only warnings (the same ones as in the build of 
Qt_5_release_integration).

See: 
http://testresults.qt-project.org/ci/WebSockets_master_Integration/build_00053/win32-msvc2010_developer-build_qtnamespace_Windows_7/log.txt.gz
 
 The first error message is the most important. Never the last.
 
 The logfile for the Windows_8 64-bit build is truncated:
 win64-msvc2012_developer-build_qtnamespace_Windows_8
 ===
 moc_qkeysequenceedit.cpp
C:\Program Files (x86)\Microsoft Visual Studio
 11.0\VC\INCLUDE\algorithm(3776) : see reference to function template
 instantiation 'void std::_Median_RanIt,bool(__cdecl *)(const
 TestNamespace::QGraphicsItem *,const TestNamespace::QGraphicsItem
 *)(_RanIt,_RanIt,_RanIt,_Pr)' being compiled
 
 No error here. Please find the first error message, the one that says 
 error, 
 not see reference, warning or info”.
That is the problem. There is no error, but the log file is truncated. What is 
shown here is the last line of the build log.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt5 release integration build

[Kurt Pattyn]

I suppose that the warnings in the list beneath are still unsolved. Is that 
correct?
How critical is it to solve those warnings? If they are critical for the 
release, I want to give a helping hand to remove them (after all there are more 
than 900, the list below is a synopsis).
Cheers,

Kurt

On 10 Dec 2013, at 17:30, Mitch Curtis mitch.cur...@digia.com wrote:

 https://codereview.qt-project.org/#change,65936
 https://codereview.qt-project.org/#change,66052
 https://codereview.qt-project.org/#change,66018
 https://codereview.qt-project.org/#change,66061
 https://codereview.qt-project.org/#change,66041
 
 You can see more by searching through gerrit. E.g.:
 
 https://codereview.qt-project.org/#q,owner:Friedemann.Kleint%2540digia.com+message:warnings,n,z
 
 or Git:
 
 git submodule foreach git log | grep warning ||:
 
 Patches are welcome. :)
 
 On 12/10/2013 11:40 AM, Kurt Pattyn wrote:
 Hi,
 
 is anybody aware of the many warnings of Qt5 release build for Windows?
 For instance the build
 win32-msvc2010_developer-build_qtnamespace_Windows_7 (build log:
 http://testresults.qt-project.org/ci/Qt5_release_Integration/build_00286/win32-msvc2010_developer-build_qtnamespace_Windows_7/log.txt.gz),
 contains the following warnings:
 
 warning C4996: 'fopen': This function or variable may be unsafe. Consider 
 using fopen_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. 
 See online help for details.
 
 warning C4996: 'strncpy': This function or variable may be unsafe. Consider 
 using strncpy_s instead. To disable deprecation, use 
 _CRT_SECURE_NO_WARNINGS. See online help for details.
 
 warning C4996: 'strerror': This function or variable may be unsafe. Consider 
 using strerror_s instead. To disable deprecation, use 
 _CRT_SECURE_NO_WARNINGS. See online help for details.
 
 And a lot more of these ‘unsafe’ warnings, probably harmless.
 I think the following ones needs more attention:
 
 warning C4018: '' : signed/unsigned mismatch
 
 warning C4146: unary minus operator applied to unsigned type, result still 
 unsigned
 
 warning C4305: 'argument' : truncation from 'double' to 'float'
 
 warning C4138: '*/' found outside of comment
 
 Command line warning D9025 : overriding '/Zm200' with '/Zm500'
 
 warning C4996: 'putenv': The POSIX name for this item is deprecated. 
 Instead, use the ISO C++ conformant name: _putenv. See online help for 
 details.
 
 warning C4189: 'eventDispatcher' : local variable is initialized but not 
 referenced
 
 testqrc\test.qrc: Warning: potential duplicate alias detected: 'aliasdir.txt'
 
 warning C4341: 'EnumTest_Enum1_bigValue' : signed value is out of range for 
 enum constant
 
 warning C4309: 'initializing' : truncation of constant value
 
 warning C4290: C++ exception specification ignored except to indicate a 
 function is not __declspec(nothrow)
 
 warning C4996: 'FunctionWithAttributes::test2': was declared deprecated
 
 warning C4723: potential divide by 0
 
 warning C4005: 'M_E' : macro redefinition
 
 warning C4530: C++ exception handler used, but unwind semantics are not 
 enabled. Specify /EHsc
 
 warning C4307: '*' : integral constant overflow
 
 warning D9002 : ignoring unknown option '-g'
 
 warning C4995: 'UnknownBaud': name was marked as #pragma deprecated
 
 warning C4244: 'function' : conversion from 'uint64' to 'size_t', possible 
 loss of data
 
 warning C4345: behavior change: an object of POD type constructed with an 
 initializer of the form () will be default-initialized
 
 Cheers,
 
 Kurt
 
 
 
 ___
 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] Qt5 release integration build

[Kurt Pattyn]

Thanks for the info. Is there a target date for 5.2.1?

I want to give a helping hand, but how can this be coordinated so that no two 
people are fixing the same warnings?

Regards,
Kurt

On 10 Dec 2013, at 20:13, Liang Qi cavendish...@gmail.com wrote:

 Those changes happened in stable branch, it means they will be part of 5.2.1, 
 then doesn't block 5.2.0 final release.
 
 Anyway, patches are welcome!
 
 Regards,
 Liang
 
 
 On 10 December 2013 20:06, Kurt Pattyn pattyn.k...@gmail.com wrote:
 I suppose that the warnings in the list beneath are still unsolved. Is that 
 correct?
 How critical is it to solve those warnings? If they are critical for the 
 release, I want to give a helping hand to remove them (after all there are 
 more than 900, the list below is a synopsis).
 Cheers,
 
 Kurt
 
 On 10 Dec 2013, at 17:30, Mitch Curtis mitch.cur...@digia.com wrote:
 
  https://codereview.qt-project.org/#change,65936
  https://codereview.qt-project.org/#change,66052
  https://codereview.qt-project.org/#change,66018
  https://codereview.qt-project.org/#change,66061
  https://codereview.qt-project.org/#change,66041
 
  You can see more by searching through gerrit. E.g.:
 
  https://codereview.qt-project.org/#q,owner:Friedemann.Kleint%2540digia.com+message:warnings,n,z
 
  or Git:
 
  git submodule foreach git log | grep warning ||:
 
  Patches are welcome. :)
 
  On 12/10/2013 11:40 AM, Kurt Pattyn wrote:
  Hi,
 
  is anybody aware of the many warnings of Qt5 release build for Windows?
  For instance the build
  win32-msvc2010_developer-build_qtnamespace_Windows_7 (build log:
  http://testresults.qt-project.org/ci/Qt5_release_Integration/build_00286/win32-msvc2010_developer-build_qtnamespace_Windows_7/log.txt.gz),
  contains the following warnings: ...
 
  Cheers,
 
  Kurt
 
 
 
 
 
 -- 
 http://www.qiliang.net

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Stable vs dev branch

[Kurt Pattyn]

Can someone explain what should go into the stable branch and what into the dev 
branch?
What about fixed bugs?

Cheers,

Kurt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Stable vs dev branch

[Kurt Pattyn]

On 09 Dec 2013, at 19:10, Giuseppe D'Angelo dange...@gmail.com wrote:

 On Mon, Dec 9, 2013 at 7:02 PM, Kurt Pattyn pattyn.k...@gmail.com wrote:
 Can someone explain what should go into the stable branch and what into the 
 dev branch?
 What about fixed bugs?
 
 Hi,
 see http://qt-project.org/wiki/Branch-Guidelines .
 
 For bug fixes depends on both the nature of the bug and the kind of
 fix you have:
 - ordinary fixes should go do stable
 - fixes that require major reworkings etc. to dev
 - fixes that are release critical (either for a pending release or
 should trigger an immediate new release) should go to release after
 coordinating with the releasing/security/etc. teams.
 
 Hope this helps,

Sure it does. Thanks.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [CI] build failures

[Kurt Pattyn]

The following builds

win32-msvc2010_developer-build_qtnamespace_Windows_7
win32-msvc2010_developer-build_angle_Windows_7
macx-ios-clang_OSX_10.8

fail with the following errors:

win32-msvc2010_developer-build_qtnamespace_Windows_7
===
jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release 
[.obj\release\qquickdroparea.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release 
[.obj\release\qquickshadereffect.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release 
[.obj\release\qquickcanvasitem.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release 
[.obj\release\qquickcontext2d.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\quick\Makefile.Release 
[.obj\release\qquickcontext2dtile.obj] Error 2

win32-msvc2010_developer-build_angle_Windows_7

jom: C:\work\build\qt\qtdeclarative\src\qml\Makefile.Release 
[.obj\release\qqmlinstruction.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\qml\Makefile.Release 
[.obj\release\qqmlcompileddata.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\qml\Makefile.Release 
[.obj\release\qqmltypenamecache.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\qml\Makefile.Release 
[.obj\release\qqmllocale.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\qml\Makefile.Release 
[.obj\release\qqmlmemoryprofiler.obj] Error 2
jom: C:\work\build\qt\qtdeclarative\src\Makefile [sub-qml-make_first-ordered] 
Error 2

macx-ios-clang_OSX_10.8
=
Code Sign error: The identity 'iPhone Developer' doesn't match any valid, 
non-expired certificate/private key pair in your keychains


The logfile for the Windows_8 64-bit build is truncated:
win64-msvc2012_developer-build_qtnamespace_Windows_8
===
moc_qkeysequenceedit.cpp
C:\Program Files (x86)\Microsoft Visual Studio 
11.0\VC\INCLUDE\algorithm(3776) : see reference to function template 
instantiation 'void std::_Median_RanIt,bool(__cdecl *)(const 
TestNamespace::QGraphicsItem *,const TestNamespace::QGraphicsItem 
*)(_RanIt,_RanIt,_RanIt,_Pr)' being compiled

I see that the qt5 stable builds pass. The QtWebSockets playground project 
fails with the above errors.
Is this a known issue?


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Order of macro expansion in compiler error messages

[Kurt Pattyn]

On 08 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:

 Just a quick poll: which order do you think is more intuitive?
 
 Option A:
 qobjectdefs.h:69:20: error: expected unqualified-id before ‘protected’
 #   define signals protected
^
 stdin:1:6: note: in expansion of macro ‘signals’
 
 Option B:
 stdin:1:6: error: expected unqualified-id
 bool signals;
 ^
 qobjectdefs.h:69:20: note: expanded from macro 'signals'
 #   define signals protected
   ^
To me option B is more comprehensive to me.

In the other example:

 Option A:
 qmetatype.h:1785:43: error: conversion to ‘int’ from ‘uint {aka unsigned 
 int}’ 
 may change the sign of the result
 const int tNameLen = qstrlen(tName); \
   ^
 qmetatype.h:1913:1: note: in expansion of macro 
 ‘Q_DECLARE_METATYPE_TEMPLATE_2ARG’
 Q_DECLARE_METATYPE_TEMPLATE_2ARG(QPair)
 ^
 
 Option B:
 qmetatype.h:1913:1: error: implicit conversion changes signedness: 'uint' 
 (aka 
 'unsigned int') to 'const int'
 Q_DECLARE_METATYPE_TEMPLATE_2ARG(QPair)
 ^
 qmetatype.h:1785:30: note: expanded from macro 
 'Q_DECLARE_METATYPE_TEMPLATE_2ARG'
const int tNameLen = qstrlen(tName); \
     ^~


I prefer option A.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Request] Compiler warnings in Qt

[Kurt Pattyn]

On 07 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:

 From: Thiago Macieira thiago.macie...@intel.com
 Subject: Re: [Development] [Request] Compiler warnings in Qt
 Date: 6 Dec 2013 18:16:20 GMT+1
 To: development@qt-project.org
 
 
 On sexta-feira, 6 de dezembro de 2013 11:16:20, Kurt Pattyn wrote:
 When compiling applications with compiler flags on, a lot of warnings are
 generated for the Qt header files. I
 
 Which compiler? Which warnings?

Both with Clang on OSX and GCC on Linux and Windows (MinGW).
These are the flags that are used:
-std=c++11
-Wall
-Wpedantic
-Wextra
-Weffc++  #turn on warnings from 
Effective C++ handbook
-fno-rtti#disable runtime 
type information
-ffor-scope
-fuse-cxa-atexit
-fno-default-inline
-fvisibility=hidden   #do not export symbols by 
default
-fvisibility-inlines-hidden
-pedantic-errors
-Wsign-conversion
-Wsign-promo
-Wsign-compare
-Wnon-virtual-dtor
-Wold-style-cast
-Woverloaded-virtual
-Wzero-as-null-pointer-constant
-Wswitch
-Wswitch-default
-Wswitch-enum
-Wcast-qual
-Wcast-align
-Wuninitialized
-Wfloat-equal
#-Wshadow #disable warning as too 
many false negatives are created
-Wuseless-cast
-Wlogical-op
-Wpacked
-Wredundant-decls
-Winline
-Wdisabled-optimization
-Wdeprecated
-Wempty-body
-Wreturn-type
-Wunused-variable
-Wformat
-Wformat-nonliteral
-Wunreachable-code

For Clang these are comparable.

The kind of warnings are mostly signed/unsigned conversions (mainly caused by 
QFlags). There is a non-virtual destructor warning on QSharedData (-Weffc++).
The moc generated files, generate errors like missing default clause in switch 
statement.
Do you want a complete list?

 
 We're not supposed to have any warnings with GCC or Clang.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Request] Compiler warnings in Qt

[Kurt Pattyn]

On 07 Dec 2013, at 12:00, development-requ...@qt-project.org wrote:

 From: Thiago Macieira thiago.macie...@intel.com
 Subject: Re: [Development] [Request] Compiler warnings in Qt
 Date: 6 Dec 2013 18:15:47 GMT+1
 To: development@qt-project.org
 
 
 On sexta-feira, 6 de dezembro de 2013 13:41:34, Olivier Goffart wrote:
 There used to be a 'compilerwarnings' autotest that made sure there was no 
 warning in the headers (in a more strict ways that the warnings we check
 while  compiling Qt itself).  But i think it's gone.
 
 I still have a pending change that compiles each and every public header 
 independently -Werror and defining the keywords.
 
 None of my builds with Clang or GCC have any warnings. There are a few with 
 ICC because it's too eager on warning 177 (unused function). 

This is great news! Are these changes committed to Gerrit?

 
 I have warnings in MSVC's own headers after we started using algorithms 
 more, so I don't bother with MSVC warnings anymore.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Build failure on stable branch

[Kurt Pattyn]

The latest stable branch (dbac1e77f79ff99945cea41522f535132cacc692), fails to 
build.
qtdeclarative/src/quick/items/qquicktextnode.cpp: smoothScalable is not defined 
on font engine

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] [Request] Compiler warnings in Qt

[Kurt Pattyn]

When compiling applications with compiler flags on, a lot of warnings are 
generated for the Qt header files.
It needs a lot of work to exclude them in our builds, and some of them can just 
not be excluded because they are located in macros or inline methods.
The same holds for the moc generated code.

I propose to change the build system of Qt to enable as much compiler flags as 
possible and fail the build when there are any warnings.
Although most of them are more or less harmless, some could be potential errors 
(e.g. compiling with -Weffc++, generates a warning that the destructor of 
QSharedData is not virtual).

The public API could be a good starting point.

What do you think?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development