Re: [Development] Proposal: move Qt provisioning scripts and 3rd party components into a dedicated repo

[Laszlo Agocs]

Hi,

> Our 3rd party dependencies currently live in the submodules where they are 
> used. For some 3rd party components, that means we have two, sometimes 
> different copies (e.g. assimp in both Qt Quick 3D and Qt 3D, only one of them 
> patched). And it makes it in general messy to maintain an overview of those 
> 3rd party components. We have a responsibility to keep track of those, and to 
> keep things up-to-date. I think that would be easier if we move them into a 
> single repo with all 3rd party libraries.

I can try sharing some concerns, many of which are similar to those voiced in 
the discussions we had around and pre-6.0, when there was a lot of talk about 
package management and such for 3rd party dependencies (which then died off 
eventually).

1. Can we assume every single 3rd party library out there has a sophisticated 
build system that builds (or at least allows building after appropriate 
configuration) exactly the way Qt needs, with first class cross-compilation and 
embedded support, including the exotic targets like INTEGRITY? (unlikely)  How 
about Yocto where you wouldn't need the upstream build system but rather 
appropriate recipes for packages? Integrating the external code into Qt's build 
system have some benefits that are probably not obvious at first glance, esp. 
when it comes to the less straightforward non-desktopish targets.

If the end result here is a partial solution for the common desktop platforms, 
while most Qt modules will still be stuck with having to support alternative 
solutions (e.g. still bundle) for the more exotic (but essential) targets, then 
that might not be much of an improvement over all.

2. Not every 3rd party library offers Qt-style compatibility guarantees. We may 
not even have proper source/behaviorial compatiblity promises in some cases. 
This means blindly updating stuff to the latest version (no matter how 
important or great that release may seem) or sharing the same 3rd party content 
between multiple Qt modules is not always feasible or wise.

A 3rd party library is often an integral part of a module, with custom patches 
applied and *careful testing* with every single update of the 3rd party code to 
make sure it plays perfectly together with the particular module.  (may not be 
the case everywhere in Qt, but certainly true for some of the graphics/3D 
dependencies)

Dumping the full upstream contents to a faraway external repository and 
claiming it will just work as-is (or that any change we apply on top is fine 
for all clients of the 3rd party lib within Qt) sounds a bit optimistic. The 
3rd party content that is essential for a Qt module should rather be "near the 
eyes of the developers", ideally next to the module sources. (again, this may 
not apply uniformly true within Qt, but certainly true in graphics/3D for 
certain 3rd party deps that provide core and essential functionality) 

3. Many 3rd party components are stripped down, meaning we build only what is 
needed by Qt. In the form that is best, even if that is something the upstream 
build system would never do, with settings or changes upstream may not support 
out of the box. (e.g. sometimes we can just compile in the 3rd party sources 
directly to the module or maybe use a static lib etc., instead of polluting 
everything with tens of shared libraries and unnecessary tools and artifacts 
from the upstream build system)

That this makes updating more difficult is not a valid argument, since updating 
*should* be an involved process - the impact of updating the 3rd party code 
must be carefully evaluated and tested. (as always, thinking of graphics/3D 3rd 
party examples here, perhaps the bar is lower elsewhere with other 3rd party 
deps)

4. Simplicity of customization. Applying custom patches to a stripped down 
bundled version may be significantly simpler than fighting the entire upstream 
repo and its build system. (and customization will be needed, given Qt's 
extensive platform and compiler coverage)

5. Manually building and installing all 3rd party dependencies for every single 
Qt module we work with (thinking here of devs with no toplevel builds and 
whatnot, just building individual repos) is not very tempting.

Best regards,
Laszlo



-Original Message-
From: Development  On Behalf Of Alexandru 
Croitor
Sent: Thursday, July 14, 2022 11:53 AM
To: Volker Hilsheimer 
Cc: development@qt-project.org
Subject: Re: [Development] Proposal: move Qt provisioning scripts and 3rd party 
components into a dedicated repo

Hi,

Just pointing to some relevant issues and discussions.

https://bugreports.qt.io/browse/QTBUG-68816
https://bugreports.qt.io/browse/QTBUG-73760
https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security

> For us as Qt developers it might mean that we either have to build that 3rd 
> party repository ourselves (which could still be done as part of the toplevel 
> build process)

If the libraries will be built using their native build 

Re: [Development] Untangling our platform plugins

[Laszlo Agocs]

Hi,

Agreed. The choice of which backend (be it a dynamically loaded or statically 
linked in one) to use is going to remain a runtime choice. I do not see 
-platform  or QT_QPA_PLATFORM going away or changing in any way. Think 
Linux for example, where xcb, wayland, eglfs, linuxfb, offscreen, vnc, and 
perhaps others may all be applicable (for the same build). Therefore I would 
advise against simply linking in a bunch of code, expecting that a build of Qt 
always uses the same one QPA backend at run time. We still need to be able to 
choose at runtime. Building on the Qt plugin system is therefore still very 
valuable here, even when the plugins are static.

Best regards,
Laszlo



From: Development  on behalf of Tor Arne 
Vestbø 
Sent: Friday, May 15, 2020 2:43 PM
To: Maurice Kalinowski 
Cc: development@qt-project.org 
Subject: Re: [Development] Untangling our platform plugins



> On 15 May 2020, at 14:28, Maurice Kalinowski  wrote:
>
>>>
>> having a significant part of the plugin's implementation (if not most of
>> it) linked into the parent library leads the concept of "plugin" ad absurdum.
>>
>>> Or, in the case of platforms such as macOS where there’s only one
>>> “platform”, the plugin is built directly into QtGui as a static plugin.
>>>
>> the logical consequence of the above would be statically linking the plugins
>> on all platforms. or, for that matter, throwing out the pretense of plugins 
>> and
>> just make it a regular factory, to the degree it even makes sense at all.
>>
> [Maurice Kalinowski]
> What about backends like WebGL, VNC etc.
> It is rather beneficial to decide on runtime which backend to use compared to 
> compile time decision. Especially given that you'd need two different builds 
> then for just a "minimal aspect" of the build.

Agreed, and that part stays as is with the proposal in the OP.

Cheers,
Tor Arne

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

[Development] Qt 6 graphics next steps

[Laszlo Agocs]

Hi all,

As outlined by Jani a few weeks ago [1], Qt 6.0 is expected to have a
Structure and Platform Freeze at the end of June. One essential piece
there is the graphics story. After evolving for some years (Qt
Contributor Summit 2017, 2018, 2019 notes can be found in [2], [3]
[4]), the plan described last spring [5] has been progressing
nicely. We are now moving on to flip a few switches in the dev branch
in order to begin switching over to the new rendering architecture in
earnest.

This affects Qt Quick and dependent modules at the moment. Plain
widget applications, and this includes QOpenGLWindow and
QOpenGLWidget, are not currently affected by this work. (apart from
minor restructuring, such as moving most QOpenGL* convenience classes
into the Qt OpenGL module, out from Qt Gui).

As the documentation [6] describes, Qt 5.14 and 5.15 have shipped the
new, graphics API abstracted Qt Quick scenegraph rendering engine as
an experimental, opt-in feature, meaning one had to set an environment
variable or call some C++ APIs to enable it. The same applies to the
dev branch as of today. This is what's going to change now.

== Phase One ==

As the first step, the defaults will be switched around. Instead of
opting in by setting the environment variable QSG_RHI=1, one can now
opt out, if desired, by setting QSG_NO_RHI=1.

This switch is expected to happen as soon as possible. (i.e. today or
the next few days at latest) This is a temporary, short-term
measure. The direct OpenGL rendering path is kept available to make
testing and transitioning easier. However, this will disappear in the
coming weeks.

In fact, some leaf modules, like Qt Quick 3D, have during the last few
days already merged patches that purge their direct OpenGL rendering
backends, leaving only the new, QRhi-based rendering code path in
place. This shows that we are in good shape, and can likely keep the
length of this phase quite short, moving on to phase two as quickly as
possible.

This phase presents no source breaks, meaning all modules and
applications continue to compile as-is, but advanced usages of Qt
Quick, that are not compatible with the RHI-based graphics stack, may
trigger run time breaks.

== Phase Two ==

Purging the direct OpenGL bits in Qt Quick is work in progress,
although none of the patches are merged yet. In this second phase we
are going to proceed with that work, which means the possibility
of opting out (QSG_NO_RHI) will disappear.

This is the point where one may encounter source breaks due to
deprecated and/or OpenGL-specific APIs being removed or replaced by
new alternatives. This will typically affect advanced use cases only,
such as application code that implements custom scenegraph materials,
or deals with integrating external rendering engines with Qt Quick.

For those interested in more details, there is a set of blog posts [7]
[8] [9] from last year introducing the new approach to handling
graphics APIs and shaders. The recording of a Qt World Summit 2019
talk is also available at [10]. The slides from the March 2020 webinar
[11] give the most up-to-date overview as of now, but there is also
going to be a session at this week's Qt Virtual Tech Con 2020 [12] (look for
"Accelerated 2D / 3D Graphics in Qt 6")

Best regards,
Laszlo

[1] https://lists.qt-project.org/pipermail/development/2020-April/039382.html
[2] https://wiki.qt.io/QtCS2017_QQSG
[3] https://wiki.qt.io/QtCS2018_Graphics_Vision_2020
[4] https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtGui_RHI_3D
[5] https://lists.qt-project.org/pipermail/development/2019-April/035551.html
[6] 
https://doc-snapshots.qt.io/qt5-5.15/qtquick-visualcanvas-scenegraph-renderer.html#rendering-via-the-qt-rendering-hardware-interface
[7] https://www.qt.io/blog/qt-quick-on-vulkan-metal-direct3d
[8] https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-2
[9] https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-3
[10] https://youtu.be/jH2gfeccpqY
[11] 
https://github.com/alpqr/talks/blob/master/Qt_Graphics_Webinar_March_2020/qt_graphics_03_2020.pdf
[12] https://www.qt.io/qtvirtualtechcon2020

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Laszlo Agocs]

That depends on the number of the functions affected, and how commonly those 
are used. If we are talking about just a few virtual functions here and there 
which are not expected to be overriden by a vast majority of applications (such 
as the QIconEngine example), then changing the signatures is probably 
acceptable. After all, Qt 6 will have a number of source compatibility breaks 
(typically in less commonly used APIs) anyways, let's have no illusions here. 
So on its own this should not be an argument for reprioritizing the tainted 
QList name.

