Re: [Development] Requesting a repository for Lottie-Qt implementation

[Sean Harmer]

On 10/01/2019 15:08, Shawn Rutledge wrote:

The next problem is how to use custom shaders and adjustable uniforms without 
breaking batching in the scene graph; today, the number of draw calls goes up 
if you do that.  This is the reason we don’t have GPU-calculated AA line 
charts, and it’s also the reason we don’t have the nice Ellipse that I wrote 
for Qt Quick.  Every custom shader runs in a separate batch (that’s 
unavoidable).  Shaders can’t have dynamically adjusted uniforms (for animation, 
or for limiting the scope of rendering of a vertex array), or even uniforms 
that vary between instances, without breaking batching, and that’s a terrible 
limitation that I would like to see solved somehow in a future scene graph 
implementation, if there’s any way.


glDrawElementsInstanced() in ES 3 and OpenGL 3 can be used or if you 
want to go further you can index into uniform buffer objects or SSBOs 
and use things like glMultiDrawIndirect. There are equivalents in 
Vulkan/Metal/DX12 of course.


However, limiting everything to the feature set provided by ES 2 won't 
allow this type of optimisation as you are forced to do more on the CPU 
side.


Cheers,

Sean

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

Re: [Development] Best practices for hacking Qt in QtCreator?

[Sean Harmer]

On 21/09/2018 08:41, Nils Jeisecke via Development wrote:

Hi there,

although I'm usually using vim as my primary environment when hacking
Qt itself it can be tempting to use QtCreator instead for better code
navigation etc.

Simply opening the .pro file of some Qt submodule does not really work
out of the box. Lots of complaints about Qt includes not found etc.
(with clang code model).

Maybe someone is willing to share the secrets on how to configure
QtCreator for a nice Qt developing experience?


Works fine here as long as you open the project using a kit set up from 
that particular build of Qt. I tend to just build qtbase etc on the 
command line, setup a kit in creator for it, then open qt3d/qt3d.pro and 
it just works.


Cheers,

Sean

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

[Development] Qt 3D Maintainership

[Sean Harmer via Development]

Hi All,

my time available for Qt 3D outside of work, has as of late, been 
reduced due to increased family commitments - the good kind, but time 
consuming nonetheless.


Given how Qt 3D has grown from our simple experiments in making 3D 
possible with Qt to the highly-configurable, multi-module, data 
processing monster it is today I feel it is no longer possible, nor 
wise, for me to maintain alone. Additionally, it looks as if Qt 3D will 
form an important piece of the graphics stack for Qt 6.


As such I would like to propose that we split the maintainership and I 
would propose that Laszlo Agocs becomes co-maintainer. I am still happy 
to co-maintain and I have plenty of ideas about improvements we can make 
both within the Qt5 and Qt 6 time frames. We have learned a lot whilst 
developing Qt 3D and I think we can make it even better for Qt 6.


I would also suggest that we find maintainers or co-maintainers for the 
sub-modules. I would propose Paul Lemire as (co-)maintainer for the 
render module. I'm happy to keep driving the animation module and help 
with qt3dcore. Other nominations are of course welcome.


Kind regards and have a great weekend,

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

Re: [Development] Do we really need Assimp?

[Sean Harmer]

Hi Thiago,

Apologies for the delay in replying, I was on vacation.


On 23/05/2018 01:16, Thiago Macieira wrote:

Given the number of warnings in this codebase, I am really skeptical about the
quality of the code. Today, compiling with GCC, Clang an ICC, I saw the
following warnings scroll by, which are real issues:

LWSLoader.cpp:428:14: warning: duplicated ‘if’ condition [-Wduplicated-cond]

new_allocator.h:140:22: warning: destructor called on non-final
'Assimp::FICDATAValueImpl' that has virtual functions but non-virtual
destructor [-Wdelete-non-virtual-dtor]

miniz.h(4430): warning #592: variable "level" is used before its value is set

And then there are of course warnings that indicate none of their developers
are testing new compilers, like

LWOLoader.cpp:1408:13: warning: this statement may fall through [-Wimplicit-
fallthrough=]

Can we get rid of it?

If not, can I ask someone to compile it with CONFIG += warn_off, to hide all
that ugliness? Those warnings make finding our warnings more difficult and it
affects our reputation because people see warnings and think they're Qt's
fault.

Qt3D maintainers, please take action to make sure those warnings disappear
from our builds.


Tbh I'd be glad to not have assimp in the source tree too as it just 
adds to maintenance.


It's used for 2 things at present:

1) A sceneloader plugin. We could move this to be not compiled by 
default or even move it to another optional module for users to compile 
themselves.


2) The qgltf tool which converts from assimp-supported file formats to 
extended glTF 1 files. Again, we coudl do similar as with 1).


Another option is to only rely upon a system installed assimp and build 
these tools only if found at configure time. In fact, that's probably 
easiest and best. Then we can remove assimp from the source. It means 
users woudl need to build these tools/plugins themselves (typically on 
macOS/Windows) but at least they would be easily available.


Would that be acceptable to the project?

Cheers,

Sean

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

Re: [Development] qdds image format

[Sean Harmer]

On 17/04/2018 15:33, Иван Комиссаров wrote:
At the point i wrote the plugin, my usecase was simple - to convert 
plain QImages to and from DDS icons (used in starcraft2, which uses 
quite a few formats DDS can handle).

But yes, i forgot floating point textures.
Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody 
uses compressed jpeg, it is decompressed before usage (correct me if i'm 
wrong, but videocards uses DDS because it's decompression algorithm can 
be easily implemented in hardware)


DDS is just a container format. Peppe's point stands, QImage and friends 
are the wrong vehicle for supporting this. They simply do not offer 
enough degrees of freedom in the API to do so properly. And adding them 
would be changing what QImage is designed for.


QImage is designed to represent a single image in one of a few supported 
formats. Proper texture support needs to be able to address images by 
mip level, array layer and cubemap face in any of the formats supported.


The compressions used by various formats supported within a DDS (or KTX) 
file are designed so they can be decompressed on the fly for a small 
block of pixels. These block compression algorithms do not offer such 
on-disk savings as png/jpeg but are much easier to sample from in access 
patterns typically required by fragment shaders.


I'm not saying a tool to convert to/from dds/some other format would not 
be useful. Just that QImage is the wrong way to approach this due to the 
above.


Sean



2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo <giuseppe.dang...@kdab.com 
<mailto:giuseppe.dang...@kdab.com>>:


On 17/04/18 13:21, Иван Комиссаров wrote:

Ok, there's another problem with QImage - ARGB64 and friends...
This can be solved adding QImage::pixel64() or something like
that... or use QTexture with 64bit "pixel"


And a bunch of packed formats not currently supported, and floating
point channels, and compressed texture formats. I stand my point:
DDS files are not meant to be handled by QImage.

What is your use case exactly for wanting this support?

Cheers,

-- 
Giuseppe D'Angelo | giuseppe.dang...@kdab.com

<mailto:giuseppe.dang...@kdab.com> | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts




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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] API breackage in Qt3D

[Sean Harmer]

Animation and Extras are tech preview. The rest are stable.

Cheers,

Sean

On 28/02/2018 16:40, Lisandro Damián Nicanor Pérez Meyer wrote:

Hi! today I was packaging Qt3D (meaning the the submodule) for Debian
and noticed that some symbols where missing. We understood that Qt3D
(the submodule) was API/ABI stable, but Konstantin Tokarev pointed
out:

   https://abi-laboratory.pro/tracker/timeline/qt/ "NOTE: The libQt53D*
objects are introduced in the library
   since 5.5.0 but with no stable ABI guarantee, so analysis of these
objects was not performed."

But then Thiago pointed out:

 well, we need to start having it stable
 it's no longer in experimental state
 $ git config -f .gitmodules --get submodule.qt3d.status
 addon
 qt3d left preview status in 5.7
 if there are libs inside that aren't stable ABI, they should
be moved to a separate module

So bringing up the issue here.




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


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

Re: [Development] Nominating Ville Voutilainen as approver

[Sean Harmer]

+1

Cheers,

Sean

On 27/02/2018 09:36, Simon Hausmann wrote:

Hi,


I would like to nominate Ville as approver. Due to his work in the GCC 
project he is certainly experienced with strict code reviews. Based on 
my interaction with him I'm convinced that he has successfully 
demonstrated the same skill set during code reviews in Qt.





Simon



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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt branches & proposal how to continue with those

[Sean Harmer]

-1 from me. How is this any less work than merging, especially with git 
rerere?


Can we please keep 5.9 open until we have at least released 5.11.0?

I really don't want to get into a situation where we have bug fixes on 
5.9 and 5.11 but not 5.10.2 say.


Once 5.10 is properly closed then fine, move to a cherry pick approach 
for 5.9 but right now, especially for Qt 3D we have some important bug 
fixes landing on 5.9 than can be merged forward (with the help of git 
rerere) but for which cherry picking would be more awkward and also risk 
missing 5.10.2 if there is one.


Cheers,

Sean

On 01/02/2018 10:21, Jani Heikkinen wrote:

-Original Message-
From: Development [mailto:development-bounces+jani.heikkinen=qt.io@qt-
project.org] On Behalf Of Tuukka Turunen
Sent: tiistai 30. tammikuuta 2018 23.38
To: Konrad Rosenbaum <kon...@silmor.de>; development@qt-project.org
Subject: Re: [Development] Qt branches & proposal how to continue with those

The item that has received comments both in favor and against is what to do
with 5.10 now. I think that instead of closing 5.10, we could move it to cherry
pick mode, just like Qt 5.9 is. That allows putting the necessary fixes there, 
but
reduces the amount of needed merges a lot. It also allows to faster get all the
fixes merged up to dev, which is something we have struggled in the past.

With this approach we have full capability to make Qt 5.10.2 release, if one is
needed. We also continue to make Qt 5.9.x patch releases. We would have two
branches open for direct submission: 5.11 and dev, and for each commit the
lowest applicable branch can be chosen. For all such important fixes that need
to be in Qt 5.9.x LTS releases or in the 5.10 branch, we use cherry picking.



This is OK for me as well so +1 from my side

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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What are new features of Qt3D in Qt 5.11?

[Sean Harmer]

Hi,

On 01/01/2018 02:43, Vincent Hui wrote:

Hi,

Happy new year. In 2018, what are new features of Qt3D in Qt 5.11? Will 
Rigid body and soft body physics simulation be included?


It will mainly be performance and stabilisation in Qt 3D for 5.11. The 
physics integration is not ready yet.


Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] [Qt3D] Mixing C++ and QML

[Sean Harmer]

On 20/10/2017 09:06, Pierre-Yves Siret wrote:



2017-10-19 20:44 GMT+02:00 Shawn Rutledge <shawn.rutle...@qt.io
<mailto:shawn.rutle...@qt.io>>:

(thread started on the interest list, but I don’t think my comments
belong there)

On Oct 19, 2017, at 18:06, Sean Harmer <sean.har...@kdab.com
<mailto:sean.har...@kdab.com>> wrote:

> Hi,
>
> you've hit one of the issues we did with exposing C++ and QML APIs. 
Namely, QQmlListProperty. This thing should ideally never have existed and instead 
support for properties of collections should have been added to QObject and the 
metaobject system.

What exactly do you think should be done there, in case we can fix
it some day?

QObjects are normally managed as a tree for memory management
purposes, so I’ve also long disliked the fact that it doesn’t quite
match the nesting of the Item declarations in QML, because of the
separate QList childItems.  It’s confusing and wastes
memory.

QQmlListProperty is flexible about storage, since you get to write
all the accessors, so you can maybe use it just for QML and also
have normal C++ API?


I have some gripes about QQmlListProperty too, maybe not the same ones.

I agree that having a QQmlListProperty in a class supposed to be used
from c++ looks alien.


Even worse, it pulls in a dependency on the QtQml module.


Having it supported in the meta object sure looks enticing at a first
view. Maybe with something like Q_LIST_PROPERTY(ElementType list GET
getFunction COUNT countFunction ...).
That ends up being quite like a simplified QAIM without the roles and
the signals.


Exactly, where to draw the line between simple properties of collections 
and full-blown models?


Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Interest] [Qt3D] Mixing C++ and QML

[Sean Harmer]

Hi,

On 19/10/2017 19:44, Shawn Rutledge wrote:

(thread started on the interest list, but I don’t think my comments
belong there)

On Oct 19, 2017, at 18:06, Sean Harmer <sean.har...@kdab.com> wrote:


Hi,

you've hit one of the issues we did with exposing C++ and QML APIs.
Namely, QQmlListProperty. This thing should ideally never have
existed and instead support for properties of collections should
have been added to QObject and the metaobject system.


What exactly do you think should be done there, in case we can fix it
some day?


Probably something like how NSObject manages properties of collections. 
So far with Qt3D we've only needed the same level of semantics as 
offered by QQmlListProperty - or rather we've worked within those 
constraints. So a simple indexed container with the ability to 
add/remove items.


In a more general setting I can easily also imagine support for 
associative containers too.


The tricky part will be deciding which semantics do we wish to support 
and where do we draw the line between such properties and recommending 
to use a full-blown model instead.


Speaking of which, improving QAIM to be able to return data for 
contiguous blocks of indices in one function call would be a really 
welcome addition. Calling so many virtuals to retrieve a single data 
value for a single index and role is not exactly efficient. The existing 
QAIM API is fine for the existing views but doesn't scale well when 
trying to use them to populate, say a buffer of per instance data on a 
large scale. Yes I know we could avoid this with custom API but users 
have so many models at this point it would be nice to offer some 
interoperability with them.




QObjects are normally managed as a tree for memory management
purposes, so I’ve also long disliked the fact that it doesn’t quite
match the nesting of the Item declarations in QML, because of the
separate QList childItems.  It’s confusing and wastes
memory.


We avoided that in Qt 3D and just use the regular parent-child 
relationship. We don't have separation between visual parent and QObject 
parent.



QQmlListProperty is flexible about storage, since you get to write
all the accessors, so you can maybe use it just for QML and also have
normal C++ API?


That's what we did. The C++ API has addComponent(), removeComponent(), 
componentCount() type functions, and then we have libraries sat on top 
for each aspect that add in the QQmlListProperty handling via extension 
objects. For e.g.


http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3drender


A typical pattern in QtQuick is that a QQmlListProperty is the
default property, so declared children are automatically added.  But
instead you have to declare the Components first, and then also add
them to a vector.  Why is that?  It seems needlessly cumbersome to
me.  If Components are naturally always children of Entities,


^ that is your broken assumption. Components do not have to be children 
of the entity. We actually started out with that but found that it 
prohibits sharing components which can sometimes be handy.


then it

ought to be enough to declare them inside an Entity.  But it seems
that any QNode can have any number of QNode children, so maybe you
could have a QQmlListPropery as the default property, whose
implementation uses the QObject children, just for convenience in
QML?


Also whilst I'm here, there's an annoying limitation in the QML language 
that prevents mixing inline declaration of elements with elements 
referenced by id in a list property. That is you cannot write something 
like:


Mesh { id: mesh }
Material { id: material }

Entity {
components: [ Transform {}, material, mesh ]
}


If you think there’s something wrong with the normal QObject
parent/child relationship, then there’s another mechanism for
detecting declared QML “children" and doing “something special” with
them.


Do you mean the autoparent callback?

http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3d/qt3dquick_global.cpp#n676

We need this here because it's not enough for us to know that the parent 
is a QObject. We need to know if it's a QNode to be able to add the new 
child to the scene.


One possible future solution we discussed with Lars and Simon for this 
is to make QObjectPrivate::setParent() virtual.


  We use it to make each Window transient for whatever Window or

Item’s window that it was declared inside of, for adding
PointerHandlers to Items, and stuff like that: any case where one
object can be declared inside another, but it’s not quite a
conventional parent/child relationship, for example because the
“parent” and “child” aren’t the same kind of objects.

Either of those mechanisms can keep the syntax nice in QML.


To avoid pulling in a QtQml dependency in the C++ API, we instead
have another layer to add the QML specifics (pretty much entirely
list properties).


Ugh that would indeed be nice to simplify.


In order to create these from c

[Development] Small clarification

[Sean Harmer]

Hi,

I'd just like to point out that my -2 on:

https://codereview.qt-project.org/#/c/204736/

is just a temporary measure whilst I investigate some alternative 
options. It is in no way meant to be obstructionist and has nothing to 
do with the recent abandoning of KDAB patches on gerrit. It's purely 
technical and to prevent accidental approval based on my previous +2 as 
I since thought of some alternatives.


Kind regards,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] std::allocate_shared for QSharedPointer

[Sean Harmer]

Hi Thiago,

On Saturday, 9 September 2017 14:37:00 BST Thiago Macieira wrote:
> On Saturday, 9 September 2017 05:46:49 -03 Sean Harmer wrote:
> > Does anybody have any plans to add such a facility? Or is there some
> > other facility to avoid operator new here for both the QSP and the
> > object itself?
> 
> There are no plans. We don't have allocators anywhere in Qt, so I doubt this
> will ever happen.
> 
> > The QSharedPointers are used in the public API as we can't use
> > std::shared_ptr there. I guess the closest I can get without such a
> > facility is to maintain a pool of QSharedPointers, a pool of the objects
> > and use QSharedPointer::reset() when recycling or just keep the two pools
> > in sync whcih I guess makes sense anyway.
> 
> That won't help:
> 
> inline void reset(T *t)
> { QSharedPointer copy(t); swap(copy); }
> 
> Have you benchmarked and found out that the malloc() for the
> QtSharedPointer::ExternalRefCountData pointer is the culprit?

Yes, vtune shows the line

static_cast(::operator 
new(sizeof(ExternalRefCountWithContiguousData)));

is the bottleneck in this particular test case, qt3d/tests/manual/bigscene-
cpp. I maybe able to reduce the calls to this by a small constant factor but 
I'm not sure yet, need to do some more digging/experimenting. So using a pool 
seemed like a viable approach to reducing this bottleneck.

