Re: [Development] Help needed to test Ministro 10.3, needed for Qt 5.4!

[Thomas Senyk]

That's a real shame!

Just to clarify / for the record, is the following a result of 
MODE_WORLD_READABLE not working any more:

D/AndroidRuntime( 9159): Shutting down VM
E/AndroidRuntime( 9159): FATAL EXCEPTION: main
E/AndroidRuntime( 9159): Process: org.qtproject.example.foo, PID: 9159
E/AndroidRuntime( 9159): java.lang.UnsatisfiedLinkError: JNI_ERR 
returned from JNI_OnLoad in 
"/data/app/org.qtproject.example.foo-1/lib/arm/foo.so"
E/AndroidRuntime( 9159):at 
java.lang.Runtime.loadLibrary(Runtime.java:371)
E/AndroidRuntime( 9159):at java.lang.System.loadLibrary(System.java:989)
E/AndroidRuntime( 9159):at 
org.qtproject.qt5.android.bindings.QtActivity.loadApplication(QtActivity.java:252)
E/AndroidRuntime( 9159):at 
org.qtproject.qt5.android.bindings.QtActivity.access$400(QtActivity.java:94)

... or is it (as I first though) about a the deployment folder mismatch?
(within the apk it's lib/armeabi-v7a, but the device looks for it in 
lib/arm/)


Greets
Thomas


On 11/26/2014 07:08 PM, Harri Pasanen wrote:
> Hmm... looking at the issue it seems to me that it is not going to be
> fixed, it is an intentional change.   They are tightening the platform
> from security point of view, and this change is similar to change that
> made removable SD cards much less useful in KitKat:
> https://plus.google.com/+TodLiebeck/posts/gjnmuaDM8sn
>
> http://developer.android.com/reference/android/content/Context.html#MODE_WORLD_READABLE
> says it has been deprecated since API level 17, so I doubt they'll bring
> it back.
>
> Ministro has had a good run, but unless I'm mistaken this basically
> kills it?
>
> Harri
>
>
> On 26/11/2014 13:28, Cristian Adam wrote:
>>
>> Please "star" the android issue so that Google developers understand
>> the severity of the problem.
>>
>> It's not like only six people are affected by this.
>>
>> Cheers,
>> Cristian.
>>
>> On 26 Nov 2014 12:45, "BogDan" > > wrote:
>>
>> Hello folks,
>>
>> I have some bad news about Ministro on Android 5.0. Due to a bug
>> https://code.google.com/p/android/issues/detail?id=79478 introduced by
>> Google in Android 5.0 final release apps that are using Ministro
>> are not working anymore, on Android L preview it worked just fine.
>> I hope in the next Android version Google will fix this problem.
>>
>> New stuff added to Ministro 10.
>> - application startup up speed improvement, I've cuted +150ms from the
>> time that your application needs to wait for Ministro's response, now
>> your application waits 2-4ms (of course if Ministro doesn't need to
>> download/extract anything).
>> - extract Qt 5.4 QuickControls style info
>> - speed up the theme extraction (now it needs 2/3 of the previous
>> time).
>> - extract InsetDrawable. On Android 4.4.4 it seems this Drawable is
>> used and will crash QWidget based apps if is not extracted.
>>
>> New stuff added to 10.1
>>  - bumped MINISTRO_MAX_API_LEVEL
>>
>> New stuff added to 10.3
>>  - for more exceptions on Android 5.0
>>  - extract default palette & fonts, needed by Qt 5.4
>>  - extract some Android 5.0 specific look and style info.
>>
>> What happen with 10.2?
>>  - I bumped the version to 10.3 by mistake and I pushed it, so
>> there was no 10.2 :).
>>
>> How to test it:
>> - make sure the previous version is installed and your apps are
>> using it.
>> - install over the previous version ($ adb install -r Ministro\
>> II\ v10.3.apk).
>>   * Ministro will extract again *ONCE* the style.
>>   * Trying your existing apps should *NOT* trigger any new downloads.
>> - after you test your applications with Ministro installed on top of
>> previous Ministro version, please test in on a clean installation. So,
>> go to settings -> apps and remove Ministro, then install it again ($
>> adb install Ministro\ II\ v10.3.apk).
>>   * Ministro should extract style info and certificates and it should
>> download again all needed libs.
>>   * Your application should work without any recompilation.
>>
>>
>> Please download and test Ministro from here:
>> https://files.kde.org/necessitas/installer/test/Ministro%20II%20v10.3.apk
>>
>> Thank you!
>>
>> Cheers,
>> BogDan.
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org 
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>>
>>
>> ___
>> Necessitas-devel mailing list
>> necessitas-de...@kde.org
>> https://mail.kde.org/mailman/listinfo/necessitas-devel
>
>
>
> ___
> Necessitas-devel mailing list
> necessitas-de...@kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>

___
Development mailin

Re: [Development] P0 - DNS test zones gone - CI blocked

[Thiago Macieira]

On Wednesday 18 February 2015 21:29:38 Thiago Macieira wrote:
> https://bugreports.qt.io/browse/QTWEBSITE-625
[snip]

Note that we will require source code changes due to the way NS records 
operate. 

I've uploaded https://codereview.qt-project.org/106693 for Qt 5.4 and this 
change will have to make its way to 5.5 and dev before those other branches 
get unblocked too. If we do that by normal, merge means, we can expect at 
minimum 4 days until all branches get unblocked, due to problems in merging.

Therefore, as soon as it integrates in 5.4 showing that it works, I propose we 
cherry-pick -x it to 5.5 and dev so we get unblocked faster. 

I'm assuming we won't need more 5.4.1 integrations -- if we do, then this 
change needs to go into that branch too.

For good measure, we should consider cherry-picking to 5.3 too but bypass the 
CI.

We should also consider postponing the end of the 5.5-dev soft-merge period 
and the release of the alpha.
-- 
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] New Qt 5.4.1 snapshot available

[Heikkinen Jani]

Hi!

Unfortunately this issue isn’t regression from 5.4.0 and so on it isn’t a 
blocker for Qt5.4.1 release, sorry. If we need to rebuild binaries once again 
because of some reason we could take this in as well, otherwise this change 
won’t be in Qt5.4.1 release

Br,
Jani

From: Liang Jian [mailto:jianlian...@gmail.com]
Sent: 18. helmikuuta 2015 16:37
To: Heikkinen Jani
Cc: development@qt-project.org
Subject: Re: [Development] New Qt 5.4.1 snapshot available

Can you merge https://codereview.qt-project.org/#/c/105855/ into 5.4.1 
before 5.4.1 releaded. It fix a showstopper issue to run apps in Android 5.0+

On Wed, Feb 18, 2015 at 1:52 PM, Heikkinen Jani 
mailto:jani.heikki...@theqtcompany.com>> wrote:

Hi all,



We have new Qt 5.4.1 snapshot available:



Windows: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_112/

Linux: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_116/

Mac: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_102/



Please sanitycheck these packages & inform me immediately if there is something 
broken which prevents us releasing these packages as Qt 5.4.1 release later 
this week



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] 5.5.0 snapshot please ?

[Massimo Callegari]

Hello Jani, hello all,as Qt 5.5.0 alpha is nearing, would you mind to produce a 
new snapshot ?I happily noticed there are a few for linux 64bit. Thanks !
Apparently I found a showstopper on Qt3D, but I want to make sure it doesn't 
depend on how I build Qt5 from GIT (linux 64bit as well).
Thanks in advance and regards,Massimo___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.5.0 snapshot please ?

[Sean Harmer]

On Thursday 19 Feb 2015 10:10:12 Massimo Callegari wrote:
> Hello Jani, hello all,as Qt 5.5.0 alpha is nearing, would you mind to
> produce a new snapshot ?I happily noticed there are a few for linux 64bit.
> Thanks ! Apparently I found a showstopper on Qt3D, but I want to make sure
> it doesn't depend on how I build Qt5 from GIT (linux 64bit as well). Thanks
> in advance and regards,Massimo

What's the showstopper?

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

Re: [Development] 5.5.0 snapshot please ?

[Massimo Callegari]

Hi Sean, this one:
https://bugreports.qt.io/browse/QTBUG-44497  
  Da: Sean Harmer 
 A: development@qt-project.org; Massimo Callegari  
 Inviato: Giovedì 19 Febbraio 2015 12:47
 Oggetto: Re: [Development] 5.5.0 snapshot please ?
   
On Thursday 19 Feb 2015 10:10:12 Massimo Callegari wrote:


> Hello Jani, hello all,as Qt 5.5.0 alpha is nearing, would you mind to
> produce a new snapshot ?I happily noticed there are a few for linux 64bit.
> Thanks ! Apparently I found a showstopper on Qt3D, but I want to make sure
> it doesn't depend on how I build Qt5 from GIT (linux 64bit as well). Thanks
> in advance and regards,Massimo