For years we have been teaching people to stay away from QList and treat it as 
a legacy thing in the API, and that it may change in a future major release. 
Any newly introduced public APIs (in the graphics-related areas at least) for 
the past 5-6 years are using QVector.  It is odd to turn this over just like 
that.

Best regards,
Laszlo




From: Simon Hausmann 
Sent: Thursday, April 23, 2020 10:52 AM
To: Laszlo Agocs ; Jaroslaw Kobus ; 
Lars Knoll 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

Hi,

If we did the search & replace and use QVector throughout our API, won't that 
make it harder for our users to maintain a code base with 5 and 6? For example 
if we change the signature of virtual functions.

I think we'd do our users a favour by sticking to QList - I'm not concerned 
about the popularity of Qt in online forums but rather about the practical 
difficulties of developing with Qt.


Simon

From: Laszlo Agocs 
Sent: Thursday, April 23, 2020 10:41
To: Jaroslaw Kobus ; Lars Knoll ; Simon 
Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:

Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

(1) Use the same type throughout the public API of Qt.

(2) Make it easy for our users to maintain a code base that works with Qt 5 
and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to QVector. In the light of that, I would like to propose simply 
deprecating QVector and stick to QList everywhere.


What do you think?


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

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

Re: [Development] Proposal: Deprecate QVector in Qt 6

[Laszlo Agocs]

-1 for QList. Why reuse and prioritize a name that has been tainted by plenty 
of past discussions and comes with a lot of past baggage? Any Google etc. 
search will bring up plenty of "QList-bad QVector-good" materials for years to 
come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x is 
not going to disappear overnight.

The current status quo of QList being an alias to QVector in Qt 6, with QVector 
being the primary and recommended name, is pretty good IMHO, it is not clear to 
me why this would need any further changes. An additional search & replace 
(QList->QVector) round in the public headers does not sound like a bad idea at 
all.

Best regards,
Laszlo




From: Development  on behalf of Jaroslaw 
Kobus 
Sent: Thursday, April 23, 2020 10:20 AM
To: Lars Knoll ; Simon Hausmann 
Cc: Qt development mailing list 
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

+1 for QList.

(6) No need to remane QStringList into QStringVector for consistency reasons.

Jarek


From: Development  on behalf of Lars Knoll 

Sent: Thursday, April 23, 2020 9:53 AM
To: Simon Hausmann
Cc: Qt development mailing list
Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6

I’ve had similar thoughts lately as well. I can see a few more reasons to keep 
QList as the name of the class:

(3) Less ambiguity with QVector(2/3/4)D
(4) QList is the known type and the one promoted in our API so far, so no need 
for people to re-learn Qt
(5) a lot less code churn for us and our users

So I’m in favour of doing this and keeping QList as the name for the class.

Cheers,
Lars

On 23 Apr 2020, at 09:43, Simon Hausmann 
mailto:simon.hausm...@qt.io>> wrote:

Hi,

In dev we've had QVector being an alias for QList for a while now. For the 6.0 
release this particular topic (QList/QVector) suggests two goals (among others):

(1) Use the same type throughout the public API of Qt.

(2) Make it easy for our users to maintain a code base that works with Qt 5 
and 6.


In the light of those two goals, I think we should keep using QList as the type 
in the public API. I don't think we should do a search and replace activity and 
switch to QVector. In the light of that, I would like to propose simply 
deprecating QVector and stick to QList everywhere.


What do you think?


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

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

Re: [Development] Moving math3d classes from GUI to CORE

[Laszlo Agocs]

> So it looks like there is a need to have something like Eigen in Qt, at least 
> for Qt 3D purposes (faster, better optimized classes, more complete API).

Not sure how that conclusion was drawn. More like the opposite. People who need 
something like Eigen can just use Eigen. There is no need to reinvent a 
half-baked alternative in QtCore. Whereas from Graphics (Quick, Quick3D, Qt3D) 
perspective this part of the discussion is irrelevant as the needs there are 
different, and those needs are better served by the existing gui/math3d, or, 
when it comes to 3rd party packages, glm (but definitely not Eigen).

Best regards,
Laszlo

 
-Original Message-
From: Jaroslaw Kobus  
Sent: Friday, January 24, 2020 11:02 AM
To: Laszlo Agocs ; KDAB Mike Krus ; 
Konstantin Tokarev 
Cc: Konstantin Shegunov ; development@qt-project.org
Subject: Re: [Development] Moving math3d classes from GUI to CORE




From: Laszlo Agocs 
Sent: Thursday, January 23, 2020 5:26 PM
To: KDAB Mike Krus; Konstantin Tokarev
Cc: Konstantin Shegunov; Jaroslaw Kobus; development@qt-project.org
Subject: RE: [Development] Moving math3d classes from GUI to CORE

> Indeed, getting some of the SSE work from Qt 3D into Gui could be useful as 
> well.

> When it comes to 3rd party solutions, the graphics stack would most likely be 
> fine and happy with using glm (and so math3d could just go away), but that 
> would mean pulling in more 3rd party dependencies, which is not necessarily 
> ideal either. (in any case, that's a topic to be discussed separately)

> And yes, Eigen is probably a good example of something Qt should not be 
> pretending to be competing with.

So it looks like there is a need to have something like Eigen in Qt, at least 
for Qt 3D purposes (faster, better optimized classes, more complete API).
So either we use it directly (this option is rather not possible, looking at 
the previous feedback: licensing issues, big codebase, etc...) or we start 
developing it in Qt.
Yeah, definitely a topic for a separate discussion :) And there is a good time 
now for this discussion I guess.

Just my 2 cents.

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

Re: [Development] Moving math3d classes from GUI to CORE

[Laszlo Agocs]

Indeed, getting some of the SSE work from Qt 3D into Gui could be useful as 
well.