Granted, this is an extreme stress test (1k QEntities, each with 2 x 
QPropertyAnimations) but it makes a nice one to profile.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] std::allocate_shared for QSharedPointer

[Sean Harmer]

On Saturday, 9 September 2017 11:54:14 BST Giuseppe D'Angelo wrote:
> Il 09/09/2017 10:46, Sean Harmer ha scritto:
> > Does anybody have any plans to add such a facility? Or is there some
> > other facility to avoid operator new here for both the QSP and the
> > object itself?
> 
> Just go ahead and use std::allocate_shared, or is it in public APIs? Any
> such improvement to QSharedPointer at this point is really a waste of time.

The QSharedPointers are used in the public API as we can't use std::shared_ptr 
there. I guess the closest I can get without such a facility is to maintain a 
pool of QSharedPointers, a pool of the objects and use QSharedPointer::reset() 
when recycling or just keep the two pools in sync whcih I guess makes sense 
anyway.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] std::allocate_shared for QSharedPointer

[Sean Harmer]

Hi,

I have a use case where we need to create, use and destroy a relatively 
large number of QSharedPointers rapidly. To avoid the malloc overhead it 
would be nice to be able to use a pool of QSharedPointers.


We have QSharedPointer::create() which is analogous to 
std::make_shared() that allows to reduce creating a QSharedPointer and 
the object it points at to a single memory allocation.


However, this uses operator new internally. I can't see any equivalent 
of std::allocate_shared() which would allow the use of a custom 
allocator for the QSP and object memory allocation.


Does anybody have any plans to add such a facility? Or is there some 
other facility to avoid operator new here for both the QSP and the 
object itself?


Thanks,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Configuring qtbase with --opengl es2 on arm* devices

[Sean Harmer]

Hi,

On Friday, 8 September 2017 15:54:23 BST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> To the best of my knowledge there are almost no arm board with opengl
> desktop support, but there are boards with es2 support.
> 
> Now the question is: is it worth to enable es2 support if there are no
> specific hardware specified? (ie, like vivante or bcrm2) Or maybe
> there are board with benefit by just using -opengl es2?
> 
> I came to this by reading
> https://wiki.qt.io/I.MX-6#i.MX6_support_in_Qt_5.2_and_up
> 
> 
> My main gripe is to understand if distros like Debian should or not
> enable opengl es2 when they don't know in advance on which specific
> boards they will run.
> 
> Any kind of extra info on the subject will be higly appreciated.
> 
> Thanks in advance, Lisandro.

I don't know what you should do but for some data points there are also boards 
that offer OpenGL ES 3/3.1/3.2 and the recent Tegra boards even offer 
"desktop" OpenGL 4. ES2 is likely a sane default minimum. If users want to use 
the sw renderer or ES3/desktop GL they would need to build themselves.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Random CI Failures

[Sean Harmer]

And again today on:

https://codereview.qt-project.org/#/c/194936/

Same configuration type, win8-mingw. Can we remove this from the active set of 
configurations for qt3d until this is resolved please?

Thanks,

Sean

On Saturday, 19 August 2017 19:56:57 BST Sean Harmer wrote:
> On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> > Hi Simon,
> > 
> > On 19/08/2017 11:59, Simon Hausmann wrote:
> > > Hi,
> > > 
> > > We've had file system corruption in our base Windows images for the past
> > > weeks. Yesterday late afternoon I finally managed to get hold of it and
> > > fix it. This may have been the cause of your trouble. Did you still see
> > > failures yesterday evening and today?
> > 
> > Ah thanks that may well explain it. I don't think I've seen it since
> > yesterday lunchtime'ish. So hopefully you've already squashed it. :)
> 
> Spoke too soon. Simon already knows, but for the record, it happened twice
> more today on:
> 
> https://codereview.qt-project.org/#/c/202556/
> 
> then eventually worked. But even on the successful run there is no log file
> recorded.
> 
> Cheers,
> 
> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, 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


-- 
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Random CI Failures

[Sean Harmer]

On Saturday, 19 August 2017 12:57:18 BST Sean Harmer wrote:
> Hi Simon,
> 
> On 19/08/2017 11:59, Simon Hausmann wrote:
> > Hi,
> > 
> > We've had file system corruption in our base Windows images for the past
> > weeks. Yesterday late afternoon I finally managed to get hold of it and
> > fix it. This may have been the cause of your trouble. Did you still see
> > failures yesterday evening and today?
> Ah thanks that may well explain it. I don't think I've seen it since
> yesterday lunchtime'ish. So hopefully you've already squashed it. :)

Spoke too soon. Simon already knows, but for the record, it happened twice 
more today on:

https://codereview.qt-project.org/#/c/202556/

then eventually worked. But even on the successful run there is no log file 
recorded.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Random CI Failures

[Sean Harmer]

Hi Simon,

On 19/08/2017 11:59, Simon Hausmann wrote:

Hi,

We've had file system corruption in our base Windows images for the past weeks. 
Yesterday late afternoon I finally managed to get hold of it and fix it. This 
may have been the cause of your trouble. Did you still see failures yesterday 
evening and today?


Ah thanks that may well explain it. I don't think I've seen it since 
yesterday lunchtime'ish. So hopefully you've already squashed it. :)


Thanks,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Random CI Failures

[Sean Harmer]

Hi,


we seem to be getting a large number of random CI failures when trying 
to integrate Qt 3D changes for the last week or so. It manifests itelf 
as the win8-mingw node failing but no log file is recorded. On the odd 
occasion we get a log file it's like the node just stopped, there's no 
error. This is hitting us around 50% of the time which is making getting 
changees in very frustrating. Could somebody look into what is going on 
please?


Many thanks,

Sean

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

Re: [Development] Qt 5.10 schedule etc

[Sean Harmer]

Hi,

On 08/08/2017 17:56, Allan Sandfeld Jensen wrote:

On Dienstag, 8. August 2017 10:41:02 CEST Jani Heikkinen wrote:

Hi all,

We should have FF & branching today. Unfortunately we are still fighting
with some issues in qt5.git integration in 'dev' . That's why we haven't
been able to start soft branching yet :( But that doesn't mean we will
officially delay the FF ;)

So let's freeze new features for Qt 5.10 today as planned. Please don't put
any new features in for 5.10 anymore. We will start soft branching
immediately when issues with qt5.git integration in' dev' are solved. And
we will finalize branching ~ after a week from that date when soft
branching starts. So there will be still enough time to get changes in
which are currently suffering these issues in dev.


I would suggest allowing features that couldnt get in due to git issues, still
be allowed to integrate once it is fixed. I don't know of anything specific
that has been caught by that though.


+1 and on a related note, I keep hitting:

Project ERROR: Cannot run compiler 
'/home/qt/work/b2qt/toolchain/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++'. 
Maybe you forgot to setup the environment?


when attempting to integrate changes to Qt 3D (for the skeletal 
animation feature).


Could somebody with CI-fu take a look please?

Thanks!

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt3D without Qml/QtQuick?

[Sean Harmer]

Hi,

On 01/08/2017 19:04, Harald Vistnes wrote:

Hi,

is it possible to build the pure C++ subset of Qt3D (Qt3DCore,
Qt3DRender, Qt3DExtras, Qt3DInput, Qt3DLogic) without Qml and QtQuick? I
tried to configure and build Qt with -skip qtdeclarative, but then Qt3D
was skipped completely.


Yeah, at the moment Qt 3D is marked as requiring QtDeclarative but 
indeed there is no reason why that can't be made an optional dependency 
to allow what you need. It should be pretty easy to fix up 
qt3d/src/src.pro. Patches welcome :)


Cheers,

Sean



After building Qt I tried building Qt3D manually by running
qmake qt3d.pro  and jom but with the following error
message:

D:\qt5\qt3d>..\qtbase\bin\qmake.exe qt3d.pro 
Info: creating cache file D:\qt5\qt3d\.qmake.cache

D:\qt5\qt3d>jom

jom 1.1.2 - empower your cores

cd src\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
-o Makefile D:\qt5\qt3d\src\src.pro  ) && c:\jom\jom.exe
-f Makefile
cd core\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
-o Makefile D:\qt5\qt3d\src\core\core.pro  ) &&
c:\jom\jom.exe -f Makefile
Cannot read D:/qt5/qt3d/src/core/qt3dcore-config.pri: No such file or
directory
Project ERROR: Could not find feature qt3d-profile-jobs.
jom: D:\qt5\qt3d\src\Makefile [sub-core-make_first] Error 3
cd doc\ && ( if not exist Makefile D:\qt5\qtbase\bin\qmake.exe
-o Makefile D:\qt5\qt3d\src\doc\doc.pro  ) &&
c:\jom\jom.exe -f Makefile
c:\jom\jom.exe -f Makefile.Release
jom: D:\qt5\qt3d\Makefile [sub-src-make_first] Error 2


I'm on Windows 10, VS2015, latest sources from git, 5.9 branch.

Thanks,
Harald




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


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

Re: [Development] Let's please drop MSVC 2013 for 5.10

[Sean Harmer]

On Friday 16 June 2017 06:57:28 Santtu Ahonen wrote:
> >From: Shawn Rutledge
> >
> >> On 15 Jun 2017, at 16:07, Thiago Macieira 
> >> wrote:
> >> 
> >> We have not one, not two, but THREE integration failures TODAY alone
> >> caused by that compiler failing to meet what we've come to expect from
> >> C++11. This is going to happen again and again.
> >> 
> >> So I'm pleading again: can we drop it? What are the download numbers
> >> for 5.9.0?
> >
> >+1 from me
> 
> Hi all
> 
> We also have paying customers whom may be using MSVC2013 and whom are not on
> this list, thus we need to look at this from business side too. Not ready
> yet to give my vote for dropping it but will get back to this in due time.

They have 5.9 as an LTS now. I'm with Thiago here, and would love us to drop 
MSVC2013. The pain/benefit ratio is not good.

Cheers,

Sean

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

Re: [Development] Examples and Demos in qtdoc

[Sean Harmer]

Hi,

On Wednesday 14 June 2017 13:18:35 Frederik Gladhorn wrote:
> Hi all,
> 
> We recently had a discussion in the Qt Company about how we can improve the
> first use experience of Qt and one important aspect are the examples and
> demos.
> 
> We have a lot of examples that are limited by the Qt module they live in,
> for example not making use of ready made buttons in Qt Quick. To allow
> examples to use any Qt module while keeping the build system clean (no
> cyclic dependencies between modules), I'd like to propose using the qtdoc
> module to gather fresh and beautiful examples.
> 
> We currently have a few bigger examples already that would fit this category
> and plan to invest more into good looking nice and welcoming examples to
> give new Qt users a positive first impression.
> 
> Of course we could create a new repo, but considering that we have an
> existing repo which did contain the demo launcher previously and which is
> ready to be used, I'd propse going with it, while the name is not perfect.
> It's already part of the infrastructure and qt5.git, so this seems like an
> easy way to go forward.

I agree that we need something like this. Ideally we also need support for 
git-lfs or some other mechanism for handling large files. Particularly for Qt 
3D, getting "nice looking" results often requires HDR textures for environment 
maps and often other texture inputs too.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New configuration system docs and FBX issues

[Sean Harmer]

Hi,

On 01/05/2017 07:17, Sean Harmer wrote:

Hi,

is there any documentation for the new configuration system please?

My specific issue is that I need a config test that uses different
library names on each platform and I can't see how to achieve this. On
windows I want the FBX config test in Qt 3D to link against the static
FBX library libfbxsdk-md.lib whereas on linux it would be
libfbxsdk-static.a and on macOS libfbxsdk.a.

An additional complication is that if we're building in debug and
release build, the FBX SDK has the libs for these in different
directories so we can't just rely upon passing the full -L
path/to/fbxsdk/lib/platform/arch/{debug|release} to configure as if we
pass debug we can't find the release lib and vice versa.

If we can solve this then hopefully we can build the FBX plugin as part
of the official build and not have to rely upon users to build it
themselves.

Thanks in advance for any help/pointers.


I've started this but am now stuck (again). Please see:

https://codereview.qt-project.org/#/c/193269/

What I would like is to be able to find the FBX SDK from:

1) Well known locations, or
2) An environment variable, or
3) A location specified as an argument to configure.

I've made a start on 3) but need to evaluate this in the custom test 
function, qtConfLibrary_fbx. 2) is already there to some extent. 1) we 
can pretty easily add a list of places to search as done for some other 
tests.


Where I'm falling down is in trying to construct the path to search for 
the actual libraries. For e.g. with the latest FBX SDK I have paths such as:


1) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x64\debug
2) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x64\release
3) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x86\debug
4) C:\Program Files\Autodesk\FBX\FBX SDK\2018.1.1\lib\vs2015\x86\release

And from the docs it looks similar for other compiler versions and 
platforms.


I've managed to build up the $compiler/$arch part of the path but I 
can't figure out how to handle the debug vs release vs debug-and-release 
parts.


Is this possible to do at configure time or should I rather be doing 
this in a .pri/.pro file where we build the actual plugin?


What is the recommendation for building the config.test, debug or 
release or both?


Sorry if I'm being dumb, I still feel like I'm missing some of the 
though processes/rationale that went into designing the new system and 
I'm having trouble reverse engineering what is or isn't possible and how 
to best go about these things.


Thanks in advance for any help.

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New configuration system docs and FBX issues

[Sean Harmer]

Hi,

On 02/05/2017 09:25, Oswald Buddenhagen wrote:

On Mon, May 01, 2017 at 07:17:23AM +0100, Sean Harmer wrote:

is there any documentation for the new configuration system please?


the "documentation" is the vast amount of configure.json files which
actually use it.


Thanks, but that doesn't make it easy to get an overview of common use 
cases though as you don't know which ones are common without looking 
through many files. I just didn't know if I was missing documentation 
somewhere but it seems not.


It's easy to miss the exact thing you are after when looking through 
like this too. I didn't know I could put a "condition" in a "sources". 
Now I do.



My specific issue is that I need a config test that uses different
library names on each platform and I can't see how to achieve this.


funny, because the very first file one might look into -
qtbase/configure.json - contains two examples of just that right at the
top of the library list (zlib and dbus).
the "next level" is openssl in qtbase/src/network.


Thanks for the tips. I had been looking in qtbase/src/corelib and gui.

Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New configuration system docs and FBX issues

[Sean Harmer]

Hi,

On 01/05/2017 14:16, Thiago Macieira wrote:

On Monday, 1 May 2017 03:17:23 -03 Sean Harmer wrote:

Hi,

is there any documentation for the new configuration system please?

My specific issue is that I need a config test that uses different
library names on each platform and I can't see how to achieve this. On
windows I want the FBX config test in Qt 3D to link against the static
FBX library libfbxsdk-md.lib whereas on linux it would be
libfbxsdk-static.a and on macOS libfbxsdk.a.


Please make sure we're abe to link against the dynamic version of that library
on Linux.


Why the preference for dynamic linking here? It's another file to have 
to distribute? I don't particularly mind either way but is there a 
policy for such things?


Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] New configuration system docs and FBX issues

[Sean Harmer]

Hi,

is there any documentation for the new configuration system please?

My specific issue is that I need a config test that uses different 
library names on each platform and I can't see how to achieve this. On 
windows I want the FBX config test in Qt 3D to link against the static 
FBX library libfbxsdk-md.lib whereas on linux it would be 
libfbxsdk-static.a and on macOS libfbxsdk.a.


An additional complication is that if we're building in debug and 
release build, the FBX SDK has the libs for these in different 
directories so we can't just rely upon passing the full -L 
path/to/fbxsdk/lib/platform/arch/{debug|release} to configure as if we 
pass debug we can't find the release lib and vice versa.


If we can solve this then hopefully we can build the FBX plugin as part 
of the official build and not have to rely upon users to build it 
themselves.


Thanks in advance for any help/pointers.

Sean

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

Re: [Development] [docs] changing the way overloads are documented and presented

[Sean Harmer]

On Friday 28 April 2017 09:35:09 Marc Mutz wrote:
> What do you think?

I like the idea. +1

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qdoc for C++ and QML

[Sean Harmer]

Hi,

On 24/04/2017 14:23, Martin Smith wrote:

Regarding documenting both C++ and QML at the same time, I will be happy to 
implement it if we can get a good idea for how to do it.


Well, take https://codereview.qt-project.org/#/c/192093/ as a case in 
point. The docs for the QML and C++ parts are 80% the same. The only 
difference really is the code samples. So perhaps one option would be to 
allow specifying code blocks and maybe other blocks as being specific to 
C++ or QML. The rest of the containing block could then be the same.


Likewise for \property vs \qmlproperty sections. The only difference is 
a "Q".


When writing the docs perhaps marking up a class name without the "Q" 
prefix could link to the class docs in C++ and the QML type in the QML 
docs. So instead of:


"A QFoo can be used to do blah" in C++ vs
"A Foo can be used to do blah" in QML, we could have something like:

"A \type Foo can be used to do blah" then when generating the C++ docs 
it looks for the QFoo docs.



Regarding the creator issue, I don't understand the problem so I can't comment.


Like when building a C++ project in creator and being told by the 
compiler there are warnings/errors, creator parses these into issues 
that are nicely displayed and when you click on them take you to the 
relevant section of the code.


Cheers,

Sean



martin

From: Development <development-bounces+martin.smith=qt...@qt-project.org> on behalf 
of Sean Harmer <sean.har...@kdab.com>
Sent: Monday, April 24, 2017 3:05:17 PM
To: development@qt-project.org
Subject: [Development] qdoc for C++ and QML

Hi,

are there any plans to reduce/remove the redundancy when writing
documentation for both C++ and QML? Seems a waste of time to have to
copy/paste or update the docs twice for both languages when really the
only things differing are the "Q" prefix on the class names in C++.

On a related note, are there any plans to be able to run make
docs/html_docs/qch_docs etc from within creator and have the issue
reporter plugin parse the output? Being flooded with warnings about
overwriting HTML files on the command line and tryign to spot genuine
issues is not much fun.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


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