What's the showstopper?

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

Re: [Development] 5.5.0 snapshot please ?

[Sean Harmer]

On Thursday 19 Feb 2015 11:56:18 Massimo Callegari wrote:
> Hi Sean, this one:
> https://bugreports.qt.io/browse/QTBUG-44497  

Hmm I'm still unable to reproduce that. Given the configuration space, it's 
certainly possible there's still a bug there and that you've done nothing 
wrong.

The trace file on that patch is not loading properly for me. I'll try updating 
my apitrace to the latest and try again.

Cheers,

Sean

>   Da: Sean Harmer 
>  A: development@qt-project.org; Massimo Callegari
>  Inviato: Giovedì 19 Febbraio 2015 12:47
>  Oggetto: Re: [Development] 5.5.0 snapshot please ?
> 
> On Thursday 19 Feb 2015 10:10:12 Massimo Callegari wrote:
> > Hello Jani, hello all,as Qt 5.5.0 alpha is nearing, would you mind to
> > produce a new snapshot ?I happily noticed there are a few for linux 64bit.
> > Thanks ! Apparently I found a showstopper on Qt3D, but I want to make sure
> > it doesn't depend on how I build Qt5 from GIT (linux 64bit as well).
> > Thanks
> > in advance and regards,Massimo
> 
> What's the showstopper?
> 
> 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

Hi,

Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and 
C++14 added a lot of new good features. C++17 is planned to be a big step 
again. 

Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in 
a C++98 world.

As an example, Qt's container classes and C++11 range based for loop do not 
mix very well.[1] And for the same reason, the upcoming Ranges TS will not be 
too useful for Qt's container. 

We have started using some parts of C++11 in Creator a year ago and our 
experience is that lambdas (and std::function) are useful everywhere. Today we 
have more than 400 lambdas in Creator's source and have several interfaces 
that take a std::function. 

I would expect that allowing C++11 in Qt would similarly lead to a wider 
understanding on how to leverage the new features for better code and better 
APIs.

We need to start now and deprecate old compilers that do not support any C++11 
features at all. I I suggest requiring support for lambda as 
supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all 
platforms that do not in Qt 5.6.

daniel

[1] ranged based for uses std::begin(container), which if not overloaded calls 
container.begin(), which detaches. 

So using range-based can be used:
- If the container is const or
- If the container is unshared or
- To actually change the container's contents
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt for iOS: Management Retina vs Non-Retina Images

[Sorvig Morten]

> On 18 Feb 2015, at 10:59, Robert Iakobashvili  wrote:
> 
> What about support for @3x?
> Is it inside or is it planned?

I’ve started implementing @3x support here:

https://codereview.qt-project.org/106717
https://codereview.qt-project.org/106705

There’s some refactoring work to be done as well to reduce the logic 
duplication.

Morten


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

Re: [Development] [Releasing] Qt 5.5 new features

[Turunen Tuukka]

Hi,

One thing to note is that the current wiki is not that good in concurrent 
editing, so it is more than likely that some edits will collide.

When making changes to the new feature list (like any other wiki articles that 
many are editing), please try to be quick. After you have made the change, 
please follow that your change does not get lost soon after.

Yours,

Tuukka Turunen
Director, R&D

The Qt Company
Piippukatu 11, 40100 Jyväskylä, Finland
Email: tuukka.turu...@theqtcompany.com | Mobile: + 358 40 7655 800
www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject 
| Facebook: www.facebook.com/qt

From: Heikkinen Jani 
mailto:jani.heikki...@theqtcompany.com>>
Date: Thursday 19 February 2015 09:55
To: "development@qt-project.org" 
mailto:development@qt-project.org>>
Cc: "releas...@qt-project.org" 
mailto:releas...@qt-project.org>>
Subject: [Releasing] Qt 5.5 new features


Hi,


As you should know branching Qt5.5 from 'dev' is ongoing & Alpha release 
nearing. So on we should know what new features will be in Qt5.5 and what will 
be dropped etc. Please fill that information as soon as possible to the 5.5 new 
features wiki:  http://qt-project.org/wiki/New-Features-in-Qt-5.5


It would be really great to get this list updated already during this week. 
Alpha is planned to happen during next week and we should have good 
understanding what is in and what not


br,

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

Re: [Development] 5.5.0 snapshot please ?

[Svenn-Arne Dragly]

On 19. feb. 2015 13:04, Sean Harmer wrote:
> On Thursday 19 Feb 2015 11:56:18 Massimo Callegari wrote:
>> Hi Sean, this one:
>> https://bugreports.qt.io/browse/QTBUG-44497
> Hmm I'm still unable to reproduce that. Given the configuration space, it's
> certainly possible there's still a bug there and that you've done nothing
> wrong.
>
> The trace file on that patch is not loading properly for me. I'll try updating
> my apitrace to the latest and try again.

The same type of crash happens on my system too (Ubuntu 14.04 64 bit 
with Nvidia drivers). It is a bit random, but I've been completely 
unable to run some examples because of this bug. I just thought there 
was something wrong with my system or the specific examples.

Is there anything I can do (collect a trace, for instance) that would 
help you debug this?


Best regards,
Svenn-Arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Rafael Roquetto]

Hi Daniel,

On Thu, Feb 19, 2015 at 01:29:48PM +0100, Daniel Teske wrote:
> Hi,
> 
> Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 
> and 
> C++14 added a lot of new good features. C++17 is planned to be a big step 
> again. 
> 
> Qt needs to evolve together with C++ or it will be a outdated toolkit stuck 
> in 
> a C++98 world.

Agreed, but there is no free lunch. See below.

> 
> As an example, Qt's container classes and C++11 range based for loop do not 
> mix very well.[1] And for the same reason, the upcoming Ranges TS will not be 
> too useful for Qt's container. 
> 
> We have started using some parts of C++11 in Creator a year ago and our 
> experience is that lambdas (and std::function) are useful everywhere. Today 
> we 
> have more than 400 lambdas in Creator's source and have several interfaces 
> that take a std::function. 
> 
> I would expect that allowing C++11 in Qt would similarly lead to a wider 
> understanding on how to leverage the new features for better code and better 
> APIs.
> 
> We need to start now and deprecate old compilers that do not support any 
> C++11 
> features at all. I I suggest requiring support for lambda as 
> supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all 
> platforms that do not in Qt 5.6.

That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
relatively new release), and BlackBerries. I personally would have loved to
remove support for 6.5.0, since it is based on an old gcc version that can
barely keep up with latest C++ developments (and keep giving me maintenance
headaches from time to time). But strategically (read, comercially) speaking,
this is still not possible - QNX 6.5.0 is still widely deployed.
The move to 6.6.0 is happening at a slow pace - probably much slower
than the time it will take us to reach Qt 5.7. One of the many reasons for
that is that many of those systems running QNX are homologated and
changing/upgrading involves lots of different process apart from the technical
stuff.

While I am not for keeping Qt stuck in the last century, I think a
more sensible move would be to actually analyze how far we can push it given
the current major platforms Qt is being used on, in other words, follow the
market, and also take into account the trade-off of dropping platforms that
generate revenue in the form of trainings, services, commercial licensing and
last but not least, code contributions. I am taking QNX as an example because
this is the platform I am familiar with, but I guess this could also affect
other platforms such as Windows CE.

Just my opinion.

Thanks,
Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] 5.5.0 snapshot please ?

[Sean Harmer]

On Thursday 19 Feb 2015 14:12:48 Svenn-Arne Dragly wrote:
> On 19. feb. 2015 13:04, Sean Harmer wrote:
> > On Thursday 19 Feb 2015 11:56:18 Massimo Callegari wrote:
> >> Hi Sean, this one:
> >> https://bugreports.qt.io/browse/QTBUG-44497
> > 
> > Hmm I'm still unable to reproduce that. Given the configuration space,
> > it's
> > certainly possible there's still a bug there and that you've done nothing
> > wrong.
> > 
> > The trace file on that patch is not loading properly for me. I'll try
> > updating my apitrace to the latest and try again.
> 
> The same type of crash happens on my system too (Ubuntu 14.04 64 bit
> with Nvidia drivers). It is a bit random, but I've been completely
> unable to run some examples because of this bug. I just thought there
> was something wrong with my system or the specific examples.
> 
> Is there anything I can do (collect a trace, for instance) that would
> help you debug this?

Backtraces, apitrace logs comparing good vs bad runs would help. The fact it's 
sporadic makes me think it's a race condition.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[André Somers]