When it comes to 3rd party solutions, the graphics stack would most likely be 
fine and happy with using glm (and so math3d could just go away), but that 
would mean pulling in more 3rd party dependencies, which is not necessarily 
ideal either. (in any case, that's a topic to be discussed separately)

And yes, Eigen is probably a good example of something Qt should not be 
pretending to be competing with.

Cheers,
Laszlo


-Original Message-
From: Mike Krus  
Sent: Thursday, January 23, 2020 5:03 PM
To: Konstantin Tokarev 
Cc: Laszlo Agocs ; Konstantin Shegunov 
; Jaroslaw Kobus ; 
development@qt-project.org
Subject: Re: [Development] Moving math3d classes from GUI to CORE



> On 23 Jan 2020, at 14:36, Konstantin Tokarev  wrote:
> 
> 
> 
> 23.01.2020, 15:56, "Laszlo Agocs" :
>> 4. Longer term, let's rather focus the energy on improving performance (via 
>> SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick 
>> and Quick 3D than spending effort on trying to get QtCore compete with 
>> existing linear algebra solutions out there.
> 
> FWIW, "existing linear algebra solutions" like Eigen already implement SIMD 
> support for many CPU architectures.
as does Qt3D


Mike

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

—
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908   Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts


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

Re: [Development] Moving math3d classes from GUI to CORE

[Laszlo Agocs]

Hi,



Regarding math3d:



It turns out that QGenericMatrix has no actual matrix operations. It is merely 
a dumb templated container, which probably exists only because someone did not 
like the idea of QMatrix4x4::normalMatrix() outputting into a plain float[9]. 
Therefore, instead of dumping stuff with limited usefulness to Core, we could 
do the following:



1. Leave QVectornD and QMatrix4x4 in gui/math3d as these are not meant to be 
used as generic math classes, they serve the needs of graphics.



2. Deprecate QGenericMatrix and the related from/to functions in QMatrix4x4 in 
5.15, remove in 6.0. Deprecate QMatrix4x4::normalMatrix() as well.



3. Add an alternative for QMatrix4x4::normalMatrix() returning an 
std::array (this is good enough for now since the only use case I am 
aware of is to expose the result as a mat3 to a shader). In the long run we’ll 
probably introduce a proper 3x3 matrix class, but that is not necessarily the 
most urgent thing for 6.0.



4. Longer term, let's rather focus the energy on improving performance (via 
SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick 
and Quick 3D than spending effort on trying to get QtCore compete with existing 
linear algebra solutions out there.

Best regards,
Laszlo


From: Development  On Behalf Of Konstantin 
Shegunov
Sent: Thursday, January 23, 2020 1:38 PM
To: Jaroslaw Kobus 
Cc: development@qt-project.org
Subject: Re: [Development] Moving math3d classes from GUI to CORE

Hi.

On Thu, Jan 23, 2020 at 10:56 AM Jaroslaw Kobus 
mailto:jaroslaw.ko...@qt.io>> wrote:
one of the tasks planned for Qt 6 is to move the math3D classes from QtGui to 
QtCore (https://bugreports.qt.io/browse/QTBUG-46653).

Why? My personal experience leads me to believe that the transformations and 
such aren't really suited for general-purpose work (i.e. gui unrelated), so I 
really don't see the point of going through the motions. This is what we also 
advise people in the forums - if you want to do math on vectors (unrelated to 
the painting), do it manually/pull a dep or w/e.

These may be interesting for you to take a look at:
https://bugreports.qt.io/browse/QTBUG-75146, which triggered:
https://bugreports.qt.io/browse/QTBUG-75879
leading to:
https://codereview.qt-project.org/c/qt/qtbase/+/261770 and
https://codereview.qt-project.org/c/qt/qtbase/+/261715
none of which seem to be possible, or wanted.

1. QMatrix4x4 class (to be moved into Core) uses QTransform class (which is 
currently a part of Gui lib, inside paining dir):
2. Old QMatrix class, which is to be ultimately deprecated in Qt 5.15, is a 
field member of:

I'll pass here, I don't have an opinion on that.

3. QMatrix inside QVariant / QMetaType. If we are going to remove QMatrix type 
in Qt 6, we need to remove it from QMetaType::Type enum (current value = 79). 
Then we create a gap at position 79. We may adjust the values for other types 
(like instead of 80 for QTransform we move it to 79, and so on). However, I 
wonder whether it is going to work in cases like data streaming (e.g. someone 
stored the variant using Qt 5.15 and now he want to read it in Qt 6). Or should 
we just leave the gap at 79?

I'd say leave the gap, seems more prudent. My concern you spelled explicitly 
already - if indeed someone uses a stream that comes from Qt 5.x but is read in 
Qt 6.x then reordering the types means breaking the stream for no obvious 
reason.

4. Where to place math3d classes? Currently they are in gui/math3d. Should they 
go to corelib/math3d, or should they be added into some already existing dir, 
like corelib/tools?

I think it's best to leave them in the gui module.

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

Re: [Development] Qt Shader Tools as proper Qt module for Qt 6.0

[Laszlo Agocs]

Hi Simon,

After qtbase and before others. I do not foresee examples in qtbase relying on 
it in the near future, simply because that would mean examples using QRhi, and 
that’s all private API so such examples are unlikely to appear. Internally, 
there are QRhi-related manual/auto tests in qtbase, but those all come with the 
generated output in place (in form of .qsb files) – the same thing what Qt 
Quick does in 5.14/5.15 – and so they do not rely on shadertools being present 
at build/run time.

There are some gray areas at the moment (for instance, to what extent widgets 
will be affected by the Qt 6 graphics work (think of the OpenGL-based 
compositor thing for Q(Quick|OpenGL)Widget)), which can eventually lead to a 
change of situation, but hopefully that can then be handled with some 
appropriate restructuring. And, as with the tests, for the typical, static (so 
non-dynamically generated) shader code the option of just pre-generating and 
checking in the output of the shadertools machinery is always there.

Best regards,
Laszlo


From: Simon Hausmann 
Sent: Tuesday, December 10, 2019 3:05 PM
To: Laszlo Agocs 
Cc: development@qt-project.org
Subject: Re: [Development] Qt Shader Tools as proper Qt module for Qt 6.0

Hi,

Great :)

In the chain of dependencies, do you see this right after qtbase and before for 
example qtdeclarative?

Or do you foresee any use of the shader compiler in qtbase itself? I suppose at 
least for some examples it would make sense, which makes me wonder if those 
examples should move out or qtbase or shader tools going straight into qtbase. 
What do you think?
Simon


Am 10.12.2019 um 14:56 schrieb Laszlo Agocs 
mailto:laszlo.ag...@qt.io>>:

Hi all,

I would like to suggest promoting Qt Shader Tools (currently 
qt-labs/qtshadertools [1]) into a proper Qt module for Qt 6.0.

Qt 5.x is not in scope, meaning the new qt/qtshadertools repo would start with 
a dev branch only, and is to be ignored for Qt 5.x builds and releases.

As described in this earlier blog post [2], the APIs and tools in this module 
provide the producer functionality for the new shader pipeline that allows Qt 
Quick, and, eventually, Qt Quick 3D, to operate on Vulkan, Metal, and Direct3D, 
in addition to OpenGL. The consumer bits are part of QtGui in 5.14 already.

In order to open up the possibility for Qt modules and applications to perform 
the necessary conditioning steps on their shaders either offline or at run 
time, the module has to be part of and ship with Qt in 6.0. (build system 
integration is planned as well, but that is a separate future exercise)

Additionally, some of the on-going Qt 6.0 graphics work, such as, the enabling 
of Qt Quick 3D to operate on top of the QRhi graphics abstraction, requires 
linking to the qtshadertools module (for the time being at least). And so in 
order to allow that work to happen in dev, qtshadertools needs to be present as 
a proper module.

Best regards,
Laszlo

[1] 
https://codereview.qt-project.org/gitweb?p=qt-labs/qtshadertools.git;a=summary

[2] https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-3

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

[Development] Qt Shader Tools as proper Qt module for Qt 6.0

[Laszlo Agocs]

Hi all,

I would like to suggest promoting Qt Shader Tools (currently 
qt-labs/qtshadertools [1]) into a proper Qt module for Qt 6.0.

Qt 5.x is not in scope, meaning the new qt/qtshadertools repo would start with 
a dev branch only, and is to be ignored for Qt 5.x builds and releases.

As described in this earlier blog post [2], the APIs and tools in this module 
provide the producer functionality for the new shader pipeline that allows Qt 
Quick, and, eventually, Qt Quick 3D, to operate on Vulkan, Metal, and Direct3D, 
in addition to OpenGL. The consumer bits are part of QtGui in 5.14 already.

In order to open up the possibility for Qt modules and applications to perform 
the necessary conditioning steps on their shaders either offline or at run 
time, the module has to be part of and ship with Qt in 6.0. (build system 
integration is planned as well, but that is a separate future exercise)

Additionally, some of the on-going Qt 6.0 graphics work, such as, the enabling 
of Qt Quick 3D to operate on top of the QRhi graphics abstraction, requires 
linking to the qtshadertools module (for the time being at least). And so in 
order to allow that work to happen in dev, qtshadertools needs to be present as 
a proper module.

Best regards,
Laszlo

[1] 
https://codereview.qt-project.org/gitweb?p=qt-labs/qtshadertools.git;a=summary

[2] https://www.qt.io/blog/qt-quick-on-vulkan-metal-and-direct3d-part-3

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

[Development] Notes from "QtGUI, RHI, 3D" session at Qt Contributors Summit 2019

[Laszlo Agocs]

Hi all,

Notes from the QtGui, RHI, 3D session are available at 
https://wiki.qt.io/Qt_Contributor_Summit_2019_-_QtGui_RHI_3D

Best regards,
Laszlo

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

Re: [Development] i.MX8 embedded Linux support

[Laszlo Agocs]

Hi,

Yes, it is a trend to move away from basing EGL/OpenGL implementations on top 
of the (deprecated) fbdev, and instead move onto drm. Sometimes, and I suspect 
this is the case with Vivante as well, vendors offer both variants of the 
drivers. With eglfs this means the backend has to be selected based on what's 
there in the system at run time. (in this case this means choosing between 
eglfs_viv[_wl] or eglfs_kms)

Qt upstream has no explicit support for i.MX8 (there are no device specs in 
mkspecs/devices since none got contributed so far), but, as you also found out, 
eglfs is known to work, so in that sense the i.MX8 is supported. Don't know if 
Wayland got tested so far.

I suppose Yocto and other distro build tools have Qt available for i.MX8 
targets as well. How they configure things there (what drivers, which eglfs 
backend) is up to them. For example, as I understand, the pre-built, 
Yocto-based reference images from the commercial Qt for Device Creation 
offering are still using the fbdev-based stack and so the eglfs_viv path for 
i.MX8. (but I could be wrong here)

Best regards,
Laszlo


From: Development  on behalf of Zeno 
Endemann via Development 
Sent: Wednesday, September 11, 2019 2:53 PM
To: development@qt-project.org 
Subject: [Development] i.MX8 embedded Linux support

Hi,

So unless I misunderstand something, for the i.MX8 NXP/Vivante changed
their proprietary graphic stack significantly. The framebuffer and X11
driver are deprecated, only Wayland will be supported, and they have
switched from the Linux framebuffer interface to (a fork of) libdrm.

I was able to run a Qt Quick application on an i.MX8M Mini using this
new infrastructure, i.e. using the regular eglfs_kms platform plugin. So
I am wondering if the qtbase configure script should be adapted to
detect i.MX8, and for that not build eglfs_viv, eglfs_viv_wl and
eglfs_kms_egldevice anymore.

Or more generally I'd like to ask if there is already further work or
information on supporting embedded Linux on i.MX8. For example, I
suppose the yocto layer needs some updates to reflect all this.


Thanks,

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

Re: [Development] Shadertools repo request and some words about state of graphics

[Laszlo Agocs]

Hi Mike,

There is some research on-going around avoiding (or rather, reducing) the need 
for going through and composing textures when combining the 2D and 3D world. 
This will likely revolve around bringing the Qt Quick scenegraph and 3D a bit 
closer to each other. I avoided talking about 3D in my mail because I am not 
directly involved with those efforts right now. Hopefully that discussion can 
be taken up in the near future.

The widget integration cases are important indeed: for instance, how 
QQuickWidget or QOpenGLWidget would evolve in the future, and if the approach 
they take today (render to texture, put software-rendered content in another 
texture, then compose) could/should change. For now the priority is to have a 
modernized "GL" paint engine (that goes through QRhi instead). Then see where 
we can go with that.

Best regards,
Laszlo


-Original Message-
From: Mike Krus  
Sent: Thursday, April 4, 2019 9:51 AM
To: Laszlo Agocs 
Cc: development@qt-project.org
Subject: Re: [Development] Shadertools repo request and some words about state 
of graphics

Hi Laszlo,

thanks for all this updated information.

> On 2 Apr 2019, at 14:14, Laszlo Agocs  wrote:
> First, a qt-labs repository request:
>  
> Repo name: qtshadertools
> Name: Qt Shader Tools
> Responsible person: me
> Purpose: will import https://git.qt.io/laagocs/qtshadertools here. This is an 
> experimental Qt module providing APIs and a host tool to perform graphics and 
> compute shader conditioning for the upcoming Qt graphics abstraction layer. 
> While it is expected to evolve into a proper Qt module in Qt 6, the intention 
> is to keep it as a qt-labs project for Qt 5.x, mainly in order to avoid 
> prematurely importing larger 3rd party dependencies.
looks like there's interesting things in your own repository. It would be a 
good addition to Qt6 tool set. It would also be nice to think of it in relation 
to the shader generator that was contributed to QtBase. While they are very 
different technologies, they do have some overlapping goals so might make sense 
to move them closer in qt6.

> Second, I believe the request above demands a few words about the current 
> status regarding the evolution of the accelerated graphics stack in Qt.
>  
> Short version:
>  
> - Graphics and shader stack evolution is on-going.
>  
> - A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come 
> already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final 
> destination.
>  
> - Qt Quick is just one piece in the puzzle. More about the others at some 
> other time.
While the effort being put in Qt Quick is important and strategic, do you have 
have an idea of how you want the rest qt’s rendering stacks to evolve? How does 
this impact QDeclarativeWidget for example? Or more importantly (although I may 
be partial), Qt 3D?

All the integrations of the various rendering tool chains currently rely on 
capturing the output of one stack in a buffer and using that in the other 
stack. Surely Qt6 can do better than that?

Since Qt 3D Studio now contains, for lack of a better word, a fork of much of 
Qt 3D, do you have ideas for that? And plans to integrate the work into main 
line Qt 3D?

Thanks again so sharing your ongoing work,


Mike


> Long version:
>  
> As discussed at https://wiki.qt.io/QtCS2018_Graphics_Vision_2020 Qt 6 will do 
> away with the hard OpenGL dependency in most, if not all, of its modules. 
> This is achieved via a small abstraction layer, currently called the Qt 
> Rendering Hardware Interface, with backends for Vulkan, Metal, Direct 3D 11, 
> and OpenGL (ES) 2.x(+ some 3.x extensions) at the moment. Shader code needs 
> additional solutions: graphics shaders in Qt itself, and eventually also in 
> applications (custom Qt Quick materials, ShaderEffect, etc.), are expected to 
> be written in a single language regardless of the platform and graphics API 
> the applications will run on. Hence the above mentioned Shader Tools module.
>  
> In (a not fully up-to-date but conceptually correct) 
> picture:https://git.qt.io/laagocs/qtrhi/blob/1dd15d715399000707552b030357a74782d50f38/rhi2.png
>  
> Qt Quick, the OpenGL paint engine of QPainter, and various other components 
> are expected to migrate to this stack in Qt 6, removing direct OpenGL usage. 
> (to be clear, applications should still be able to do 
> OpenGL/Vulkan/Metal/etc. rendering directly in the future as well, just like 
> they can resort to direct OpenGL usage today via QSGRenderNode or 
> QQuickFramebufferObject or the QQuickWindow under/overlay signals, but then 
> they get tied to running with a given rhi backend, and so graphics API; 
> therefore, this is not an option for Qt itself, at least when it comes to the 
> essential Qt modules)
>  
> This is a long journey, po

[Development] Shadertools repo request and some words about state of graphics

[Laszlo Agocs]

Hi all,

First, a qt-labs repository request:

Repo name: qtshadertools
Name: Qt Shader Tools
Responsible person: me
Purpose: will import https://git.qt.io/laagocs/qtshadertools here. This is an 
experimental Qt module providing APIs and a host tool to perform graphics and 
compute shader conditioning for the upcoming Qt graphics abstraction layer. 
While it is expected to evolve into a proper Qt module in Qt 6, the intention 
is to keep it as a qt-labs project for Qt 5.x, mainly in order to avoid 
prematurely importing larger 3rd party dependencies.

Second, I believe the request above demands a few words about the current 
status regarding the evolution of the accelerated graphics stack in Qt.

Short version:

- Graphics and shader stack evolution is on-going.

- A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come 
already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final 
destination.

- Qt Quick is just one piece in the puzzle. More about the others at some other 
time.

Long version:

As discussed at https://wiki.qt.io/QtCS2018_Graphics_Vision_2020 Qt 6 will do 
away with the hard OpenGL dependency in most, if not all, of its modules. This 
is achieved via a small abstraction layer, currently called the Qt Rendering 
Hardware Interface, with backends for Vulkan, Metal, Direct 3D 11, and OpenGL 
(ES) 2.x(+ some 3.x extensions) at the moment. Shader code needs additional 
solutions: graphics shaders in Qt itself, and eventually also in applications 
(custom Qt Quick materials, ShaderEffect, etc.), are expected to be written in 
a single language regardless of the platform and graphics API the applications 
will run on. Hence the above mentioned Shader Tools module.

In (a not fully up-to-date but conceptually correct) picture: 
https://git.qt.io/laagocs/qtrhi/blob/1dd15d715399000707552b030357a74782d50f38/rhi2.png

Qt Quick, the OpenGL paint engine of QPainter, and various other components are 
expected to migrate to this stack in Qt 6, removing direct OpenGL usage. (to be 
clear, applications should still be able to do OpenGL/Vulkan/Metal/etc. 
rendering directly in the future as well, just like they can resort to direct 
OpenGL usage today via QSGRenderNode or QQuickFramebufferObject or the 
QQuickWindow under/overlay signals, but then they get tied to running with a 
given rhi backend, and so graphics API; therefore, this is not an option for Qt 
itself, at least when it comes to the essential Qt modules)

This is a long journey, possibly with numerous road bumps (or blocks, even) on 
the way. Therefore, the intention is to provide some of the components of the 
new stack as tech previews already in the Qt 5.x time frame, in order to make 
it easier to iterate, discover problems, and get feedback.

As a first step, it is likely that in Qt 5.14 we can already include the some 
of the Qt Quick work as an early preview. In practice this would mean that 
(suitable) Qt Quick applications could opt-in to the new RHI-based rendering 
path (currently this is done by simply setting an environment variable), thus 
switching from OpenGL to D3D11, Vulkan or Metal, transparently to the 
application.

This involves the following pieces:

1. Most the RHI is to be imported (mostly) as private APIs. This is what 
https://codereview.qt-project.org/#/c/256713/ is. (basically a private-ized 
version of https://git.qt.io/laagocs/qtrhi with a bunch of changes on top)

It is not unlikely that QRhi & co. becomes a public API at some point in Qt 
6.x, but we cannot yet commit to having them as public yet. While we believe 
this already provides sufficient foundations for Qt Quick, QPainter, and Qt 3D 
Studio, it will evolve and change over time as necessary so no API guarantees 
can be given.

BTW, (slightly outdated) sets of the generated documentation of qtrhi and 
qtshadertools are available at https://alpqr.github.io/qtrhi/qtrhi-index.html# 
and https://alpqr.github.io/qtshadertools/qtshadertools-index.html#

2. The shader conditioning tools will not be taken into Qt 5.x, as explained 
above. When it comes to the Qt Quick scenegraph's built-in materials 
(QSGVertexColorMaterial and friends), they will come with the necessary 
pre-processed shaders so this is not a problem for typical Quick items. 
Developers wishing to experiment with ShaderEffects or custom QSGMaterials on 
top of the RHI will need to check out and build this module themselves for now.

3. The Qt Quick port will move to the wip/scenegraphng branch of qtdeclarative 
soon, from there we can merge to dev eventually. For now this still lives at 
https://git.qt.io/laagocs/qtgreyhound (and is heavily work in progress).

Unlike earlier attempts, such as the D3D12 backend introduced in Qt 5.8, the 
RHI port is not merely a new scenegraph backend (plugin) - rather, it is the 
fully featured, default OpenGL rendering path that is getting extended and 
massaged into being able to operate with QRhi instead of calling glWhatever() 

Re: [Development] Nominating Rebecca Worledge for maintainer of Qt Lottie

[Laszlo Agocs]

+1

Cheers,
Laszlo

-Original Message-
From: Development  On Behalf Of Eskil 
Abrahamsen Blomfeldt
Sent: onsdag 13. februar 2019 07.21
To: development@qt-project.org
Subject: [Development] Nominating Rebecca Worledge for maintainer of Qt Lottie

Hi!

In Qt 5.13 we have added a Qt.labs module called "Qt Lottie", with Qt 
Quick APIs for showing scenes and animations that were exported using 
the Bodymovin plugin in After Effects.

     https://codereview.qt-project.org/qt/qtlottie

Rebecca Worledge has graciously offered to adopt the maintainership of 
this module. She has worked for Qt for eight years in our Professional 
Services organization, providing invaluable work for our customers as 
well as researching and developing internal prototypes, but this would 
be her first maintainership in the Qt Project.

Thanks, Rebecca!

-- 
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
http://qt.io

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] QUIP 12: Code of Conduct