Re: [Development] qdoc for C++ and QML

[Sean Harmer]

On 24/04/2017 14:26, Friedemann Kleint wrote:

Hi,

For starters, take a look at the script:

http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/scripts/qdoc2tasks.pl?h=4.3


You can pipe the error output of qdoc through it to convert it to a Qt
Creator task file. Opening it in Qt Creator will show the issues as
build issues (see http://doc.qt.io/qtcreator/creator-task-lists.html )
and you can then click through them.


Thanks, will give it a try!

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] qdoc for C++ and QML

[Sean Harmer]

Hi,

are there any plans to reduce/remove the redundancy when writing 
documentation for both C++ and QML? Seems a waste of time to have to 
copy/paste or update the docs twice for both languages when really the 
only things differing are the "Q" prefix on the class names in C++.


On a related note, are there any plans to be able to run make 
docs/html_docs/qch_docs etc from within creator and have the issue 
reporter plugin parse the output? Being flooded with warnings about 
overwriting HTML files on the command line and tryign to spot genuine 
issues is not much fun.


Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Problem pushing to 5.9 branch

[Sean Harmer]

Ah, never mind. I'm on a new machine and forgot to set something up. 
False alarm.


Sean


On 13/03/2017 21:03, Sean Harmer wrote:

Hi,

is there some problem with gerrit? I don't seem to be able to push to 
the 5.9 branch at the moment.


Thanks,

Sean

___
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] Problem pushing to 5.9 branch

[Sean Harmer]

Hi,

is there some problem with gerrit? I don't seem to be able to push to 
the 5.9 branch at the moment.


Thanks,

Sean

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

Re: [Development] Qt 5.9 API review

[Sean Harmer]

On Tuesday 28 February 2017 10:09:13 Jani Heikkinen wrote:
> Hi all,
> 
> It seems Qt 5.9 API review is still badly ongoing, see

> https://codereview.qt-project.org/184392qt3d

We went through this last week and resulted in:

https://bugreports.qt.io/secure/RapidBoard.jspa?rapidView=48

We're now working through those as best we can. We may need another pass on 
the animation stuff but that's a tech preview for 5.9 so not absolutely 
critical.

Cheers,

Sean

> Please finalize the reviews & do needed fixes as soon as possible so that we
> will be ready for beta early enough.
> 
> br,
> Jani Heikkinen
> Release Manager
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Sean Harmer]

On Friday 17 February 2017 08:10:55 Alex Blasche wrote:
> > [...]
> > 
> > I note that an answer on this is still pending, but as an aside: CI on
> > 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any
> > false failures anymore.
> 
> The CI integration process is only partly to blame. Yes, after each fix
> round there is a new round of qt5 git integrations with more unit test
> fixes followed by a new round of package generation.
> > I do realise that the main load probably comes from qt5.git
> > integrations, but even so, if 5.8 (qtbase) integrations run through the
> > first time instead of requiring half a dozen restages, either the CI
> > load is lowered significantly, helping to avoid flakiness in other
> > tests, or allowing more stuff to be merged per unit time.
> 
> Each of the packages must be tested. We are talking about 17 different types
> of packages. For each package the tester has to install the package and run
> a series of tests. This means you have to have testers for each platform
> and this takes half a day to do.  We are talking about principle testing
> for each feature domain, QtCreator, app install & deployment, completeness
> of the install package etc. it is not a sexy task either as it is very
> mundane.

Some steps of this can be automated with squish or similar but I appreciate 
that may not be the case at the current time.

> This also assumes that each tester has time to do the testing at the same
> time. Whenever the last platform tester finishes that's when you can
> progress to the next step.

And this is one of the areas which KDAB is offering to help with if it gets a 
5.8.1 release out. But we can only do this if the candidate packages are made 
available.

> 5.8.1 is a release with a lot of changes. It would not be a low effort
> release testing. I do not believe that smoke testing is sufficient. At
> least the past .1 have very much proven this fact.

Sure, but 5.9.0 has even more changes and is therefore more of a risk of 
taking longer. Nobody is debating that making a .1 release is not a lot of 
effort. What we are arguing is that making 5.8.1 is more important than 
releasing 5.9.0 a few weeks earlier than if there is a 5.8.1.

As makers of a toolkit there is an implicit promise that there will be timely 
bug fix releases. It seems that The Qt Company has decided otherwise and that 
releasing 5.9.0 before the summer vacations is more important.

At the end of the day, all we, KDAB and other community members, can do is 
point out that your customers may well not see it this way and offer to help. 
But since you control all of the infrastructure there is little else we can do 
about it.

> Yes, there is things we can and want to improve but we are not there yet. I
> also do not believe that making a bad release is helping customers either.

Again, nobody wants a bad release. We're suggesting a different prioritisation 
of releases, not sacrificing on quality for any of them.

Cheers,

Sean

> > Shutting down 5.8 because of load problems in the CI now makes even less
> > sense than before.
> 
> As shown above it is not.
> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Sean Harmer]

On Wednesday 15 February 2017 18:17:32 Thiago Macieira wrote:
> On quarta-feira, 15 de fevereiro de 2017 09:00:09 PST Tuukka Turunen wrote:
> > First I want to say that I am also very sorry that we need to skip 5.8.1.
> > Unfortunately I do not see any other approach that would allow us to: 1)
> > catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6
> > being
> > late) and 2) enable implementation the much needed CI changes in good time
> > before Qt 5.10 feature freeze.
> 
> Here's a way:
> 
> Push the 5.9 and 5.10 timelines back. If necessary, unfreeze Qt 5.9.

Yes this is what I would vote for too. The 5.9 deadline is somewhat 
arbitrary/self imposed so does not have to be set in stone. If this has knock-
on effects for the CI upgrades, why can't these be done during the summer 
break by staggering the sysadmin vacations instead of all of them going off at 
the same time?

With this we could have a timeline something like this:

1) Release 5.8.1 asap. Hopefully this would go smoothly given it's a .1 
release.
2) Push 5.9.0 deadline to end of June but aim for earlier if the config system 
doesn't adversely affect the package generation.
3) Perform CI upgrades as soon as 5.9.0 is out (may require some juggling of 
vacation requests if 5.9.0 goes until end of June.
4) After summer vacation, start release process for 5.9.1 and 5.10.

This also helps mitigate the risk of something delaying the 5.9.0 release by 
getting a .1 release to the users in the interim.

Also, to allow others to help with the release process, could you explain 
where the main bottle neck is with the release process please? Is it the 
package generation itself? The smoke testing? Something else?

KDAB is willing to help where we can if it means we can get a 5.8.1 release in 
the hands of yours and our customers. But to be able to help, we need to know 
how we can.

Kind regards,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Sean Harmer]

On Wednesday 15 February 2017 11:52:50 Shawn Rutledge wrote:
> > On 15 Feb 2017, at 11:11, Marc Mutz <marc.m...@kdab.com> wrote:
> > 
> > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote:
> > 
> >> First of all, apologies for not being able to make the release meeting
> >> yesterday. I was in a workshop all day.
> >> 
> >> For the record I think skipping 5.8.1 is a big mistake. I would much
> >> rather
 delay 5.9 by a few weeks and have a 5.8.1 release out than skip
> >> it and try for a quick 5.9.0.
> > 
> > 
> > Amen.
> > 
> > I would like to add that this decision, made behind closed doors, does not
> > 
 match well with Qt-as-an-open-governance-project. In particular, it
> > feels like we OSS contributors are being held hostage here. If you close
> > the 5.8 CI, anything we can do, incl. following the dictate of TQC to
> > focus on 5.9, will hurt Qt users one way or another. Either we fragment
> > Qt by releasing a 5.8.1 without TQC backing or we leave users hanging in
> > the air for extended periods of time without the ability for bugfixes.
> > Both are unacceptable, IMHO.
> 
> There are a lot of potential bug fixes.  Skipping 5.8.1 might pull some
> users into upgrading to 5.9 sooner than they might otherwise, which is good
> from one side, but the ones who are afraid of new features and new
> regressions will resist.  So I think it’s a mistake because of those
> people… but I always think those people should be less afraid of new
> releases, too.  (Just try it… how bad can it be.  Soon enough you will know
> if there are regressions that affect you.  If so, get patches for them and
> apply them locally.  If there’s no patch, write one and contribute.  That
> helps everyone.)

That assumes users a) have the ability, b) have the time, c) have company 
permission to create such patches. And regressions like this can prevent users 
from upgrading to new feature releases. As a case in point, see

https://bugreports.qt.io/browse/QTBUG-58679
 
> Some Linux distros will pull in some newer patches for their custom 5.8.0
> builds.

Sure, but what about Windows, macOS, Android, iOS, ... ?
 
> FWIW the discussion was on #qt-releases, not exactly behind closed doors.

The initial discussion was announced by Tuukka as the OP of this thread which  
presented it as pretty much a done deal. And, as Marc says, if the Qt Project 
disagrees, what can we do about it without fragmenting?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Sean Harmer]

 be purchasing more blades and other HW during H1/17, which will add
> capacity, so we will be able to run more parallel integrations. We are also
> looking into changing the system architecture away from central disk into
> using local ssd for build machines. This is expected to bring improvements
> to both performance and reliability (especially now as we have had issues
> with disks failing despite the disk system still being in the mid of its
> life-cycle). Third item we are looking into is change of the virtualization
> platform, which we hope will bring improvements in stability as well as new
> capabilities.
 
> Arranging enough time to implement the improvements in our systems as well
> as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately
> means that we can’t make any scheduled patch releases until June, after Qt
> 5.9 is out. We will keep the ability to release patch release for urgent
> security vulnerabilities, as always. Such release would be on top of the
> previous patch release and not include all other changes in the
> corresponding branch. Even with a lot more help from community than before,
> making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the
> system load as well as to the work needed from the release team and
> others.
 
> I am well aware that a Qt 5.8.1 release would be beneficial, but making one
> now would impact Qt 5.9 schedule and our capability to improve CI system
> stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9
> release, but not before. After the Qt 5.9.0 in May we should then focus
> into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt
> 5.9.0 is already out. With the CI improvements in place, we should
> definitely be able to make more than one patch release for Qt 5.9.
 
> As a scheduled Qt 5.8.1 release is not planned, should we start pushing
> fixes directly to 5.9 branch now? It would reduce the workload as we do not
> need to first integrate changes into 5.8 and then merge upwards to 5.9. It
> would also reduce the time it takes to get fixes into to 5.9 and dev as
> well as reduce the load to the CI system as less integrations are needed.
> We can keep 5.8 branch open for a while still similarly as 5.6 is in case
> there is some fix that must be in the 5.8 branch. Let’s discuss in the next
> release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9
> branch directly would be good approach.
 
> Yours,
> 
> Tuukka
> 
> 
> 
> 
> 

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominate Mike Krus as approver

[Sean Harmer]

On Monday 06 February 2017 14:54:53 Alex Blasche wrote:
> >There were no objections and maintainer of a module implies approver, so
> >could somebody do the honours and grant Mike the rights please? The
> >necessary period has long since passed.
> 
> I am sorry but being the maintainer does not imply approver rights. At most
> it implies approver rights for the component he is maintainer for. I agree
> that when you maintain a cross module component that this is somewhat
> harder to manage.
> 
> In any case I am sure that waiting for the required time does not make much
> of a difference. Then this discussion is over anyway.

My misunderstanding then. No problem to wait now of course.

Cheers,

Sean

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

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominate Mike Krus as approver

[Sean Harmer]

Hi,

in fact, I've just been reminded we already proposed and voted for Mike as 
maintainer of the tvOS system last year:

http://lists.qt-project.org/pipermail/development/2016-August/026903.html

There were no objections and maintainer of a module implies approver, so could 
somebody do the honours and grant Mike the rights please? The necessary period 
has long since passed.

Thanks,

Sean

On Monday 06 February 2017 12:26:03 Sean Harmer wrote:
> Hi,
> 
> I'd like to nominate Mike Krus as an approver. Mike contributed support for
> Qt on tvOS along with the refactoring that went in as part of this. Mike
> has done a lot of work within Qt 3D too.
> 
> Disclaimer: Mike is a colleague at KDAB.
> 
> Cheers,
> 
> Sean

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Nominate Mike Krus as approver

[Sean Harmer]

Hi,

I'd like to nominate Mike Krus as an approver. Mike contributed support for Qt 
on tvOS along with the refactoring that went in as part of this. Mike has done 
a lot of work within Qt 3D too.

Disclaimer: Mike is a colleague at KDAB.

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] GPL tooling in Qt module?

[Sean Harmer]

On Wednesday 01 February 2017 09:37:41 Thiago Macieira wrote:
> Em quarta-feira, 1 de fevereiro de 2017, às 17:01:36 PST, Sean Harmer
> 
> escreveu:
> > As such addons need to run within the blender runtime which is GPL, the
> > addon also needs to be GPL licensed.
> 
> If there's a process separation, then Blender's licence does not impact on
> the selection of the licence of the parent code.
> 
> If I understand you correctly, you have code that is a plugin to Blender.
> That plugin does not need to be licenced as GPL either, but since it is
> loaded into Blender, it needs to be GPL-compatible and the program+plugin
> combination, when run, will be under the GPL too.
> 
> As such, I don't see any need to provide any GPL-only code into a Qt
> repository at all.

Thanks, I somehow skipped over the words "compliant with" in the blender FAQ. 
So LGPL/MIT etc looks to be fine.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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

[Development] GPL tooling in Qt module?

[Sean Harmer]

Hi,

as part of the current animation support in Qt3D we've written an addon for 
blender that is able to export all the animation clips in a blender file to a 
format that Qt 3D can use (json based).

As such addons need to run within the blender runtime which is GPL, the addon 
also needs to be GPL licensed. Which is fine. The only question is, is it OK to 
add such a tool (python script) to the Qt 3D repo? It's not used within Qt 3D 
itself at all.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Branch request for Qt 3D

[Sean Harmer]

On Monday 30 January 2017 13:45:49 Frederik Gladhorn wrote:
> On torsdag 26. januar 2017 14.11.33 CET Sean Harmer wrote:
> > Hi,
> > 
> > Could somebody create me a new wip/physics branch for the Qt 3D branched
> > off of dev please? This is to start preparing a physics aspect hopefully
> > for Qt 5.10.
> 
> Looks like this has been done, the branch is there.

Yes, thanks. Ossi did it on Friday.

Cheers,

Sean

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

[Development] Policy for examples with large resources?

[Sean Harmer]

Hi,

we're adding in support for Physics Based Rendering to Qt 3D for much nicer 
rendering results. To make this look good we need resources (environment maps) 
that are large, typically many megabytes. See for e.g. 
https://codereview.qt-project.org/#/c/183721/

Obviously putting these directly in the qt3d repo is not ideal yet we need 
examples to demonstrate this stuff (and more in the future). Is there a way we 
can get a git-lfs repo set up as a submodule to be referenced by the qt3d 
repo?

Or is there some other solution that would be preferred?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Branch request for Qt 3D

[Sean Harmer]

Hi,

Could somebody create me a new wip/physics branch for the Qt 3D branched off 
of dev please? This is to start preparing a physics aspect hopefully for Qt 
5.10.

The existing wip/animation and wip/qtquickintegration branches should be going 
away shortly to keep things under control.

Thanks in advance,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Texture image loading library

[Sean Harmer]

On Saturday 21 January 2017 13:51:15 André Pönitz wrote:
> On Sat, Jan 21, 2017 at 10:51:11AM +0000, Sean Harmer wrote:
> > On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> > > 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
> > > > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> > > >>  Nonetheless, since such loaders would be useful in more than one
> > > >>  place
> > > >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them
> > > >>  would
> > > >>  be a new private library in qtimageformats.
> > > > 
> > > > you can't put it there if qtbase is to use it.
> > > > 
> > > > the central "regular" image loaders are in qtgui, and the "elementary"
> > > > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > > > seems quite plausible to put the texture loaders there as well.
> > > 
> > > FWIW not everyone is happy by fact that QtGui is bloated with OpenGL
> > > code
> > > and pulls in OpenGL libraries into application adress space with itself.
> > 
> > Well that decision was made prior to Qt 5.0 being released.
> 
> I think it's about time to stop using the existence of decisions that were
> made around the 5.0 release as part of a technical discussion.

I'm not. I'm pointing out that this technical decision has nothing to do with 
the one to put OpenGL dependent related features in QtGui.

> 2012 was a very special year for Qt development, in a very special
> environment, leading to very special decisions, some of which already at
> that time were made knowing that they are only acceptable in this context.

Well, some of us don't have visibility of what decisions were made, the 
reasoning behind them and what issues were identified, as that took place 
behind closed doors.

> Yes, there might still be real consequences for Qt development today, e.g.
> due to the independently existing compatibility promises, which, might
> make it impossible to disentangle Qt Gui and OpenGL, leading to the same
> conclusion. But then *this* argument should be used.

For the record I have no problem with removing the OpenGL dependency from 
QtGui in the future. It's possible now to compile with it stripped out but of 
course that's an all or nothing approach. I don't see how we could rectify 
this in the Qt5 life time. Anyway, that's not what this thread is about. It's 
about being able to parse texture files into CPU addressable memory. From there 
it can be used by OpenGL, Direct3D, Vulkan, Metal, $OTHER_API.

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] Texture image loading library

[Sean Harmer]

On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>:
> > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> >>  Nonetheless, since such loaders would be useful in more than one place
> >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them would
> >>  be a new private library in qtimageformats.
> > 
> > you can't put it there if qtbase is to use it.
> > 
> > the central "regular" image loaders are in qtgui, and the "elementary"
> > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > seems quite plausible to put the texture loaders there as well.
> 
> FWIW not everyone is happy by fact that QtGui is bloated with OpenGL code
> and pulls in OpenGL libraries into application adress space with itself.