Daniel Teske schreef op 19-2-2015 om 13:29:
> Hi,
>
> Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and
> C++14 added a lot of new good features. C++17 is planned to be a big step
> again.
>
> Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in
> a C++98 world.
>
> As an example, Qt's container classes and C++11 range based for loop do not
> mix very well.[1] And for the same reason, the upcoming Ranges TS will not be
> too useful for Qt's container.
>
> We have started using some parts of C++11 in Creator a year ago and our
> experience is that lambdas (and std::function) are useful everywhere. Today we
> have more than 400 lambdas in Creator's source and have several interfaces
> that take a std::function.
>
> I would expect that allowing C++11 in Qt would similarly lead to a wider
> understanding on how to leverage the new features for better code and better
> APIs.
>
> We need to start now and deprecate old compilers that do not support any C++11
> features at all. I I suggest requiring support for lambda as
> supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all
> platforms that do not in Qt 5.6.
>
> daniel
>
> [1] ranged based for uses std::begin(container), which if not overloaded calls
> container.begin(), which detaches.
>
> So using range-based can be used:
> - If the container is const or
> - If the container is unshared or
> - To actually change the container's contents
I do get what you mean, and I think they are all valid concerns. But I 
am wondering if the move to support/base Qt API more on top of modern 
C++ developments is not something that belongs in a major release 
instead of a minor one. I think there are quite a few APIs in Qt that 
may need reconsidering in this light. Would it not make more sense to 
introduce a break like that in a major release instead?

Perhaps Qt 6 should not be in the too far future, and might be focused 
on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might 
be kept alive next to that for a while yet. Not just with bugfixes, but 
with whatever features are still feasible to backport to it.

Question would be: if C++11 support could be dropped, what APIs would 
benefit from being re-designed?

André

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto 
wrote:

> > We need to start now and deprecate old compilers that do not support any
> C++11
> > features at all. I I suggest requiring support for lambda as
> > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating
> all
> > platforms that do not in Qt 5.6.
>
> That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
> relatively new release), and BlackBerries. I personally would have loved to
> remove support for 6.5.0, since it is based on an old gcc version that can
> barely keep up with latest C++ developments (and keep giving me maintenance
> headaches from time to time). But strategically (read, comercially)
> speaking,
> this is still not possible - QNX 6.5.0 is still widely deployed.
> The move to 6.6.0 is happening at a slow pace - probably much slower
> than the time it will take us to reach Qt 5.7. One of the many reasons for
> that is that many of those systems running QNX are homologated and
> changing/upgrading involves lots of different process apart from the
> technical
> stuff.
>

QNX 6.6 comes with GCC 4.7.3, which has lambda support:
https://gcc.gnu.org/gcc-4.7/cxx0x_status.html

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Tomasz Siekierda]

On 19 February 2015 at 14:17, Rafael Roquetto  wrote:
> One of the many reasons for that is that many of those systems running QNX 
> are homologated and
> changing/upgrading involves lots of different process apart from the technical
> stuff.

So those companies/ users of QNX are not willing to upgrade their OS,
compiler, but they are willing to upgrade Qt?

In my experience, people who stick to old versions of operating
systems are also not very keen on upgrading other software as well...
so for them, it should not matter, whether the newest Qt version will
drop old compiler support or not.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Rafael Roquetto]

On Thu, Feb 19, 2015 at 02:25:27PM +0100, Cristian Adam wrote:
> On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto 
> wrote:
> 
> > > We need to start now and deprecate old compilers that do not support any
> > C++11
> > > features at all. I I suggest requiring support for lambda as
> > > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating
> > all
> > > platforms that do not in Qt 5.6.
> >
> > That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a
> > relatively new release), and BlackBerries. I personally would have loved to
> > remove support for 6.5.0, since it is based on an old gcc version that can
> > barely keep up with latest C++ developments (and keep giving me maintenance
> > headaches from time to time). But strategically (read, comercially)
> > speaking,
> > this is still not possible - QNX 6.5.0 is still widely deployed.
> > The move to 6.6.0 is happening at a slow pace - probably much slower
> > than the time it will take us to reach Qt 5.7. One of the many reasons for
> > that is that many of those systems running QNX are homologated and
> > changing/upgrading involves lots of different process apart from the
> > technical
> > stuff.
> >
> 
> QNX 6.6 comes with GCC 4.7.3, which has lambda support:
> https://gcc.gnu.org/gcc-4.7/cxx0x_status.html

Indeed, but it builds against Dinkumware's libcpp, which has half-baked C++11
support (see https://codereview.qt-project.org/#/c/106599/ for one example).

Cheers,
Rafael

> 
> Cheers,
> Cristian.

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Rafael Roquetto]

On Thu, Feb 19, 2015 at 02:27:32PM +0100, Tomasz Siekierda wrote:
> On 19 February 2015 at 14:17, Rafael Roquetto  
> wrote:
> > One of the many reasons for that is that many of those systems running QNX 
> > are homologated and
> > changing/upgrading involves lots of different process apart from the 
> > technical
> > stuff.
> 
> So those companies/ users of QNX are not willing to upgrade their OS,
> compiler, but they are willing to upgrade Qt?
> 
> In my experience, people who stick to old versions of operating
> systems are also not very keen on upgrading other software as well...
> so for them, it should not matter, whether the newest Qt version will
> drop old compiler support or not.

And in my experience, it is not as simple as you put it...

There are several cases where it does matter:
for example: sometimes a company needs modules
that are not available in previous Qt versions, such as qt3d or
qtremoteobjects.


Cheers,
Rafael

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Cristian Adam]

On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto 
wrote:

> >
> > QNX 6.6 comes with GCC 4.7.3, which has lambda support:
> > https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
>
> Indeed, but it builds against Dinkumware's libcpp, which has half-baked
> C++11
> support (see https://codereview.qt-project.org/#/c/106599/ for one
> example).
>
>
Microsoft also uses Dinkumware's libcpp, but it seems Stephan T. Lavavej
does
a better job integrating it with the Visual C++ compiler.

One can watch QNX's GCC activity here:
http://community.qnx.com/integration/viewvc/viewvc.cgi/tools/?root=core-dev-tools&system=exsy1001

The most uptodate GCC is 4.9, no GCC 5.0 traces.

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

Re: [Development] 5.5.0 snapshot please ?

[Sean Harmer]

Hi,

On Thursday 19 Feb 2015 19:45:39 Alexandr Akulich wrote:
> As bugreport says, it's regression, which happend two weeks ago. Once
> there is example that completely broken because of the issue, it
> should be easy-enough to perform git bisect automatic or manual
> search.

Yes, but as I said, I can't reproduce it, so I can't do the git bisect to find 
the culprit. If someone who is able to reproduce wants to git bisect that 
would indeed help a lot.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Frank Osterfeld]

> On 19 Feb 2015, at 14:27, Tomasz Siekierda  wrote:
> 
> On 19 February 2015 at 14:17, Rafael Roquetto  
> wrote:
>> One of the many reasons for that is that many of those systems running QNX 
>> are homologated and
>> changing/upgrading involves lots of different process apart from the 
>> technical
>> stuff.
> 
> So those companies/ users of QNX are not willing to upgrade their OS,
> compiler, but they are willing to upgrade Qt?
> 
> In my experience, people who stick to old versions of operating
> systems are also not very keen on upgrading other software as well...
> so for them, it should not matter, whether the newest Qt version will
> drop old compiler support or not.

Often those customers aren’t new to QNX, but new to Qt. And often they need the 
latest and greatest Qt for some feature or bugfixes.
Other third-party dependencies they can’t get migrated (or even recompiled) 
often make them stick to old QNX versions. Things tend to be somewhat more 
complicated than one might be used to, in the embedded world.

-- 
Frank Osterfeld | frank.osterf...@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ)  +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions



smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Björn Breitmeyer]

I agree that it would be nice to have this, but we can do quite a bit of 
things with the Qt abstraction of most new features. And for std::function
you can add new interfaces for compilers that do support it without breaking 
old code, its done for move constructors and co already.

Sure it would be nice to have all the nice new and nifty features, but then 
again even msvc 2010 only supports a subset of c++11 and msvc2013 still 
doesn't fully support c++11 or c++98, neither will old gccs. What is allowed 
what not. And then breaking in a minor version is not very customer friendly.

Dropping this would for e.g. drop the support for WinCE. Of course we are also 
porting to WEC2013 and maybe Qt6 only supports WEC2013, whichs compiler 
supports most c++11 and a lot of the windows platform plugin code, but i agree
with Andre that this is something for a major release. Right the support for 
old hardware/software stacks is a big plus for Qt. Thats because customers are
sitting on those platforms and want to go into the future, but they can just 
do that when their old platform goes End of Life. So Qt offers them a way to 
already build the next generation software on their old stack and then switch 
over. This is a big selling point for Qt. Customers in aviation, medical, 
automotive and others have demands to support their products for 10-20 years.
And they also have to certify their stack.