[Laszlo Agocs]

Fully agree. Is it really necessary to dedicate ca. half of the proposed 
document to sections full of "enforcement", "ban", "violation", "danger", etc., 
which in the end leads to creating an overly dark and bureaucratic vibe?

Laszlo


From: Development  on 
behalf of André Pönitz 
Sent: Thursday, October 25, 2018 7:39 PM
To: Volker Krause
Cc: development@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
> We do have a Code of Conduct at KDE for about 10 years now, and this hasn't
> led to abuse of power, suppression of free speech, racism against white people
> or whatever other nonsense people seem to attribute to CoCs nowadays.

The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic",
"support". It doesn't push someone's personal political agenda.  This is a
completely different beast than the Contributor Covenant that's about
"enforcing", "reporting", "banning".

I think we'd see much less heat in the discussion if the proposed Qt CoC had
been based on the KDE CoC.

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

Re: [Development] Qt 3D Maintainership

[Laszlo Agocs]

Hi guys,

Thanks, Qt 3D is almost certainly going to be an important piece in Qt 6. Once 
the dust settles and we have a clear view of the new maintainership structure, 
we should definitely sync up on the state of things and plan a bit ahead since 
there's plenty to be done and think about, especially with Qt 6 and its 
potentially unified 2D-3D engines in mind. (renderer optimizations, graphics 
API abstractions (RHI), shader graphs, some new features of course, , fun 
times ahead :) )

Cheers,
Laszlo 

-Original Message-
From: Development  On 
Behalf Of Lars Knoll
Sent: fredag 14. september 2018 14.50
To: Tuukka Turunen 
Cc: Qt development mailing list ; Sean Harmer 

Subject: Re: [Development] Qt 3D Maintainership

Hi Sean,

First of all thank you for all the great work on Qt 3D over the last years. Qt 
3D has become a very important part of Qt, and I believe that parts of it will 
get a much more central role in our graphics stack when we move towards Qt 6.

I’ve been discussing a bit with the graphics team in Oslo, and I think the idea 
of having Laszlo as a co-maintainer is good. I would also like to propose that 
we have Svenn-Arne as the co-maintainer for the renderer component. He’s been 
doing a lot of good work in that area over the last year.

We’re also trying to find candidates to help with some of the other modules, 
and I hope we’ll at least one more person we can nominate there next week.

Cheers,
Lars


> On 14 Sep 2018, at 12:47, Tuukka Turunen  wrote:
> 
> 
> Hi Sean,
> 
> Yes, Qt 3D certainly growing both in size and importance. Happily also the 
> number of people working on it has been growing nicely.
> 
> In addition to you and Paul, I believe we should be able to find 1-2 
> additional from developers of The Qt Company working on Qt 3D.
> 
> Would it be possible to have someone from KDAB to maintain Qt 3D Extras? That 
> is an area we have not touched that much. 
> 
> Yours,
> 
>   Tuukka
> 
> On 14/09/2018, 13.29, "Development on behalf of Sean Harmer via Development" 
>  development@qt-project.org> wrote:
> 
>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
> 
> 
> ___
> 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] Nominating Valentyn Doroshchuk for Approver status

[Laszlo Agocs]

+1 from me as well.

Cheers,
Laszlo

-Original Message-
From: Development  On 
Behalf Of Shawn Rutledge
Sent: tirsdag 20. mars 2018 14.28
To: development@qt-project.org
Subject: Re: [Development] Nominating Valentyn Doroshchuk for Approver status

+1 from me
___
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] QtCS2017 Qt Quick Scenegraph session notes

[Laszlo Agocs]