Well that decision was made prior to Qt 5.0 being released. This doesn't 
change that or add any OpenGL specific code. It's just about parsing a file 
format and finding somewhere common to do that so that Qt Quick and Qt 3D don't 
have to duplicate code.

Cheers,

Sean

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

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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

[Development] Coding convention for private includes

[Sean Harmer]

Hi,

Just a query about the coding convention around inclusion of private headers 
as specified at:

https://wiki.qt.io/Coding_Conventions#Including_headers

It states:

If you need to include private headers, be careful. Use the following syntax, 
irrespective of which module or directory whatever_p.h is in.

 #include 

The issue is that this could lead to collisions. Is it OK to use:

 #include 

?

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] State of dev branch in CI

[Sean Harmer]

Hi,

seems something is still not happy in CI land.

https://codereview.qt-project.org/#/c/181832/

Could someone take a look please?

Thanks,

Sean

On 10/01/2017 13:06, Sean Harmer wrote:

Thanks to all involved in resolving this!

Sean

On Tuesday 10 January 2017 12:45:17 Simon Hausmann wrote:

Hi,


As a heads-up to everyone: Tony's changes are in effect now and staging of
changes that target the dev branch for modules outside of qtbase should
work again.



Simon


From: Tony Sarajärvi
Sent: Tuesday, January 10, 2017 12:31:10 PM
To: Simon Hausmann; development@qt-project.org
Subject: RE: [Development] State of dev branch in CI

Hi,

Sounds good to me. I’ll proceed with that.
Funny that the only platform we’ve managed to get in during the last half a
year or year is immediately causing problems so that we have to remove it
;)

-Tony

From: Development
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf
Of Simon Hausmann Sent: Tuesday, January 10, 2017 12:43 PM
To: development@qt-project.org
Subject: Re: [Development] State of dev branch in CI


Hi,



I just had another chat with Liang about this situation. We can't get a
newer qtbase into qt5.git because tests in declarative fail, some of it
also due to a newer qtbase (and the qurl changes). So the path we would
propose is



(1) The CI team reverts the addition of RHEL 7.2 to the dev branch that
brought us here.

(2) We either get fixes or blacklist-additions into the corresponding
modules, WHILE the rest of development of modules in Qt outside qtbase with
the dev branch can resume.

(3) RHEL 7.2 is re-added to the CI when it passes tests.



We need agreement and help from the CI team to do that.



Simon


From: Development
<development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development
-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Simon Hausmann
<simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> Sent: Tuesday, January
10, 2017 10:49:29 AM
To: Sean Harmer;
development@qt-project.org<mailto:development@qt-project.org> Subject: Re:
[Development] State of dev branch in CI


Hi,



as far as I can tell this is not resolved yet. It appears that the macOS
10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed
up.





Simon


From: Development
<development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development
-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Sean Harmer
<sean.har...@kdab.com<mailto:sean.har...@kdab.com>> Sent: Tuesday, January
10, 2017 10:45:07 AM
To: development@qt-project.org<mailto:development@qt-project.org>
Subject: Re: [Development] State of dev branch in CI

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:

Hi,


Brief "update": dev is still blocked.


The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to
be due to the removal of macOS 10.9 support, while the CI still builds
with 10.9.


