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
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.
On Thursday 19 February 2015 17:46:01 Giuseppe D'Angelo wrote:
On 19 February 2015 at 17:26, Thiago Macieira thiago.macie...@intel.com
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
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.
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
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
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
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:
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
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
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
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
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
Hi Sean, this one:
https://bugreports.qt.io/browse/QTBUG-44497
Da: Sean Harmer sean.har...@kdab.com
A: development@qt-project.org; Massimo Callegari massimocalleg...@yahoo.it
Inviato: Giovedì 19 Febbraio 2015 12:47
Oggetto: Re: [Development] 5.5.0 snapshot please ?
On Thursday 19
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
On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto rafael.roque...@kdab.com
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
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
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
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
On Thu, Feb 19, 2015 at 02:25:27PM +0100, Cristian Adam wrote:
On Thu, Feb 19, 2015 at 2:17 PM, Rafael Roquetto rafael.roque...@kdab.com
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
On Thu, Feb 19, 2015 at 02:27:32PM +0100, Tomasz Siekierda wrote:
On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com
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
On 18 Feb 2015, at 10:59, Robert Iakobashvili corobe...@gmail.com 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
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
On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com 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
On Thu, Feb 19, 2015 at 2:36 PM, Rafael Roquetto rafael.roque...@kdab.com
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
On 19 Feb 2015, at 14:27, Tomasz Siekierda sierd...@gmail.com wrote:
On 19 February 2015 at 14:17, Rafael Roquetto rafael.roque...@kdab.com
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
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
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
On Thu, Feb 19, 2015 at 03:11:05PM +0100, Björn Breitmeyer wrote:
snip
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,
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
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 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
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
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
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:
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.
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
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
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.
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;
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
Lähettäjä: development-bounces+tuukka.turunen=theqtcompany@qt-project.org
development-bounces+tuukka.turunen=theqtcompany.com@qt-
project.org käyttäjän puolestaRafael Roquetto rafael.roque...@kdab.com
Lähetetty: 19. helmikuuta 2015 17:03
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,
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
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
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 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
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
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
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
On 19 February 2015 at 17:26, Thiago Macieira thiago.macie...@intel.com 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
On Thu, Feb 19, 2015 at 3:03 PM, Sorvig Morten
morten.sor...@theqtcompany.com wrote:
On 18 Feb 2015, at 10:59, Robert Iakobashvili corobe...@gmail.com wrote:
What about support for @3x?
Is it inside or is it planned?
I’ve started implementing @3x support here:
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
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
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,
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
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
57 matches
Mail list logo