Qt 6 Changes epic ( https://bugreports.qt.io/browse/QTBUG-62425 ) has a Qt 
Quick Scenegraph subtask: https://bugreports.qt.io/browse/QTBUG-62439

Basis of discussion.

- background story. Qt 3D Studio likely based on Qt 3D in the future, it has 
been brought up if Qt Quick should also be unified to use the same underlying 
engine (i.e. Qt 3D) Also, new graphics APIs coming, all engines have to support 
multiple ones in the future, why not unify?

- however, Qt Quick is more: software (QPainter, not necessarily raster paint 
engine) backend, OpenVG

- software backend (QPainter) seen as highly valuable

- Qt Quick also targeting low-end (bad GPU, no GPU, rumors about ports to MCU 
class systems even) Putting in a 3D engine with all bells and whistles is no-no.

- Maintaining a separate Qt Quick 2 while having a new "Qt Quick 3" based on 
some other rendering engine is a no-go.

- Embedding type of use cases more and more relevant: QQuickRenderControl, 
integration with foreign engines (e.g. Qt Quick in Unity 3D in VR, etc.). Make 
this easier: Can QQuickWindow be decoupled from the actual scene?

- alternative to "QQuickScene" proposal: extend QQuickRenderControl instead.

- Reduce global state (per-scene, not per-application scenegraph backend and 
render loop/animation system). Likely good, no further comments.

- New backends for Vulkan, Metal ?

- D3D12 experiment shows it is a lot of work.

- Backend infra still incomplete: one cannot do a new backend that 100% on-par 
with OpenGL (custom materials story lacking, public API for material shaders 
and such is tied to OpenGLisms, need new APIs that are more generic).

- Presented the RHI idea: new backends should use a common graphics abstraction 
layer.

- Ideal target is to expand this to the whole of Qt (Qt 3D, etc.). (very big 
task though; just focusing 2D in the beginning makes it a lot easier)

- Shaders. "Common language" experiment at 
https://github.com/alpqr/qtshaderstack17

- Was questioned if this is really suitable and stable. Wouldn't it be better 
to stay with different languages per-API, but add a whole new option on top: 
node-based shader editing (with visual tooling). Currently being prototyped in 
Qt3D.

- C++ scenegraph API was brought up. Not sure about it. Materials story shows 
that existing public APIs are a problem even. New graphics API stuff and other 
proposed changes likely need no significant restructuring but it's too early to 
tell.

- Note: nothing in the Jira task is committed to. Playing with ideas while busy 
with other stuff.
--
Best regards,
Laszlo

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

[Development] QtCS2017 3D session summary

[Laszlo Agocs]

* Qt 3D Studio is now open (GPLv3/Commercial), on Gerrit at 
qt3dstudio/qt3dstudio.

https://codereview.qt-project.org/gitweb?p=qt3dstudio%2Fqt3dstudio.git;a=summary

* Official Qt 3D Studio 1.0 release targeting end of November.

* Meanwhile research/work is on-going for a new, Qt 3D-based runtime. Available 
on Gerrit at qt3dstudio/qt3d-runtime. Target is next year, this is work in 
progress and subject to heavy changes.

https://codereview.qt-project.org/gitweb?p=qt3dstudio%2Fqt3d-runtime.git;a=summary

* Qt 3D performance improvements: to bring down CPU usage when there are few or 
no changes in the scene between frames, and to reduce memory usage. Achieved by 
more caching, optimizing QThreadPool, etc. Changes targeting 5.9 (LTS), so 
5.9.2 and up will benefit. Great news for any Qt 3D user.

* How the closer integration of 2D and 3D tooling (Quick Designer and Qt 3D 
Studio) will look longer term is not yet clear. At minimum the apps should 
launch from each other to provide a smoother workflow.

--
Best regards,
Laszlo

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

Re: [Development] Screen mirroring

[Laszlo Agocs]

Ouch, wrong link. The correct one is 
https://codereview.qt-project.org/#/c/201648/


Laszlo


From: Development <development-bounces+laszlo.agocs=qt...@qt-project.org> on 
behalf of Laszlo Agocs <laszlo.ag...@qt.io>
Sent: Thursday, August 3, 2017 3:57 PM
To: Quentin Schulz; development@qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring


There's now a patch in https://codereview.qt-project.org/#/c/201604/ 
demonstrating the concept. (only tried with 2 screens on Mesa 17 on Intel) It 
is against dev and part of bigger patch set, and will not apply to 5.8 for 
sure. But could be helpful.


Cheers,

Laszlo



From: Development <development-bounces+laszlo.agocs=qt...@qt-project.org> on 
behalf of Laszlo Agocs <laszlo.ag...@qt.io>
Sent: Wednesday, August 2, 2017 9:18:50 AM
To: Quentin Schulz; development@qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is 
called only once. Other than that it should be alright conceptually (as long as 
the two screens support the same mode). Proper plumbing with config file 
support can get more complicated, of course. There is some work 
planned/on-going around eglfs_kms (see umbrella task at 
https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this 
(configurable cloning) as well, but all that won't land before 5.11 at 
earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo


-Original Message-
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development@qt-project.org
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>; Boris Brezillon 
<boris.brezil...@free-electrons.com>; Alexandre Belloni 
<alexandre.bell...@free-electrons.com>
Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with 
Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display 
Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can 
each handle one screen. It is my understanding that a DI can be assimilated as 
a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS 
with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both 
screens at the same time, but different images) thanks to a JSON file I specify 
with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the 
same time (same resolution of 1024x768 limited by the LVDS) without having to 
code the application to explicitly "copy" what is displayed on one screen to 
the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I 
basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded 
connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How 
do you see it being implemented? I guess that we should also adapt the JSON 
file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Screen mirroring

[Laszlo Agocs]

There's now a patch in https://codereview.qt-project.org/#/c/201604/ 
demonstrating the concept. (only tried with 2 screens on Mesa 17 on Intel) It 
is against dev and part of bigger patch set, and will not apply to 5.8 for 
sure. But could be helpful.


Cheers,

Laszlo



From: Development <development-bounces+laszlo.agocs=qt...@qt-project.org> on 
behalf of Laszlo Agocs <laszlo.ag...@qt.io>
Sent: Wednesday, August 2, 2017 9:18:50 AM
To: Quentin Schulz; development@qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon; Alexandre Belloni
Subject: Re: [Development] Screen mirroring

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is 
called only once. Other than that it should be alright conceptually (as long as 
the two screens support the same mode). Proper plumbing with config file 
support can get more complicated, of course. There is some work 
planned/on-going around eglfs_kms (see umbrella task at 
https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this 
(configurable cloning) as well, but all that won't land before 5.11 at 
earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo


-Original Message-
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development@qt-project.org
Cc: Thomas Petazzoni <thomas.petazz...@free-electrons.com>; Boris Brezillon 
<boris.brezil...@free-electrons.com>; Alexandre Belloni 
<alexandre.bell...@free-electrons.com>
Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with 
Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display 
Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can 
each handle one screen. It is my understanding that a DI can be assimilated as 
a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS 
with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both 
screens at the same time, but different images) thanks to a JSON file I specify 
with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the 
same time (same resolution of 1024x768 limited by the LVDS) without having to 
code the application to explicitly "copy" what is displayed on one screen to 
the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I 
basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded 
connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How 
do you see it being implemented? I guess that we should also adapt the JSON 
file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Screen mirroring

[Laszlo Agocs]

Hi,

Don't you need to duplicate the drmModePageFlip call too? drmModeSetCrtc is 
called only once. Other than that it should be alright conceptually (as long as 
the two screens support the same mode). Proper plumbing with config file 
support can get more complicated, of course. There is some work 
planned/on-going around eglfs_kms (see umbrella task at 
https://bugreports.qt.io/browse/QTBUG-62132 ) which could provide this 
(configurable cloning) as well, but all that won't land before 5.11 at 
earliest. So current versions need custom patches for the time being.

Cheers,
Laszlo
 

-Original Message-
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Quentin Schulz
Sent: onsdag 2. august 2017 08.34
To: development@qt-project.org
Cc: Thomas Petazzoni ; Boris Brezillon 
; Alexandre Belloni 

Subject: [Development] Screen mirroring

Hi all,

I'm currently working on getting screen mirroring working on an iMX6Q with 
Qt5.8 and eglfs plugin.

On this SoC, there is an IPU (Image Processing Unit) which has two DI (Display 
Interface). The DI is connected to encoders (HDMI and LVDS in our case) and can 
each handle one screen. It is my understanding that a DI can be assimilated as 
a CRTC.

We use the eglfs plugin (via -platform) with kms back-end.

I'm able to display content on the two screens connected to the HDMI and LVDS 
with Qt5_Cinematicexperience (one screen at a time) or quickmwtest[1] (both 
screens at the same time, but different images) thanks to a JSON file I specify 
with QT_QPA_EGLFS_KMS_CONFIG.

What I would like to achieve is to have the same image on both screens at the 
same time (same resolution of 1024x768 limited by the LVDS) without having to 
code the application to explicitly "copy" what is displayed on one screen to 
the other.

I managed to achieve this goal by using the same framebuffer for both CRTCs. I 
basically added a drmModeSetCrtc to QEglFSKmsGbmScreen::flip[2] with hardcoded 
connectors and CRTCs ids. See horrible patch here[3].

Is it (using the same framebuffer for both CRTCs) the right way to do it? How 
do you see it being implemented? I guess that we should also adapt the JSON 
file to be able to specify screen mirroring.

Else, what do you suggest?

Thanks,
Quentin

[1] https://github.com/alpqr/quickmwtest
[2]
https://git.qt.io/consulting-usa/qtbase-xcb-rendering/blob/dev/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms/qeglfskmsgbmscreen.cpp#L193
[3] http://code.bulix.org/vs6d7z-176162
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coin infrastructure changes

[Laszlo Agocs]

Hi,

Are we sure that the week before the 5.10 feature freeze date is really the 
best time to do this?

Cheers,
Laszlo

-Original Message-
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Frederik Gladhorn
Sent: mandag 31. juli 2017 15.19
To: development@qt-project.org
Subject: [Development] Coin infrastructure changes

Hi all,

this is mostly for your information. On Wednesday this week (most likely) we're 
making changes to Coin, potentially leading to some interruptions in 
integrations.

The longer version:

We've been working towards replacing the underlying virtualization layer in our 
Continuous Integration infrastructure and have now reached a point where we're 
ready (as ready as we'll get at least) to switch over from VSphere to 
OpenNebula. There are a bunch of advantages (not least that we can actually 
debug issues in OpenNebula/KVM, it'll make the scheduling code in Coin easier, 
...).

This will also be the point at which we start to use some of the new hardware 
that The Qt Company has been purchasing and getting ready, so things will 
initially be at the same speed and eventually much faster.

We have Qt 5.6 and 5.9 running smoothly, the dev branch currently needs some 
merges, hopefully we'll get it working really soon now.

Hopefully the process is: stop the system; change branch; restart and things 
will work. I would expect some hickups when we scale up and run in production 
mode, so bear with us and report issues, we'll eventually be better off, once 
things are in shape.

Cheers,
Frederik

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

Re: [Development] New repository for WebGL Streaming QPA plugin

[Laszlo Agocs]

Hi,

To clarify, would a qt-labs repo work? As I understand the code still needs 
maturization. It can eventually be graduated to a proper Qt module later on. 
(this also means the repo would not be CI controlled for now, but I suspect 
that’s fine)

It is a bit unfortunate that the platform plugin cannot be part of qtbase, but 
it involves a WebSockets dependency and some additional tooling so there’s not 
much choice left.

Cheers,
Laszlo
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Gunnar Roth
Sent: onsdag 5. april 2017 16.22
To: Jesus Fernandez 
Cc: development@qt-project.org
Subject: Re: [Development] New repository for WebGL Streaming QPA plugin

When i klick on this I camoe to a login page of gitlab.
When trying to register I get
1 error prohibited this user from being saved:

  *   Email domain is not authorized for sign-up

I tried that with gmx.de and siemens.com

Regards,
Gunnar Roth
Gesendet: Mittwoch, 05. April 2017 um 15:01 Uhr
Von: "Jesus Fernandez" >
An: development@qt-project.org
Betreff: [Development] New repository for WebGL Streaming QPA plugin
Hi all!

I have been working on a QPA plugin to send the GLES2.0 calls from a host 
computer over the network to a WebGL capable browser. Now it's approaching a 
state in which it could be usable. For this, we'll need a new public repository.

Having a public and controlled repository could help the project to grow up 
significantly.

The name could be Qt WebGL Streaming (qt/qtwebglstreaming).
The current location of the project is 
https://git.qt.io/playground/qtwebglplugin

--

Best regards,
Jesus
___
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] Texture image loading library

[Laszlo Agocs]

Hmm right. Could be that it is less relevant today. Android's etc1tool only did 
PKM but perhaps that is not so interesting anymore with the advent of ETC2.


Cheers,

Laszlo



From: Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Sent: Friday, January 20, 2017 11:11:09 AM
To: Laszlo Agocs; development@qt-project.org
Subject: Re: [Development] Texture image loading library

Il 20/01/2017 11:05, Laszlo Agocs ha scritto:
> Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D
> should have some code for it IIRC), but that can be added later.
>

Is there anyone using those containers? Last time I checked I had a very
hard time finding specifications for them (I think they were hosted on
some Ericsson website that went offline). Also usually tools that can
compress in ETC1/2 can write in KTX.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

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

Re: [Development] Texture image loading library

[Laszlo Agocs]

Ok. Adding support for ETC1/2 in PKM containers may be useful too (Qt 3D should 
have some code for it IIRC), but that can be added later.


Cheers,

Laszlo





From: giuseppe.dang...@kdab.com <giuseppe.dang...@kdab.com> on behalf of 
Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Sent: Friday, January 20, 2017 10:45 AM
To: Laszlo Agocs; development@qt-project.org
Subject: Re: [Development] Texture image loading library

Il 20/01/2017 09:25, Laszlo Agocs ha scritto:
> This would bring the benefit of potential reuse in the Quick (Image
> element) compressed texture support, once that materializes at some
> point in the future.
>
>
> Are ETC1 and ETC2 included? They would be fairly important as well.

Yes, but only because .ktx files can store textured compressed in those
formats. That is: the idea is to be able to load texture files, the
format of the texture stored inside those files depends just on the
limitations of the container. .ktx can store textures in any internal
format supported by OpenGL, .dds is more D3D oriented, yet we can
support a huge degree of it.

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

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

Re: [Development] Texture image loading library

[Laszlo Agocs]

Hi Giuseppe,


It is hard to say for sure without seeing the actual code, but if there are no 
3rd party dependencies involved and all we are talking about is a compact, 
private helper class in the style of Qt3D's current TextureLoadingHelper, then 
adding it next to QOpenGL* in QtGui is still the way to go. (long term these GL 
enablers should be moved out from QtGui but that's something for the far future 
and is not feasible to change now)


This would bring the benefit of potential reuse in the Quick (Image element) 
compressed texture support, once that materializes at some point in the future.


Are ETC1 and ETC2 included? They would be fairly important as well.


Best regards,

Laszlo




From: Development  on 
behalf of Thiago Macieira 
Sent: Friday, January 20, 2017 2:53 AM
To: development@qt-project.org
Subject: Re: [Development] Texture image loading library

On quinta-feira, 19 de janeiro de 2017 22:22:17 PST Oswald Buddenhagen wrote:
> 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.

And eventually they could become public API.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] A new approach for Qt main()

