Hi,
Not sure if this is what you want but recently I have implemented a dynamic
delegate usage by using the Component class.
DeviceParameterView had three types: button, option, slider. I want to render a
different delegate depending on the type of the parameter model. This was the
solution I
Thank you.
I suggest to add checksum files.
md5sum
906eaddf087a19ce294b529aab69a331 qt5-5.3.2-i486-1_SBo.tgz
sha1sum
894d3210262c987c03bcb389e6de6ae0057f7eb9 qt5-5.3.2-i486-1_SBo.tgz
On Sun, 16 Nov 2014 17:20:44 -0400
Rodrigo Gonçalves de Oliveira rodrigo.gol...@gmail.com wrote:
I've built
Nuno:
Thanks for this info.
I had not gotten a running example yet to determine performance,
but I figured if I could reduce that substantially if I embedded the
dynamic components inside the QML file that contained the Loader.
In your sample, you gave:
component =
Hello Mark.
Seems like the access of values in the listview does not work as you would
expect from what is written in the documentation.
The instanciated delegate is not treated as an actual child object and as such
does not have access to the references it would have if it was instanciated
On Monday 17 November 2014 12:54:59 René J.V. Bertin wrote:
Out of curiosity: is QEventLoopLocker thread-safe? That is, can the lock be
set (increased aka reference counter increment) in a background thread and
unset (decreased aka reference counter decrement) in the main thread? This
happens
On Monday November 17 2014 09:03:48 Thiago Macieira wrote:
Yes, it's thread-safe.
OK, thanks. :)
R.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
There is a QVector::resize
but no
QList::resize
Any design reason for this?
Philippe
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
On Monday November 17 2014 22:23:15 Philippe wrote:
There is a QVector::resize
but no
QList::resize
Any design reason for this?
Vector classes are often designed for speed (for instance to support SIMD
operations), lists for flexibility.
I don't know if that difference applies to QVector
Il 17/11/2014 22:23, Philippe ha scritto:
Any design reason for this?
No, simply nobody implemented it so far. (And given that QList is the
preferred return type in Qt APIs, I've hit my face against this many
many times. However there's the long trend of moving towards QVector...)
Hi List !
I narrowed down my previous Problem about beeing unable to draw exact
RGB device values...
The core problem is that i cannot really use native (CGContext) drawing
in Qt5 !
(Where it was working fine in Qt4).
When i show the Qwidget subclass containing my paintEvent there is a
short
On Monday 17 November 2014 22:47:51 Giuseppe D'Angelo wrote:
Il 17/11/2014 22:23, Philippe ha scritto:
Any design reason for this?
No, simply nobody implemented it so far. (And given that QList is the
preferred return type in Qt APIs, I've hit my face against this many
many times. However
I filed a bug: https://bugreports.qt-project.org/browse/QTBUG-42737
2014-11-16 16:24 GMT+03:00 Dmitrii Volosnykh dmitrii.volosn...@gmail.com:
By the way, it is unclear when canvas gets repainted on requestPaint():
some time when it becomes visible or immediately?
2014-11-16 16:21 GMT+03:00
12 matches
Mail list logo
