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 o
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,
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 descr
gards,
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 us
-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
m (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 classe
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 A
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 st
-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
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 describe
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
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 selecte
-
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
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 condition
+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 modu
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
behal
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 c
+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
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
* 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 runtim
Ouch, wrong link. The correct one is
https://codereview.qt-project.org/#/c/201648/
Laszlo
From: Development on
behalf of Laszlo Agocs
Sent: Thursday, August 3, 2017 3:57 PM
To: Quentin Schulz; development@qt-project.org
Cc: Thomas Petazzoni; Boris Brezillon
aszlo
From: Development on
behalf of Laszlo Agocs
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 drmMo
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 wor
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:
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
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
Sent: Friday, January 20, 2017 11:11:09 AM
To: La
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 s
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 th
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 ;
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 platfor
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 forev
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
Se
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
+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] N
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
Sent: Thursday, August 4, 2016 4:48:40 PM
To: developme
+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 Appr
_
From: Development on
behalf of Dominik Holland
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 La
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
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
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
Hi,
It misses screenSize.
android:configChanges="orientation|screenSize|keyboardHidden"
should work.
Cheers,
Laszlo
On Mon, Nov 12, 2012 at 3:15 PM, Walter Horsten
wrote:
> Hi all,
>
> I don't think this works very well (or at all) with NativeActivity at the
> moment, I put "configChanges:ori
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
som
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
QWindowSystem
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.
Regarding the input plugins: Once you reach a certain level of
complexity (that is, you need tighter integration between the input
subsystems and graphics, need device-specific workarounds, need to
support special embedded setups, etc.), you will find it easier and more
productive to simply fo
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 the
46 matches
Mail list logo