So long point short, i would like to dicuss this for a move to Qt6 because of 
this and the points Andre mentioned already.

-- 
Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Germany: +49-30-521325470, Sweden (HQ): +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions 
Am Donnerstag, 19. Februar 2015, 14:26:34 schrieb André Somers:
> Daniel Teske schreef op 19-2-2015 om 13:29:
> > Hi,
> > 
> > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11
> > and C++14 added a lot of new good features. C++17 is planned to be a big
> > step again.
> > 
> > Qt needs to evolve together with C++ or it will be a outdated toolkit
> > stuck in a C++98 world.
> > 
> > As an example, Qt's container classes and C++11 range based for loop do
> > not
> > mix very well.[1] And for the same reason, the upcoming Ranges TS will not
> > be too useful for Qt's container.
> > 
> > We have started using some parts of C++11 in Creator a year ago and our
> > experience is that lambdas (and std::function) are useful everywhere.
> > Today we have more than 400 lambdas in Creator's source and have several
> > interfaces that take a std::function.
> > 
> > I would expect that allowing C++11 in Qt would similarly lead to a wider
> > understanding on how to leverage the new features for better code and
> > better APIs.
> > 
> > We need to start now and deprecate old compilers that do not support any
> > C++11 features at all. I I suggest requiring support for lambda as
> > supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating
> > all
> > platforms that do not in Qt 5.6.
> > 
> > daniel
> > 
> > [1] ranged based for uses std::begin(container), which if not overloaded
> > calls container.begin(), which detaches.
> > 
> > So using range-based can be used:
> > - If the container is const or
> > - If the container is unshared or
> > - To actually change the container's contents
> 
> I do get what you mean, and I think they are all valid concerns. But I
> am wondering if the move to support/base Qt API more on top of modern
> C++ developments is not something that belongs in a major release
> instead of a minor one. I think there are quite a few APIs in Qt that
> may need reconsidering in this light. Would it not make more sense to
> introduce a break like that in a major release instead?
> 
> Perhaps Qt 6 should not be in the too far future, and might be focused
> on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might
> be kept alive next to that for a while yet. Not just with bugfixes, but
> with whatever features are still feasible to backport to it.
> 
> Question would be: if C++11 support could be dropped, what APIs would
> benefit from being re-designed?
> 
> André
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Rafael Roquetto]

On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:

> So long point short, i would like to dicuss this for a move to Qt6 because of 
> this and the points Andre mentioned already.
+1

-- 
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions


smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QtPlatformSupport is really public in 5.4.0?

[Lisandro Damián Nicanor Pérez Meyer]

I might have even missed it before, but are the following QtPlatformSupport 
headers really public (ie, API/ABI stable)?

/usr/include/qt5/QtPlatformSupport/QtPlatformSupportVersion
/usr/include/qt5/QtPlatformSupport/QtPlatformSupportDepends
/usr/include/qt5/QtPlatformSupport/QtPlatformSupport
/usr/include/qt5/QtPlatformSupport/qtplatformsupportversion.h

Thanks in advance, Lisandro.

-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code Coverage Statistics for QtBase

[Agocs Laszlo]

Hi,

Most of the platformsupport and platform plugin code was there in 5.4 too. 
Perhaps they were filtered out in the previous reports?

Best regards,
Laszlo


From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org 
 on behalf of 
Paeglis Gatis 
Sent: Thursday, February 19, 2015 4:45 PM
To: Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase


Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Sébastien Fricker 
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp   0,5789473684
qsystemsemaphore_systemv.cpp0,78125
qsslellipticcurve_openssl.cpp   1

___
Development mailing list
Development@qt-project.org
ht

Re: [Development] Code Coverage Statistics for QtBase

[Sébastien Fricker]

All files stating with a 'q' are not 3rdparty files.


On 19/02/2015 16:45, Paeglis Gatis wrote:


Many of those files are from 3rdparty code, the ones I recognize are 
from /qtbase/src/3rdparty/xkbcommon, those I think can


be ignored when thinking from code coverage point of view.



*From:* 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on 
behalf of Sébastien Fricker 

*Sent:* Thursday, February 19, 2015 3:51 PM
*To:* development
*Subject:* [Development] Code Coverage Statistics for QtBase
Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ 
there is a big decrease of the code coverage between Qt5/dev and Qt5.4.

The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get 
added into the project and the code coverage of this set is near to 
zero (see the HTML attachment and the table below).
This new uncovered files are responsible of a lost of the code 
coverage of 3% approximately.
Question: are these files not tested through an unit test? If they are 
tested, I need to look why they are not taken in account by the code 
coverage analysis.



The main difference are caused by the code coverage of the unit tests 
itself.
The number of unit tests did not decrease, but the code coverage of 
the tests with the status Unknown decrease from 13% (from 43% to 30%) 
and this explain the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running 
before and after a unit test (setup the GUI, common initializations 
executed before main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in 
the unit tests or in QtBase) which could explain this?


Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)
action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp   0,5789473684
qsystemsemaphore_systemv.cpp0,78125
qsslellipticcurve_openssl.cpp   1




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

Re: [Development] Code Coverage Statistics for QtBase

[Paeglis Gatis]

> Why can they be ignored?

I mean, we use only some of the API from that library, but bundle all of it. If 
it is not fully covered by tests it is not an issue.



From: Hausmann Simon
Sent: Thursday, February 19, 2015 4:51 PM
To: Paeglis Gatis; Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase

Why can they be ignored? When the users run Qt applications that code is 
executed, so coverage is important IMO.

However if the added code is from build tools (Code generators) then maybe it's 
not so critical, as long as the generated code is covered.

That said, the results look incomplete to me. Qxc‎bwindow.cpp surely has 
non-zero coverage when running tests on X11.

Simon

From: Paeglis Gatis
Sent: Thursday, February 19, 2015 23:45
To: Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase



Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Sébastien Fricker 
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cp

Re: [Development] Code Coverage Statistics for QtBase

[Hausmann Simon]

Why can they be ignored? When the users run Qt applications that code is 
executed, so coverage is important IMO.

However if the added code is from build tools (Code generators) then maybe it's 
not so critical, as long as the generated code is covered.

That said, the results look incomplete to me. Qxc‎bwindow.cpp surely has 
non-zero coverage when running tests on X11.

Simon

From: Paeglis Gatis
Sent: Thursday, February 19, 2015 23:45
To: Sébastien Fricker; development
Subject: Re: [Development] Code Coverage Statistics for QtBase



Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Sébastien Fricker 
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp   0,5789473684
qsystemsemaphore_systemv.cpp0,78125
qsslellipticcurve_openssl.cpp 

Re: [Development] Code Coverage Statistics for QtBase

[Paeglis Gatis]

Many of those files are from 3rdparty code, the ones I recognize are from 
/qtbase/src/3rdparty/xkbcommon, those I think can

be ignored when thinking from code coverage point of view.



From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on behalf 
of Sébastien Fricker 
Sent: Thursday, February 19, 2015 3:51 PM
To: development
Subject: [Development] Code Coverage Statistics for QtBase

Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ there is 
a big decrease of the code coverage between Qt5/dev and Qt5.4.
The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get added into 
the project and the code coverage of this set is near to zero (see the HTML 
attachment and the table below).
This new uncovered files are responsible of a lost of the code coverage of 3% 
approximately.
Question: are these files not tested through an unit test? If they are tested, 
I need to look why they are not taken in account by the code coverage analysis.


The main difference are caused by the code coverage of the unit tests itself.
The number of unit tests did not decrease, but the code coverage of the tests 
with the status Unknown decrease from 13% (from 43% to 30%) and this explain 
the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running before 
and after a unit test (setup the GUI, common initializations executed before 
main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in the unit 
tests or in QtBase) which could explain this?

Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)

action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
qxcbwindow.cpp  0
qxcbwmsupport.cpp   0
qxcbxsettings.cpp   0
qxdgnotificationproxy.cpp   0
qxlibeglintegration.cpp 0
rules.c 0
scanner.c   0
state.c 0
symbols.c   0
text.c  0
types.c 0
utf8.c  0
utils.c 0
vmod.c  0
xkb-compat.c0
xkb-keymap.c0
xkbcomp.c   0
forkfd.c0,2841726619
qsharedmemory_systemv.cpp   0,5789473684
qsystemsemaphore_systemv.cpp0,78125
qsslellipticcurve_openssl.cpp   1

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

Re: [Development] Code Coverage Statistics for QtBase

[Sébastien Fricker]

The script and the code behind which produce the coverage analysis is 
the same.

In both cases, a 'make check' is performed and then the data are collected.

Is it possible that the default build parameter get changed between 
Qt5.4 and dev?