[Laszlo Agocs]

Hi,

How does this handle the cases that need code before the QGuiApplication 
construction? AFAICS it does not.

Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: Tuesday, December 13, 2016 10:37 AM
To: Mathias Hasselmann ; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()


Hi,



The joke of the bikeshedding aside I for one do like the idea of exporting a 
QObject sub-class instead of a function. That makes it easier to extend in the 
future with more entry-points as slots for example.







Simon


From: Development 
>
 on behalf of Mathias Hasselmann 
>
Sent: Monday, December 12, 2016 7:53:50 PM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

Seems this turned into a nice bike shed discussion quickly, so let me
use the chance to present my preferred Qt main(). I am totally convinced
that this one should rule the Qt world:

 class BlueBikeShedApplication : public QApplication
 {
 Q_OBJECT

 public:
 using QApplication::QApplication;

 int run()
 {
 if (!parseCommandLine())
 return EXIT_FAILURE;
 if (!initializeColorBucket())
 return EXIT_FAILURE;

 setupBrush();

 return exec();
 }
 };

 int main(int argc, char *argv[])
 {
 return BlueBikeShedApplication{argc, argv}.run();
 }

The big advantage I see in this approach is, that you work within a
proper QObject context with fully setup QApplication early. Also this
main() is sufficiently generic to be hidden in a platform specific
macro, or static library.

Thank you for reading,
Mathias
___
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] A new approach for Qt main()

[Laszlo Agocs]

There are two separate things in there, though: the entry point and the 
construction of the Q(Core|Gui)Application object. The problem is with the 
latter: is it not clear why Morten’s proposal moves that under the framework’s 
control. Introducing a new entry point, e.g. qtMain(), for all platforms in Qt 
6 is fine. Moving the application object construction into the underlying 
platform-specific entry point Qt provides is not.

Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Filippo Cucchetto
Sent: Friday, December 9, 2016 12:08 PM
To: Lars Knoll 
Cc: Qt Project Development Mailing-List 
Subject: Re: [Development] A new approach for Qt main()

Does this relates to moving Qt main loop to a different thread other than the 
main thread? Cause currently creating the QtApp from a different thread causes 
problems. In particular the plugins static objects are destroyed at app exit 
and thus on the main thread (and this causes problems because QObjects should 
be freed in the same thread where they've created). An example is the 
QQmlComponentsCache.



Il 09 dic 2016 11:44, "Lars Knoll" > 
ha scritto:
Well, the problem is that the main() entry point is causing huge amounts of 
issues on at least Android and iOS. We’d help those platforms a lot if we 
didn’t support this kind of entry point (on those platforms) anymore. But I 
agree that we can’t break this in Qt 5, but we can prepare for Qt6.

I’d propose to define a new entry point that works better on these platforms 
and offering that as the recommended way for new apps. The best solution is 
probably a static library that provides callbacks that can be used to 
initialize things.

When we then come to Qt6, we could deprecate using main() as the entry point, 
and remove support for it at least on the platforms where this is problematic.

Cheers,
Lars

From: Development 
>
 on behalf of Simon Hausmann >
Date: Friday, 9 December 2016 at 11:17
To: Friedemann Kleint 
>, Qt development 
mailing list >
Subject: Re: [Development] A new approach for Qt main()




Yes, and we will forever (?) support that kind of main function and application 
entry point. I don't think that we can break that.



I'm all interested in supporting a second supported way of describing an entry 
point that more closely matches today's semantics

of graphics applications on the underlying operating/windowing systems.



Oddly, I do like the way that we're doing this on Windows and have been doing 
it forever, by shoehorning main() into WinMain()

through a static library. I'm not suggesting to replace QtMain, but I wonder if 
we could offer a cross-platform QtMain (with a different

name that doesn't clash with the existing one) that requires the programmer to 
supply a _two_ (or more?) functions instead of one function. No

macros involved then.





Simon


From: Development 
>
 on behalf of Friedemann Kleint 
>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

 > Q_GUI_MAIN(appInit, appExit);

Magic macros for main should be avoided, IMO.

A typical application main() can look like

  main()
  {
 QApplication a();

 Initialization code for other libraries

 parseArguments(), return if failed

 show some FileDialog prompting for argument if sth was missing

 try {
   app.exec()
 } catch (exception) {
 }
 De-Initialize something
  }

There is no way to shoehorn this into some macro; this can already be
observed when trying to adding some initialization to a test.

Regards,
Friedemann

--

Friedemann Kleint
The Qt Company GmbH

___
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] A new approach for Qt main()

[Laszlo Agocs]

Special macros for straightforward applications on exotic systems? Sure. 
Forcing an unnecessary change on existing and future applications on platforms 
that are doing just fine (i.e. the majority)? No.

Building on Friedemann's example the list of potentially problematic cases 
could go on forever. For example, what if you need to set certain application 
attributes, default surface formats, etc. before the Q(Gui)Application 
construction. Or the special cases where app object creation should be 
carefully placed. In the end those macros would need to get a lot more 
complicated than they look at first. Based on all the negative experience with 
testlib's similar and the qtdeclarative examples' main-wrapping macros, I'd 
rather prefer we think twice before introducing any such macros.

Also, if migration for the typical applications is seen that easy, it should be 
no problem for developers targeting exotic systems to provide a new-style entry 
point in their apps.

Best regards,
Laszlo

From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Simon Hausmann
Sent: Friday, December 9, 2016 11:17 AM
To: Friedemann Kleint ; development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()




Yes, and we will forever (?) support that kind of main function and application 
entry point. I don't think that we can break that.



I'm all interested in supporting a second supported way of describing an entry 
point that more closely matches today's semantics

of graphics applications on the underlying operating/windowing systems.



Oddly, I do like the way that we're doing this on Windows and have been doing 
it forever, by shoehorning main() into WinMain()

through a static library. I'm not suggesting to replace QtMain, but I wonder if 
we could offer a cross-platform QtMain (with a different

name that doesn't clash with the existing one) that requires the programmer to 
supply a _two_ (or more?) functions instead of one function. No

macros involved then.





Simon


From: Development 
>
 on behalf of Friedemann Kleint 
>
Sent: Friday, December 9, 2016 11:00:00 AM
To: development@qt-project.org
Subject: Re: [Development] A new approach for Qt main()

Hi,

 > Q_GUI_MAIN(appInit, appExit);

Magic macros for main should be avoided, IMO.

A typical application main() can look like

  main()
  {
 QApplication a();

 Initialization code for other libraries

 parseArguments(), return if failed

 show some FileDialog prompting for argument if sth was missing

 try {
   app.exec()
 } catch (exception) {
 }
 De-Initialize something
  }

There is no way to shoehorn this into some macro; this can already be
observed when trying to adding some initialization to a test.

Regards,
Friedemann

--

Friedemann Kleint
The Qt Company GmbH

___
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] Notes on "Qt Build Systems" @ QtCon 2016

[Laszlo Agocs]

Using one "bin" is the default behavior, yes, but one can pass -hostprefix to 
separate them upon install.


http://doc-snapshots.qt.io/qt5-5.8/embedded-linux.html#configuring-a-specific-device


Cheers,

Laszlo


From: Development  on 
behalf of Thiago Macieira 
Sent: Tuesday, September 6, 2016 3:49 PM
To: development@qt-project.org
Subject: Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 06:20:34 PDT, Thiago Macieira
escreveu:
> Building the host tools while cross-compiling is a convenience and I think
> we  can keep it, but I don't think we should simply have different "bin"
> dirs.

Fail in sentence rewrite. I wanted to write "don't think we should mix" and
then rewrote to "think we should simply have different 'bin' dirs" -- except I
forgot to remove the "don't".

I don't have a cross-compiled build of Qt handy, but I think we put both host
and target builds in the same "bin" dir during the build. It should be easy to
split and then always build target tools too.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

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

Re: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64

[Laszlo Agocs]

It looks like the failures in https://codereview.qt-project.org/#/c/159484/ (we 
cannot currently build the bundled libxkbcommon with xkb support on these 
machines). The xkb stuff should be skipped in this case, but that recently went 
broken due to some configure cleanups. 
https://codereview.qt-project.org/#/c/169063 may fix this.


