Re: [Development] [Interest] [Qt3D] Mixing C++ and QML
2017-10-19 20:44 GMT+02:00 Shawn Rutledge : > (thread started on the interest list, but I don’t think my comments belong > there) > > On Oct 19, 2017, at 18:06, Sean Harmer wrote: > > > Hi, > > > > you've hit one of the issues we did with exposing C++ and QML APIs. > Namely, QQmlListProperty. This thing should ideally never have existed and > instead support for properties of collections should have been added to > QObject and the metaobject system. > > What exactly do you think should be done there, in case we can fix it some > day? > > QObjects are normally managed as a tree for memory management purposes, so > I’ve also long disliked the fact that it doesn’t quite match the nesting of > the Item declarations in QML, because of the separate QList > childItems. It’s confusing and wastes memory. > > QQmlListProperty is flexible about storage, since you get to write all the > accessors, so you can maybe use it just for QML and also have normal C++ > API? > I have some gripes about QQmlListProperty too, maybe not the same ones. I agree that having a QQmlListProperty in a class supposed to be used from c++ looks alien. Having it supported in the meta object sure looks enticing at a first view. Maybe with something like Q_LIST_PROPERTY(ElementType list GET getFunction COUNT countFunction ...). That ends up being quite like a simplified QAIM without the roles and the signals. My other wish would be to be able to populate a QQmlListProperty from a model, and the general lack of support for models in the QML world (caused by the need to explicitly add support for models for your types) For example how do I add series from a model in a ChartView ? (this is embarrassing for what should be a data driven component) How can I populate the new Shape type from a model ? etc. Some types add explicit support for models, MapItemView for example, but this seems to be hard. Look at all the bugs related to MapItemView in the bug tracker (sorry Paolo, it's the first one that came to mind, I don't mean to be mean ;) ). And if you eventually manage to do it correctly, you still don't support dumb models like js array, integer, stringlist... You'll have to bring it complicated private stuff for it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Branch request: wip/webassembly in Qt Base
Hi, I would like to request a WIP branch in Qt Base: wip/webassembly Purpose is for the development of Qt for WebAssembly (http://webassembly.org) No CI is needed for this. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D 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 http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] [Qt3D] Mixing C++ and QML
Hi,
On 19/10/2017 19:44, Shawn Rutledge wrote:
(thread started on the interest list, but I don’t think my comments
belong there)
On Oct 19, 2017, at 18:06, Sean Harmer wrote:
Hi,
you've hit one of the issues we did with exposing C++ and QML APIs.
Namely, QQmlListProperty. This thing should ideally never have
existed and instead support for properties of collections should
have been added to QObject and the metaobject system.
What exactly do you think should be done there, in case we can fix it
some day?
Probably something like how NSObject manages properties of collections.
So far with Qt3D we've only needed the same level of semantics as
offered by QQmlListProperty - or rather we've worked within those
constraints. So a simple indexed container with the ability to
add/remove items.
In a more general setting I can easily also imagine support for
associative containers too.
The tricky part will be deciding which semantics do we wish to support
and where do we draw the line between such properties and recommending
to use a full-blown model instead.
Speaking of which, improving QAIM to be able to return data for
contiguous blocks of indices in one function call would be a really
welcome addition. Calling so many virtuals to retrieve a single data
value for a single index and role is not exactly efficient. The existing
QAIM API is fine for the existing views but doesn't scale well when
trying to use them to populate, say a buffer of per instance data on a
large scale. Yes I know we could avoid this with custom API but users
have so many models at this point it would be nice to offer some
interoperability with them.
QObjects are normally managed as a tree for memory management
purposes, so I’ve also long disliked the fact that it doesn’t quite
match the nesting of the Item declarations in QML, because of the
separate QList childItems. It’s confusing and wastes
memory.
We avoided that in Qt 3D and just use the regular parent-child
relationship. We don't have separation between visual parent and QObject
parent.
QQmlListProperty is flexible about storage, since you get to write
all the accessors, so you can maybe use it just for QML and also have
normal C++ API?
That's what we did. The C++ API has addComponent(), removeComponent(),
componentCount() type functions, and then we have libraries sat on top
for each aspect that add in the QQmlListProperty handling via extension
objects. For e.g.
http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3drender
A typical pattern in QtQuick is that a QQmlListProperty is the
default property, so declared children are automatically added. But
instead you have to declare the Components first, and then also add
them to a vector. Why is that? It seems needlessly cumbersome to
me. If Components are naturally always children of Entities,
^ that is your broken assumption. Components do not have to be children
of the entity. We actually started out with that but found that it
prohibits sharing components which can sometimes be handy.
then it
ought to be enough to declare them inside an Entity. But it seems
that any QNode can have any number of QNode children, so maybe you
could have a QQmlListPropery as the default property, whose
implementation uses the QObject children, just for convenience in
QML?
Also whilst I'm here, there's an annoying limitation in the QML language
that prevents mixing inline declaration of elements with elements
referenced by id in a list property. That is you cannot write something
like:
Mesh { id: mesh }
Material { id: material }
Entity {
components: [ Transform {}, material, mesh ]
}
If you think there’s something wrong with the normal QObject
parent/child relationship, then there’s another mechanism for
detecting declared QML “children" and doing “something special” with
them.
Do you mean the autoparent callback?
http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3d/qt3dquick_global.cpp#n676
We need this here because it's not enough for us to know that the parent
is a QObject. We need to know if it's a QNode to be able to add the new
child to the scene.
One possible future solution we discussed with Lars and Simon for this
is to make QObjectPrivate::setParent() virtual.
We use it to make each Window transient for whatever Window or
Item’s window that it was declared inside of, for adding
PointerHandlers to Items, and stuff like that: any case where one
object can be declared inside another, but it’s not quite a
conventional parent/child relationship, for example because the
“parent” and “child” aren’t the same kind of objects.
Either of those mechanisms can keep the syntax nice in QML.
To avoid pulling in a QtQml dependency in the C++ API, we instead
have another layer to add the QML specifics (pretty much entirely
list properties).
Ugh that would indeed be nice to simplify.
In order to create these from code we have a factory. Try something
like:
Re: [Development] [Interest] [Qt3D] Mixing C++ and QML
On 20/10/2017 09:06, Pierre-Yves Siret wrote: 2017-10-19 20:44 GMT+02:00 Shawn Rutledge mailto:shawn.rutle...@qt.io>>: (thread started on the interest list, but I don’t think my comments belong there) On Oct 19, 2017, at 18:06, Sean Harmer mailto:sean.har...@kdab.com>> wrote: > Hi, > > you've hit one of the issues we did with exposing C++ and QML APIs. Namely, QQmlListProperty. This thing should ideally never have existed and instead support for properties of collections should have been added to QObject and the metaobject system. What exactly do you think should be done there, in case we can fix it some day? QObjects are normally managed as a tree for memory management purposes, so I’ve also long disliked the fact that it doesn’t quite match the nesting of the Item declarations in QML, because of the separate QList childItems. It’s confusing and wastes memory. QQmlListProperty is flexible about storage, since you get to write all the accessors, so you can maybe use it just for QML and also have normal C++ API? I have some gripes about QQmlListProperty too, maybe not the same ones. I agree that having a QQmlListProperty in a class supposed to be used from c++ looks alien. Even worse, it pulls in a dependency on the QtQml module. Having it supported in the meta object sure looks enticing at a first view. Maybe with something like Q_LIST_PROPERTY(ElementType list GET getFunction COUNT countFunction ...). That ends up being quite like a simplified QAIM without the roles and the signals. Exactly, where to draw the line between simple properties of collections and full-blown models? Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] vertical text layout and https://codereview.qt-project.org/#/c/73319/2
I'm looking into vertical text layout in Qt, and the
only things I've been able to find are this old patch:
https://codereview.qt-project.org/#/c/73319/2 and the relevant
https://bugreports.qt.io/browse/QTBUG-529 .
I am wondering whether:
* there have been some other efforts since then that I just didn't manage
to find?
* the patch mentioned in the diff's comments ("don't worry, I have a
similar patch for HB-NG bridge in my queue") landed somewhere?
* and whether this patch was a move in the right direction. If so,
I might want to take a stab at reviving it, if not, I wonder what the
right direction would be.
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] [Qt3D] Mixing C++ and QML
> On 20 Oct 2017, at 12:33, Sean Harmer wrote:
>
> Hi,
>
> On 19/10/2017 19:44, Shawn Rutledge wrote:
>>
>> What exactly do you think should be done there, in case we can fix it
>> some day?
>
> Probably something like how NSObject manages properties of collections. So
> far with Qt3D we've only needed the same level of semantics as offered by
> QQmlListProperty - or rather we've worked within those constraints. So a
> simple indexed container with the ability to add/remove items.
>
> In a more general setting I can easily also imagine support for associative
> containers too.
We have dynamic properties at least.
> The tricky part will be deciding which semantics do we wish to support and
> where do we draw the line between such properties and recommending to use a
> full-blown model instead.
>
> Speaking of which, improving QAIM to be able to return data for contiguous
> blocks of indices in one function call would be a really welcome addition.
> Calling so many virtuals to retrieve a single data value for a single index
> and role is not exactly efficient. The existing QAIM API is fine for the
> existing views but doesn't scale well when trying to use them to populate,
> say a buffer of per instance data on a large scale. Yes I know we could avoid
> this with custom API but users have so many models at this point it would be
> nice to offer some interoperability with them.
So you want something like QVector dataRows(const QModelIndex
&startIndex, int rows, int role = Qt::DisplayRole)?
It’s been pointed out as somewhat of a bottleneck (for QtQuick applications at
least) that data() returns QVariant. But what sort of alternative is there for
C++ API?
>> A typical pattern in QtQuick is that a QQmlListProperty is the
>> default property, so declared children are automatically added. But
>> instead you have to declare the Components first, and then also add
>> them to a vector. Why is that? It seems needlessly cumbersome to
>> me. If Components are naturally always children of Entities,
>
> ^ that is your broken assumption. Components do not have to be children of
> the entity. We actually started out with that but found that it prohibits
> sharing components which can sometimes be handy.
“sometimes”… so maybe add declared child Components to the vector
automatically, but also allow sharing them by ID when necessary?
> Also whilst I'm here, there's an annoying limitation in the QML language that
> prevents mixing inline declaration of elements with elements referenced by id
> in a list property. That is you cannot write something like:
>
> Mesh { id: mesh }
> Material { id: material }
>
> Entity {
>components: [ Transform {}, material, mesh ]
> }
Is there a bug written up about that one?
>> If you think there’s something wrong with the normal QObject
>> parent/child relationship, then there’s another mechanism for
>> detecting declared QML “children" and doing “something special” with
>> them.
>
> Do you mean the autoparent callback?
>
> http://code.qt.io/cgit/qt/qt3d.git/tree/src/quick3d/quick3d/qt3dquick_global.cpp#n676
>
> We need this here because it's not enough for us to know that the parent is a
> QObject. We need to know if it's a QNode to be able to add the new child to
> the scene.
OK, it calls setParent but does not add it to the components vector.
> One possible future solution we discussed with Lars and Simon for this is to
> make QObjectPrivate::setParent() virtual.
Yeah that might work, but has a pervasive cost I suppose.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: > Are there any supported platforms that we do not test in the CI? Probably > INTEGRITY? > > [...] > > So the question is: are there any platforms that could break even after > passing the CI check? It would help us (Debian) a lot if Qt had something big endian on the CI. Currently big endian support breaks with almost every major Qt release. -- Dmitry Shachnev signature.asc Description: PGP signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
20.10.2017, 16:55, "Dmitry Shachnev" : > On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: >> Are there any supported platforms that we do not test in the CI? Probably >> INTEGRITY? >> >> [...] >> >> So the question is: are there any platforms that could break even after >> passing the CI check? > > It would help us (Debian) a lot if Qt had something big endian on the CI. > > Currently big endian support breaks with almost every major Qt release. Or at least use some kind of bi-endian compiler on little-endian host, with running unit tests > > -- > Dmitry Shachnev > , > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
On 20 October 2017 at 16:59, Konstantin Tokarev wrote: > > > 20.10.2017, 16:55, "Dmitry Shachnev" : >> On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: >>> Are there any supported platforms that we do not test in the CI? Probably >>> INTEGRITY? >>> >>> [...] >>> >>> So the question is: are there any platforms that could break even after >>> passing the CI check? >> >> It would help us (Debian) a lot if Qt had something big endian on the CI. >> >> Currently big endian support breaks with almost every major Qt release. > > Or at least use some kind of bi-endian compiler on little-endian host, with > running unit tests Any suggestions for what that something would be? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
20.10.2017, 17:03, "Ville Voutilainen" : > On 20 October 2017 at 16:59, Konstantin Tokarev wrote: >> 20.10.2017, 16:55, "Dmitry Shachnev" : >>> On Wed, Oct 11, 2017 at 01:23:58PM +0200, Thiago Macieira wrote: Are there any supported platforms that we do not test in the CI? Probably INTEGRITY? [...] So the question is: are there any platforms that could break even after passing the CI check? >>> >>> It would help us (Debian) a lot if Qt had something big endian on the CI. >>> >>> Currently big endian support breaks with almost every major Qt release. >> >> Or at least use some kind of bi-endian compiler on little-endian host, with >> running unit tests > > Any suggestions for what that something would be? I've found this on Intel side: https://software.intel.com/en-us/node/628867 I hope Thiago can tell us more about this option. I know PathScale had bi-endian compiler in the past, but I don't know if it's possible to obtain it now. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branch request: wip/webassembly in Qt Base
On Fri, Oct 20, 2017 at 12:02:42PM +0200, Eskil Abrahamsen Blomfeldt wrote: > I would like to request a WIP branch in Qt Base: wip/webassembly > > Purpose is for the development of Qt for WebAssembly > (http://webassembly.org) > how does this relate to this effort? https://codereview.qt-project.org/178543 > No CI is needed for this. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
On Friday, 20 October 2017 07:09:26 PDT Konstantin Tokarev wrote: > I've found this on Intel side: > > https://software.intel.com/en-us/node/628867 > > I hope Thiago can tell us more about this option. > > I know PathScale had bi-endian compiler in the past, but I don't know if > it's possible to obtain it now. That's a compiler to run on bi-endian systems, which I don't think anyone ever does. I've never seen this tool, I don't know if we could get access to it, and in any case I recommend against trying to do that. For every architecture where the processor can run in either endianness, the system chooses one and sticks to it, so all software is specifically compiled for that choice. It's also encoded in the Qt sysinfo name: $ $QTLIBDIR/libQt5Core.t.so | head -1 This is the QtCore library version Qt 5.10.0 (x86_64-little_endian-lp64 shared (dynamic) debug build; by GCC 7.2.1 20171005 [gcc-7-branch revision 253439]) See https://www.debian.org/releases/stable/i386/ch02s01.html.en armel - l for little endian mipsel - l for little endian mips64el- l for little endian ppc64el - l for little endian I'd recommend trying the mips build, though it doesn't have the "e" which I believe stands for either "embedded" or "EABI" (where the E stands for "embedded"). Yocto also defaults to big endian: $ file -L /opt/poky/2.3/sysroots/mips32r2-poky-linux/lib/libc.so.6 /opt/poky/2.3/sysroots/mips32r2-poky-linux/lib/libc.so.6: ELF 32-bit MSB shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, stripped -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any supported platforms not tested in CI?
20.10.2017, 18:14, "Thiago Macieira" : > On Friday, 20 October 2017 07:09:26 PDT Konstantin Tokarev wrote: >> I've found this on Intel side: >> >> https://software.intel.com/en-us/node/628867 >> >> I hope Thiago can tell us more about this option. >> >> I know PathScale had bi-endian compiler in the past, but I don't know if >> it's possible to obtain it now. > > That's a compiler to run on bi-endian systems, which I don't think anyone ever > does. I've never seen this tool, I don't know if we could get access to it, > and in any case I recommend against trying to do that. Oh, then I just confused it with similarly named tool from PathScale which was building code for running on little-endian machine but using big-endian memory layout (by inserting byte swapping code where needed) > > For every architecture where the processor can run in either endianness, the > system chooses one and sticks to it, so all software is specifically compiled > for that choice. It's also encoded in the Qt sysinfo name: > > $ $QTLIBDIR/libQt5Core.t.so | head -1 > This is the QtCore library version Qt 5.10.0 (x86_64-little_endian-lp64 shared > (dynamic) debug build; by GCC 7.2.1 20171005 [gcc-7-branch revision 253439]) > > See > https://www.debian.org/releases/stable/i386/ch02s01.html.en > armel - l for little endian > mipsel - l for little endian > mips64el - l for little endian > ppc64el - l for little endian > > I'd recommend trying the mips build, though it doesn't have the "e" which I > believe stands for either "embedded" or "EABI" (where the E stands for > "embedded"). Yocto also defaults to big endian: > > $ file -L /opt/poky/2.3/sysroots/mips32r2-poky-linux/lib/libc.so.6 > /opt/poky/2.3/sysroots/mips32r2-poky-linux/lib/libc.so.6: ELF 32-bit MSB > shared object, MIPS, MIPS32 rel2 version 1 (SYSV), dynamically linked, > interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, stripped > > -- > 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 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS 2017 QtCore sessions
On Tuesday, 10 October 2017 05:49:48 PDT Thiago Macieira wrote: > Move to the containers session: > * use qssize_t By the way, re: https://bugreports.qt.io/browse/QTBUG-47629 We should use 64-bit in QJsonPrivate too. Specifically, because of the way that the internal binary JSON format stores values, we steal 5 bits from all possible lengths, causing the maximum JSON data to be limited to 128 MB. Apparently, it's not that difficult to hit that limit today. Given that we have QJsonDocument::fromRawData / fromBinaryData as public API, we need to keep compatibility with version 1 input for at least a couple more years, so if we do this change, we either need to keep both codepaths available or we need to reindex version 1 data. Any volunteers to look into this? -- 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