For example XCB support get detected automatically and the code get enabled?

On 19/02/2015 16:55, Agocs Laszlo wrote:

Hi,

Most of the platformsupport and platform plugin code was there in 5.4 
too. Perhaps they were filtered out in the previous reports?


Best regards,
Laszlo


*From:* 
development-bounces+laszlo.agocs=theqtcompany@qt-project.org 
 on 
behalf of Paeglis Gatis 

*Sent:* Thursday, February 19, 2015 4:45 PM
*To:* Sébastien Fricker; development
*Subject:* Re: [Development] Code Coverage Statistics for QtBase

Many of those files are from 3rdparty code, the ones I recognize are 
from /qtbase/src/3rdparty/xkbcommon, those I think can


be ignored when thinking from code coverage point of view.



*From:* 
development-bounces+gatis.paeglis=theqtcompany@qt-project.org 
 on 
behalf of Sébastien Fricker 

*Sent:* Thursday, February 19, 2015 3:51 PM
*To:* development
*Subject:* [Development] Code Coverage Statistics for QtBase
Hi,
According http://download.froglogic.com/public/qt5-squishcoco-report/ 
there is a big decrease of the code coverage between Qt5/dev and Qt5.4.

The code coverage from QtBase is decreasing from 56% to 42%.

The first reason of that, is that approximately 100 new files get 
added into the project and the code coverage of this set is near to 
zero (see the HTML attachment and the table below).
This new uncovered files are responsible of a lost of the code 
coverage of 3% approximately.
Question: are these files not tested through an unit test? If they are 
tested, I need to look why they are not taken in account by the code 
coverage analysis.



The main difference are caused by the code coverage of the unit tests 
itself.
The number of unit tests did not decrease, but the code coverage of 
the tests with the status Unknown decrease from 13% (from 43% to 30%) 
and this explain the rest of the code coverage lost.
These tests are in fact the code coverage of the code which is running 
before and after a unit test (setup the GUI, common initializations 
executed before main(), exit code, ...).
Question: are they changes between Qt5.4 and Qt5/dev in QTestLib (in 
the unit tests or in QtBase) which could explain this?


Regards,
Sébastien

List of new files:
Source  Coverage (1 means 100%)
action.c0
ast-build.c 0
atom.c  0
compat.c0
context-priv.c  0
context.c   0
expr.c  0
include.c   0
keycodes.c  0
keymap-dump.c   0
keymap-priv.c   0
keymap.c0
keysym-utf.c0
keysym.c0
keywords.c  0
parser.c0
parser.y0
qbasicfontdatabase.cpp  0
qdbusmenuadaptor.cpp0
qdbusmenuconnection.cpp 0
qdbusmenutypes.cpp  0
qdbusplatformmenu.cpp   0
qdbustrayicon.cpp   0
qdbustraytypes.cpp  0
qdevicediscovery_udev.cpp   0
qeglconvenience.cpp 0
qeglfscontext.cpp   0
qeglfsdeviceintegration.cpp 0
qeglfshooks.cpp 0
qeglfsintegration.cpp   0
qeglfsoffscreenwindow.cpp   0
qeglfsscreen.cpp0
qeglfswindow.cpp0
qeglpbuffer.cpp 0
qeglplatformcontext.cpp 0
qeglplatformcursor.cpp  0
qeglplatformintegration.cpp 0
qeglplatformscreen.cpp  0
qeglplatformwindow.cpp  0
qevdevkeyboardhandler.cpp   0
qevdevkeyboardmanager.cpp   0
qevdevmousehandler.cpp  0
qevdevmousemanager.cpp  0
qevdevtablet.cpp0
qevdevtouch.cpp 0
qeventdispatcher_glib.cpp   0
qfbbackingstore.cpp 0
qfbcursor.cpp   0
qfbscreen.cpp   0
qfbvthandler.cpp0
qfbwindow.cpp   0
qfontconfigdatabase.cpp 0
qfontengine_ft.cpp  0
qfontenginemultifontconfig.cpp  0
qgenericunixeventdispatcher.cpp 0
qgenericunixservices.cpp0
qgenericunixthemes.cpp  0
qglxconvenience.cpp 0
qinputdevicemanager.cpp 0
qopenglcompositor.cpp   0
qopenglcompositorbackingstore.cpp   0
qopenglfunctions_4_4_compatibility.cpp  0
qopenglfunctions_4_4_core.cpp   0
qopenglfunctions_4_5_compatibility.cpp  0
qopenglfunctions_4_5_core.cpp   0
qplatformgraphicsbuffer.cpp 0
qplatformgraphicsbufferhelper.cpp   0
qsslellipticcurve.cpp   0
qsslpresharedkeyauthenticator.cpp   0
qstatusnotifieritemadaptor.cpp  0
qunixeventdispatcher.cpp0
qxcbbackingstore.cpp0
qxcbclipboard.cpp   0
qxcbconnection.cpp  0
qxcbconnection_xi2.cpp  0
qxcbcursor.cpp  0
qxcbdrag.cpp0
qxcbglintegration.cpp   0
qxcbglintegrationfactory.cpp0
qxcbimage.cpp   0
qxcbintegration.cpp 0
qxcbkeyboard.cpp0
qxcbmime.cpp0
qxcbnativeinterface.cpp 0
qxcbnativeinterfacehandler.cpp  0
qxcbscreen.cpp  0
qxcbsessionmanager.cpp  0
qxcbsystemtraytracker.cpp   0
q

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Turunen Tuukka]

>
> Lähettäjä: development-bounces+tuukka.turunen=theqtcompany@qt-project.org 
>  project.org> käyttäjän  puolestaRafael Roquetto 
> Lähetetty: 19. helmikuuta 2015 17:03
> Vastaanottaja: Björn Breitmeyer
> Kopio: development@qt-project.org
> Aihe: Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't 
> support lambda
>
> On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
> 
> > So long point short, i would like to dicuss this for a move to Qt6 because 
> > of
> > this and the points Andre mentioned already.
> +1

I think we should be able to address deprecation of old platform and compiler 
version also during the lifespan of Qt 5.x. I also do not think that time is 
yet right to make Qt 6, even though we are approaching the final Qt 4 releases 
:)

In Qt 5.5 we are dropping quite many older platform and compiler versions in 
order to be able to support new, so doing same in Qt 5.6 is completely 
reasonable to consider. 

Stating this, I am not yet taking stand whether we need to go "all-in" with 
C++11 in Qt 5.6, but we should at least properly consider the pros and cons. We 
already see that Qt WebEngine benefits from newer compilers and there are also 
other things to be gained by being able to better leveraging capabilities 
provided by C++11. 

What comes to supporting older compilers and OS versions, that is of course a 
significant item to consider as well. The typical options there are to support 
only a subset of Qt functionality in these platforms as well as case by case 
leveraging back porting to bring features from new Qt versions on top of an 
older one. One extreme approach is also to make a special version of Qt for 
these platforms, if the need is big enough. And a rather commonly used approach 
is to have an extended support agreement to cover the needed product lifespan, 
therefore reducing the need of moving to a new version.

Yours,

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> [1] ranged based for uses std::begin(container), which if not overloaded
> calls  container.begin(), which detaches.
> 
> So using range-based can be used:
> - If the container is const or
> - If the container is unshared or
> - To actually change the container's contents

Sounds like the intended behaviour to me. What's wrong with this picture?

-- 
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] RFC: Improved Q_ENUM

[Matthew Woehlke]

On 2015-02-18 16:53, Thiago Macieira wrote:
> On Wednesday 18 February 2015 12:16:58 Matthew Woehlke wrote:
>>> I have not tried QSettings yet, but since it works with QVariant it
>>> should 
>>> work.
>>
>> Sure, I'd expect it to work, also :-). What I meant was, does it get
>> written as an integer, or as a string?
> 
> Neither.
> 
> It's written as @Variant() 
> where the QDataStream serialisation includes the type's name. It also only 
> works if you've registered operator<< and operator>> for your type.

  enum foo {bar};
  QSettings().setValue("foo", bar);

Didn't check, but considering I haven't even registered the metatype,
I'm pretty sure this writes "foo=0". However, that goes back to my
previous point; adding Q_ENUM(foo) is not going to change this, because
the value is already converted to numeric when the QVariant is
constructed, when I'm doing it this way.

If I'm doing QVariant::fromValue(bar), then presumably I already
have my own QDataStreap << and >> operators, and Q_ENUM isn't going to
change that either (at least not without me as a developer being very
aware of that change, which I think is sufficient).

A better question might be if this works:

  Q_ENUM(foo) // assume same 'foo' as above
  QSettings().setValue("foo", QVariant::fromValue(bar).toString());
  auto v = QSettings().value("foo");
  v.value(); // does this return foo::bar?