Laszlo



From: Development  on 
behalf of Marc Mutz 
Sent: Monday, August 29, 2016 1:01:48 PM
To: development@qt-project.org
Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64

Cf. attached posts.
--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Paolo Angelelli for Approver status

[Laszlo Agocs]

+1. Besides fixes he's been doing quite some new features as well. Keep them 
coming.


Cheers,

Laszlo



From: Development  on 
behalf of Eskil Abrahamsen Blomfeldt 
Sent: Friday, August 26, 2016 11:31 AM
To: development@qt-project.org
Subject: Re: [Development] Nominating Paolo Angelelli for Approver status



Den 26.08.2016 10:17, skrev Alexander Blasche:
> Hi,
>
> I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt 
> Company at the end of 2015, and has been working full time on Qt since. Paolo 
> has been actively involved fixing and improving QtPositioning and QtLocation.

+1

Paolo has been and is doing great work on Qt Location :)

--
Eskil Abrahamsen Blomfeldt
Senior Manager, R

The Qt Company
Sandakerveien 116
0484 Oslo, Norway
eskil.abrahamsen-blomfe...@qt.io
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] [QML][EGLFS] Bits depth

[Laszlo Agocs]

Hi Denis,


QSurfaceFormat::setDefaultFormat() with a format of red/blue/green set to 8, or 
alternatively setting QT_QPA_EGLFS_FORCE888 is indeed what you need. The 
default format with unspecified sizes results in choosing 16 over 32 bit 
configs when both are offered, that's normal.


Check with QSG_INFO what you get. It may either be 8880 or , depending on 
what is offered by the EGL implementation. As for the 24 bit depth, regardless 
of what X or EGL says, under the hood it is quite likely that you have 32 bit 
framebuffers anyway, true packed 24 bit ones are probably rare.


As for the "other bad issues", the flickering, that is the real issue here, but 
that's likely caused by something else outside of Qt's scope.


Best regards,

Laszlo


From: Denis Shienkov <denis.shien...@gmail.com>
Sent: Thursday, August 4, 2016 4:48:40 PM
To: development@qt-project.org; Laszlo Agocs
Subject: [QML][EGLFS] Bits depth

Hi guys,

I have use Qt 5.7 on Linux Embedded board (Toradex Apalis T30) with the EGLFS 
via X11 platform (NVidia drivers).

My QML application uses 24-bit PNG images. But I see that these images is looks 
like 16-bit (I see the gradients borders, and it looks ugly),
howewer my X11 uses DefaultDepth == 24!!!

Also this command:

{quote}
root@apalis-t30:~/deploy-apps# xdpyinfo | grep 'depth of root'
  depth of root window:24 planes
{quote}

shows 24-bit mode too.

Next, I have added this debug env variable:

{quote}
 export QSG_INFO=1
{quote}

to see what happens when my QML app starts:

{quote}
...
qt.scenegraph.general: threaded render loop
qt.scenegraph.general: Using sg animation driver
qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms
qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms
qt.scenegraph.general: texture atlas dimensions: 2048x2048
qt.scenegraph.general: R/G/B/A Buffers:5 6 5 0
qt.scenegraph.general: Depth Buffer:   16
qt.scenegraph.general: Stencil Buffer: 8
qt.scenegraph.general: Samples:0
qt.scenegraph.general: GL_VENDOR:  NVIDIA Corporation
qt.scenegraph.general: GL_RENDERER:NVIDIA Tegra 3
...
{quote}

I see that OpenGL (yes?) initializes with the "R/G/B/A Buffers:5 6 5 0" 
mode,
that is 16-bit depth!!! O_O

Next, I have tried to change the FB depth via:

{quote}
  fbset -fb /dev/fb1 -depth 24
{quote}

I see that FB changes own settings, but nothing changes when my app starts,
it still shows images ugly, as 16-bit depth.

Also I have tried to use QT_QPA_EGLFS_DEPTH variable (with 16, 24 or 32),
but nothing changes, not helps.

Helps only the QT_QPA_EGLFS_FORCE888 variable, but it introduces others bad 
issues,
like the whole/half HDMI display flickering.. So, I can not to use 
QT_QPA_EGLFS_FORCE888..

So, is there are any tricks to use 24-bit depth?

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

Re: [Development] Nominating Johan Helsing for Approver status

[Laszlo Agocs]

+1


Cheers,

Laszlo



From: Development  on 
behalf of Paul Tvete 
Sent: Thursday, August 4, 2016 12:22:58 PM
To: Qt development mailing list
Subject: [Development] Nominating Johan Helsing for Approver status

Hi all,


I'd like to nominate Johan Helsing for Approver status. He joined The Qt 
Company half a year ago, and has been working full time on Qt since. Johan has 
been actively involved in making the QtWaylandCompositor module ready for Qt 
5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 
5.7.

Here is his gerrit dashboard:

https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z

Johan's list of reviews can be found at:

https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d

Cheers,

- Paul


___
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] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

[Laszlo Agocs]

Sure, you could add something like that on top once the basic multiple QScreen 
support is in place. (for HDMI at least, replicating more or less what 
'tvservice' does. Not sure what (if any) API you have for other type of 
displays, though.)

Laszlo


From: Development <development-bounces+laszlo.agocs=qt...@qt-project.org> on 
behalf of Dominik Holland <dominik.holl...@pelagicore.com>
Sent: Tuesday, July 26, 2016 4:00 PM
To: development@qt-project.org
Subject: Re: [Development] Are there any limitations on implementing the 
changing of the screen for a QWindow on systems using EGLFS?

Hi,

Am 07/26/2016 um 03:33 PM schrieb Laszlo Agocs:
> Lack of contributions and suitable hardware setup. There was a patch for
> making the target screen configurable via an environment variable which
> never made it to integration. We are now reviving it for 5.6 at
> https://codereview.qt-project.org/#/c/166117/
>

Can't we do something similar to QT_QPA_EGLFS_KMS_CONFIG and share the
json file setup here as well ? This would make it way more consistent.

Dominik

>
> Additional patches for discovering and exposing all available screens as
> separate QScreens are welcome. Not entirely sure about the feasibility,
> especially when it comes to discovering and monitoring the connected
> outputs, but it is definitely worth a try.
>
>
> Best regards,
>
> Laszlo
>
>
> <https://codereview.qt-project.org/#/c/166117/>
>
> 
> *From:* Development
> <development-bounces+laszlo.agocs=qt...@qt-project.org> on behalf of
> Verebélyi Viktor <vvikt...@gmail.com>
> *Sent:* Sunday, July 24, 2016 8:28:15 AM
> *To:* development@qt-project.org
> *Subject:* [Development] Are there any limitations on implementing the
> changing of the screen for a QWindow on systems using EGLFS?
>
>
> I looked at the code for the EGLFS BRCM integration and the screen it
> uses is hard-coded. After trying some test code for Dispmanx it seems
> that it is fairly straight forward to change the screen it uses.
>
> My question is: Are there any limitations to implementing the functions
> that would allow us to change the screen using QWindows->setScreen()?
>
> The reason for why I'm asking is, because I'd like to implement this,
> but I'd like to know whether if this is not implemented beacuse of some
> limitations or because of lack of intrest/contributors?
>
>
>
> --
> - Viktor Verebelyi
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

--
Dominik Holland
SENIOR SOFTWARE ENGINEER

Pelagicore AG
Balanstr. 55, 81541 Munich, Germany
+49 (0)171 760 25 96
dominik.holl...@pelagicore.com
www.pelagicore.com<http://www.pelagicore.com>

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

Re: [Development] Are there any limitations on implementing the changing of the screen for a QWindow on systems using EGLFS?

[Laszlo Agocs]

Lack of contributions and suitable hardware setup. There was a patch for making 
the target screen configurable via an environment variable which never made it 
to integration. We are now reviving it for 5.6 at 
https://codereview.qt-project.org/#/c/166117/