We can't bring qt5.git up-to-date with a newer qtbase that includes the
pcre fix, because the macOS 10.9 drop
(a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre
fix.


A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of
the 10.9 drop until the CI "supports" it was rejected.


So either

(a) the temporary reversal gets approved instead of rejected. Then
over

the remaining weekend we could try to get a qt5.git update through with
the
pcre fix to unblock dev.


or

(b) the CI removes 10.9 support and moves the features the 10.9 tests

(namespace, etc.) over to another macOS build. Then we could get a qt5.git
update through that includes the pcre fix.


Differently put, there are two things blocking Qt dev branch development

outside of qtbase:
(1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or

alternatively RHEL 7.2 temporary reversal in the CI.

(2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to

proceed) or CI changes as mentioned in (b).




Simon


From: Development
<development-bounces+simon.hausmann=qt...@qt-project.org<mailto:developme
nt-bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Simon
Hausmann <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> Sent:
Thursday, January 5, 2017 8:50:52 PM
To: development
Subject: [Development] State of dev branch in CI


Hi,

I wanted to give a quick update on the state of the dev branch in the CI:

Currently any changes to any module outside of qtbase targeting the dev
branch will fail to pass the build stage in the CI.

Recently RHEL 7.2 was added to dev. When that was tested - back in fall
last year - all was fine. Then some configure options of qtbase were
changed (-qt-pcre became -q

Re: [Development] State of dev branch in CI

[Sean Harmer]

Thanks to all involved in resolving this!

Sean

On Tuesday 10 January 2017 12:45:17 Simon Hausmann wrote:
> Hi,
> 
> 
> As a heads-up to everyone: Tony's changes are in effect now and staging of
> changes that target the dev branch for modules outside of qtbase should
> work again.
> 
> 
> 
> Simon
> 
> 
> From: Tony Sarajärvi
> Sent: Tuesday, January 10, 2017 12:31:10 PM
> To: Simon Hausmann; development@qt-project.org
> Subject: RE: [Development] State of dev branch in CI
> 
> Hi,
> 
> Sounds good to me. I’ll proceed with that.
> Funny that the only platform we’ve managed to get in during the last half a
> year or year is immediately causing problems so that we have to remove it
> ;)
> 
> -Tony
> 
> From: Development
> [mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] On Behalf
> Of Simon Hausmann Sent: Tuesday, January 10, 2017 12:43 PM
> To: development@qt-project.org
> Subject: Re: [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> 
> 
> I just had another chat with Liang about this situation. We can't get a
> newer qtbase into qt5.git because tests in declarative fail, some of it
> also due to a newer qtbase (and the qurl changes). So the path we would
> propose is
> 
> 
> 
> (1) The CI team reverts the addition of RHEL 7.2 to the dev branch that
> brought us here.
> 
> (2) We either get fixes or blacklist-additions into the corresponding
> modules, WHILE the rest of development of modules in Qt outside qtbase with
> the dev branch can resume.
> 
> (3) RHEL 7.2 is re-added to the CI when it passes tests.
> 
> 
> 
> We need agreement and help from the CI team to do that.
> 
> 
> 
> Simon
> 
> 
> From: Development
> <development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development
> -bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Simon Hausmann
> <simon.hausm...@qt.io<mailto:simon.hausm...@qt.io>> Sent: Tuesday, January
> 10, 2017 10:49:29 AM
> To: Sean Harmer;
> development@qt-project.org<mailto:development@qt-project.org> Subject: Re:
> [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> 
> 
> as far as I can tell this is not resolved yet. It appears that the macOS
> 10.9 replacement with 10.10 happened, but a test failure on RHEL 7.2 showed
> up.
> 
> 
> 
> 
> 
> Simon
> 
> 
> From: Development
> <development-bounces+simon.hausmann=qt...@qt-project.org<mailto:development
> -bounces+simon.hausmann=qt...@qt-project.org>> on behalf of Sean Harmer
> <sean.har...@kdab.com<mailto:sean.har...@kdab.com>> Sent: Tuesday, January
> 10, 2017 10:45:07 AM
> To: development@qt-project.org<mailto:development@qt-project.org>
> Subject: Re: [Development] State of dev branch in CI
> 
> Hi Simon,
> 
> is this resolved yet?
> 
> Cheers,
> 
> Sean
> 
> On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> > Hi,
> > 
> > 
> > Brief "update": dev is still blocked.
> > 
> > 
> > The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to
> > be due to the removal of macOS 10.9 support, while the CI still builds
> > with 10.9.
> > 
> > 
> > We can't bring qt5.git up-to-date with a newer qtbase that includes the
> > pcre fix, because the macOS 10.9 drop
> > (a670f063909689dc6c03c9090fff25c6f531d2b2) landed right before the pcre
> > fix.
> > 
> > 
> > A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of
> > the 10.9 drop until the CI "supports" it was rejected.
> > 
> > 
> > So either
> > 
> > (a) the temporary reversal gets approved instead of rejected. Then
> > over
> > 
> > the remaining weekend we could try to get a qt5.git update through with
> > the
> > pcre fix to unblock dev.
> > 
> > 
> > or
> > 
> > (b) the CI removes 10.9 support and moves the features the 10.9 tests
> > 
> > (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> > update through that includes the pcre fix.
> > 
> > 
> > Differently put, there are two things blocking Qt dev branch development
> > 
> > outside of qtbase:
> > (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> > 
> > alternatively RHEL 7.2 temporary reversal in the CI.
> > 
> > (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> > 
> &g

Re: [Development] State of dev branch in CI

[Sean Harmer]

Hi Simon,

is this resolved yet?

Cheers,

Sean

On Saturday 07 January 2017 10:18:22 Simon Hausmann wrote:
> Hi,
> 
> 
> Brief "update": dev is still blocked.
> 
> 
> The build issue of https://bugreports.qt.io/browse/QTBUG-57935 appears to be
> due to the removal of macOS 10.9 support, while the CI still builds with
> 10.9.
> 
> 
> We can't bring qt5.git up-to-date with a newer qtbase that includes the pcre
> fix, because the macOS 10.9 drop (a670f063909689dc6c03c9090fff25c6f531d2b2)
> landed right before the pcre fix.
> 
> 
> A temporary reversal in https://codereview.qt-project.org/#/c/181578/ of the
> 10.9 drop until the CI "supports" it was rejected.
> 
> 
> So either
> 
> 
> (a) the temporary reversal gets approved instead of rejected. Then over
> the remaining weekend we could try to get a qt5.git update through with the
> pcre fix to unblock dev.
> 
> 
> or
> 
> 
> (b) the CI removes 10.9 support and moves the features the 10.9 tests
> (namespace, etc.) over to another macOS build. Then we could get a qt5.git
> update through that includes the pcre fix.
> 
> 
> Differently put, there are two things blocking Qt dev branch development
> outside of qtbase:
> 
> 
> (1) Propagation of the -qt-pcre fix from qtbase to qt5.git, or
> alternatively RHEL 7.2 temporary reversal in the CI.
> 
> 
> (2) Temporary reversal of the macOS 10.9 drop (that would allow (1) to
> proceed) or CI changes as mentioned in (b).
> 
> 
> 
> 
> Simon
> 
> 
> From: Development <development-bounces+simon.hausmann=qt...@qt-project.org>
> on behalf of Simon Hausmann <simon.hausm...@qt.io> Sent: Thursday, January
> 5, 2017 8:50:52 PM
> To: development
> Subject: [Development] State of dev branch in CI
> 
> 
> Hi,
> 
> I wanted to give a quick update on the state of the dev branch in the CI:
> 
> Currently any changes to any module outside of qtbase targeting the dev
> branch will fail to pass the build stage in the CI.
> 
> Recently RHEL 7.2 was added to dev. When that was tested - back in fall last
> year - all was fine. Then some configure options of qtbase were changed
> (-qt-pcre became -qt-pcre2), which are only passed with RHEL 7.2 (longer
> story but basically because of our binary packages). Earlier this week the
> change in the CI to add RHEL 7.2 to dev was taken into production and
> immediately broke the build of all modules in dev because -qt-pcre was not
> a valid configure parameter anymore and without qtbase nothing else builds.
> As a consequence the CI changes were reverted.
> 
> Meanwhile the qtbase configure parameters were fixed and support for
> -qt-pcre was restored. Today the CI changes were taken in again and qtbase
> in the dev branch compiles on RHEL 7.2.
> 
> Unfortunately all other modules are built against qtbase from qt5.git, which
> doesn't understand -qt-pcre yet (wants pcre2). Therefore all modules other
> than qtbase are broken in dev.
> 
> An update of qt5.git with a newer qtbase is scheduled, but unfortunately it
> won't go through because of https://bugreports.qt.io/browse/QTBUG-57935 .
> 
> There are different options for solving this. One would be to revert the CI
> change. Another would be to fix the above bug and get the qt5 change
> through.
> 
> 
> The right solution to prevent these types of situations in the future is to
> have these platform configs inside qt5.git, not in the CI. Unfortunately
> that is not a priority yet.
> 
> 
> 
> Simon

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Jira action buttons

[Sean Harmer]

On 09/01/2017 08:21, Alexander Blasche wrote:

Hi,


-Original Message-
From: Development [mailto:development-
bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Samuel Gaist
Sent: Sunday, 8 January 2017 23:44



Is there any rule/filter that are applied on the bug reports related to the 
actions
made available ?

For example:

https://bugreports.qt.io/browse/QTBUG-57991: I have  Edit, Comment, Assign,
More

https://bugreports.qt.io/browse/QTBUG-57996 : Same as above plus Not
enough info, Accept, Close

I wanted to close https://bugreports.qt.io/browse/QTBUG-57993 as a duplicate
of https://bugreports.qt.io/browse/QTBUG-57992 but I can’t do it currently
because for both of them I only get the reduced set of buttons.


This is a bug. Nobody had any state transition options for this task. Jira ran 
out of disk space last week. Maybe this has caused the problem. In any case, I 
have recovered the work flow state and marked QTBUG-57993 as duplicate of 
QTBUG-57992.


Hi Alex,

could you do the same for

https://bugreports.qt.io/browse/QTBUG-55824

and

https://bugreports.qt.io/browse/QTBUG-55825

please? I only have a reduced set of actions available.

Thanks,

Sean



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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

[Sean Harmer]

On Tuesday 20 December 2016 15:14:17 Sean Harmer wrote:
> Hi Tuukka,
> 
> I agree with your proposal, however I think there is also another issue or
> two that we should address.

Except that instead of calling it RC1 why not call it another beta? The RC 
should be something that *may* be suitable for release. But at present we get 
the RC too late so it gets difficult to get fixes for issues accepted. Sure we 
might need a new RC after that but calling the initial packages after the 
release branch is branched an RC seems like a misnomer.

Cheers,

Sean

> 
> At present we have ~ 4 releases per year 2 minor versions and 2 further
> patch releases. One issue is that it looks like 5.8.0 will soon render the
> very new 5.7.1 release redundant. With that in mind was it worth splitting
> the effort and having the 5.7.1 release at all? Don't get me wrong I'm all
> for additional patch releases just that I'd hope they wouldn't coincide so
> closely with a minor version release.
> 
> This brings me onto another issue which perhaps we feel more strongly than
> average in Qt 3D as a new module that is undergoing rapid bug-fixing,
> improvements and with lots of new feature development starting to open up.
> For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of
> effort, we still fixed a huge number of issues for 5.7.1, which took 181
> days to release from 5.7.0.
> 
> Would it be possible for us to release more frequent patch releases? If not
> for the whole of Qt, then at least for addon modules such as Qt 3D? The
> latter would require splitting the packaging of such modules but would
> reduce the amount of overall testing required for a new patch release. If
> we'd collectively rather not go down that street I still think more
> frequent patch releases would be nice. Users have the option of upgrading
> or not if they want to reduce their own internal regression testing burden
> and freeze on a specific version. But it would have the benefit that other
> users don't need to wait 6 months for a set of bug fixes - roughly the same
> time to wait as for new features.
> 
> I wonder how much of the current pressure on releases is driven by the time-
> based release policy. We aim for a new minor release every 6 months which
> is admirable. But I wonder about the consequences of trying to stick to
> that at the expense of quality of the 5.x.0 releases, especially given the
> long turn around for subsequent patch releases.
> 
> With the above in mind, how about this proposal in addition to yours
> regarding the RC phase?
> 
> * Branch off new feature branch every 6 months as at present.
> 
> * Do not rush the release at the expense of quality or when it's convenient
> due to packagers going on vacation etc. We release only when the release is
> deemed to meet quality standards.
> 
> * Aim for a patch release every alternate month if there are fixes on the
> minor version branch and packaging/release staff are available. i.e. don't
> try to force one out before the summer/Xmas vacations.
> 
> * Consider releasing at least one patch release of the previous minor series
> after the release of the next minor series' .0 release. For example, in the
> current situation, potentially release a 5.7.2 after 5.8.0. (We already
> have fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7
> branch if there were to be a 5.7.2 release).
> 
> Additionally, is there any way that contributors outside of The Qt Company
> can assist with the practicalities of packaging?
> 
> Just some food for thought.
> 
> Cheers,
> 
> Sean
> 
> On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote:
> > Hi,
> > 
> > I think we have three major problems with our current release process
> > regarding the release candidate phase:
> > 
> > 1.   Process to make a RC that is as flawless as final causes
> > inefficiency as we only get full test coverage with the RC itself
> > 
> > 2.   We get full attention for testing a bit too late, many fixes are
> > still coming in close to the planned RC time causing instability
> > 
> > 3.   Current time between RC and final is planned to be 2 weeks, which
> > is very little in order to take in the feedback and fix things
> > 
> > Therefore, I would like to propose the following:
> > 
> > a.   Consider "Release Candidate" to be a phase rather than an
> > individual delivery
> > 
> > b.   Create the first "RC1" almost immediately after release branch
> > (e.g. 5.9.0) is operational
> > 
> > c.   Criteria for the "RC1" is that no known P0 bugs exist (i.e. there
> > can be other issues that would not 

Re: [Development] Proposal to adjust release candidate process

[Sean Harmer]

; about considering the "RC1" the beginning of the final releasing phase (.0
> branch), not something we do almost at the end of it. I believe that
> lowering the quality criterial for "RC1" helps us in being more efficient
> as it has been in practice impossible to really fulfill the current process
> goal and have already the first RC as good as the final.
> 
> In case of Qt 5.9 it would mean that we have the first "RC" out around end
> of April, soon after the branching to 5.9.0 has been completed. We then
> have 4 or so weeks to make all the needed amount of candidates / snapshots
> until one of them will be released as Qt 5.9.0 final. If it happens earlier
> than in 4 weeks, great. If it takes more time, then so be it (although in
> such case we have probably missed something in the earlier steps of the
> release creation).
> 
> Yours,
> 
> ---
> Tuukka Turunen
> Director, R
> 
> The Qt Company
> Lutakonaukio 1
> 40100 Jyväskylä, Finland
> tuukka.turu...@qt.io
> +358 40 7655 800
> http://qt.io
> ---

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Retargeting Requests: 5.8 -> 5.8.0

[Sean Harmer]

Hi Ossi/Friedeman,

could you retarget the following to the 5.8.0 branch please?

Thanks in advance!

https://codereview.qt-project.org/#/c/170339/
https://codereview.qt-project.org/#/c/170431/
https://codereview.qt-project.org/#/c/170432/
https://codereview.qt-project.org/#/c/170433/
https://codereview.qt-project.org/#/c/170434/
https://codereview.qt-project.org/#/c/170439/
https://codereview.qt-project.org/#/c/170440/
https://codereview.qt-project.org/#/c/170441/
https://codereview.qt-project.org/#/c/170442/
https://codereview.qt-project.org/#/c/170443/
https://codereview.qt-project.org/#/c/170444/
https://codereview.qt-project.org/#/c/170445/
https://codereview.qt-project.org/#/c/170493/
https://codereview.qt-project.org/#/c/170494/
https://codereview.qt-project.org/#/c/170495/
https://codereview.qt-project.org/#/c/170496/
https://codereview.qt-project.org/#/c/170578/
https://codereview.qt-project.org/#/c/170579/
https://codereview.qt-project.org/#/c/170580/
https://codereview.qt-project.org/#/c/170581/
https://codereview.qt-project.org/#/c/170621/
https://codereview.qt-project.org/#/c/170622/
https://codereview.qt-project.org/#/c/170623/
https://codereview.qt-project.org/#/c/170690/
https://codereview.qt-project.org/#/c/170691/
https://codereview.qt-project.org/#/c/170692/
https://codereview.qt-project.org/#/c/170693/
https://codereview.qt-project.org/#/c/170694/
https://codereview.qt-project.org/#/c/172659/
https://codereview.qt-project.org/#/c/172660/
https://codereview.qt-project.org/#/c/172661/
https://codereview.qt-project.org/#/c/172662/
https://codereview.qt-project.org/#/c/172663/
https://codereview.qt-project.org/#/c/172664/
https://codereview.qt-project.org/#/c/172665/
https://codereview.qt-project.org/#/c/172666/
https://codereview.qt-project.org/#/c/172666/
https://codereview.qt-project.org/#/c/173077/
https://codereview.qt-project.org/#/c/173078/
https://codereview.qt-project.org/#/c/173079/
https://codereview.qt-project.org/#/c/173167/
https://codereview.qt-project.org/#/c/178047/
https://codereview.qt-project.org/#/c/177976/
https://codereview.qt-project.org/#/c/177977/
https://codereview.qt-project.org/#/c/177978/
https://codereview.qt-project.org/#/c/177979/

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Very slow incremental builds with 5.8

[Sean Harmer]

On Friday 25 November 2016 09:36:19 Mitch Curtis wrote:
> > -Original Message-
> > From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> > project.org] On Behalf Of Sean Harmer
> > Sent: Friday, 25 November 2016 10:16 AM
> > To: development@qt-project.org
> > Subject: [Development] Very slow incremental builds with 5.8
> > 
> > Hi all,
> > 
> > what is the reason that when doing incremental builds with the 5.8 branch
> > that qmake gets run in each and every subdir please? It *really* slows
> > down
> > doing incremental builds. Is there any way to avoid this or can we go back
> > to the
> > 5.7 behaviour please?
> 
> I had a similar problem with Creator:
> https://bugreports.qt.io/browse/QTCREATORBUG-16807
> 
> Apparently it's better (or fixed?) in 4.2, but I haven't tested it properly
> yet.

Thanks. I'm using he work around of removing the call to qmake in the build 
settings and manually running qmake when necessary for now.

Building Qt 5.7 modules in creator doesn't suffer from this problem so 
something must have changed in qmake or related files that triggered this 
behaviour in creator.

Cheers,

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

[Development] Very slow incremental builds with 5.8

[Sean Harmer]

Hi all,

what is the reason that when doing incremental builds with the 5.8 branch that 
qmake gets run in each and every subdir please? It *really* slows down doing 
incremental builds. Is there any way to avoid this or can we go back to the 
5.7 behaviour please?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Antti Määttä as Qt3D approver

[Sean Harmer]

On Monday 14 November 2016 15:15:16 Paul Lemire wrote:
> Hi
> 
> I would like to propose the nomination of Antti Määttä for approver status.
> Antti has been contributing many patches to Qt3D adding new features and
> providing bug fixes. In addition, having another approver would be a great
> help to reduce the amount of time patches are spent awaiting a review.

+1 from me.

Cheers,

Sean

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

Re: [Development] [Releasing] Qt 5.8.0 API review

[Sean Harmer]

On Monday 14 November 2016 10:34:38 Sean Harmer wrote:
> On Monday 14 November 2016 09:37:21 Lars Knoll wrote:
> > Hi,
> > 
> > I went through all modules now, and added my comments. Mainly small
> > issues,
> > with the exception of Qt 3D, where I see some real BC breakages.
> > 
> > Sean, could you please look at
> > https://codereview.qt-project.org/#/c/170642/ asap.
> 
> I'm just back from vacation today. Paul is taking a look now.

Fixes in 

https://codereview.qt-project.org/#/c/176569/
https://codereview.qt-project.org/#/c/176570/

are integrating...

Cheers,

Sean

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

Re: [Development] [Releasing] Qt 5.8.0 API review

[Sean Harmer]

On Monday 14 November 2016 09:37:21 Lars Knoll wrote:
> Hi,
> 
> I went through all modules now, and added my comments. Mainly small issues,
> with the exception of Qt 3D, where I see some real BC breakages.
> 
> Sean, could you please look at https://codereview.qt-project.org/#/c/170642/
> asap.

I'm just back from vacation today. Paul is taking a look now.

Cheers,

Sean

> 
> Thanks,
> Lars
> 
> On 14/11/16 09:44, "Jani Heikkinen" <jani.heikki...@qt.io> wrote:
> 
> Hi all,
> 
> It seems this is still badly ongoing, only few '+1' and only one '+2'
> there :(
> 
> Please try to finalize the review during this week: We need to have
> reviews done & possible changes in '5.8' before we can start branching from
> '5.8' to '5.8.0'
> 
> br,
> Jani
> 
> 
> From: Edward Welbourne
> Sent: Monday, November 7, 2016 4:57 PM
> To: releas...@qt-project.org
> Cc: Jani Heikkinen; Sune Vuorela; development@qt-project.org
> Subject: Re: [Releasing] Qt 5.8.0 API review
> 
> With the 5.8.0 release now close at hand, I've updated the API reviews:
> 
> https://codereview.qt-project.org/170634 - qtbase
> https://codereview.qt-project.org/170635 - qtdeclarative
> https://codereview.qt-project.org/170636 - qtactiveqt
> https://codereview.qt-project.org/170637 - qtmultimedia
> https://codereview.qt-project.org/170640 - qtconnectivity
> https://codereview.qt-project.org/170641 - qtwayland
> https://codereview.qt-project.org/170642 - qt3d
> https://codereview.qt-project.org/170643 - qtserialbus
> https://codereview.qt-project.org/170644 - qtserialport
> https://codereview.qt-project.org/170645 - qtandroidextras
> https://codereview.qt-project.org/170646 - qtwebsockets
> https://codereview.qt-project.org/170647 - qtwebengine
> https://codereview.qt-project.org/170648 - qtcanvas3d
> https://codereview.qt-project.org/170649 - qtcharts
> https://codereview.qt-project.org/170650 - qtdatavis3d
> https://codereview.qt-project.org/170652 - qtscxml
> https://codereview.qt-project.org/176059 - qtquickcontrols2
> 
> Note that, although Gerrit thinks of these as proposals to change 5.8,
> they are actually commits based on tag v5.7.0 showing what's changed in
> 5.8's API, with lots of boring bits filtered out.
> 
> It would be nice if some of these did in fact get reviewed ...
> 
> Eddy.
> ___
> 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

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Distributing 3rd party closed source libs

[Sean Harmer]

Hi,

On 05/11/2016 02:34, Kevin Kofler wrote:

Sean Harmer wrote:

Yeah, trouble with that approach is we are always chasing feature
support and we'd rather focus efforts elsewhere.


And just running Blender's Python FBX converter
(https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX)
as is and then working with the Blender format is not an option?


No, the whole point is to have support for a format that is efficient at 
runtime. Blender's format is designed for allowing editing, not runtime 
efficiency. Also as I mentioned before we would always be lacking full 
support. In an ideal world the format would be open and documented. But 
it isn't, and the reality is that users want to use this format. We have 
some support via assimp but like Blender's importer it is incomplete.




As a Fedora packager, I can say that the proprietary FBX SDK will never be
in Fedora, so either you use the Blender code or Qt 3D will not be built
with FBX support in Fedora, no matter how you ship it.


That's your prerogative of course but if we ship the source or have a 
plugin that dlopen's the fbx libs then Fedora users still have the 
option to use this format if they wish, they just won't be able to do it 
via your package manager.


(And if you ship part

of the SDK in the Qt 3D source tarball, we will really hate you because it
would force us to respin your tarball with the proprietary code/binaries
removed. So please don't do that, ever.)


Nobody is suggesting bundling the FBX SDK at all. In fact it's not 
allowed by the Autodesk licensing terms.


Cheers,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Distributing 3rd party closed source libs

[Sean Harmer]

Hi Lars,

On 31/10/2016 09:22, Lars Knoll wrote:



On 31/10/16 10:08, "Development on behalf of Sean Harmer" 
<development-bounces+lars.knoll=qt...@qt-project.org on behalf of sean.har...@kdab.com> 
wrote:


Hi,

On 31/10/2016 00:48, Chris Gilbert wrote:

Greetings,

We use both QT5 and the Autodesk FBX loader in our application - and we
would strongly prefer Qt to NOT link it in.

There is a need quite often for us to update the Autodesk FBX SDK
asymmetrically to QT, and it would be preferable QT doesn't use it in
order to avoid potential conflicts.

Also, I believe there is a provision in the Autodesk FBX library which
forbids inclusion in free/open source software.
(Anti-blender provision)

As a result, I believe Blender and some other applications (UE4) have
done their own implementation, perhaps QT could borrow from that?


Yeah, trouble with that approach is we are always chasing feature
support and we'd rather focus efforts elsewhere. The options look like:

* Provide a precompiled plugin like Qt does for the mysql/postgres
database driver plugins but which requires the user to install the fbx
dll's.

* Source only plugin to allow users to easily build it against the fbx sdk.

* dlopen the fbx lib from a plugin.

We do not intend to ship the fbx sdk or compile it in or link it
directly to Qt for the reasons you mention.


We’re facing the same problem in a couple of places in Qt. For postgres/mysql 
we provide a precompiles plugin, but don’t ship the client libs which has 
proven to be problematic, as users wonder why it doesn’t work, or because of BC 
issues on Windows.

Other SQL plugins such as Oracle or DB2 are only reachable through compiling 
the source code. Unfortunately we don’t make that easy currently, as these 
plugins are shipped as part of qtbase, not as a standalone package.

It might make sense to rethink this, and provide those plugins as standalone 
source packages, that can be easily compiled within creator by our users. That 
would of probably also require that they live in a repository separate from 
qtbase (for SQL) or qt3d (in your case).


I like that idea. We could add those repos as source only options to the 
Qt SDK installer to make it easy for end user developers.


To this end, could somebody create us a qt3d-plugins git repo and gerrit 
project please?


Many thanks,

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

Re: [Development] Distributing 3rd party closed source libs

[Sean Harmer]

Hi,

On 31/10/2016 00:48, Chris Gilbert wrote:

Greetings,

We use both QT5 and the Autodesk FBX loader in our application - and we
would strongly prefer Qt to NOT link it in.

There is a need quite often for us to update the Autodesk FBX SDK
asymmetrically to QT, and it would be preferable QT doesn't use it in
order to avoid potential conflicts.

Also, I believe there is a provision in the Autodesk FBX library which
forbids inclusion in free/open source software.
(Anti-blender provision)

As a result, I believe Blender and some other applications (UE4) have
done their own implementation, perhaps QT could borrow from that?


Yeah, trouble with that approach is we are always chasing feature 
support and we'd rather focus efforts elsewhere. The options look like:


* Provide a precompiled plugin like Qt does for the mysql/postgres 
database driver plugins but which requires the user to install the fbx 
dll's.


* Source only plugin to allow users to easily build it against the fbx sdk.

* dlopen the fbx lib from a plugin.

We do not intend to ship the fbx sdk or compile it in or link it 
directly to Qt for the reasons you mention.


Cheers,

Sean

ps Thanks for the Lys tool. Really useful and I use it a lot. :)



Thanks,
Chris Gilbert
Knald Technologies, LLC

On 10/30/2016 10:11 AM, Thiago Macieira wrote:

On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote:

I guess this is similar to the database driver plugins.

Right.

We ship the compiled plugins for both MySQL and PostgreSQL, but not their
libraries, so the plugins can't be loaded unless the user installs the
required client libraries (and in the case of MySQL, since they change
the
soname often, it's a difficult proposal).

We do not ship compiled plugins for the proprietary databases, like OCI,
Interbase and TDS. People who want one of those can download the
sources and
compile themselves. That's just the plugin, no need to recompile all
of Qt.

With my OSS hat on, I would say we shouldn't ship even a non-working
binary.
People who want it should download the source for the module and compile
themselves. It is, after all, just a qmake && make.



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


--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Distributing 3rd party closed source libs

[Sean Harmer]

Hi,

a very common request is for Qt 3D to support the Autodesk FBX file 
format which is a pretty standard format for exchanging 3D meshes, and 
animations. Unfortunately the format is undocumented and proprietary but 
Autodesk does provide a free (as in beer) SDK that can be used to parse 
FBX files.


Guillermo and Mauro have been making the QMesh geometry loading 
component plugin based to help support more formats. One of the formats 
we'd like to support is FBX. For developers building from git, this is 
manageable, although not ideal, by downloading the fbx sdk and pointing 
the build at it.


What can we do in terms of pre-compiled release builds of Qt? Is it 
feasible for us to distribute the runtime lib required by the plugin 
from the fbx SDK? Or do we need to find some other solution such as 
build the plugin for the release packages but require the user to 
install the fbx SDK?


I guess this is similar to the database driver plugins.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OpenGL Issues in Qt5.7

[Sean Harmer]

And now Gunnar has just pointed out there is work in this area: :)

https://codereview.qt-project.org/#/c/166202/

Cheers,

Sean

On 26/10/2016 08:54, Sean Harmer wrote:

Hi,

On 26/10/2016 08:21, Kai Koehne wrote:

-Original Message-
From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
Sent: Wednesday, October 26, 2016 7:09 AM
To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
<liang...@qt.io>; Kai Koehne <kai.koe...@qt.io>; development@qt-
project.org
Subject: RE: OpenGL Issues in Qt5.7



Spread to Qt mail-list to ask for help.



From: Liu, Jeff (SRDC SW)
Sent: Tuesday, October 25, 2016 2:26 PM
To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 
'liang...@qt.io';

'kai.koe...@qt.io'
Subject: OpenGL Issues in Qt5.7



Hi Sletta, Qi and Koehne,

Hi Jeff!

This is Jeff from AMD, recently a customer reports a game issue with 
AMD
cards, but the game runs well on Nvidia card, after some debug, I 
find out
that the issues are caused by Qt libraries, when Qt programs with 
OpenGL
API, it doesn’t follow the OpenGL programming specification 
strictly, so it will

report errors on AMD platform.

Now we find out the two following issues, both issues come from Qt 
paint

engine.

1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
Qt5Guid.dll

I submit a ticket to address this issue, and this issue is assigned 
to Sletta, but
it seems no one starts to work on it, the usage of 
glVertexAttribArray API is
wrong, it is still used in the old way (OpenGL 3.0), but it 
apparently violate the

latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.


As commented on the bug, this QOpenGL2PaintEngine is only meant for 
use with a 2.x OpenGL context. The paint engine will not work properly 
with a Core Profile context. All the shaders are also legacy 
(attribute + varying vs in + out).




2.   I don’t submit the ticket for the second issue yet,  Qt 
paint engine uses

GL_RED to upload the texture, so based on the spec, the texture will be
(GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, 
which is a
constant 0 value in AMD platform, if changed to src * mask.r, then 
everything

will be correct, I will submit a ticket to address it later.

Feel free to report this, too.


Again, this would really require a new OpenGL paint engine for modern 
OpenGL to be written. Afaik nobody is working on this or even looking 
into it. Using Qt Quick 2 would be an easier path if it suits your use 
case. I'd love to have the ability to composite widget painting with 
modern GL so if you want to work on such a thing then please do feel 
free to do so.


Cheers,

Sean


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


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

Re: [Development] OpenGL Issues in Qt5.7

[Sean Harmer]

Hi,

On 26/10/2016 08:21, Kai Koehne wrote:

-Original Message-
From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
Sent: Wednesday, October 26, 2016 7:09 AM
To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
; Kai Koehne ; development@qt-
project.org
Subject: RE: OpenGL Issues in Qt5.7



Spread to Qt mail-list to ask for help.



From: Liu, Jeff (SRDC SW)
Sent: Tuesday, October 25, 2016 2:26 PM
To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io';
'kai.koe...@qt.io'
Subject: OpenGL Issues in Qt5.7



Hi Sletta, Qi and Koehne,

Hi Jeff!


This is Jeff from AMD, recently a customer reports a game issue with AMD
cards, but the game runs well on Nvidia card, after some debug, I find out
that the issues are caused by Qt libraries, when Qt programs with OpenGL
API, it doesn’t follow the OpenGL programming specification strictly, so it will
report errors on AMD platform.

Now we find out the two following issues, both issues come from Qt paint
engine.

1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
Qt5Guid.dll

I submit a ticket to address this issue, and this issue is assigned to Sletta, 
but
it seems no one starts to work on it, the usage of glVertexAttribArray API is
wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate 
the
latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.


As commented on the bug, this QOpenGL2PaintEngine is only meant for use 
with a 2.x OpenGL context. The paint engine will not work properly with 
a Core Profile context. All the shaders are also legacy (attribute + 
varying vs in + out).





2.   I don’t submit the ticket for the second issue yet,  Qt paint engine 
uses
GL_RED to upload the texture, so based on the spec, the texture will be
(GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a
constant 0 value in AMD platform, if changed to src * mask.r, then everything
will be correct, I will submit a ticket to address it later.

Feel free to report this, too.


Again, this would really require a new OpenGL paint engine for modern 
OpenGL to be written. Afaik nobody is working on this or even looking 
into it. Using Qt Quick 2 would be an easier path if it suits your use 
case. I'd love to have the ability to composite widget painting with 
modern GL so if you want to work on such a thing then please do feel 
free to do so.


Cheers,

Sean


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

Re: [Development] macOS CI node segfault

[Sean Harmer]

On 10/10/2016 09:14, Jedrzej Nowacki wrote:

As Thiago said. Moc is crashing on OSX for an unknown reason. It is
unlikely to be RAM problem,  because we would see much wider
distribution of crashes (related bug report:
https://bugreports.qt.io/browse/QTQAINFRA-990).


Argh, sorry I indeed misread the segfault error. It is moc, not the 
compilation of moc's output as I thought.



Regarding overwriting logs, it is Coin bug. For some reason we naively
believed that builds are deterministic and there is only one build log
100 % reproducible...  Well something to fix.


Is there a JIRA for this or should I file one?

Cheers,

Sean




Cheers,

  Jędrek


*From:* Development
<development-bounces+jedrzej.nowacki=qt...@qt-project.org> on behalf of
Sean Harmer <s...@theharmers.co.uk>
*Sent:* Sunday, October 9, 2016 9:51:47 AM
*To:* development@qt-project.org
*Subject:* Re: [Development] macOS CI node segfault

Hi Thiago,

On 08/10/2016 21:52, Thiago Macieira wrote:

Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu:

Hi,

Just seen another segfault on one of the mac mini CI nodes:

http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498
b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel
ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz


Where? That log file does not contain the word "segfault", "error" or the
phrase "segmentation fault".


Something very wrong is going on then. Look at the failed run at Oct 8
2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is
where I copied the link from. The report on gerrit says segmentation
fault, as did the report when I checked it at the time, yet now indeed
the report has no mention of a segfault at all.

Sounds like something overwrote the compile report which is a little
concerning.



That said, we've known moc has been crashing on Mac for a couple of months and
we have no idea what's causing it.


This was a segfault in the compiler when building
.moc/release/moc_qrenderaspect.cpp rather than when running moc but I am
suspicious of some bad RAM or something on the hardware.

Cheers,

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

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

Re: [Development] macOS CI node segfault

[Sean Harmer]

On 10/10/2016 15:25, Sérgio Martins wrote:

On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira
<thiago.macie...@intel.com> wrote:

That said, we've known moc has been crashing on Mac for a couple of months and
we have no idea what's causing it.


I recently hit a moc crash when compiling KHTML, then replaced moc
with a script that called "valgrind moc $@", gave the report to
olivier and he fixed it immediately.
Is it possible to trigger a manual build on macOS node and try until
it crashes ?


I suspect hw here as it was the compiler, not moc, which crashed in this 
case.


But that's a good idea to try in general in case there is a moc specific 
issue too.


Cheers,

Sean




Regards,
Sérgio Martins
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] macOS CI node segfault

[Sean Harmer]

Hi Thiago,

On 08/10/2016 21:52, Thiago Macieira wrote:

Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu:

Hi,

Just seen another segfault on one of the mac mini CI nodes:

http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498
b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel
ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz


Where? That log file does not contain the word "segfault", "error" or the
phrase "segmentation fault".


Something very wrong is going on then. Look at the failed run at Oct 8 
2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is 
where I copied the link from. The report on gerrit says segmentation 
fault, as did the report when I checked it at the time, yet now indeed 
the report has no mention of a segfault at all.


Sounds like something overwrote the compile report which is a little 
concerning.




That said, we've known moc has been crashing on Mac for a couple of months and
we have no idea what's causing it.


This was a segfault in the compiler when building 
.moc/release/moc_qrenderaspect.cpp rather than when running moc but I am 
suspicious of some bad RAM or something on the hardware.


Cheers,

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

[Development] macOS CI node segfault

[Sean Harmer]

Hi,

Just seen another segfault on one of the mac mini CI nodes:

http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz

Cheers,

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

Re: [Development] Qt 3D WIP branches

[Sean Harmer]

Many thanks to whoever created the branches.

Cheers,

Sean

On Friday 30 September 2016 11:46:39 Sean Harmer wrote:
> Hi,
> 
> Without knowing the internals of COIN, is it a problem for CI load if we
> request some WIP branches for upcoming major Qt 3D features? The
> branches we would like are for features that will take many commits to
> mature and involve many people so local branches are not enough and we
> don't know if they will mature in time for 5.9 so dev is not ideal
> either as then we may have to strip a ton of stuff out.
> 
> The branches we would like created are:
> 
> * wip-animation - for key frame animation support
> * wip-quickintegration - for providing support to render and interact
> with Qt Quick 2 elements in a 3D scene
> * wip-particles - for a new particle system in Qt 3D
> 
> There will be others needed later but these are the pressing ones.
> 
> if this is OK, then is this email sufficient to get it rolling or do I
> need to file a JIRA too?
> 
> Thanks in advance,
> 
> Sean

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Retargeting requests

[Sean Harmer]

Hi Ossi (or anybody else with rights),

could you retarget the following commits to the 5.7.1 branch please?

https://codereview.qt-project.org/#/c/169378/
https://codereview.qt-project.org/#/c/169386/
https://codereview.qt-project.org/#/c/169392/
https://codereview.qt-project.org/#/c/172623/
https://codereview.qt-project.org/#/c/172624/
https://codereview.qt-project.org/#/c/172625/

Thanks in advance!

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] scaling the background of QGraphicsView or QGraphicsScene

[Sean Harmer]

Hi,

use a cosmetic pen (width of zero).

Cheers,

Sean

On 02/10/2016 02:18, 心翔 wrote:

Hi，
I subclass the QGraphicsView to
reimplement drawBackground and wheelEvent  and want to get  this effect：


but when I wheel the mouse， the background point will scale also。

​
how can implement that it only scale t/he spacing between points but not
the point itself，like this:/
/
/
/
​
/
/
/
/the code:/

voidSchView::wheelEvent(QWheelEvent*event)

{

qrealscaleFactor=(pow((double)2,event->delta()/240.0));


qrealfactor=transform().scale(scaleFactor,scaleFactor).mapRect(QRectF(0,0,1,1)).width();


if(factor<0.07||factor>100)

return;


scale(scaleFactor,scaleFactor);

}


voidSchView::drawBackground(QPainter*painter,constQRectF)

{

intgridSize=20;

QPenpen(QColor(Qt::white));

painter->setPen(pen);


qrealleft=int(rect.left())-(int(rect.left())%gridSize);

qrealtop=int(rect.top())-(int(rect.top())%gridSize);


QVarLengthArray<QPointF,800>points;

for(qrealx=left;x<rect.right();x+=gridSize){

for(qrealy=top;y<rect.bottom();y+=gridSize){

points.append(QPointF(x,y));

}

}

painter->drawPoints(points.data(),points.size());

}




/
/
/Any suggestions are greatly appreciated./
/thanks/
/
/
/
/
/
/

itviewer
/
/


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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Managing branches of Qt's git modules

[Sean Harmer]

On 30/09/2016 11:57, Marc Mutz wrote:

On Friday 30 September 2016 12:39:20 Sean Harmer wrote:

Hi,

just a query as to how people do bulk checkouts of different branches
when working with the Qt git modules. It would be nice to be able to use
git submodule foreach ... but this is a problem because not all modules
use the same branching scheme.

So, what do people do to checkout all interesting modules to 5.7, 5.8,
dev etc on Unix like systems and on Windows?

On *nix systems I've been getting away with a simple bash for loop. But
on windows I find this painful but maybe that's just my unfamiliarity
with windows batch scripts.


to speed up fetching:

  git submdule foreach "git fetch --all &"

for everything else there's the repo tool, though I have not gotten around
to checking it out, since most of my work is in qtbase.

  git checkout 
  git submodule update --rebase


Thanks! Somehow I'd missed knowing about the --rebase option.


doesn't do what you want?


Looks like it should.

Thanks,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt 3D WIP branches

[Sean Harmer]

Hi,

Without knowing the internals of COIN, is it a problem for CI load if we 
request some WIP branches for upcoming major Qt 3D features? The 
branches we would like are for features that will take many commits to 
mature and involve many people so local branches are not enough and we 
don't know if they will mature in time for 5.9 so dev is not ideal 
either as then we may have to strip a ton of stuff out.


The branches we would like created are:

* wip-animation - for key frame animation support
* wip-quickintegration - for providing support to render and interact 
with Qt Quick 2 elements in a 3D scene

* wip-particles - for a new particle system in Qt 3D

There will be others needed later but these are the pressing ones.

if this is OK, then is this email sufficient to get it rolling or do I 
need to file a JIRA too?


Thanks in advance,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Managing branches of Qt's git modules

[Sean Harmer]

Hi,

just a query as to how people do bulk checkouts of different branches 
when working with the Qt git modules. It would be nice to be able to use 
git submodule foreach ... but this is a problem because not all modules 
use the same branching scheme.


So, what do people do to checkout all interesting modules to 5.7, 5.8, 
dev etc on Unix like systems and on Windows?


On *nix systems I've been getting away with a simple bash for loop. But 
on windows I find this painful but maybe that's just my unfamiliarity 
with windows batch scripts.


Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Maintainers: your action needed: Qt 5.6.2 change files mostly missing!

[Sean Harmer]

Hi,

Qt 3D doesn’t need one for 5.6.2.

Cheers,

Sean

> On 12 Sep 2016, at 06:45, Jani Heikkinen  wrote:
> 
> Hi all,
> 
> It seems most of change files for Qt 5.6.2 is still missing from packages :( 
> Here are the links for open changes:
> 
> qt3d:https://codereview.qt-project.org/#/c/170367/ 
> 
> qtandroidextras: https://codereview.qt-project.org/#/c/170387/3 
> 
> qtbase: https://codereview.qt-project.org/#/c/170370/ 
> qtcanvas3d: 
> https://codereview.qt-project.org/#/c/170369/ 
> 
> qtconnectivity: https://codereview.qt-project.org/#/c/170389/ 
> 
> qtlocation: https://codereview.qt-project.org/#/c/170413/ 
> qtmultimedia: 
> https://codereview.qt-project.org/#/c/170406/ 
> 
> qtsensors: https://codereview.qt-project.org/#/c/170379/ 
> qtserialport:https://codereview.qt-project.org/#/c/170373/
>  
> qtwayland: https://codereview.qt-project.org/#/c/170414/ 
> qtwebengine: 
> https://codereview.qt-project.org/#/c/170310/ 
> 
> qtwebview: https://codereview.qt-project.org/#/c/170378/ 
> 
> 
>  
> Maintainers, please make sure you finalize these & get it approved today (or 
> comment if one isn't needed in 5.6.2). These are now delaying our Qt 5.6.2 
> release! It seems mandatory fixes are in, we just need to get these change 
> files in and final packages created. Then we should be ready for the 
> release...
> 
> br,
> Jani
> 
> 
> 
> From: Jani Heikkinen
> Sent: Wednesday, September 7, 2016 3:27 PM
> To: development@qt-project.org
> Subject: Maintainers: your action needed
>  
> Hi all (maintainers),
> 
> We in the release team did initial versions of change files for Qt 5.6.2 
> release (to those modules where it was missing). Please take those over & 
> finalize those as soon as possible; We are planning to release Qt 5.6.2 
> already during next week. Changes are pushed to gerrit as WIP so please just 
> add/modify content, get the change approved & we will then stage those in.
> 
> br,
> Jani
> 
> Jani Heikkinen
> Release Manager
> 
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikki...@qt.io
> +358 50 4873735
> http://qt.io 
> 
>  
>      
>   
>  
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

Re: [Development] Proposing Mike Krus as tvOS maintainer

[Sean Harmer]

On Tuesday 30 August 2016 13:51:04 Tor Arne Vestbø wrote:
> Hi all!
> 
> Mike Krus was so kind to contribute support for Apple's tvOS to the
> UIKit platforms, and I'd like to make it official that he's the tvOS
> maintainer.

+1

Disclaimer: I'm a colleague of Mike's at KDAB

Sean

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [QML] Avoiding graphics flicker in Quick2

[Sean Harmer]

I suggested to use an OpenGL example, not a Qt Quick one. We're trying to 
isolate where the issue is in the stack. So use a single threaded, plain 
OpenGL application with a 32 bit framebuffer and see if that gives the same 
issue.

Cheers,

Sean

On Friday 05 August 2016 14:22:00 Denis Shienkov wrote:
> So, I have compiled the standard Samehame QMML application from:
> 
> /home/builder/Projects/qt5/qtdeclarative/examples/quick/demos/samegame/
> 
> and got same artifacts when I use RDBA= mode.
> 
> I have "screenshoot" of this flicking attifact:
> http://pasteboard.co/4XjMl3GNq.png
> 
> I'm personally don't think that this is an NVidia's OpenGL ES2 bug... I
> think it is Qt bug...
> 
> I'm not an OpenGL expert... so, can anybody point me what I need to do with
> the Qt sources (where to look in)?
> 
> Maybe I need to add some of gl_ functions to clear of content or something
> else... but where?
> 
> 2016-08-05 12:03 GMT+03:00 Sean Harmer <sean.har...@kdab.com>:
> > On Friday 05 August 2016 12:02:10 Denis Shienkov wrote:
> > > > Can you try a plain OpenGL test application with RGBA8 framebuffer
> > > 
> > > Do you mean: I should take any OpenGL application from the Qt examples?
> > 
> > And
> > 
> > > to check there?
> > 
> > You may need to modify it to explicitly request R8G8B8A8 using a
> > QSurfaceFormat but yes any of those should work to prove/disprove.
> > 
> > Sean
> > 
> > > 2016-08-05 11:53 GMT+03:00 Sean Harmer <sean.har...@kdab.com>:
> > > > Hi,
> > > > 
> > > > Can you try a plain OpenGL test application with RGBA8 framebuffer and
> > 
> > see
> > 
> > > > if
> > > > that exhibits the same flashing/flickering problem. If so, it's a
> > > > driver/hardware issue.
> > > > 
> > > > If you are forced into then using a 16-bit framebuffer, then you can
> > 
> > avoid
> > 
> > > > the
> > > > banding by using dithering in your gradients. Either apply the
> > 
> > dithering
> > 
> > > > offline
> > > > and store the gradients as images or write a custom material that
> > 
> > applies
> > 
> > > > the
> > > > dithering in the fragment shader.
> > > > 
> > > > Cheers,
> > > > 
> > > > Sean
> > > > 
> > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote:
> > > > > Hi all,
> > > > > 
> > > > > I have an idea how to avoid flickering, but I don't know about
> > 
> > results:
> > > > > what if I will discard the Open GL support in favor to Quick2
> > > > > render?
> > > > > 
> > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/
> > > > > which says about the "Qt Quick 2D Renderer" module.
> > > > > 
> > > > > So, my things is:
> > > > > 
> > > > > 1. Download && build && install  this module:
> > > > > 
> > > > > git://code.qt.io/qt/qtdeclarative-render2d.git
> > > > > 
> > > > > 2. Use this env variable:
> > > > > 
> > > > > export QMLSCENE_DEVICE=softwarecontext
> > > > > 
> > > > > 3. Run my app...
> > > > > 
> > > > > 
> > > > > But, I  don't understand:
> > > > > 
> > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS
> > 
> > only?
> > 
> > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can
> > > > > keep the "-opengl es2" option) ?
> > > > > 
> > > > > 04.08.2016 16:10, Denis Shienkov пишет:
> > > > > > Hi Robin,
> > > > > > 
> > > > > > > Repeating my last answer...
> > > > > > > http://lists.qt-project.org/pipermail/development/2016-> >
> > > > 
> > > > July/026736.html
> > > > 
> > > > > > I'm sorry, but I did not receive (did not see) your last answer.
> > > > > > 
> > > > > > > I'm going to guess you're using eglfs or something like that
> > > > > > 
> > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used
> > > > > > NVIDIA's drivers.
> > > > > &g

Re: [Development] [QML] Avoiding graphics flicker in Quick2

[Sean Harmer]

On Friday 05 August 2016 12:02:10 Denis Shienkov wrote:
> > Can you try a plain OpenGL test application with RGBA8 framebuffer
> 
> Do you mean: I should take any OpenGL application from the Qt examples? And
> to check there?

You may need to modify it to explicitly request R8G8B8A8 using a 
QSurfaceFormat but yes any of those should work to prove/disprove.

Sean

> 
> 2016-08-05 11:53 GMT+03:00 Sean Harmer <sean.har...@kdab.com>:
> > Hi,
> > 
> > Can you try a plain OpenGL test application with RGBA8 framebuffer and see
> > if
> > that exhibits the same flashing/flickering problem. If so, it's a
> > driver/hardware issue.
> > 
> > If you are forced into then using a 16-bit framebuffer, then you can avoid
> > the
> > banding by using dithering in your gradients. Either apply the dithering
> > offline
> > and store the gradients as images or write a custom material that applies
> > the
> > dithering in the fragment shader.
> > 
> > Cheers,
> > 
> > Sean
> > 
> > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote:
> > > Hi all,
> > > 
> > > I have an idea how to avoid flickering, but I don't know about results:
> > > what if I will discard the Open GL support in favor to Quick2 render?
> > > 
> > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/
> > > which says about the "Qt Quick 2D Renderer" module.
> > > 
> > > So, my things is:
> > > 
> > > 1. Download && build && install  this module:
> > > 
> > > git://code.qt.io/qt/qtdeclarative-render2d.git
> > > 
> > > 2. Use this env variable:
> > > 
> > > export QMLSCENE_DEVICE=softwarecontext
> > > 
> > > 3. Run my app...
> > > 
> > > 
> > > But, I  don't understand:
> > > 
> > > 1) What of engine is used to 2D rendering in case if I have EGLFS only?
> > > 
> > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can
> > > keep the "-opengl es2" option) ?
> > > 
> > > 04.08.2016 16:10, Denis Shienkov пишет:
> > > > Hi Robin,
> > > > 
> > > > > Repeating my last answer...
> > > > > http://lists.qt-project.org/pipermail/development/2016-> > 
> > July/026736.html
> > 
> > > > I'm sorry, but I did not receive (did not see) your last answer.
> > > > 
> > > > > I'm going to guess you're using eglfs or something like that
> > > > 
> > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used
> > > > NVIDIA's drivers.
> > > > 
> > > > Seems, the flickering is when are used:
> > > > 
> > > > export QT_QPA_EGLFS_FORCE888=1
> > > > 
> > > > ENV variable... (I need this variable to smooth the Image's
> > > > gradients... even X11 started with 24-bit depth).
> > > > 
> > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :(
> > > > 
> > > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw)
> > > > 
> > > > could be handy for trying to rule
> > > > this out, as if it is specific to the application,
> > > > 
> > > > Ok, many thanks, I will try it.
> > > > 
> > > > 
> > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell <robin...@viroteck.net
> > > > 
> > > > <mailto:robin...@viroteck.net>>:
> > > > Repeating my last answer...
> > > > 
> > > > http://lists.qt-project.org/pipermail/development/2016-> > 
> > July/026736.htm
> > 
> > > > l
> > > > 
> > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote:
> > > > > {quote}
> > > > > 
> > > > > Hi all.
> > > > > 
> > > > > I have some QML application, where just use QQuickView as QML
> > > > 
> > > > container.
> > > > 
> > > > > This application uses Qt 5.7.x and running on Linux embedded
> > > > 
> > > > board with
> > > > 
> > > > > the
> > > > > NVIDIA core (Toradex Apalis T30).
> > > > > 
> > > > > But sometimes I got flickering in process of animation. A
> > 
> > flickering
> > 
>

Re: [Development] [QML] Avoiding graphics flicker in Quick2

[Sean Harmer]

 > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use
> > > another
> > > tricks?
> > > 
> > > BR,
> > > Denis
> > 
> > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-> 
> > > qml.html> 
> > > {quote}
> > > 
> > > This flickering present on some HDMI displays...
> > > 
> > > We currently have this flags:
> > > 
> > > {code}
> > > ...
> > > view.setFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint);
> > > ...
> > > {code}
> > > 
> > > Maybe is it an reasons of flikering? Has someone any ideas?
> > > 
> > > BR,
> > > Denis
> > > ___
> > > Development mailing list
> > > Development@qt-project.org <mailto:Development@qt-project.org>
> > > http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Charts poor dynamic/resolution with OpenGL

[Sean Harmer]

On 19/07/2016 18:26, jeandet wrote:

Hi All,

We are developing in my lab a scientific data plot/analysis software
using Qt Charts module. In order to plot quite large data-sets
(XYSeries) we enabled OpenGL which produce unexpected behavior. The
plots values are grouped by X values see here:
https://ao.lpp.polytechnique.fr/s/T2HcZDtrdL0DcDi
passwd:
-Plot0 with OpenGL
-Plot1 without OpenGL

We found that it was due to float conversion with OpenGL, as far as I
know we can't safely use doubles with OpenGL since not al GPU/drivers
support it(and it increase version requirement). So for now it really
limits plots quality since float has a 23+1 bits mantissa so +/-8M
relative dynamic.

For example data with X values representing seconds since epoch(1970)
would have to store:
(2016-1970)*365*24*60*60 = 1450656000 seconds ~2^31
This indeed doesn't fit in 23 bits, to store it in a float you will
need to truncate it and you would get something close to 3 minutes
resolution.
Here is a tool to see what append.
http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html

It will also fail with  non uniform X values, packets of data with a
small dX spaced by bigger dX. For example 8kSps time series grouped in
packets of 1000 points with few minutes between each packets would
fail.

That said there seems to be solutions to make the situation better.
I think that before plotting te data we should perform a coordinate
change to fit float dynamic.
This pipeline might be implemented like this?:

CPU:  -Data domain analysis (min, max, dynamic)
CPU:  -Produce a Temporary vector of visible data centered and reduced
CPU:  -Push Temporary vector to GPU
GPU:  -Generate Vertices with or without downsampling strategy
CPU:  -Build Axes from visible bounds in data coordinates


That's essentially the same strategy I've implemented in the past. I 
don't know the code of Qt Charts or how easily this woudl fit into it 
but as an approach I think it's sound.


Cheers,

Sean



Note that this would also work without OpenGL and the downsampling
insanely increase performances. On QCustomPlot if we replace data
containers which are QMap by QVector you can plot more than 10M points
without problems.
Here is one example with 3M points with QCustomPlot and without OpenGL:
https://hephaistos.lpp.polytechnique.fr/data/QLop_new_Features2.webm

This would imply to store two coordinate systems for Data and View.
We are happy to discuss about that and contribute to the development if
we agree on a solution.
Anyway I would be happy to have any feedback on this.

Some readings:
http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisio
ns/
http://www.urbanrobots.com/Blogs/WW/2006/01/working-to-solution-in-prec
ision.html
http://www.urbanrobots.com/Blogs/WW/2006/01/solving-coordinate-precisio
n-problems.html


Best regards
Alexis Jeandet
Laboratory of Plasma Physics(LPP)
http://www.lpp.fr/?lang=en
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages

[Sean Harmer]

On Monday 27 June 2016 07:18:02 Tuukka Turunen wrote:
> > -Original Message-
> > From: Development [mailto:development-
> > bounces+tuukka.turunen=qt...@qt-project.org] On Behalf Of Sean Harmer
> > Sent: perjantaina 24. kesäkuuta 2016 11.23
> > To: development@qt-project.org
> > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1
> > packages
> > 
> > -- clip --- 
> > This is why we have a process. How is this situation compatible with TQC's
> > ISO
 9001 certification?!
> > 
> 
> 
> Hi Sean,
> 
> Making a fix release fits well with the release process of the ISO 9001
> certification, no problems there. 

ISO 9001 is about following the processes that you say you follow. This is 
clearly not the case here as a process was made up on the spot to do it 
quickly. This is clearly a non-conformance. Removing packages is clearly 
another.

I'm not disputing that a process for quick fix releases should be made, but the 
time to do this is not when there is a sudden need for it. That's when 
unforeseen mistakes slip through the cracks.

Had the decision to just cherry pick this one fix and apply the usual release 
process for a 5.6.2 had been made, the level of testing could have been 
reduced accordingly to speed up the process and a message put out saying to 
avoid 5.6.1 if you are using QML/Quick. With a 5.6.2 release coming shortly, 
users could have made the informed decision to stick with 5.6.0 until 5.6.2 
was ready. If the installer had the ability to downgrade as well as upgrade, 
this would be even easier.

Cheers,

Sean
 
> In general, it is valuable to be able to make releases quickly to fix e.g. a
> security vulnerability. The fastest way to do it is to push the needed
> change (or changes) into the release branch, and create new release
> directly from there. I do not have any strong opinion if the number of the
> release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation
> has been -1, but if there is desire to change it going forward, I do not
> think that is a problem.
 
> Yours,
> 
>   Tuukka 
> 
> 
> 
> 
> > Sean
> > --
> > Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB
> > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-
> > 563-540090
> > Mobile: +44 (0)7545 140604
> > KDAB - Qt Experts
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Push to Gerrit

[Sean Harmer]

Hi Harald,

often on Windows it's easiest to install PuTTy and it's helper program, 
pageant. Run pageant and import/convert your ssh key and set this up in 
your gerrit webui.


Cheers,

Sean

On 25/06/2016 16:06, Harald Vistnes wrote:

Hi,

I'm trying to make my first ever contribution to Qt, but I am 
struggling with the last part of actually pushing to Gerrit. I've 
followed the guidelines in the Wiki, but I have probably done 
something wrong.


I've added and committed the patch locally, but when I try to run

git push gerrit HEAD:refs/for/5.7

I get a popup messagebox:

TortoiseGitPlink Fatal Error
Disconnected: No supported authentication methods available (server 
sent: publickey)


I'm on Windows. I assume the problem is related to the ssh keys.

Any hints on how to continue would be welcome.

Thanks,

Harald Vistnes



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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

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

[Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components

[Sean Harmer]

Well, that's a new one but fits quite well with the news today.

Sean

 Forwarded Message 
Subject: 	Change in qt/qt3d[5.7]: Entity: add simple method to check for 
components

Date:   Fri, 24 Jun 2016 16:04:39 +
From:   Qt CI Bot (Code Review) <gerrit-nore...@qt-project.org>
Reply-To:   qt_ci_...@qt-project.org
To: Paul Lemire <paul.lem...@kdab.com>
CC: 	Qt Sanity Bot <qt_sanity...@qt-project.org>, Sean Harmer 
<sean.har...@kdab.com>, Robert Brock <robert.br...@kdab.com>




Qt CI Bot has posted comments on this change.

Change subject: Entity: add simple method to check for components
..


Continuous Integration: Failed

 Module "qt/qt3d" (3524e549c48edf4f6c90ba1e8f8af24d864b4afb) Failed test(s): 
/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine:
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 ^D
 ^D
 quit
 ^D
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 ^D
 quit
 Attaching to process with:
 process attach -p 3095
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 quit
 ^D
 quit
 quit
 ^D
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 ^D
 quit
 ^D
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 quit
 quit
 quit
 ^D
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 quit
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 quit
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 quit
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 quit
 quit
 quit
 ^D
 quit
 ^D
 ^D
 quit
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 quit
 quit
 ^D
 ^D
 quit
 ^D
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 quit
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 ^D
 quit
 quit
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 quit
 quit
 ^D
 ^D
 ^D
 quit
 quit
 ^D
 ^D
 quit
 ^D
 ^D
 quit
 quit
 quit
 ^D
 ^D
 ^D
 quit
 ^D
 quit
 quit
 quit
 quit
 ^D
 quProcess 3095 stopped
 Executable module set to 
"/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine/tst_qaspectengine.app/Contents/MacOS/tst_qaspectengine".
 Architecture set to: x86_64-apple-macosx.
 (lldb) quit
 ^D
 (lldb) quitquit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 quit
 
 agent:2016/06/24 19:04:33 build.go:221: Killed process after timeout (total time)

 agent:2016/06/24 19:04:34 agent.go:170: Test failed
 agent:2016/06/24 19:04:34 build.go:158: Error reading from stdout/err: Timeout 
after 15m0s: Maximum duration reached
 agent:2016/06/24 19:04:34 agent.go:127: ERROR building: Timeout after 15m0s: 
Maximum duration reached

 Build log: 
http://testresults.qt.io/logs/qt/qt3d/224055f620a8fc4ed6bcf965832b26d79e39b965/OSXOSX_10_08x86_64OSXOSX_10_08x86_64ClangRelease_NoFramework/f5928a8f6f410b5c920089ab39348d986238c96e/testrun_1466782347/testlog.txt.gz

 Details: 
http://testresults.qt.io/coin/integration/qt/qt3d/tasks/1466782347.thrift_bin

 Tested changes (refs/builds/qtci/5.7/1466782346):
   
https://codereview.qt-project.org/#/q/9746c18738d3191120f51ff08d259c05bd5f2d83,n,z
 Entity: add simple method to check for components
   
https://codereview.qt-project.org/#/q/cb1fdc35938a70acc56054d363476690abac2e89,n,z
 Entity: use QVector for componentsHandle/renderComponents
   
https://codereview.qt-project.org/#/q/fbc7ea5d2d64ec2fa229a326a5e8ce2caa9145cd,n,z
 FrameGraphNode: make children() return a QVector

--
To view, visit https://code

Re: [Development] Many congratulations and one question

[Sean Harmer]

Hi Massimo,


On 18/06/2016 15:41, Massimo Callegari via Development wrote:

Hi everyone,
today, instead of being the usual "complaining guy" I'd like to explicit my 
biggest congratulations and gratitude to all the people behind the Qt3D module.
In particular to Sean Harmer and Paul Lemire at KDAB, who have been doing a 
monumental job working during weekends, fighting against CI breakage and taking 
care of an infinite number of JIRA issues and reports.

I've been following the Qt3D developments for a couple of years and I have to 
say Qt3D is going to be an awesome addition to the Qt features set.
I tried as much as I could to support the developments by testing patches and 
reporting issues and I hope I've been somehow helpful for the project.


Thank you for your kind words. Yes, please do keep the bug reports 
coming and prodding us when needed.



I'm also very excited by the Qt3D editor and I'd like to congratulate with all 
the Qt people behind it as well.
Even if it's in a very early stage, you can already feel it is going to be an 
awesome tool !


+1. It's already shaping up to be a nice addition. I hope it can 
continue to be extended and hopefully one day become a great plugin for 
Qt Creator



So, well done everybody !


Thank you and I'd like to echo my own thanks to everybody who has helped 
with code, reporting bugs, asking questions that pushed us to make sure 
Qt 3D is flexible enough to work with as many rendering algorithms as 
possible. I already have plenty of ideas on how to continue extending 
the frame graph in 5.8 and beyond plus a whole bunch of other additions 
that we discussed with Pasi and his team in Oulu recently.



Now I've got a question for the Qt3D guys who knows all the techy bits of the 
current status of the module.
It is my intention to implement the technique described in these AMD slides:
https://developer.amd.com/wordpress/media/2012/10/Mitchell_LightShafts.pdf

I am wondering if Qt3D can already cover such usage or if there are missing 
bits that are still not there or not planned at all.


I don't see anything in there that Qt 3D can't do with a suitable 
configuration.



A plus for my project is if that technique can work in a deferred rendering 
pipeline.


That technique relies upon alpha blended, view-aligned quads. It would 
need to be applied after the deferred portion of the rendering as alpha 
blending doesn't play nicely with deferred. So something like this might 
be something to try:


1) G-buffer pass
2) Lighting pass of opaque geometry
3) Light shafts pass for the brightest n lights, where n is tuned to 
what your hardware can handle.


Depending upon the scene you want to render you may be able to hand 
select which lights trigger light shafts. For example, if you have 10 
bright spot lights, use those with light shafts and just rely upon some 
other post-processing effect like bloom for the dimmer lights or point 
lights which can be done in a single post-proc pass.



If KDAB/Qt is interested in such usage case, I am more than willing to 
contribute to the developments or even support a developer more skilled than me 
in the 3D area with a monetary contribution.


Sounds like an interesting algorithm to implement. If you'd like to do 
it on a commercial basis then feel free to contact us.


Have a nice weekend and thank you again for your kind words and help!

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

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

Re: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ?

[Sean Harmer]

On Monday 13 June 2016 06:47:44 Bo Thorsen wrote:
> Den 12-06-2016 kl. 12:59 skrev Denis Shienkov:
> >> No, use of the C++11 Standard Library features is not permitted
> > 
> > Lousy to hear it...
> > 
> > How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE,
> > HKEY, HDEVINFO and other stuff)?
> 
> QScopedPointer?

Not moveable.

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] CI problems being solved

[Sean Harmer]

Hi Tony,


On 29/05/2016 18:10, Tony Sarajärvi wrote:


Hi again.

Seems I got it building again. However, there might be commits left 
out of control either in ‘staging’, ‘staged’ or ‘integrating’ states. 
If you find your commits hanging weirdly in these states, please let 
us know and we’ll manually poke them with a cattle prod J




Could you poke:

https://codereview.qt-project.org/#/c/160719/
https://codereview.qt-project.org/#/c/160723/

please?

Thanks,

Sean


-Tony

*From:* Development 
[mailto:development-bounces+tony.sarajarvi=qt...@qt-project.org] *On 
Behalf Of *Tony Sarajärvi

*Sent:* 29. toukokuuta 2016 19:58
*To:* development@qt-project.org
*Subject:* [Development] CI problems being solved

Hi all!

The CI is suffering from technical problems in the world of 
virtualization. I’m working on it and hopefully will get it back 
online within the hour if all goes well. I really can’t say what the 
state of the server is before I can get the server back online. If 
it’s a matter of restarting stuff then, then all should come back 
within an hour.


Regards,

-Tony

Tony Sarajärvi

CI Tech Lead

The Qt Company  - Elektroniikkatie 13, 90590 Oulu, Finland

Email: tony.saraja...@theqtcompany.com 



http://qt.io

Qt Facebook: www.facebook.com/qt 



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


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

Re: [Development] Help needed: Qt 3D Android build issue

[Sean Harmer]

Hi Marc,

On Thursday 26 May 2016 08:32:21 Marc Mutz wrote:
> Hi,
> 
> In QAtomic, we use compare_exchange_strong with a single memory_order
> argument. The failure mode is therefore calculated by libctdc++, the
> relevant code in atomic_base.h has not changed from 4.8.0 to 6.1.0, and
> appears to do the correct thing. It does use signed bitmasking operations
> with enums that have values with the high bit set (on 32-bit platforms), so
> theoretically there can be a miscompile there.
> 
> A workaround for Qt might be to pass an explicit failure mode, which would
> avoid aforementioned code in libstdc++.
> 
> If the failure is reproducible, then someone with access to the
> configuration could try the attached patch.

Thanks for the patch. The issue was worked around by upgrading the Android CI 
nodes to use gcc 4.9 rather than 4.8.

If anybody else if using 4.8 then they can try this patch.

Cheers,

Sean

> 
> Thanks,
> Marc
> 
> On Monday 23 May 2016 13:54:16 Sean Harmer wrote:
> > Bump, is anybody able to help here please?
> > 
> > Thanks,
> > 
> > Sean
> > 
> > On Friday 20 May 2016 10:13:51 Sean Harmer wrote:
> > > Hi,
> > > 
> > > Trying to submit a simple patch to Qt 3D we are hitting a weird
> > > compilation error on Android CI configurations. The change is:
> > > 
> > > https://codereview.qt-project.org/#/c/157592/
> > > 
> > > and the compilation errors can be seen in full at:
> > > 
> > > http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfc
> > > a
> > > 8c0
> > > 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_Open
> > > GLES
> > > 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.
> > > gz
> > > 
> > > but in brief they are:
> > > 
> > > In file included from /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/atomic:41:0,
> > > 
> > >  from
> > > 
> > > /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from
> > > /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from
> > > /home/qt/work/install/include/QtCore/qatomic.h:46, from
> > > /home/qt/work/install/include/QtCore/qglobal.h:1145, from
> > > ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43,
> > > 
> > >  from ../../include/Qt3DCore/qt3dcore_global.h:1,
> > >  from
> > > 
> > > ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43,
> > > 
> > >  from ../../include/Qt3DRender/qt3drender_global.h:1,
> > >  from
> > > 
> > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/ren
> > > d
> > > er/ backend/backendnode_p.h:54, from
> > > ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1,
> > > 
> > >  from backend/entity_p.h:55,
> > > 
> > >  from backend/entity.cpp:40:
> > > /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_b
> > > a
> > > se. h: In member function 'virtual void
> > > Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)':
> > > /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> > > libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory
> > > model cannot be stronger than success memory model for
> > > '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> > > &__i1, __i2, 0, __m1, __m2); ^
> > > /opt/android/ndk/sourc

Re: [Development] Help needed: Qt 3D Android build issue

[Sean Harmer]

Bump, is anybody able to help here please?

Thanks,

Sean

On Friday 20 May 2016 10:13:51 Sean Harmer wrote:
> Hi,
> 
> Trying to submit a simple patch to Qt 3D we are hitting a weird compilation
> error on Android CI configurations. The change is:
> 
> https://codereview.qt-project.org/#/c/157592/
> 
> and the compilation errors can be seen in full at:
> 
> http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfca8c0
> 2f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_OpenGLES
> 2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.gz
> 
> but in brief they are:
> 
> In file included from /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/atomic:41:0,
>  from
> /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45, from
> /home/qt/work/install/include/QtCore/qbasicatomic.h:53, from
> /home/qt/work/install/include/QtCore/qatomic.h:46, from
> /home/qt/work/install/include/QtCore/qglobal.h:1145, from
> ../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43,
>  from ../../include/Qt3DCore/qt3dcore_global.h:1,
>  from
> ../../include/Qt3DRender/../../src/render/qt3drender_global.h:43,
>  from ../../include/Qt3DRender/qt3drender_global.h:1,
>  from
> ../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/render/
> backend/backendnode_p.h:54, from
> ../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1,
>  from backend/entity_p.h:55,
>  from backend/entity.cpp:40:
> /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base.
> h: In member function 'virtual void
> Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)':
> /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model
> cannot be stronger than success memory model for
> '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model
> cannot be stronger than success memory model for
> '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model
> cannot be stronger than success memory model for
> '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> &__i1, __i2, 0, __m1, __m2); ^ /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model
> cannot be stronger than success memory model for
> '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> &__i1, __i2, 0, __m1, __m2); ^
> /opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base
> .h: In member function 'virtual void
> Qt3DRender::Render::Entity::initializeFromPeer(const
> QNodeCreatedChangeBasePtr&)':
> /opt/android/ndk/sources/cxx-stl/gnu-
> libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model
> cannot be stronger than success memory model for
> '__atomic_compare_exchange' return __atomic_compare_exchange_n(&_M_i,
> &__i1, __i2, 0, __m1, __m2); ^
> 
> The patch makes no direct use of atomics, only via QSharedPointer. BogDan
> reports that it builds fine with latest NDK.
> 
> Is this a genuine error on our part or some corner case issue with the CI's
> installed NDK?
> 
> I'm at a total loss with this one and have no idea how to investigate/fix.
> 
> Any help would be greatly appreciated. :)
> 
> Kind regards,
> 
> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, 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

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing

[Sean Harmer]

On Saturday 21 May 2016 12:10:16 Sean Harmer wrote:
> On Friday 20 May 2016 19:49:11 Sean Harmer wrote:
> > Hi Ossi,
> > 
> > apologies I have a set of changes now integrating that have been
> > fighting with the CI for a few days which now look to be going through.
> > Should I do another 5.7 -> 5.7.0 merge after they land? They need to get
> > in to fix some P0 issues in Qt 3D.
> 
> Thanks for doing the merge and sorry once again.
> 
> Could you retarget these to 5.7.0 please? :
> 
> https://codereview.qt-project.org/#/c/159582/
> https://codereview.qt-project.org/#/c/159583/
> https://codereview.qt-project.org/#/c/159638/
> https://codereview.qt-project.org/#/c/159639/
> https://codereview.qt-project.org/#/c/159756/
> https://codereview.qt-project.org/#/c/159757/
> https://codereview.qt-project.org/#/c/157592/
> https://codereview.qt-project.org/#/c/159835/

And this one too please:

https://codereview.qt-project.org/#/c/159649/

Cheers,

Sean

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

Re: [Development] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing

[Sean Harmer]

On Friday 20 May 2016 19:49:11 Sean Harmer wrote:
> Hi Ossi,
> 
> apologies I have a set of changes now integrating that have been
> fighting with the CI for a few days which now look to be going through.
> Should I do another 5.7 -> 5.7.0 merge after they land? They need to get
> in to fix some P0 issues in Qt 3D.

Thanks for doing the merge and sorry once again.

Could you retarget these to 5.7.0 please? :

https://codereview.qt-project.org/#/c/159582/
https://codereview.qt-project.org/#/c/159583/
https://codereview.qt-project.org/#/c/159638/
https://codereview.qt-project.org/#/c/159639/
https://codereview.qt-project.org/#/c/159756/
https://codereview.qt-project.org/#/c/159757/
https://codereview.qt-project.org/#/c/157592/
https://codereview.qt-project.org/#/c/159835/

Many thanks!

Sean

> 
> Cheers,
> 
> Sean
> 
> On 20/05/2016 18:39, Oswald Buddenhagen wrote:
> > 5.7.0 is fully (*) branched now. staging is limited to the release team.
> > 
> > as usual, i'm taking retargeting requests for tardy changes.
> > 
> > (*) actually, it's not. webengine is still integrating something since
> > half a day.
> > 
> > On Fri, May 13, 2016 at 01:36:30PM +0200, Oswald Buddenhagen wrote:
> >> The 5.7.0 branch is now available. Please start using it for changes
> >> targeting the Qt 5.7.0 release.
> >> 
> >> We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so
> >> there should be enough time to finalize ongoing changes in 5.7, and
> >> start using 5.7.0 for new changes.
> >> 
> >> Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual.
> >> Don't cherry-pick in either direction if at all avoidable - as usual.
> >> ___
> >> Releasing mailing list
> >> releas...@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/releasing
> > 
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] [Releasing] HEADS UP: Qt 5.7.0 branching ongoing