-- 
Matthew

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

Re: [Development] Code Coverage Statistics for QtBase

[Thiago Macieira]

On Thursday 19 February 2015 15:57:30 Paeglis Gatis wrote:
> > Why can they be ignored?
> 
> I mean, we use only some of the API from that library, but bundle all of it.
> If it is not fully covered by tests it is not an issue.

It's also possible that Froglogic built Qt against the system xkbcommon, which 
explains why the coverage in the 3rdparty xkbcommon is zero.

-- 
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Daniel Teske]

On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> > [1] ranged based for uses std::begin(container), which if not overloaded
> > calls  container.begin(), which detaches.
> > 
> > So using range-based can be used:
> > - If the container is const or
> > - If the container is unshared or
> > - To actually change the container's contents
> 
> Sounds like the intended behaviour to me. What's wrong with this picture?

You don't want to detach if you are only reading.

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

Re: [Development] Code Coverage Statistics for QtBase

[Thiago Macieira]

On Thursday 19 February 2015 17:08:42 Sébastien Fricker wrote:
> Is it possible that the default build parameter get changed between 
> Qt5.4 and dev?
> For example XCB support get detected automatically and the code get enabled?

Yes for the EGL parts: it's possible the files are now built when they 
previously weren't. I think it's the work that made EGL be supported with non-
ES configurations. The same goes for the qevdev* and qfb* files.

The OpenGL 4.4 and 4.5 files might be because your testing environment does not 
support those profiles. Or they simply aren't tested, I don't know.

The qdbusmenu* and qdbustray* things are also probably environmental issues: 
if your DE does not have a host for those specs, they wouldn't get activated.

I can't explain why the qxcb* and font files.

As forkfd.c reaching only 28% usage:
 - part of the file is spawnfd, which wouldn't get used on Linux. I'll see 
about dropping it from the build.
 - a great deal of the code depends on timing of the OS scheduler, so it's 
very hard to increase coverage. One way to do that is to launch a separate 
process that keeps sending SIGCHLD periodically to the test process. 

I think we already have a stress test that launches more than 16 concurrent 
tests and would exercise the "big array", but I will check.

PS: I'm working on clonefd with a colleague.
-- 
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

On Thursday 19 February 2015 17:32:11 Daniel Teske wrote:
> On Thursday 19 Feb 2015 08:26:29 Thiago Macieira wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> > > [1] ranged based for uses std::begin(container), which if not overloaded
> > > calls  container.begin(), which detaches.
> > > 
> > > So using range-based can be used:
> > > - If the container is const or
> > > - If the container is unshared or
> > > - To actually change the container's contents
> > 
> > Sounds like the intended behaviour to me. What's wrong with this picture?
> 
> You don't want to detach if you are only reading.

Then make your container const. A cast or template function call that adds 
const is very easy.

The design for the range-based for is that it can be used to mutate the 
container, so the above picture is exactly what is intended for that 
construct.

-- 
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Giuseppe D'Angelo]

On 19 February 2015 at 17:26, Thiago Macieira  wrote:
> Sounds like the intended behaviour to me. What's wrong with this picture?

That on a non-const shared container

for (auto i : container)

will detach it. That's why having rules instead of saying "just use
it", I guess...

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

Re: [Development] Qt for iOS: Management Retina vs Non-Retina Images

[Robert Iakobashvili]

On Thu, Feb 19, 2015 at 3:03 PM, Sorvig Morten
 wrote:
>
>> On 18 Feb 2015, at 10:59, Robert Iakobashvili  wrote:
>>
>> What about support for @3x?
>> Is it inside or is it planned?
>
> I’ve started implementing @3x support here:
>
> https://codereview.qt-project.org/106717
> https://codereview.qt-project.org/106705
>
> There’s some refactoring work to be done as well to reduce the logic 
> duplication.
>
> Morten

Looks great. Thank you.

Is it something to be coming only in 5.5 or could
be expected in 5.4.2 as well?

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-19 07:29, Daniel Teske wrote:
> Qt's container classes and C++11 range based for loop do not mix very well.
> Ranged based for uses std::begin(container), which if not overloaded calls 
> container.begin(), which detaches. 

As an aside, the "correct" fix for this IMHO is for range-based for to
support a mechanism for marking the RHS 'const', whether or not it
otherwise would be so.

Worst case, Qt could (should?) implement something like:

  struct QConstWrapper
  {
ContainerType::const_iterator begin() const;
ContainerType::const_iterator end() const;
// remaining "magic" elided
  };

  QConstWrapper qConst(ContainerType const&);

That said, note that range-based for also differs from foreach in that
the former operates on the original container, whereas the latter
operates on a copy.

-- 
Matthew

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

Re: [Development] Code Coverage Statistics for QtBase

[Sean Harmer]

On Thursday 19 Feb 2015 08:39:52 Thiago Macieira wrote:
> On Thursday 19 February 2015 17:08:42 Sébastien Fricker wrote:
> > Is it possible that the default build parameter get changed between
> > Qt5.4 and dev?
> > For example XCB support get detected automatically and the code get
> > enabled?
> Yes for the EGL parts: it's possible the files are now built when they
> previously weren't. I think it's the work that made EGL be supported with
> non- ES configurations. The same goes for the qevdev* and qfb* files.
> 
> The OpenGL 4.4 and 4.5 files might be because your testing environment does
> not support those profiles. Or they simply aren't tested, I don't know.

We can't sensibly test them on the CI. In theory we could write a manual test 
for them but all we'd really be able to test is that the functions resolve to 
non-null addresses. We can't do it on the CI as they won't have a GL 4 
implementation.

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

Re: [Development] QtPlatformSupport is really public in 5.4.0?

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 19 February 2015 12:50:27 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> I might have even missed it before, but are the following QtPlatformSupport
> headers really public (ie, API/ABI stable)?
> 
> /usr/include/qt5/QtPlatformSupport/QtPlatformSupportVersion
> /usr/include/qt5/QtPlatformSupport/QtPlatformSupportDepends
> /usr/include/qt5/QtPlatformSupport/QtPlatformSupport
> /usr/include/qt5/QtPlatformSupport/qtplatformsupportversion.h

Looking at the content they do not define anything important, so I guess
this is still WIP :)

-- 
127.0.0.1 sweet 127.0.0.1

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Does QNetworkAccessManager could provide the Server Sent Event feature ?

[Paul Chavent]

On 02/17/2015 10:17 PM, Thiago Macieira wrote:
> On Tuesday 17 February 2015 20:50:44 Paul Chavent wrote:
>> On 02/16/2015 11:58 PM, Thiago Macieira wrote:
>>> On Monday 16 February 2015 23:52:19 Paul Chavent wrote:
 The parts 6 "Parsing an event stream" [2] gives the specs of the format
 over http. The part 7 "Interpreting an event stream" explains how it
 should be handled by the client. For some sample code, I've found useful
 those two pages [3] and [4].

 [2] http://www.w3.org/TR/eventsource/#parsing-an-event-stream
 [3]
 https://today.java.net/article/2010/03/31/html5-server-push-technologies-> 
 >> pa
 rt-1#sse [4] http://www.html5rocks.com/en/tutorials/eventsource/basics/
>>>
>>> I'm looking for the HTTP command verb and expected replies.
>>>
>>> If it's a GET, POST, PUT, DELETE or similar, with the reply a 200 Ok, then
>>> QNAM already supports this and no modifications are necessary.
>>
>> The difference is that the server can send asynchronous responses (event). I
>> will look deeper in the current code base.
>
> If it's plain HTTP/1.x, then the server cannot send anything that the client
> did not ask for (HTTP/2.0 can do that). The only way to implement server-
> pushed data in HTTP/1.x is for the client to make a request that the server
> always responds with a Chunked transfer that never ends. That's how 1990s web-
> based chats were implemented.
>
> If that's ow this server event is implemented, then QNAM already supports it.
> The QNetworkReply's readyRead() signal will be emitted whenever new events are
> received. You just have to parse it.
>
> At most, we'd implement a wrapper around QNetworkReply to make the parsing
> easier.
>
> If it's not how it's implemented -- if there are HTTP spec changes -- then
> QNAM needs modifications.
>

Thank you for pointing this alternative.

Indeed, I'm not sure that this specification (SSE) require a minimal HTTP 
version in order to work.

The advantage of SSE over chunks would be the availability of an event 
framework.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
> On 19 February 2015 at 17:26, Thiago Macieira  
wrote:
> > Sounds like the intended behaviour to me. What's wrong with this picture?
> 
> That on a non-const shared container
> 
> for (auto i : container)
> 
> will detach it. That's why having rules instead of saying "just use
> it", I guess...

And who says it's not what you wanted?