Additional patches for discovering and exposing all available screens as 
separate QScreens are welcome. Not entirely sure about the feasibility, 
especially when it comes to discovering and monitoring the connected outputs, 
but it is definitely worth a try.


Best regards,

Laszlo





From: Development  on 
behalf of Verebélyi Viktor 
Sent: Sunday, July 24, 2016 8:28:15 AM
To: development@qt-project.org
Subject: [Development] Are there any limitations on implementing the changing 
of the screen for a QWindow on systems using EGLFS?


I looked at the code for the EGLFS BRCM integration and the screen it uses is 
hard-coded. After trying some test code for Dispmanx it seems that it is fairly 
straight forward to change the screen it uses.

My question is: Are there any limitations to implementing the functions that 
would allow us to change the screen using QWindows->setScreen()?

The reason for why I'm asking is, because I'd like to implement this, but I'd 
like to know whether if this is not implemented beacuse of some limitations or 
because of lack of intrest/contributors?


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

Re: [Development] Internal compiler error when building dev branch of qtbase with MSVC2015 on Windows 10

[Laszlo Agocs]

Yes. Same problem I complained about on IRC a few days ago. I was using VS2015 
Update 1 then. Installing VS2015 Update 2 fixed it. The CIs have Update 2 
installed as well.

BR,
Laszlo

-Original Message-
From: Development 
[mailto:development-bounces+laszlo.agocs=qt...@qt-project.org] On Behalf Of 
Mitch Curtis
Sent: Friday, May 20, 2016 11:11 AM
To: development@qt-project.org
Subject: [Development] Internal compiler error when building dev branch of 
qtbase with MSVC2015 on Windows 10

Is anyone else able to reproduce this? I configured Qt with the following 
arguments (shadow build):

-debug -developer-build -opensource -confirm-license -nomake tests -nomake 
examples -opengl desktop

If I use nmake instead of jom, the only error comes from qlogging.cpp.

I've attached the output of jom.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] FreeBSD / Clang / Raspberry Pi

[Laszlo Agocs]

Hello,

The device specs indeed assume cross-compiling (after all it's just a shorthand 
for -xplatform plus some common stuff to avoid duplication in the specs for 
each device) but note how for instance the linux-nuc-g++ device spec is used to 
build for an Intel device on an Intel host using an Intel compiler and sysroot. 
The architecture being the same all the way is not interesting, what matters is 
that there is a separate compiler and sysroot.

Therefore this won't be suitable in your case.

Introducing freebsd-clang-rasp-pi as a plain makespec works but does not sound 
very appealing as it is step back to the structure of device-specific makespecs 
from pre-Qt5 times. One alternative, out of my head, would be to add the 
support next to freebsd-clang and use -device-option with some custom, 
freebsd-clang-specific variable to trigger the RPi/ARM specifics - by doing a 
conditional include() for the RPi-specific snippet (or whatever device was 
specified, hence this would work just fine once you need to add FreeBSD support 
for some other device as well). Or something along these lines.

Best regards,
Laszlo



From: Development  on 
behalf of Sylvain Garrigues 
Sent: Tuesday, May 17, 2016 10:50 PM
To: development@qt-project.org
Subject: [Development] FreeBSD / Clang / Raspberry Pi

Hello,

I have ported Qt 5.6 to FreeBSD / Raspberry Pi and would like to share my 
config. I have a question though.

I have created a « device » mkspec (mkspecs/device/freebsd-rasp-pi-clang/ to 
follow the scheme) and I am using it with '-platform freebsd-clang -device 
freebsd-rasp-pi-clang’ but technically *I am not cross-compiling* as either the 
port is built on the Pi or it will later be on the FreeBSD packages building 
infrastructures which runs QEMU arm simulators which emulate a complete arm 
system (filesystem, kernel, etc). Therefore it’s always an arm compiler 
producing arm binaries on a freebsd system - no cross compiling.

So should I just create a mkspecs/freebsd-clang-rasp-pi/ in the top mkspecs 
folder and just use -platform freebsd-clang-rasp-pi? (no -device option)

I can see that using a device is triggering a cross_compile qmake feature with 
configure, and it has side effects (e.g. no stripping) - hence the question.

Happy to hear your thoughts.

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

Re: [Development] QT5 Beta 1 Android

[Laszlo Agocs]

Hi,

It misses screenSize.
android:configChanges=orientation|screenSize|keyboardHidden
should work.

Cheers,
Laszlo



On Mon, Nov 12, 2012 at 3:15 PM, Walter Horsten
walter.hors...@telenet.bewrote:

 Hi all,

 I don't think this works very well (or at all) with NativeActivity at the
 moment, I put configChanges:orientation in the manifest, but android
 insists on restarting the NativeActivity ... for example:

 activity android:name=android.app.NativeActivity
 android:label=@string/native_activity_name
 android:configChanges=orientation|keyboardHidden
 !-- Tell NativeActivity the name of our .so --
 meta-data android:name=android.app.lib_name
 android:value=qtqpatest/
 /activity

 Or am I missing something?

 Regards,
 Walter



 On Mon, Nov 12, 2012 at 1:33 PM, shane.kea...@accenture.com wrote:

  On Android it is possible to handle display orientation by yourself,
 not using the default behaviour of destroying and recreating the UI.

 You’d use OrientationEventListener  Display classes to detect the
 orientation then.

 This would make sense for a QML application where the scene graph can
 handle rotation of elements.

 ** **

 The android:configChanges element in the manifest file is used to specify
 what things the application can handle itself.

 ** **

 See also
 http://developer.android.com/guide/topics/resources/runtime-changes.html*
 ***

 -- 

 --
 This message is for the designated recipient only and may contain
 privileged, proprietary, or otherwise private information. If you have
 received it in error, please notify the sender immediately and delete the
 original. Any other use of the e-mail by you is prohibited.

 Where allowed by local law, electronic communications with Accenture and
 its affiliates, including e-mail and instant messaging (including content),
 may be scanned by our systems for the purposes of information security and
 assessment of internal compliance with Accenture policy.


 __

 www.accenture.com



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


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

Re: [Development] Removing Wacom support in Qt5

[Laszlo Agocs]

About the state of QTabletEvent in Qt 5: For platforms other than xcb this
event will never be delivered. To be on par with Qt 4 somebody needs to
step up and add support for Windows and OS X. The support on QPA level is
there in QWindowSystemInterface, now it's up to the platform plugins to do
something with it.

On Linux, QTabletEvents are supported, I added this a few months back using
my Wacom Bamboo. It should be considered experimental though. Event
delivery, position and pressure, proximity enter/leave seem to work. Other
things (e.g. additional properties like tilt which I cannot test with the
Bamboo) may not.

Laszlo

On Thu, Sep 6, 2012 at 10:41 AM, Boudewijn Rempt b...@valdyas.org wrote:

 On Thursday 06 September 2012 Sep, Thiago Macieira wrote:
  On quinta-feira, 6 de setembro de 2012 09.13.01, Boudewijn Rempt wrote:
But since I made the suggestion to remove it: if we can't get it
 tested
and  get it to work, just disable the support. No code needs to be
removed. Just make the loading of the Wacom DLL always fail.
  
   So, basically, QTabletEvent will still exist, but will be useless?
 
  It will never be delivered.

 Right, so it will be useless, then. Code will compile, but the application
 will be broken and porting to Qt5 will become a really difficult task.

 I know that there are problems with Qt and tablet support -- that with
 some versions of the wacom driver on Windows, there are way too many events
 happening for an application to manage, or that on Linux only Wacom tablets
 and no non-wacom tablets are supported and so on (though there's a patch in
 Jira for that).

 For me as an application developer, I wonder what the alternative would
 be. I guess to write two platform specific event handlers myself (win and
 X11, I cannot afford a Mac) and synthesize the QTabletEvents... Do a fund
 raiser to get me some different kinds of tablets and see how to support
 those.

 --
 Boudewijn Rempt
 http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
 ___
 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] Does the QtWidgets in Qt5 support touch event handling ?

[Laszlo Agocs]

Hi,

Yes, touch events are delivered to QWidgets too, just like in Qt 4.

Regards,
Laszlo

On 06/01/2012 11:16 AM, ext song.7@nokia.com wrote:


Hi,

In Qt5, does the QtWidgets support the touch event handling ?

That the touch event is routed from my side to system by invoking 
QWindowSystemInterface::handleTouchEvent...


Thanks,

Song



___
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] qpa api - current status

[Laszlo Agocs]

Hi,

 2. qwindowsysteminterface_qpa.h. This is a little tricky. We have
 qtestlib using it at this point because this is the way to send events
 to Qt. The API looks OK, can we make this public?

QWindowSystemInterface should not be public and is meant to be handled like the 
other QPA headers. Perhaps syncqt could be taught to treat qwindowsystem* the 
same way as qplatform* ?

Laszlo


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

Re: [Development] QWindowSystemInterface::handleMouseEvent() relative or absolute?

[Laszlo Agocs]

Hi,

Because windowing systems will usually provide absolute coordinates in 
their pointer events, hiding all the cursor management, raw event 
translation, etc. hassle from the clients. Also the Qt events contain 
absolute coordinates and in the end a handleMouseEvent() call is not 
much more then generating a QMouseEvent.

In your case there is no windowing system so it is up to the platform 
and generic plug-ins to implement all the needed logic. Like you 
noticed, if your system becomes complicated, having the loosely coupled 
'platform plug-in plus a bunch of generic plug-ins' combination might 
not be feasible anymore because you are effectively implementing your 
own windowing system and thus need to synchronize and translate the 
incoming raw events in a centralized manner instead of just blindly 
pumping out events (via QWindowSystemInterface calls) independently from 
each generic plug-in.

Cheers,
Laszlo


On 05/16/2012 02:19 AM, ext Johannes Zellner wrote:
 Hi,

 I am currently working on evdevmouse input fixes for the eglfs usecase.
 During the testing I had two mice in parallel .
 I saw that each mouse maintains its own position on the screen, because the
 QWindowSystemInterface::handleMouseEvent() takes only absolute coordinates.
 Wouldn't be relative coordinates better?

 Its hard to fix the issue of multiple mouse input devices, because the
 evdevmouse plugin itself could manage the coordinates and sync between
 multiple devices handled by the same plugin, but if the pointer position is
 manipulated by two different plugins we have a problem.

 This might be already discussed but I could not find an answer, why we choose
 to use absolute coordinates here.

 Thanks,
 Johannes
 ___
 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