[Sean Harmer]

Hi Ossi,

apologies I have a set of changes now integrating that have been 
fighting with the CI for a few days which now look to be going through. 
Should I do another 5.7 -> 5.7.0 merge after they land? They need to get 
in to fix some P0 issues in Qt 3D.


Cheers,

Sean


On 20/05/2016 18:39, Oswald Buddenhagen wrote:

5.7.0 is fully (*) branched now. staging is limited to the release team.

as usual, i'm taking retargeting requests for tardy changes.

(*) actually, it's not. webengine is still integrating something since
half a day.

On Fri, May 13, 2016 at 01:36:30PM +0200, Oswald Buddenhagen wrote:

The 5.7.0 branch is now available. Please start using it for changes
targeting the Qt 5.7.0 release.

We will merge the 5.7 branch to 5.7.0 a last time on May 19th, so
there should be enough time to finalize ongoing changes in 5.7, and
start using 5.7.0 for new changes.

Changes done on 5.7.0 are forward-merged to 5.7 and dev - as usual.
Don't cherry-pick in either direction if at all avoidable - as usual.
___
Releasing mailing list
releas...@qt-project.org
http://lists.qt-project.org/mailman/listinfo/releasing

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



--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts

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

[Development] Help needed: Qt 3D Android build issue