for (auto &i : container) {
if (i.startsWith("foo"))
i = bar;
}

-- 
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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
> On 2015-02-19 07:29, Daniel Teske wrote:
> > Qt's container classes and C++11 range based for loop do not mix very
> > well.
> > Ranged based for uses std::begin(container), which if not overloaded calls
> > container.begin(), which detaches.
> 
> As an aside, the "correct" fix for this IMHO is for range-based for to
> support a mechanism for marking the RHS 'const', whether or not it
> otherwise would be so.
> 
> Worst case, Qt could (should?) implement something like:
> 
>   struct QConstWrapper
>   {
> ContainerType::const_iterator begin() const;
> ContainerType::const_iterator end() const;
> // remaining "magic" elided
>   };
> 
>   QConstWrapper qConst(ContainerType const&);
> 
> That said, note that range-based for also differs from foreach in that
> the former operates on the original container, whereas the latter
> operates on a copy.

It actually needs to be:

template  const T qConst(const T &t) { return t; }

It needs to create a copy and return it. There's a gotcha with range-based for 
that it is defined in such a way that your temporaries may be destroyed before 
the iteration. The standard defines it as:

{
auto && __range = ;
for ( auto __begin = std::begin(__range),
__end = std::end(__range);
__begin != __end;
++__begin ) {
 = *__begin;

}
}

If you have a temporary in your right hand of the ':' it will get lifetime-
extended by that __range reference. Any other temporaries will get destroyed.

That means a cast works and a copy works. Returning a reference doesn't.

-- 
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] P0 - DNS test zones gone - CI blocked

[Thiago Macieira]

On Thursday 19 February 2015 01:17:57 Thiago Macieira wrote:
> On Wednesday 18 February 2015 21:29:38 Thiago Macieira wrote:
> > https://bugreports.qt.io/browse/QTWEBSITE-625
> 
> [snip]

The CI should now be unblocked. Arto reverted the DNS delegation back to 
Linpro, since their servers are still responding authoritatively for some time 
(until the contract ends, I'd guess).

No changes have so far been necessary.

We'll retry moving the zone to the new host. I don't think we can do it 
without disruption again due to the nature of NS records, but we'll try our 
best to minimise it. Please expect the CI to be unavailable during the weekend 
of Feb 28 - Mar 1.

-- 
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] Code Coverage Statistics for QtBase

[Sébastien Fricker]

On 19/02/2015 17:39, Thiago Macieira wrote:
> On Thursday 19 February 2015 17:08:42 Sébastien Fricker wrote:
>> Is it possible that the default build parameter get changed between 
>> Qt5.4 and dev?
>> For example XCB support get detected automatically and the code get enabled?
> Yes for the EGL parts: it's possible the files are now built when they 
> previously weren't. I think it's the work that made EGL be supported with non-
> ES configurations. The same goes for the qevdev* and qfb* files.
>
> The OpenGL 4.4 and 4.5 files might be because your testing environment does 
> not 
> support those profiles. Or they simply aren't tested, I don't know.
I'm just pointing that some new files are not covered.
I would not wonder me that the files are build and not used if the tests
are not directly use OpenGL, but the "old" X11 interface.
I prefer principally in such case not excluding it. But, if all CIs are
skipping EGL and OpenGL tests systematically, it might not be good at all.
>
> The qdbusmenu* and qdbustray* things are also probably environmental issues: 
> if your DE does not have a host for those specs, they wouldn't get activated.
Do you have a README which permits to set this?
>
> I can't explain why the qxcb* and font files.
>
> As forkfd.c reaching only 28% usage:
>  - part of the file is spawnfd, which wouldn't get used on Linux. I'll see 
> about dropping it from the build.
>  - a great deal of the code depends on timing of the OS scheduler, so it's 
> very hard to increase coverage. One way to do that is to launch a separate 
> process that keeps sending SIGCHLD periodically to the test process. 
>
> I think we already have a stress test that launches more than 16 concurrent 
> tests and would exercise the "big array", but I will check.
>
> PS: I'm working on clonefd with a colleague.
If you want I can generate a diff which compute what was covered in
Qt4.5 which is not covered in dev.
Just let me know.

PS: I'm next week on vacation, so I'm not sure that I can do a fast reply.

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

Re: [Development] Code Coverage Statistics for QtBase

[Sébastien Fricker]

On 19/02/2015 17:31, Thiago Macieira wrote:
> On Thursday 19 February 2015 15:57:30 Paeglis Gatis wrote:
>>> Why can they be ignored?
>> I mean, we use only some of the API from that library, but bundle all of it.
>> If it is not fully covered by tests it is not an issue.
> It's also possible that Froglogic built Qt against the system xkbcommon, 
> which 
> explains why the coverage in the 3rdparty xkbcommon is zero.
>
I must check this.
But for both versions we are using the same VM.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-19 14:28, Thiago Macieira wrote:
> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>> That on a non-const shared container
>>
>> for (auto i : container)
>>
>> will detach it. That's why having rules instead of saying "just use
>> it", I guess...
> 
> And who says it's not what you wanted?
> 
> for (auto &i : container) {
>   if (i.startsWith("foo"))
>   i = bar;
> }

Correct me if I'm wrong, but:

  auto c = expensive();

  // assume 'c' is shared and a deep copy of c would be really expensive

  foreach (auto const& item, c) { ... } // does not deep copy
  for (auto const& item : c) { ... } // *does* deep copy; ouch!

I think the point here is that it's easy to incur deep copies using
range-based for when there is no need to do so. There really "needs" to
be a simple and concise way to stop that from happening.

-- 
Matthew

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-19 14:36, Thiago Macieira wrote:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not overloaded calls
>>> container.begin(), which detaches.
>>
>> As an aside, the "correct" fix for this IMHO is for range-based for to
>> support a mechanism for marking the RHS 'const', whether or not it
>> otherwise would be so.
>>
>> Worst case, Qt could (should?) implement something like:
>>
>>   struct QConstWrapper
>>   {
>> ContainerType::const_iterator begin() const;
>> ContainerType::const_iterator end() const;
>> // remaining "magic" elided
>>   };
>>
>>   QConstWrapper qConst(ContainerType const&);
>>
>> That said, note that range-based for also differs from foreach in that
>> the former operates on the original container, whereas the latter
>> operates on a copy.
> 
> It actually needs to be:
> 
> template  const T qConst(const T &t) { return t; }
> 
> It needs to create a copy and return it. There's a gotcha with range-based 
> for 
> that it is defined in such a way that your temporaries may be destroyed 
> before 
> the iteration. The standard defines it as:
> 
> {
>   auto && __range = ;
>   for ( auto __begin = std::begin(__range),
>   __end = std::end(__range);
>   __begin != __end;
>   ++__begin ) {
>= *__begin;
>   
>   }
> }
> 
> If you have a temporary in your right hand of the ':' it will get lifetime-
> extended by that __range reference. Any other temporaries will get destroyed.
> 
> That means a cast works and a copy works. Returning a reference doesn't.

You'll note that I did *not* return a reference.

Returning a copy may be okay for Qt since containers are COW (in fact,
your version would result in a range-based for that works much more like
Q_FOREACH, which is probably good for some cases). What I was aiming for
was rather a class that internally holds a reference to the container
(such class would be copyable) and forwards the calls to begin/end to
that container, such that in a range-based for it appears to *be* the
container, but forces use of const_iterator. Note that this would work
equally well for non-Qt containers, as long as they have 'IteratorType
{begin,end}() const' methods. (Trailing return specification may be
required to permit the container's iterator type to be unknown.)

I was initially thinking that this was perhaps simple enough to not be
worth it. Given your point, I am leaning more toward that it *would* be
valuable.

(I still think the best solution is for C++ to just accept 'const
' as a modifier to make the type of '' constant, regardless
of whether or not it was. This would allow things like 'for (auto item :
const container)', '(const this)->begin()', 'foo(const bar)', and so forth.)

-- 
Matthew

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Marc Mutz]

On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> more than 400 lambdas in Creator's source

Sounds like lambdas are overused (as any new language feature is overused 
before it's fully understood by the resp. language community).

> and have several interfaces 
> that take a std::function. 

What about boost::function?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-19 15:21, Marc Mutz wrote:
> On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
>> more than 400 lambdas in Creator's source
> 
> Sounds like lambdas are overused (as any new language feature is overused 
> before it's fully understood by the resp. language community).

Maybe, maybe not.

I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
using them most often in QObject::connect. Basically, a lambda saves
writing a protected (or worse, *private*) slot by allowing the relevant
code to be written inline. These are rarely more than a few lines long,
and it's not unusual for them to be one-liners, e.g.:

  connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
  [d](int value){ d->scrollTo(value); });

The above is basically a private slot that's *actually private*. I've
also had cases of needing to connect a signal to a slot where the slot
needs to be called with additional (constant) arguments; these tend to
look like the above also.

Of course, the usual caveats of binding to a lambda apply, but in many
cases those aren't issues (e.g. my MainWindow class is not going to
disappear without taking its widgets with it, and said widgets aren't
likely to be emitting signals from other threads).