[Sean Harmer]

Hi,

Trying to submit a simple patch to Qt 3D we are hitting a weird compilation 
error on Android CI configurations. The change is:

https://codereview.qt-project.org/#/c/157592/

and the compilation errors can be seen in full at:

http://testresults.qt.io/logs/qt/qt3d/489c6abe13e098eb87fa2c0a8639d43dfca8c02f/LinuxRHEL_6_6x86_64AndroidAndroid_22armv7GCCRelease_DisableTests_OpenGLES2_NoUseGoldLinker/1e29b40895b69af3bcc7f2f8a4b041b69e05b286/buildlog.txt.gz

but in brief they are:

In file included from /opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/atomic:41:0,
 from /home/qt/work/install/include/QtCore/qatomic_cxx11.h:45,
 from /home/qt/work/install/include/QtCore/qbasicatomic.h:53,
 from /home/qt/work/install/include/QtCore/qatomic.h:46,
 from /home/qt/work/install/include/QtCore/qglobal.h:1145,
 from 
../../include/Qt3DCore/../../src/core/qt3dcore_global.h:43,
 from ../../include/Qt3DCore/qt3dcore_global.h:1,
 from 
../../include/Qt3DRender/../../src/render/qt3drender_global.h:43,
 from ../../include/Qt3DRender/qt3drender_global.h:1,
 from 
../../include/Qt3DRender/5.7.0/Qt3DRender/private/../../../../../src/render/backend/backendnode_p.h:54,
 from 
../../include/Qt3DRender/5.7.0/Qt3DRender/private/backendnode_p.h:1,
 from backend/entity_p.h:55,
 from backend/entity.cpp:40:
/opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base.h: 
In member function 'virtual void 
Qt3DRender::Render::Entity::sceneChangeEvent(const QSceneChangePtr&)':
/opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model 
cannot be stronger than success memory model for '__atomic_compare_exchange'
  return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2);
  ^
/opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model 
cannot be stronger than success memory model for '__atomic_compare_exchange'
  return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2);
  ^
/opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model 
cannot be stronger than success memory model for '__atomic_compare_exchange'
  return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2);
  ^
/opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model 
cannot be stronger than success memory model for '__atomic_compare_exchange'
  return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2);
  ^
/opt/android/ndk/sources/cxx-stl/gnu-libstdc++/4.8/include/bits/atomic_base.h: 
In member function 'virtual void 
Qt3DRender::Render::Entity::initializeFromPeer(const 
QNodeCreatedChangeBasePtr&)':
/opt/android/ndk/sources/cxx-stl/gnu-
libstdc++/4.8/include/bits/atomic_base.h:577:70: error: failure memory model 
cannot be stronger than success memory model for '__atomic_compare_exchange'
  return __atomic_compare_exchange_n(&_M_i, &__i1, __i2, 0, __m1, __m2);
  ^

The patch makes no direct use of atomics, only via QSharedPointer. BogDan 
reports that it builds fine with latest NDK.

Is this a genuine error on our part or some corner case issue with the CI's 
installed NDK?

I'm at a total loss with this one and have no idea how to investigate/fix.

Any help would be greatly appreciated. :)

Kind regards,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] QVariant performance

[Sean Harmer]

On Monday 16 May 2016 08:22:26 Thiago Macieira wrote:
> On segunda-feira, 16 de maio de 2016 11:52:57 PDT Sean Harmer wrote:
> > We have a WIP to replace the use of QVariant on the backend of Qt 3D but
> > it
> > would benefit all of Qt (including Qt 3D frontend to backend change
> > notifications) if we can also improve the locking behaviour of QVariant.
> > We
> > have some ideas here to either use thread local storage in addition to the
> > global metatype information registry and/or to use a scheme involving
> > atomic compare/exchange when updating metatype registration info.
> 
> Uncontended locks in Qt are extremely cheap.

They're better now than they were since Olivier rewrote QReadWriteLock 
recently.

Probably the biggest hit we see from the use of QVariant in Qt 3D these days 
is the memory allocations for passing around QMatrix4x4's in them. We will 
soon replace these with a strongly typed alternative.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] QVariant performance

[Sean Harmer]

On Monday 16 May 2016 12:32:41 Mark Gaiser wrote:
> Hi,
> 
> Just a fyi since the article might be of interest to some on this list.
> I just stumbled upon this github project [1].
> The article and rationale for that project can be found here [2].
> 
> It claims to be a stack based "variant" implementation made for performance
> and as little overhead as possible. Perhaps the code has some nice tricks
> that could be used to make QVariant faster? QVariant in those benchmarks,
> as seen in [1], seems to be the slowest when compared to std::any,
> boost::any and his own variant.

Thanks for the article.

QVariant has to deal with dynamic type registration. This in turn leads to 
lots of locking of metatype information - something that profiling Qt 3D has 
pointed as being an issue.

In the case of the article you link and for Qt 3D we have a set of known types 
that we need to cater for. So QVariant is too general here and some templated 
types will be better suited and higher performing than QVariant or any other 
variant like type.

We have a WIP to replace the use of QVariant on the backend of Qt 3D but it 
would benefit all of Qt (including Qt 3D frontend to backend change 
notifications) if we can also improve the locking behaviour of QVariant. We 
have some ideas here to either use thread local storage in addition to the 
global metatype information registry and/or to use a scheme involving atomic 
compare/exchange when updating metatype registration info.

Cheers,

Sean

> 
> [1] https://github.com/david-grs/static_any
> [2] http://david-grs.github.io/low_latency_stack_based_boost_any/

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, 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] [5.7-beta] qtgamepad compile failure

[Sean Harmer]

On Friday 06 May 2016 11:35:16 Tim Blechmann wrote:
> > I've just downloaded qt-everywhere-opensource-src-5.7.0-beta.tar.xz and
> > confirmed that qtgamepad/include/QtGamepad/qtgamepadglobal.h is present
> 
> ah, thanks for the pointer ... importing qt tarballs into git repos is
> full of surprises: qtgamepad/.gitignore ignores 'include'
> 
> my usual workflow is to import the qt-everywhere-enterprise-src*.tar
> tarball into a git repo, as i need to apply 10-40 patches to work around
> qt bugs. of course .gitignore or .gitmodules files don't exactly make
> this a no-brainer :/

Which bugs? Can you not upstream the fixes?

Cheers,

Sean
-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt CI reliability

[Sean Harmer]

On Thursday 05 May 2016 13:01:24 Sean Harmer wrote:
> And more problems today:
> 
> http://testresults.qt.io/logs/qt/qt3d/83275e6eb72baa5f80d4fbaaf84bc0ffd1b597
> 62/LinuxUbuntu_15_04x86_64LinuxUbuntuTouch_15_04armv7GCCDisableTests_OpenGLE
> S2/f09f2056189e7df3613966a77c6b671ff3d5ea88/buildlog.txt.gz
> 
> results in a 404. I hope this doesn't last all of the holiday weekend...

And now another qt3d integration fails with:

Module "qt/qtdeclarative" (9a7cf067a178c7a08a7ed9f2c6253e1feade5569) did not 
compile:
 Could not parse build log :(

Is anybody able to poke the system please to see what's going wrong?

Sean

> 
> Sean
> 
> On Thursday 05 May 2016 11:15:38 Sean Harmer wrote:
> > On Tuesday 03 May 2016 17:36:49 Jędrzej Nowacki wrote:
> > > On Tuesday 03 of May 2016 14:54:50 Sean Harmer wrote:
> > > > Do you mean VM template? If so then yes that's again something that
> > > > should
> > > > ideally be verified before deployment.
> > > 
> > > Eh, wrong phrasing. Templates are tested. The problem is that the
> > > current
> > > process is a bit racy. Updating template is a work that require time,
> > > especially for testing and deployment. Regressions may appear during
> > > that
> > > time window. Anyway the process is about to be changed soon.
> > 
> > Here's another new failure mode:
> > 
> > http://testresults.qt.io/logs/qt/qtbase/3356adaae5186a77c2aec458e2a1ebd3e4
> > 0d
> > b8ab/LinuxUbuntu_14_04x86_64LinuxUbuntu_14_04x86_64GCCDeveloperBuild_OutO
> > fSo
> > urceBuild_QtLibInfix_QtNamespace/85d6b000f945a84bc84a4f01f53ac65bc05cbe86
> > /bu ildlog.txt.gz
> > 
> > Failing with:
> > 
> > Determining architecture... ()
> > make: Warning: File `../../../qt/qtbase/config.tests/arch/arch.pro' has
> > modification time 1.3e+03 s in the future
> > /home/qt/work/build/bin/qmake -qtconf /home/qt/work/build/bin/qt.conf
> > -nocache -spec /home/qt/work/qt/qtbase/mkspecs/linux-g++ LIBS+=
> > QMAKE_CXXFLAGS+= INCLUDEPATH+= CONFIG-=app_bundle -o Makefile
> > ../../../qt/qtbase/config.tests/arch/arch.pro
> > ...
> > 
> > agent:2016/05/05 13:07:20 build.go:221: Killed process after timeout
> > (total
> > time)
> > agent:2016/05/05 13:07:20 agent.go:170: Build failed
> > agent:2016/05/05 13:07:20 agent.go:127: ERROR building: Timeout after
> > 5m0s:
> > Maximum duration reached
> > agent:2016/05/05 13:07:20 build.go:158: Error reading from stdout/err:
> > Timeout after 5m0s: Maximum duration reached
> > 
> > Sean

-- 
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development