p.s. It would be cool if these restrictions could be relaxed by adding
an overload that takes a QObject that "owns" the slot.

>> and have several interfaces 
>> that take a std::function. 
> 
> What about boost::function?

Ugh, make Qt depend on boost? No, thanks...

-- 
Matthew

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Kevin Funk]

On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> > 
> > Sounds like lambdas are overused (as any new language feature is overused
> > before it's fully understood by the resp. language community).
> 
> Maybe, maybe not.
> 
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
> 
>   connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
>   [d](int value){ d->scrollTo(value); });
> 
> The above is basically a private slot that's *actually private*. I've
> also had cases of needing to connect a signal to a slot where the slot
> needs to be called with additional (constant) arguments; these tend to
> look like the above also.
> 
> Of course, the usual caveats of binding to a lambda apply, but in many
> cases those aren't issues (e.g. my MainWindow class is not going to
> disappear without taking its widgets with it, and said widgets aren't
> likely to be emitting signals from other threads).
> 
> p.s. It would be cool if these restrictions could be relaxed by adding
> an overload that takes a QObject that "owns" the slot.

http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2)

Isn't that what you need?
- Resolves issues with thread-affinity (via QueuedConnection if req.)
- Automatic disconnect when the receiver/context is destroyed

> 
> >> and have several interfaces
> >> that take a std::function.
> > 
> > What about boost::function?
> 
> Ugh, make Qt depend on boost? No, thanks...

Greets

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[André Pönitz]

On Thu, Feb 19, 2015 at 03:41:42PM -0500, Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> > 
> > Sounds like lambdas are overused (as any new language feature is overused 
> > before it's fully understood by the resp. language community).
> 
> Maybe, maybe not.
> 
> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
> 
>   connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
>   [d](int value){ d->scrollTo(value); });


That's one (good) example.

Another one would be to avoid passing data through QAction::data
and using QObject::sender() in cases like


void someSlot()
{
const QAction *action = qobject_cast(sender());
/* FIXME: check action */
Data data = action->data().value();
foo()->useData(data);
}

/* ... possibly lots of lines inbetween ... */

{
...
Data data = /*...*/;
QAction *action = new QAction(...)
action->setData(data);
connect(action, &QAction::triggered, this, &ThisClass::someSlot); 
...
   }

vs:

{
...
Data data = /*...*/;
QAction *act = new QAction(...)
connect(act, &QAction::triggered, [this, data] { foo()->useData(data); }
...
}

This is less than half the code, is type-safe, an keeps related code in
one place. One line to express one idea. No awkward boilerplate.

Andre'

PS: I probably should praise Olivier more often for the new connect syntax.
Personally I think that's the #1 feature in Qt 5. It makes a real (positive)
difference in Qt application development.

PPS:

> > What about boost::function?
> 
> Ugh, make Qt depend on boost? No, thanks...

*grin*

Indeed.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Mathias Hasselmann]

NO, please. Just use std::cref(). The feature is there already in the STL.

Am 19.02.2015 um 20:36 schrieb Thiago Macieira:
> On Thursday 19 February 2015 12:07:04 Matthew Woehlke wrote:
>> On 2015-02-19 07:29, Daniel Teske wrote:
>>> Qt's container classes and C++11 range based for loop do not mix very
>>> well.
>>> Ranged based for uses std::begin(container), which if not overloaded calls
>>> container.begin(), which detaches.
>>
>> As an aside, the "correct" fix for this IMHO is for range-based for to
>> support a mechanism for marking the RHS 'const', whether or not it
>> otherwise would be so.
>>
>> Worst case, Qt could (should?) implement something like:
>>
>>struct QConstWrapper
>>{
>>  ContainerType::const_iterator begin() const;
>>  ContainerType::const_iterator end() const;
>>  // remaining "magic" elided
>>};
>>
>>QConstWrapper qConst(ContainerType const&);
>>
>> That said, note that range-based for also differs from foreach in that
>> the former operates on the original container, whereas the latter
>> operates on a copy.
>
> It actually needs to be:
>
> template  const T qConst(const T &t) { return t; }
>
> It needs to create a copy and return it. There's a gotcha with range-based for
> that it is defined in such a way that your temporaries may be destroyed before
> the iteration. The standard defines it as:
>
> {
>   auto && __range = ;
>   for ( auto __begin = std::begin(__range),
>   __end = std::end(__range);
>   __begin != __end;
>   ++__begin ) {
>= *__begin;
>   
>   }
> }
>
> If you have a temporary in your right hand of the ':' it will get lifetime-
> extended by that __range reference. Any other temporaries will get destroyed.
>
> That means a cast works and a copy works. Returning a reference doesn't.
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Mathias Hasselmann]

Am 19.02.2015 um 20:47 schrieb Matthew Woehlke:
> On 2015-02-19 14:28, Thiago Macieira wrote:
>> On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
>>> That on a non-const shared container
>>>
>>> for (auto i : container)
>>>
>>> will detach it. That's why having rules instead of saying "just use
>>> it", I guess...
>>
>> And who says it's not what you wanted?
>>
>> for (auto &i : container) {
>>  if (i.startsWith("foo"))
>>  i = bar;
>> }
>
> Correct me if I'm wrong, but:
>
>auto c = expensive();
>
>// assume 'c' is shared and a deep copy of c would be really expensive
>
>foreach (auto const& item, c) { ... } // does not deep copy
>for (auto const& item : c) { ... } // *does* deep copy; ouch!
>
> I think the point here is that it's easy to incur deep copies using
> range-based for when there is no need to do so. There really "needs" to
> be a simple and concise way to stop that from happening.

Use std::cref() if not sure about your container's constness.

 for (auto const& item : std::cref(c)) { ... }

But yes, I'd also prefer the C++ consortium would have opted for an 
immutable range loop. "Optimize the common case, not the rare case". 
Well, and for the code I usually write mutable range loops are a rare 
exception. Also since we got the auto keyword mutable loops are 
convenient to type now:

 for (auto it = begin(c); it != end(c); ++i) { ... }

Not much longer than a range loop statement. But well, we won't change 
that anymore, and at least I have no idea how to avoid that ugly 
"std::cref()". Thinking now in the the direction of just teaching QML 
about C++ standard containers and avoiding the Qt containers then. But 
that also are crazy thoughts.

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Matthew Woehlke]

On 2015-02-19 16:27, Kevin Funk wrote:
> On Thursday 19 February 2015 15:41:42 Matthew Woehlke wrote:
>> p.s. It would be cool if these restrictions could be relaxed by adding
>> an overload that takes a QObject that "owns" the slot.
> 
> http://doc.qt.io/qt-5/qobject.html#connect-6 (since Qt 5.2)
> 
> Isn't that what you need?
> - Resolves issues with thread-affinity (via QueuedConnection if req.)
> - Automatic disconnect when the receiver/context is destroyed

Um... how'd I miss that? Thanks! :-)

-- 
Matthew

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

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Thiago Macieira]

On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
> Use std::cref() if not sure about your container's constness.
> 
>  for (auto const& item : std::cref(c)) { ... }

Do NOT do this. This will crash:

for (auto const &item : std::cref(somefunction()) { ... }

See my other email for an explanation.

And another reason is that std::cref is a C++11 Standard Library addition and 
we cannot depend on that yet.
-- 
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] New Qt 5.4.1 snapshot available

[Heikkinen Jani]

Hi all,


Unfortunately couple of blockers found from previous packages. Blockers should 
be fixed & updates packages are available here:


Windows: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-19_114/

Linux: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-19_118/

Mac: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-19_104/


Qt content is same than in previous packages, only  QtCreator & QtCanvas3D is 
updated.


Please sanitycheck these packages & inform me immediately if there is something 
broken which prevents us releasing these packages as Qt 5.4.1 at the beginning 
of next week


br,

Jani




Lähettäjä: Heikkinen Jani
Lähetetty: 18. helmikuuta 2015 7:52
Vastaanottaja: development@qt-project.org
Aihe: New Qt 5.4.1 snapshot available


Hi all,


We have new Qt 5.4.1 snapshot available:


Windows: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_112/

Linux: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_116/

Mac: http://download.qt.io/snapshots/qt/5.4/5.4.1/2015-02-17_102/


Please sanitycheck these packages & inform me immediately if there is something 
broken which prevents us releasing these packages as Qt 5.4.1 release later 
this week


br,

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