Re: [Interest] Setting currentIndex in Qt Quick ComboBox does not work

[Fabian Sturm]

Hi,

here a short update, I think I finally cracked my problem! Somehow
setting currentIndex initially seems to break the model loading. But if
I leave that out and connect to onModelChanged it works. Final problem
was that the model loading was overriding my selected item. I solved
that by no longer updating the model in onCurrentIndexChanged but in
onActivated.

Here the qml binding code:

ComboBox {
id: combo

width: parent.width

model: mymodel.items
textRole: 'name'

onActivated: {
console.log('Activated')
mymodel.item = mymodel.items[index]
}

onModelChanged: {
console.log('modelChanged')
currentIndex = getCurrentIndex(mymodel.items, mymodel.item)
}

}

Thanks a lot,
Fabian


Am Mittwoch, den 23.03.2016, 22:24 +0100 schrieb Fabian Sturm:
> Hi Jerome!
> 
> Thanks a lot for your help and I already read the article and tried
> for
> another several hours. Unfortunately I still can only get one half
> working. Here is the new code for the event propagation:
> 
> ComboBox {
> id: combo
> width: parent.width
> model: mymodel.items // order is important
> currentIndex: getCurrentIndex(mymodel.items, mymodel.item)
> onCurrentIndexChanged: mymodel.item = model[currentIndex]
> textRole: 'name'
> Component.onCompleted: {
> combo.modelChanged.connect(modelUpdated)
> }
> function modelUpdated() {
> console.log('model updated')
> // tried to set the index here but the vaue is already
> overriden
> }
> }
> 
> With this the model is loaded first and then the index is set to the
> correct initial value. But with this solution I can only append to
> the
> model once and after the append, the index will be wrong.
> 
> I also don't seem to be able to save the currentIndex at the right
> time. Therefore a small working example would really be great!
> 
> My updated code is again at: 
> https://github.com/sturmf/python_samples/tree/master/pyqt_combobox
> 
> Thanks a lot,
> Fabian
> 
> Am Mittwoch, den 23.03.2016, 10:11 -0400 schrieb Jérôme Godbout:
> > Hi,
> > You have a binding problem here inside the combobox: 
> > currentIndex: getCurrentIndex(mymodel.items, mymodel.item)
> 
> > > 
> > > The sample source is here:
> > > https://github.com/sturmf/python_samples/tree/master/pyqt_combobo
> > > x
> > > 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QAbstractItemModel::layoutAboutToBeChanged

[Dmitry Volosnykh]

Bill, for example, you may have sorted rows. In this case all items are
still up to date, but they are rearranged visually. So, the view may do
some optimisations upon rendering this case, since the only thing it needs
is to reposition old items without the need to re-read theirs data.

On Thu, Mar 24, 2016 at 2:44 AM Bill Crocker 
wrote:

> Gang:
>
> The doc for QAbstractItemModel::layoutAboutToBeChanged() says...
>
>  This signal is emitted just before the layout of a model is changed.
>  Components connected to this signal use it to adapt to changes in the
> model's layout.
>
> What is the "layout of a model" and how does that differ from
> adding and removing rows and columns.
>
> Thanks.
>
> Bill
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Thiago Macieira]

On quarta-feira, 23 de março de 2016 21:49:41 PDT Scott Aron Bloom wrote:
> What does this flag do?  Is there an equivalent flag for CMake???

It makes rcc operate in a two-pass mode. Without it, resource compilation is:

$$QMAKE_RCC $$QMAKE_RESOURCE_FLAGS ${QMAKE_FILE_IN} -o ${QMAKE_FILE_OUT}

and the output file is then compiled.

With it, it becomes:

$$QMAKE_RCC $$QMAKE_RESOURCE_FLAGS ${QMAKE_FILE_IN} -pass 1 -o $$RCC_CPP 
&& \
$$RCC_CXX -c $$RCC_CPP $$RCC_CXX_O_FLAG$$RCC_TMP && \
$$QMAKE_RCC $$QMAKE_RESOURCE_FLAGS ${QMAKE_FILE_IN} -pass 2 -temp $
$RCC_TMP -o ${QMAKE_FILE_OUT}

In pass 1, rcc calculates the size of the data and simply fills it with zeroes. 
Then the compiler is called, to produce an object file. Then the second pass 
kicks in and fills the data in the dummy .o, producing the result.

Also note how the compiler is called without any optimisation flags, which is 
required (the compiler can't deduce that the data is zeroes) and also helps 
with the build time because then the compiler won't try to optimise.

This isn't enabled by default because it doesn't work under some scenarios:
 * LTCG
 * generators that don't support custom commands (Xcodeproj, for example)
 * object file formats that "compress" the data (a large section of zeroes is 
   highly compressible)

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

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Nye]

Hello,
> At one stage I thought about having a C++ object that could be created in
QML and would somehow keep count of references to the game object. For
example, each Loader whose source component has access to the game object
would somehow register itself with the object, and the game wouldn’t start
quitting until all references were gone. As long as the C++ doesn’t know
about the UI, I think it could work quite well.

Unfortunately my QML knowledge is quite rudimentary, however I believe
(correct me if I'm wrong) each component is a `QObject` instance and is
parented to the parent component and so on until you reach the root
context. So one thing that comes to mind is to "spy" (by installing an
event filter) on the root context for when children are added or removed
(QEvent::ChildAdded & QEvent::ChildRemoved) and if the children are Loaders
then count them up. Respectively when they're destroyed you decrease the
count and when it goes to zero you can unload/clean up. This approach would
(hopefully) lift the need to do this:

GameScope {

   game: root.game

}


Kind regards.

On Wed, Mar 23, 2016 at 10:41 AM, Curtis Mitch <
mitch.cur...@theqtcompany.com> wrote:

> Hi.
>
>
>
> That does help, thanks. It means that I’d really need to use an
> arbitrarily long timer, or find the “proper” solution.
>
>
>
> At one stage I thought about having a C++ object that could be created in
> QML and would somehow keep count of references to the game object. For
> example, each Loader whose source component has access to the game object
> would somehow register itself with the object, and the game wouldn’t start
> quitting until all references were gone. As long as the C++ doesn’t know
> about the UI, I think it could work quite well.
>
>
>
> Something like this:
>
>
>
> Loader {
>
> // ... contains GameView
>
> }
>
>
>
> // GameView.qml
>
>
>
> Item {
>
> id: root
>
> property alias game
>
>
>
> GameScope {
>
> game: root.game
>
> }
>
> }
>
>
>
> // GameScope.cpp
>
>
>
> GameScope::setGame(Game *game)
>
> {
>
> if (game == mGame)
>
> return;
>
>
>
> if (game)
>
> game->increaseReferenceCount();
>
> else
>
> game->decreaseReferenceCount();
>
>
>
> mGame = game;
>
> }
>
>
>
> GameScope::~GameScope()
>
> {
>
> if (game)
>
> game->decreaseReferenceCount();
>
> }
>
>
>
>
>
> Each event loop after a quit has been requested, Game could check the
> reference count and begin the actual quitting if it’s 0.
>
>
>
> It still feels like it shouldn’t be necessary, but at least there’s no
> guesswork involved.
>
>
>
> *From:* Nye [mailto:kshegu...@gmail.com]
> *Sent:* Tuesday, 22 March 2016 10:33 PM
> *To:* Curtis Mitch 
> *Cc:* interest@qt-project.org
> *Subject:* Re: [Interest] Ensuring that a queued invocation occurs after
> deferred deletion
>
>
>
> Hello,
>
> I don't work with QML, but I'm pretty sure the events are processed in the
> order of their appearance in the event queue. So if you have a
> `deleteLater` call (i.e. you have a QEvent::DeferredDelete, which is
> scheduled through the event loop) any queued call to a slot (i.e.
> QEvent::MetaCall) that was made before the deletion request should be
> happening before the actual deletion. So, if you're emitting signals from a
> single thread, their respective slots would be called in the order in which
> the signals had happened.
>
> Now, with multiple threads it's a bit tricky, since there's the chance
> that two threads will be trying to post a deferred function invocation at
> the same time (hence the event queue is protected by a mutex). However that
> mutex can't guarantee in what order the events will be posted, or rather no
> one can.
>
> > My only thought is to use a zero-second single-shot timer. The question
> is: is this guaranteed to happen *after* deferred deletion for a given
> iteration of an event loop?
>
> This posts a timer event on the queue, so you can achieve the same with
> QMetaObject::invokeMethod(receiverObject, "method", Qt::QueuedConnection),
> and the same "restrictions" apply as mentioned above.
>
> I hope this is of help.
> Kind regards.
>
>
>
> On Tue, Mar 22, 2016 at 7:50 PM, Curtis Mitch <
> mitch.cur...@theqtcompany.com> wrote:
>
>
> I recently discovered [1] that Loader defers deletion of items via
> deleteLater(). Up until that point, I had been treating certain operations
> in my program as synchronous (as I haven't introduced threads yet). Now
> that I can't safely assume that UI items will be instantly destroyed, I
> have to convert these operations into asynchronous ones.
>
> For example, previously, I had this code:
>
> game.quitGame();
>
> My idea is to turn it into this:
>
> game.requestQuitGame();
>
> Within this function, the Game object would set its "ready" property to
> false, emitting its associated property change signal so that Loaders can
> set active to false. Then, QMetaObject::invoke would be called with
> Qt::QueuedConnection to ensure that

[Interest] Two item models.

[william.croc...@analog.com]

Hello:

If I have a single data structure being presented to the world
by two, separate item models and I want to "insert a row".

I assume I would:
1 - call beginInsertRows on both models,
2 - insert the row in my single data structure
3 - call endInsertRows on both models.

I am pretty sure I am doing it correctly, but the ModelTest class
does not seem to like that.

Q_ASSERT(c.oldSize + (end - start + 1) == model->rowCount(parent));

Yes, I know, I should have a single model and use QIdentityProxyModel
for my alternate view. Pretend the question is academic. :-)

Thanks.

Bill


BTW: ModelTest is a life saver.
 Even if you think you know what you are doing.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Hamish Moffatt]

On 24/03/16 07:23, Thiago Macieira wrote:

On quarta-feira, 23 de março de 2016 16:39:02 EDT Jason H wrote:

I have a qrc devoted to media: audio and video. It's only about 100 megs
total of both (2 videos and several languages for each). It results in
about a 500MB cpp file. It takes 8 gigs to compile, which is what my
hardware ram is, so I spend a lot of time swapping.

Everytime I compile it takes 10 minutes to compile the assets.qrc, even
though it doesn't change. Is there a way that I can get the build system to
be more intelligent about building it?

CONFIG += resources_big



What does it do? It's not in the documentation in 5.5.1.


Hamish
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] QAbstractItemModel::layoutAboutToBeChanged

[Bill Crocker]

Gang:

The doc for QAbstractItemModel::layoutAboutToBeChanged() says...

This signal is emitted just before the layout of a model is changed.
Components connected to this signal use it to adapt to changes in the 
model's layout.


What is the "layout of a model" and how does that differ from
adding and removing rows and columns.

Thanks.

Bill
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jérôme Godbout]

Canvas
{
id: component
//...
renderStrategy: Canvas.Immediate
renderTarget: Canvas.FramebufferObject

onWidthChanged: requestPaint()
onHeightChanged: requestPaint()
onPaint: paintHandler()

function paintHandler()
{
var ctx = getContext('2d');
ctx.reset();
// clear with transparent
ctx.beginPath();
ctx.fillStyle = 'rgba(0,0,0,0)';
ctx.clearRect(0,0,width,height);
ctx.fill();
// Set general style
...
// Call draw functions here
...
}
}

At a few overhead near, this is what I do, the thing is clear, I guess my
ctx.reset() is the missing key here, I had problems too with this clear
thing with Qml Canvas where Html canvas where working perfectly fine with
the same code.

My guess is that the Widgets try to redraw as little as possible somehow,
not sure if a replacement to the requestPaint() or a function that will:
function myRequestPaint()
{
  markDirty(Qt.rect(0,0,width,height));
  requestPaint();
}

onWidthChanged: myRequestPaint()
onHeightChanged: myRequestPaint()

Hope this help you out, let me know if the makeDirty() change anything, I
may change my code for it too.

Jerome

On Wed, Mar 23, 2016 at 5:26 PM, Jason H  wrote:

> Thanks for the tip, but a few things:
> 1. I don't think clearRect uses fillStyle
> 2. I don't think clearRect needs a fill, as "clear" implies both color and
> fill op.
> http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_clearrect
>
>
> I had played with that, including your code, no luck.
> It looks like the Black Sabbath - Paraoid album cover.
>
>
> *Sent:* Wednesday, March 23, 2016 at 5:11 PM
> *From:* "Jérôme Godbout" 
> *To:* "Jason H" 
> *Cc:* "interest@qt-project.org Interest" 
> *Subject:* Re: [Interest] Canvas keeping artifacts
> You may want to clear fill with blank transparency:
>
> ctx.fillStyle = 'rgba(0,0,0,0)';
> ctx.clearRect(0,0,width,height);
> ctx.fill();
>
> for me it did the trick.
>
> On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:
>>
>> I have a very simple pause button:
>> Canvas {
>> id: pauseCanvas
>> anchors.fill: parent
>> onWidthChanged: requestPaint()
>> onHeightChanged: requestPaint()
>> onPaint: {
>> var ctx = getContext('2d');
>> ctx.save()
>> ctx.clearRect(0,0, width,height)
>> ctx.fillStyle = color;
>> ctx.rect(0.125*width, 0.05*height, 0.25*width,
>> 0.90*height);
>> ctx.fill();
>> ctx.rect(0.625*width, 0.05*height, 0.25*width,
>> 0.90*height);
>> ctx.fill();
>> ctx.restore();
>> }
>> }
>>
>> The problem is when I resize the window (which in turn resizes the
>> canvas), I get artifacts of previous draws. If the window is made larger
>> (corner drag or maximize) I can see the smaller original rectangles. And
>> vice-versa.
>>
>> How can I get Canvas to play nice?
>>
>>
>> ___
>> Interest mailing list
>> Interest@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Scott Aron Bloom]

-Original Message-
From: Interest [mailto:interest-bounces+scott=towel42@qt-project.org] On 
Behalf Of Jason H
Sent: Wednesday, March 23, 2016 2:41 PM
To: Thiago Macieira
Cc: interest@qt-project.org
Subject: Re: [Interest] Very large QRC file

> Sent: Wednesday, March 23, 2016 at 4:23 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Very large QRC file
>
> On quarta-feira, 23 de março de 2016 16:39:02 EDT Jason H wrote:
> > I have a qrc devoted to media: audio and video. It's only about 100 
> > megs total of both (2 videos and several languages for each). It 
> > results in about a 500MB cpp file. It takes 8 gigs to compile, which 
> > is what my hardware ram is, so I spend a lot of time swapping.
> > 
> > Everytime I compile it takes 10 minutes to compile the assets.qrc, 
> > even though it doesn't change. Is there a way that I can get the 
> > build system to be more intelligent about building it?
> 
> CONFIG += resources_big


 Nice. Since 5.4. Never knew. "Just works". Thanks!


What does this flag do?  Is there an equivalent flag for CMake???

Scott

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Jason H]

> Sent: Wednesday, March 23, 2016 at 4:23 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] Very large QRC file
>
> On quarta-feira, 23 de março de 2016 16:39:02 EDT Jason H wrote:
> > I have a qrc devoted to media: audio and video. It's only about 100 megs
> > total of both (2 videos and several languages for each). It results in
> > about a 500MB cpp file. It takes 8 gigs to compile, which is what my
> > hardware ram is, so I spend a lot of time swapping.
> > 
> > Everytime I compile it takes 10 minutes to compile the assets.qrc, even
> > though it doesn't change. Is there a way that I can get the build system to
> > be more intelligent about building it?
> 
> CONFIG += resources_big


 Nice. Since 5.4. Never knew. "Just works". Thanks!
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jason H]

Thanks for the tip, but a few things:

1. I don't think clearRect uses fillStyle

2. I don't think clearRect needs a fill, as "clear" implies both color and fill op. http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_canvas_clearrect

 

 

I had played with that, including your code, no luck.

It looks like the Black Sabbath - Paraoid album cover. 

 

 

Sent: Wednesday, March 23, 2016 at 5:11 PM
From: "Jérôme Godbout" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Canvas keeping artifacts


You may want to clear fill with blank transparency:

 

ctx.fillStyle = 'rgba(0,0,0,0)';

ctx.clearRect(0,0,width,height);

ctx.fill();


 

for me it did the trick.


 
On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:

I have a very simple pause button:
        Canvas {
                id: pauseCanvas
                anchors.fill: parent
                onWidthChanged: requestPaint()
                onHeightChanged: requestPaint()
                onPaint: {
                        var ctx = getContext('2d');
                        ctx.save()
                        ctx.clearRect(0,0, width,height)
                        ctx.fillStyle = color;
                        ctx.rect(0.125*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.rect(0.625*width, 0.05*height, 0.25*width, 0.90*height);
                        ctx.fill();
                        ctx.restore();
                }
        }

The problem is when I resize the window (which in turn resizes the canvas), I get artifacts of previous draws. If the window is made larger (corner drag or maximize) I can see the smaller original rectangles. And vice-versa.

How can I get Canvas to play nice?


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest






___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Setting currentIndex in Qt Quick ComboBox does not work

[Fabian Sturm]

Hi Jerome!

Thanks a lot for your help and I already read the article and tried for
another several hours. Unfortunately I still can only get one half
working. Here is the new code for the event propagation:

ComboBox {
id: combo
width: parent.width
model: mymodel.items // order is important
currentIndex: getCurrentIndex(mymodel.items, mymodel.item)
onCurrentIndexChanged: mymodel.item = model[currentIndex]
textRole: 'name'
Component.onCompleted: {
combo.modelChanged.connect(modelUpdated)
}
function modelUpdated() {
console.log('model updated')
// tried to set the index here but the vaue is already
overriden
}
}

With this the model is loaded first and then the index is set to the
correct initial value. But with this solution I can only append to the
model once and after the append, the index will be wrong.

I also don't seem to be able to save the currentIndex at the right
time. Therefore a small working example would really be great!

My updated code is again at: 
https://github.com/sturmf/python_samples/tree/master/pyqt_combobox

Thanks a lot,
Fabian

Am Mittwoch, den 23.03.2016, 10:11 -0400 schrieb Jérôme Godbout:
> Hi,
> You have a binding problem here inside the combobox: 
> currentIndex: getCurrentIndex(mymodel.items, mymodel.item)

> > 
> > The sample source is here:
> > https://github.com/sturmf/python_samples/tree/master/pyqt_combobox
> > 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Canvas keeping artifacts

[Jérôme Godbout]

You may want to clear fill with blank transparency:

ctx.fillStyle = 'rgba(0,0,0,0)';
ctx.clearRect(0,0,width,height);
ctx.fill();

for me it did the trick.

On Wed, Mar 23, 2016 at 4:54 PM, Jason H  wrote:

> I have a very simple pause button:
> Canvas {
> id: pauseCanvas
> anchors.fill: parent
> onWidthChanged: requestPaint()
> onHeightChanged: requestPaint()
> onPaint: {
> var ctx = getContext('2d');
> ctx.save()
> ctx.clearRect(0,0, width,height)
> ctx.fillStyle = color;
> ctx.rect(0.125*width, 0.05*height, 0.25*width,
> 0.90*height);
> ctx.fill();
> ctx.rect(0.625*width, 0.05*height, 0.25*width,
> 0.90*height);
> ctx.fill();
> ctx.restore();
> }
> }
>
> The problem is when I resize the window (which in turn resizes the
> canvas), I get artifacts of previous draws. If the window is made larger
> (corner drag or maximize) I can see the smaller original rectangles. And
> vice-versa.
>
> How can I get Canvas to play nice?
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Canvas keeping artifacts

[Jason H]

I have a very simple pause button:
Canvas {
id: pauseCanvas
anchors.fill: parent
onWidthChanged: requestPaint()
onHeightChanged: requestPaint()
onPaint: {
var ctx = getContext('2d');
ctx.save()
ctx.clearRect(0,0, width,height)
ctx.fillStyle = color;
ctx.rect(0.125*width, 0.05*height, 0.25*width, 
0.90*height);
ctx.fill();
ctx.rect(0.625*width, 0.05*height, 0.25*width, 
0.90*height);
ctx.fill();
ctx.restore();
}
}

The problem is when I resize the window (which in turn resizes the canvas), I 
get artifacts of previous draws. If the window is made larger (corner drag or 
maximize) I can see the smaller original rectangles. And vice-versa. 

How can I get Canvas to play nice?


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Thiago Macieira]

On quarta-feira, 23 de março de 2016 16:39:02 EDT Jason H wrote:
> I have a qrc devoted to media: audio and video. It's only about 100 megs
> total of both (2 videos and several languages for each). It results in
> about a 500MB cpp file. It takes 8 gigs to compile, which is what my
> hardware ram is, so I spend a lot of time swapping.
> 
> Everytime I compile it takes 10 minutes to compile the assets.qrc, even
> though it doesn't change. Is there a way that I can get the build system to
> be more intelligent about building it?

CONFIG += resources_big

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

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[André Pönitz]

On Wed, Mar 23, 2016 at 04:39:02PM +0100, Jason H wrote:
> I have a qrc devoted to media: audio and video. It's only about 100
> megs total of both (2 videos and several languages for each). It
> results in about a 500MB cpp file. It takes 8 gigs to compile, which
> is what my hardware ram is, so I spend a lot of time swapping.
> 
> Everytime I compile it takes 10 minutes to compile the assets.qrc,
> even though it doesn't change. Is there a way that I can get the build
> system to be more intelligent about building it?

Do you have 

CONFIG += resources_big

in your .pro?

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

Re: [Interest] Qt Quick Controls 2 Button Fails in GridView

[Nurmi J-P]

> On 23 Mar 2016, at 18:24, Mark R Youngquist 
>  wrote:
> 
> I've been enjoying my time with using the QtQuick Controls in the labs 
> portion of Qt 5.6
> 
> I have a scenario where I use a GridView with a delegate Button component 
> with a custom background property.  Once I run the application and scroll 
> through the grid I receive several errors in my output and an equivalent 
> number of blank spaces in the grid itself.  As soon as I remove my custom 
> background, everything works great.  This occurs on both desktop and embedded 
> builds.
> 
> The main.qml code is as follows:
> 
> import QtQuick 2.6
> import Qt.labs.controls 1.0
> ApplicationWindow {
> visible: true
> width: 640
> height: 480
> 
> GridView {
> id: gridThing;
> anchors.fill: parent;
> cellWidth: 75;
> cellHeight: 75;
> model: 500;
> 
> delegate: Button {
> id: control
> text: "Test"
> width: gridThing.cellWidth;
> height: gridThing.cellHeight;
> background: Rectangle {
> implicitHeight: 20;
> implicitWidth: 20;
> color: "red";
> width: control.width;
> height: control.height;
> x: 0;
> y: 0;
> }
> }
> }
> }
> 
> Is anyone else experiencing this problem or have a recommendation for 
> troubleshooting this?

Hi Mark,

Looks strange. Please file a bug. I can see some ": QML 
VisualDataModel: Error creating delegate” messages, but it requires some 
debugging to figure out what’s actually going on there.

--
J-P Nurmi

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Qt Quick Controls 2 Button Fails in GridView

[Mark R Youngquist]

I've been enjoying my time with using the QtQuick Controls in the labs portion 
of Qt 5.6


I have a scenario where I use a GridView with a delegate Button component with 
a custom background property.  Once I run the application and scroll through 
the grid I receive several errors in my output and an equivalent number of 
blank spaces in the grid itself.  As soon as I remove my custom background, 
everything works great.  This occurs on both desktop and embedded builds.


The main.qml code is as follows:


import QtQuick 2.6
import Qt.labs.controls 1.0
ApplicationWindow {
visible: true
width: 640
height: 480

GridView {
id: gridThing;
anchors.fill: parent;
cellWidth: 75;
cellHeight: 75;
model: 500;

delegate: Button {
id: control
text: "Test"
width: gridThing.cellWidth;
height: gridThing.cellHeight;
background: Rectangle {
implicitHeight: 20;
implicitWidth: 20;
color: "red";
width: control.width;
height: control.height;
x: 0;
y: 0;
}
}
}
}

Is anyone else experiencing this problem or have a recommendation for 
troubleshooting this?





Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir 
des informations sensibles et/ ou confidentielles ne devant pas être 
divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous 
recevez ce message par erreur), nous vous remercions de le notifier 
immédiatement à son expéditeur, et de détruire ce message. Toute copie, 
divulgation, modification, utilisation ou diffusion, non autorisée, directe ou 
indirecte, de tout ou partie de ce message, est strictement interdite.
Se désabonner: Si vous souhaitez être retiré de notre liste de diffusion, s'il 
vous plaît envoyer vos coordonnées à 
casl.unsubscr...@legrand.ca et indiquer 
quels sont les messages que vous ne souhaitez plus recevoir.


This e-mail, and any document attached hereby, may contain confidential and/or 
privileged information. If you are not the intended recipient (or have received 
this e-mail in error) please notify the sender immediately and destroy this 
e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution 
or other use of the material or parts thereof is strictly forbidden.
Unsubscribe: If you would like to be removed from our mailing list, please send 
your contact information to 
casl.unsubscr...@legrand.ca and indicate 
what messages you no longer wish to receive.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Konstantin Tokarev]

23.03.2016, 19:11, "André Somers" :
> Op 23/03/2016 om 17:04 schreef Konstantin Tokarev:
>>  23.03.2016, 19:03, "Sean Harmer" :
>>>  On Wednesday 23 March 2016 16:57:04 Jason H wrote:
>>>  Notice the -no-compress option too this can save runtime CPu costs
>>>  involved with decompressing the data especially for already
>>>  compressed formats such as most video codecs.
>>  I haven't noticed any difference when using this option with png assets, 
>> resulting files were byte-identical
>
> That's because qrc is clever enough to not even try compressing pngs. It
> doesn't know about all possible file types though.

No. It just checks if each file compresses well[1], otherwise file is stored
without compression.

[1] See -threshold argument of rcc.
By default it is 70 which means that reduction must be >= 70 %

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse

[Elvis Stansvik]

2016-03-23 17:40 GMT+01:00 Elvis Stansvik :
> Hi Martin,
>
> (and sorry in advance for the line breaks in the inline quotations of
> your mail below, seems GMail mis-parsed something).
>
> 2016-03-22 22:38 GMT+01:00 Martin Leutelt :
>> Von: Elvis Stansvik 
>> An: "interest@qt-project.org Interest" 
>> Gesendet: 22.03.2016 20:19
>> Betreff: Re: [Interest] Structuring of QML app as set of interlinked screens
>> for maximum code reuse
>>
>> 2016-03-22 20:13 GMT+01:00 Elvis Stansvik :
>>> Hi all,
>>>
>>> I'm working on a fullscreen Qt Quick/QML app (for machine control)
>>> which will consist of a set of interlinked screens, with key presses
>>> as the only interaction method.
>>>
>>> Each screen will have roughly the following QML structure:
>>>
>>> Rectangle {
>>>
>>> NavBar {
>>> id: topBar
>>> ...
>>> controls for navigation and information stuff,
>>> different depending on which screen
>>> ...
>>> }
>>>
>>> Rectangle {
>>> id: topSeparator
>>> ...
>>> aesthetic divider rectangle between top nav bar and content.
>>> ...
>>> }
>>>
>>> Rectangle {
>>> id: content
>>> ...
>>> main content here, different depending on which screen.
>>> ...
>>> }
>>>
>>> Rectangle {
>>> id: bottomSeparator
>>> ...
>>> aesthetic divider rectangle between top nav bar and content.
>>> ...
>>> }
>>>
>>> NavBar {
>>> id: bottomBar
>>> ...
>>> controls for navigation and information stuff,
>>> different depending on which screen
>>> ...
>>> }
>>> }
>>
>> To clarify, think of NavBar as just another Rectangle in the example
>> above. It's just a custom item with some common visual properties.
>>
>> Elvis
>>
>>>
>>> And I'm now trying to find a good structure that will minimize
>>> repetition of QML code.
>>
>>
>> Since you already know that every screen will have two NavBars and
>> separators
>>
>> why don't you use your current QML structure as a skeleton for the whole
>> application?
>>
>> The content area could then be a thing that loads the 'pages' of your
>> application. Take a
>>
>> look at elements like StackView, TabView and ListView (in combination with
>> Loader as a delegate) which
>>
>> already provide a mechanism to navigate between (dynamic) content...
>
> Thanks a lot for the pointers, I had been looking at StackView for
> doing the navigation between pages (though see my question about Qt
> Quick Controls below).

And of course I forgot to include the question I referred to above. I
was going to ask: Do you think using Qt Quick Controls would be a good
idea for an app like this? I'm a bit hesitant as I know we'll want a
completely custom look, and in many cases probably a quite custom
behavior for making input (due to the limited input devices), and fear
that I'll have to shoehorn a lot of this look/behavior if using Quick
Controls (or another component library which makes a lot of
assumptions).

Elvis

>
> The approach you describe sounds good. I think the reason I didn't
> think of it at first was that I didn't know about the possibility of
> having my "pages" provide a model for use by the navigation bars (like
> you describe further on). I'm completely new to Quick / QML, so still
> learning the ropes.
>
>>
>>
>>>
>>> I understand that QMLs main model for code reuse is composition, but
>>> that it also has a form of "inheritance": by defining a new Item in a
>>> separate file using another Item as the top level item and redefining
>>> some of its properties, I'm sort of inheriting that item.
>>>
>>> I could save the above general structure in a Screen.qml, and in
>>> FooScreen.qml, BarScreen et.c. do:
>>>
>>> Screen {
>>> ...
>>> override some properties
>>> ...
>>> }
>>>
>>> But this will only allow me to redefine properties, and add new child
>>> items. How would I then be able to define both which content goes in
>>> the main area (the content Rectangle in the "base" item) and in the
>>> two navigation bars (topBar and bottomBar Rectangles)?
>>>
>>
>>
>> The content of your NavBars could be defined by models (maybe either
>> ListModel or
>>
>> something more advanced), at least that's what I would suggest. Either each
>> 'page' of
>>
>> your application defines a model for both the upper and the lower NavBar and
>> these
>>
>> models are then used to dynamically create the appropriate content OR your
>>
>> application switches the content of the NavBars based on whatever state the
>> application
>>
>> is currently in.
>
> That makes a lot of sense. My only question is: If my "pages" provide
> the models to be used for the top/bottom navbar, where would I define
> the behavior for the navigational items in the bars? (the actual
> interlinking of pages so to speak).
>
> Just to clarify: Some of the actions in these bars will not be
> navigational in nature, but should perform an action.
>
> 

Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse

[Elvis Stansvik]

Hi Martin,

(and sorry in advance for the line breaks in the inline quotations of
your mail below, seems GMail mis-parsed something).

2016-03-22 22:38 GMT+01:00 Martin Leutelt :
> Von: Elvis Stansvik 
> An: "interest@qt-project.org Interest" 
> Gesendet: 22.03.2016 20:19
> Betreff: Re: [Interest] Structuring of QML app as set of interlinked screens
> for maximum code reuse
>
> 2016-03-22 20:13 GMT+01:00 Elvis Stansvik :
>> Hi all,
>>
>> I'm working on a fullscreen Qt Quick/QML app (for machine control)
>> which will consist of a set of interlinked screens, with key presses
>> as the only interaction method.
>>
>> Each screen will have roughly the following QML structure:
>>
>> Rectangle {
>>
>> NavBar {
>> id: topBar
>> ...
>> controls for navigation and information stuff,
>> different depending on which screen
>> ...
>> }
>>
>> Rectangle {
>> id: topSeparator
>> ...
>> aesthetic divider rectangle between top nav bar and content.
>> ...
>> }
>>
>> Rectangle {
>> id: content
>> ...
>> main content here, different depending on which screen.
>> ...
>> }
>>
>> Rectangle {
>> id: bottomSeparator
>> ...
>> aesthetic divider rectangle between top nav bar and content.
>> ...
>> }
>>
>> NavBar {
>> id: bottomBar
>> ...
>> controls for navigation and information stuff,
>> different depending on which screen
>> ...
>> }
>> }
>
> To clarify, think of NavBar as just another Rectangle in the example
> above. It's just a custom item with some common visual properties.
>
> Elvis
>
>>
>> And I'm now trying to find a good structure that will minimize
>> repetition of QML code.
>
>
> Since you already know that every screen will have two NavBars and
> separators
>
> why don't you use your current QML structure as a skeleton for the whole
> application?
>
> The content area could then be a thing that loads the 'pages' of your
> application. Take a
>
> look at elements like StackView, TabView and ListView (in combination with
> Loader as a delegate) which
>
> already provide a mechanism to navigate between (dynamic) content...

Thanks a lot for the pointers, I had been looking at StackView for
doing the navigation between pages (though see my question about Qt
Quick Controls below).

The approach you describe sounds good. I think the reason I didn't
think of it at first was that I didn't know about the possibility of
having my "pages" provide a model for use by the navigation bars (like
you describe further on). I'm completely new to Quick / QML, so still
learning the ropes.

>
>
>>
>> I understand that QMLs main model for code reuse is composition, but
>> that it also has a form of "inheritance": by defining a new Item in a
>> separate file using another Item as the top level item and redefining
>> some of its properties, I'm sort of inheriting that item.
>>
>> I could save the above general structure in a Screen.qml, and in
>> FooScreen.qml, BarScreen et.c. do:
>>
>> Screen {
>> ...
>> override some properties
>> ...
>> }
>>
>> But this will only allow me to redefine properties, and add new child
>> items. How would I then be able to define both which content goes in
>> the main area (the content Rectangle in the "base" item) and in the
>> two navigation bars (topBar and bottomBar Rectangles)?
>>
>
>
> The content of your NavBars could be defined by models (maybe either
> ListModel or
>
> something more advanced), at least that's what I would suggest. Either each
> 'page' of
>
> your application defines a model for both the upper and the lower NavBar and
> these
>
> models are then used to dynamically create the appropriate content OR your
>
> application switches the content of the NavBars based on whatever state the
> application
>
> is currently in.

That makes a lot of sense. My only question is: If my "pages" provide
the models to be used for the top/bottom navbar, where would I define
the behavior for the navigational items in the bars? (the actual
interlinking of pages so to speak).

Just to clarify: Some of the actions in these bars will not be
navigational in nature, but should perform an action.

Should I define some central state machine? I've understood by now
that each QML item actually has a state machine, but this is primarily
meant for the visual state of the item in question (?).

>
>
>> It seems QML is not really meant to be used this way, and I'd have to
>> essentially redefine these things in each of my screens, even if
>> they'll all have the same general structure? There's no "template"
>> mechanism so to speak?
>>
>
>
> I think your example fits QML rather fine. Your application seems to be the
> typical
>
> page-based mobile application, only limited to key interaction instead of
> touch/mouse.

Yes, sorry, I didn't mean to suggest QML isn't up to the task. Just
that it's not 

Re: [Interest] Very large QRC file

[Jason H]

> 
> mac {
> asset_builder.output = 
> $$OUT_PWD/VideoPlayerHIV.app/Contents/MacOs/${QMAKE_FILE_IN_BASE}.qrb
> } else {
> asset_builder.output = $$OUT_PWD/${QMAKE_FILE_IN_BASE}.qrb
> }
> 
> Or similar.


Most excellent. Thank you.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Sean Harmer]

On Wednesday 23 March 2016 17:28:21 Jason H wrote:
> > Notice the -no-compress option too this can save runtime CPu costs
> > involved
> > with decompressing the data especially for already compressed formats such
> > as most video codecs.
> > 
> > Then in your c++ source add:
> > 
> > QResource::registerResource("mybigmedia.qrb");
> > 
> > and use it just like any other resource. Just remember to deploy the qrb
> > file with your app.
> 
> Thanks, that seems to have fixed my compile time, but the call to
> registerResource fails. int main(int argc, char *argv[])
> {
>   QGuiApplication app(argc, argv);
>   qDebug() << "registerResource" << 
QResource::registerResource("media.qrb");
> // FALSE
> 
>   QQmlApplicationEngine engine;
>   engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
> 
>   return app.exec();
> }
> 
> However the build directory contains: media.qrb (100mb)
> However when the app is launched it is that build dir plus
> "VideoPlayerHIV.app/Contents/MacOS"
> 
> How can I set this up in a platform independent way? (Develop on OSX, deploy
> to iOS/Android)

mac {
asset_builder.output = 
$$OUT_PWD/VideoPlayerHIV.app/Contents/MacOs/${QMAKE_FILE_IN_BASE}.qrb
} else {
asset_builder.output = $$OUT_PWD/${QMAKE_FILE_IN_BASE}.qrb
}

Or similar.

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Jason H]

> Op 23/03/2016 om 16:57 schreef Jason H:
> > Not sure. This is an app for a tablet, I've always packaged assets in qrc, 
> > because it "just worked". I could try DISTFILES, but I'm unsure how that 
> > work on mobile platforms.
> Please don't. Don't fill your users' devices with assets they are not 
> going to use, like video or audio for different languages. It doesn't 
> scale. Instead, get the right contents for your application on demand 
> when first requested, so you only store on the users device what the 
> user actually needs.

Normally, I would agree with you, but we are deploying the app to 
connectivity-limited areas. We get one shot to load the tablet.  Not everywhere 
on the planet has it as good as the western world.

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Jason H]

> Notice the -no-compress option too this can save runtime CPu costs involved 
> with decompressing the data especially for already compressed formats such as 
> most video codecs.
> 
> Then in your c++ source add:
> 
> QResource::registerResource("mybigmedia.qrb");
> 
> and use it just like any other resource. Just remember to deploy the qrb file 
> with your app.


Thanks, that seems to have fixed my compile time, but the call to 
registerResource fails.
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
qDebug() << "registerResource" << 
QResource::registerResource("media.qrb"); // FALSE

QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));

return app.exec();
}

However the build directory contains: media.qrb (100mb)
However when the app is launched it is that build dir plus 
"VideoPlayerHIV.app/Contents/MacOS"

How can I set this up in a platform independent way? (Develop on OSX, deploy to 
iOS/Android)
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[André Somers]

Op 23/03/2016 om 16:57 schreef Jason H:

Not sure. This is an app for a tablet, I've always packaged assets in qrc, because it 
"just worked". I could try DISTFILES, but I'm unsure how that work on mobile 
platforms.
Please don't. Don't fill your users' devices with assets they are not 
going to use, like video or audio for different languages. It doesn't 
scale. Instead, get the right contents for your application on demand 
when first requested, so you only store on the users device what the 
user actually needs.


André





Sent: Wednesday, March 23, 2016 at 11:41 AM
From: "Gian Maxera" 
To: "Jason H" 
Cc: "interest@qt-project.org Interest" 
Subject: Re: [Interest] Very large QRC file

My absolute rule is Never Never put big files into qrc file.
Can you avoid it too ?


On 23 Mar 2016, at 15:39, Jason H  wrote:

I have a qrc devoted to media: audio and video. It's only about 100 megs total 
of both (2 videos and several languages for each). It results in about a 500MB 
cpp file. It takes 8 gigs to compile, which is what my hardware ram is, so I 
spend a lot of time swapping.

Everytime I compile it takes 10 minutes to compile the assets.qrc, even though 
it doesn't change. Is there a way that I can get the build system to be more 
intelligent about building it?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Sean Harmer]

On Wednesday 23 March 2016 17:10:35 André Somers wrote:
> Op 23/03/2016 om 17:04 schreef Konstantin Tokarev:
> > 23.03.2016, 19:03, "Sean Harmer" :
> >> On Wednesday 23 March 2016 16:57:04 Jason H wrote:
> >> Notice the -no-compress option too this can save runtime CPu costs
> >> involved with decompressing the data especially for already
> >> compressed formats such as most video codecs.
> > 
> > I haven't noticed any difference when using this option with png assets,
> > resulting files were byte-identical
> That's because qrc is clever enough to not even try compressing pngs. It
> doesn't know about all possible file types though.

Indeed, try it with 1GB of DDS textures. :)

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[André Somers]

Op 23/03/2016 om 17:04 schreef Konstantin Tokarev:


23.03.2016, 19:03, "Sean Harmer" :

On Wednesday 23 March 2016 16:57:04 Jason H wrote:
Notice the -no-compress option too this can save runtime CPu costs 
involved with decompressing the data especially for already 
compressed formats such as most video codecs. 

I haven't noticed any difference when using this option with png assets, 
resulting files were byte-identical
That's because qrc is clever enough to not even try compressing pngs. It 
doesn't know about all possible file types though.


André

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Konstantin Tokarev]

23.03.2016, 19:03, "Sean Harmer" :
> On Wednesday 23 March 2016 16:57:04 Jason H wrote:
>>  Not sure. This is an app for a tablet, I've always packaged assets in qrc,
>>  because it "just worked". I could try DISTFILES, but I'm unsure how that
>>  work on mobile platforms.
>>  > Sent: Wednesday, March 23, 2016 at 11:41 AM
>>  > From: "Gian Maxera" 
>>  > To: "Jason H" 
>>  > Cc: "interest@qt-project.org Interest" 
>>  > Subject: Re: [Interest] Very large QRC file
>>  >
>>  > My absolute rule is Never Never put big files into qrc file.
>>  > Can you avoid it too ?
>
> No need, just put it into a binary resource file and load that at runtime. 
> That
> avoids the compilation step. Put something like this in your .pro/.pri file:
>
> RCC_BINARY_SOURCES += \
> $$PWD/assets/mybigmedia.qrc
>
> asset_builder.commands = $$[QT_HOST_BINS]/rcc -binary ${QMAKE_FILE_IN} -o
> ${QMAKE_FILE_OUT} -no-compress
> asset_builder.depend_command = $$[QT_HOST_BINS]/rcc -list
> $$QMAKE_RESOURCE_FLAGS ${QMAKE_FILE_IN}
> asset_builder.input = RCC_BINARY_SOURCES
> asset_builder.output = $$OUT_PWD/${QMAKE_FILE_IN_BASE}.qrb
> asset_builder.CONFIG += no_link target_predeps
> QMAKE_EXTRA_COMPILERS += asset_builder
>
> Notice the -no-compress option too this can save runtime CPu costs involved
> with decompressing the data especially for already compressed formats such as
> most video codecs.

I haven't noticed any difference when using this option with png assets, 
resulting files were byte-identical

>
> Then in your c++ source add:
>
> QResource::registerResource("mybigmedia.qrb");
>
> and use it just like any other resource. Just remember to deploy the qrb file
> with your app.
>
> Cheers,
>
> Sean
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Sean Harmer]

On Wednesday 23 March 2016 16:57:04 Jason H wrote:
> Not sure. This is an app for a tablet, I've always packaged assets in qrc,
> because it "just worked". I could try DISTFILES, but I'm unsure how that
> work on mobile platforms.
> > Sent: Wednesday, March 23, 2016 at 11:41 AM
> > From: "Gian Maxera" 
> > To: "Jason H" 
> > Cc: "interest@qt-project.org Interest" 
> > Subject: Re: [Interest] Very large QRC file
> > 
> > My absolute rule is Never Never put big files into qrc file.
> > Can you avoid it too ?

No need, just put it into a binary resource file and load that at runtime. That 
avoids the compilation step. Put something like this in your .pro/.pri file:

RCC_BINARY_SOURCES += \
$$PWD/assets/mybigmedia.qrc

asset_builder.commands = $$[QT_HOST_BINS]/rcc -binary ${QMAKE_FILE_IN} -o 
${QMAKE_FILE_OUT} -no-compress
asset_builder.depend_command = $$[QT_HOST_BINS]/rcc -list 
$$QMAKE_RESOURCE_FLAGS ${QMAKE_FILE_IN}
asset_builder.input = RCC_BINARY_SOURCES
asset_builder.output = $$OUT_PWD/${QMAKE_FILE_IN_BASE}.qrb
asset_builder.CONFIG += no_link target_predeps
QMAKE_EXTRA_COMPILERS += asset_builder

Notice the -no-compress option too this can save runtime CPu costs involved 
with decompressing the data especially for already compressed formats such as 
most video codecs.

Then in your c++ source add:

QResource::registerResource("mybigmedia.qrb");

and use it just like any other resource. Just remember to deploy the qrb file 
with your app.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Gian Maxera]

I done various app for Android and iOS … never used QRC.
On Android use “assets” and on iOS use Bundle data.


> On 23 Mar 2016, at 15:57, Jason H  wrote:
> 
> Not sure. This is an app for a tablet, I've always packaged assets in qrc, 
> because it "just worked". I could try DISTFILES, but I'm unsure how that work 
> on mobile platforms.
> 
> 
>> Sent: Wednesday, March 23, 2016 at 11:41 AM
>> From: "Gian Maxera" 
>> To: "Jason H" 
>> Cc: "interest@qt-project.org Interest" 
>> Subject: Re: [Interest] Very large QRC file
>> 
>> My absolute rule is Never Never put big files into qrc file.
>> Can you avoid it too ?
>> 
>>> On 23 Mar 2016, at 15:39, Jason H  wrote:
>>> 
>>> I have a qrc devoted to media: audio and video. It's only about 100 megs 
>>> total of both (2 videos and several languages for each). It results in 
>>> about a 500MB cpp file. It takes 8 gigs to compile, which is what my 
>>> hardware ram is, so I spend a lot of time swapping.
>>> 
>>> Everytime I compile it takes 10 minutes to compile the assets.qrc, even 
>>> though it doesn't change. Is there a way that I can get the build system to 
>>> be more intelligent about building it? 
>>> ___
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>> 
>> 

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Jason H]

Not sure. This is an app for a tablet, I've always packaged assets in qrc, 
because it "just worked". I could try DISTFILES, but I'm unsure how that work 
on mobile platforms.


> Sent: Wednesday, March 23, 2016 at 11:41 AM
> From: "Gian Maxera" 
> To: "Jason H" 
> Cc: "interest@qt-project.org Interest" 
> Subject: Re: [Interest] Very large QRC file
>
> My absolute rule is Never Never put big files into qrc file.
> Can you avoid it too ?
> 
> > On 23 Mar 2016, at 15:39, Jason H  wrote:
> > 
> > I have a qrc devoted to media: audio and video. It's only about 100 megs 
> > total of both (2 videos and several languages for each). It results in 
> > about a 500MB cpp file. It takes 8 gigs to compile, which is what my 
> > hardware ram is, so I spend a lot of time swapping.
> > 
> > Everytime I compile it takes 10 minutes to compile the assets.qrc, even 
> > though it doesn't change. Is there a way that I can get the build system to 
> > be more intelligent about building it? 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> 
> 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Konstantin Tokarev]

23.03.2016, 18:39, "Jason H" :
> I have a qrc devoted to media: audio and video. It's only about 100 megs 
> total of both (2 videos and several languages for each). It results in about 
> a 500MB cpp file. It takes 8 gigs to compile, which is what my hardware ram 
> is, so I spend a lot of time swapping.
>
> Everytime I compile it takes 10 minutes to compile the assets.qrc, even 
> though it doesn't change. Is there a way that I can get the build system to 
> be more intelligent about building it?

Build it as binary .rcc file

rcc -binary assets.qrc -o assets.rcc

After that use QResource to load it.

-- 
Regards,
Konstantin
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Very large QRC file

[Gian Maxera]

My absolute rule is Never Never put big files into qrc file.
Can you avoid it too ?

> On 23 Mar 2016, at 15:39, Jason H  wrote:
> 
> I have a qrc devoted to media: audio and video. It's only about 100 megs 
> total of both (2 videos and several languages for each). It results in about 
> a 500MB cpp file. It takes 8 gigs to compile, which is what my hardware ram 
> is, so I spend a lot of time swapping.
> 
> Everytime I compile it takes 10 minutes to compile the assets.qrc, even 
> though it doesn't change. Is there a way that I can get the build system to 
> be more intelligent about building it? 
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Very large QRC file

[Jason H]

I have a qrc devoted to media: audio and video. It's only about 100 megs total 
of both (2 videos and several languages for each). It results in about a 500MB 
cpp file. It takes 8 gigs to compile, which is what my hardware ram is, so I 
spend a lot of time swapping.

Everytime I compile it takes 10 minutes to compile the assets.qrc, even though 
it doesn't change. Is there a way that I can get the build system to be more 
intelligent about building it? 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Setting currentIndex in Qt Quick ComboBox does not work

[Jérôme Godbout]

Hi,
You have a binding problem here inside the combobox:
*currentIndex: getCurrentIndex(mymodel.items, mymodel.item)*
this binding will get override when the user change the current value of
the combobox, the combo box will assign an int to this value. You need to
set the model onCurrentIndexChanged: setModelIndex(currentIndex)
And do the same with the model changed value.

You can wrap this up inside a synchronizer that take both object and
property and set value on respectively changed (if value is not the same to
avoid binding loop). You can also see
http://imaginativethinking.ca/bi-directional-data-binding-qt-quick/

On another note, take care if the combobox  model property change on a
combo box, the current index is reset too (cause of the property list way
of working, only have clear and push under, so assigning clear it then copy
is a lot of push, but when clear append, the current index is no more). You
can assign it by onChange of another property, backup currentIndex, set the
list to the model and try to apply backup current index if still valid
value.

Jerome


On Wed, Mar 23, 2016 at 2:44 AM, Fabian Sturm  wrote:

> Hello list,
>
> I hope this is the right forum to write, even though my sample code is
> in Python but I think the problem lies deeper in the event propagation
> or similar.
>
> What I want to do looks simple at first. I want to show a ComboBox with
> a list of items in it and one of them is selected. On a push of a
> button the list ost extended by one element and that should be
> reflected by the ComboBox. The selected item should of course always
> stay the same. Unfortunately this is what does not work and the
> selected item is reset to 0 even.
>
> Any help is greatly appreciated!!!
>
> Thanks Fabian
>
> The sample source is here:
> https://github.com/sturmf/python_samples/tree/master/pyqt_combobox
>
> main.qml excerpt:
>
> And the important parts are this:
>
> function getCurrentIndex(list, element) {
> console.log('getCurrentIndex')
> if (list && element) {
> for (var i = 0; i < list.length; i++) {
> if (list[i].name === element.name) {
> console.log('Found item at pos: ' + i)
> return i
> }
> }
> }
> return -1
> }
>
>
> [...]
>
> ComboBox {
> id: combo
> width: parent.width
> currentIndex: getCurrentIndex(mymodel.items, mymodel.item)
> model: mymodel.items
> textRole: 'name'
> }
>
>
>
> The python model is this:
>
> class MyModel(QObject):
>
> itemChanged = pyqtSignal()
> itemsChanged = pyqtSignal()
>
> def __init__(self, parent=None):
> QObject.__init__(self, parent)
> self._items = [MyItem('one'), MyItem('two'), MyItem('three')]
> self._item = self._items[2]
>
> @pyqtProperty(MyItem, notify=itemChanged)
> def item(self):
> return self._item
>
> @pyqtProperty(QQmlListProperty, notify=itemsChanged)
> def items(self):
> print('Query for items')
> return QQmlListProperty(MyItem, self, self._items)
>
> @pyqtSlot()
> def new_item(self):
> print('Append new item')
> self._items.append(MyItem('new'))
> self.itemsChanged.emit()
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse

[Jason H]

You can inherit, with the higher level taking precedence, just like with 
polymorphism. I use this feature heavily, with great success.

You are correct, that there you should have a Screen.qml with common properties 
and elements. 
Then CustomScreen1.qml which contains a screen element, and other elements. 

For instance, I use one NavBar.qml which is in all my screens. The NavBar 
contains two of my StyledButton elements, and I use a custom StyledText Text 
element everywhere. For the final screen where Nav bar shows "Exit" instead of 
"Next" I just set a property. 

Finally, one last piece of advice, set your main element up as main.qml 
Window {
StackView {}
Screen1 {}
Screen2 {}
Screen3 {}
}

Have each screen emit navigation signals, and let your main decide what to do 
on the StackView: 
Screen1 {
  onNext: stackView.push(screen2)
}

But do add screen-specific functions to each Screen to keep them logical 
components. I'd not put those functions in main:
Screen1 {
  onAction: someScreenSpecificFunction(); // a function in main.qml 
}

That will just lead to confusion. Unless that invocation depends on other 
variables at the main.qml level.



> Sent: Tuesday, March 22, 2016 at 3:13 PM
> From: "Elvis Stansvik" 
> To: "interest@qt-project.org Interest" 
> Subject: [Interest] Structuring of QML app as set of interlinked screens for 
> maximum code reuse
>
> Hi all,
> 
> I'm working on a fullscreen Qt Quick/QML app (for machine control)
> which will consist of a set of interlinked screens, with key presses
> as the only interaction method.
> 
> Each screen will have roughly the following QML structure:
> 
> Rectangle {
> 
> NavBar {
> id: topBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
> 
> Rectangle {
> id: topSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
> 
> Rectangle {
> id: content
> ...
> main content here, different depending on which screen.
> ...
> }
> 
> Rectangle {
> id: bottomSeparator
> ...
> aesthetic divider rectangle between top nav bar and content.
> ...
> }
> 
> NavBar {
> id: bottomBar
> ...
> controls for navigation and information stuff,
> different depending on which screen
> ...
> }
> }
> 
> And I'm now trying to find a good structure that will minimize
> repetition of QML code.
> 
> I understand that QMLs main model for code reuse is composition, but
> that it also has a form of "inheritance": by defining a new Item in a
> separate file using another Item as the top level item and redefining
> some of its properties, I'm sort of inheriting that item.
> 
> I could save the above general structure in a Screen.qml, and in
> FooScreen.qml, BarScreen et.c. do:
> 
> Screen {
> ...
> override some properties
> ...
> }
> 
> But this will only allow me to redefine properties, and add new child
> items. How would I then be able to define both which content goes in
> the main area (the content Rectangle in the "base" item) and in the
> two navigation bars (topBar and bottomBar Rectangles)?
> 
> It seems QML is not really meant to be used this way, and I'd have to
> essentially redefine these things in each of my screens, even if
> they'll all have the same general structure? There's no "template"
> mechanism so to speak?
> 
> I'm very thankful for any tips from people more experienced with Quick / QML.
> 
> And if you know of a well designed full screen QML app modeled as a
> set of interlinked screens with keyboard navigation, I'm idle ears.
> 
> Cheers,
> Elvis
> ___
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> 
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Can't login to bugreports.qt.io / OpenGL bug

[Yves Bailly]

> > And just in case, here's the bug:
> > - Download and install Qt 5.6.0 for Windows, 64bits, Visual 2013
> > - Open \5.6\Src\qtbase\examples\opengl\qopenglwidget\
> > qopenglwidget.pro example in QtCreator
>  - Build, run: fine.
> > - Set the screen colors to 65536 (16bits), from
> > "Display/Resolution/Advanced" monitor property.
>  - Build, run: crash.
> > Tested in Windows 7, 64bits, GPU nVidia Quadro K2000. In can give a
> > call stack is needed.
> 
> The example requests a 32-bit RGBA default framebuffer. System can't
> provide it as you set it to 16-bit colour. Example doesn't check for
> this case. Boom.
> 
> 1) Change system back to 32-bit color (24-bit RGB)
> 2) Change example to request 16-bit framebuffer.

Actually I didn't find any request for 32-bit RGBA in the example... Neither in 
the doc about QPainter, QOpenGLWidget nor QOpenGLWindow. Unless I missed 
something?

Just in case, I removed the format request in the main(): so basically now I 
get whatever the OS will give me by default.

But it still crashes...

Also I may not have the hand on the machine running the program - it may be a 
customer's machine far, far away in a distant... well you get the idea.

Regards,


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Can't login to bugreports.qt.io / OpenGL bug

[Sean Harmer]

On Wednesday 23 March 2016 08:35:30 Yves Bailly wrote:
> Hello all,
> 
> Not sure where to ask, so I post here
> 
> I'm trying to report a bug, but I can't login to bugreports.qt.io nor
> login.qt.io.
 I gave a mail address, a password, but then I'm stuck at the
> page " This will be your username at blabla": when I click "Set username",
> it ends with a "Internal server error" page. 
> Tried on Windows 7, 64bits, Firefox & IE.
> 
> Any hint is welcome...
> 
> And just in case, here's the bug:
> - Download and install Qt 5.6.0 for Windows, 64bits, Visual 2013
> - Open \5.6\Src\qtbase\examples\opengl\qopenglwidget\ qopenglwidget.pro
> example in QtCreator
 - Build, run: fine.
> - Set the screen colors to 65536 (16bits), from
> "Display/Resolution/Advanced" monitor property.
 - Build, run: crash.
> Tested in Windows 7, 64bits, GPU nVidia Quadro K2000. In can give a call
> stack is needed.

The example requests a 32-bit RGBA default framebuffer. System can't provide it 
as you set it to 16-bit colour. Example doesn't check for this case. Boom.

1) Change system back to 32-bit color (24-bit RGB)
2) Change example to request 16-bit framebuffer.

Cheers,

Sean
--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

Hi.

That does help, thanks. It means that I’d really need to use an arbitrarily 
long timer, or find the “proper” solution.

At one stage I thought about having a C++ object that could be created in QML 
and would somehow keep count of references to the game object. For example, 
each Loader whose source component has access to the game object would somehow 
register itself with the object, and the game wouldn’t start quitting until all 
references were gone. As long as the C++ doesn’t know about the UI, I think it 
could work quite well.

Something like this:

Loader {
// ... contains GameView
}

// GameView.qml

Item {
id: root
property alias game

GameScope {
game: root.game
}
}

// GameScope.cpp

GameScope::setGame(Game *game)
{
if (game == mGame)
return;

if (game)
game->increaseReferenceCount();
else
game->decreaseReferenceCount();

mGame = game;
}

GameScope::~GameScope()
{
if (game)
game->decreaseReferenceCount();
}


Each event loop after a quit has been requested, Game could check the reference 
count and begin the actual quitting if it’s 0.

It still feels like it shouldn’t be necessary, but at least there’s no 
guesswork involved.

From: Nye [mailto:kshegu...@gmail.com]
Sent: Tuesday, 22 March 2016 10:33 PM
To: Curtis Mitch 
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hello,
I don't work with QML, but I'm pretty sure the events are processed in the 
order of their appearance in the event queue. So if you have a `deleteLater` 
call (i.e. you have a QEvent::DeferredDelete, which is scheduled through the 
event loop) any queued call to a slot (i.e. QEvent::MetaCall) that was made 
before the deletion request should be happening before the actual deletion. So, 
if you're emitting signals from a single thread, their respective slots would 
be called in the order in which the signals had happened.

Now, with multiple threads it's a bit tricky, since there's the chance that two 
threads will be trying to post a deferred function invocation at the same time 
(hence the event queue is protected by a mutex). However that mutex can't 
guarantee in what order the events will be posted, or rather no one can.

> My only thought is to use a zero-second single-shot timer. The question is: 
> is this guaranteed to happen *after* deferred deletion for a given iteration 
> of an event loop?

This posts a timer event on the queue, so you can achieve the same with 
QMetaObject::invokeMethod(receiverObject, "method", Qt::QueuedConnection), and 
the same "restrictions" apply as mentioned above.

I hope this is of help.
Kind regards.

On Tue, Mar 22, 2016 at 7:50 PM, Curtis Mitch 
mailto:mitch.cur...@theqtcompany.com>> wrote:

I recently discovered [1] that Loader defers deletion of items via 
deleteLater(). Up until that point, I had been treating certain operations in 
my program as synchronous (as I haven't introduced threads yet). Now that I 
can't safely assume that UI items will be instantly destroyed, I have to 
convert these operations into asynchronous ones.

For example, previously, I had this code:

game.quitGame();

My idea is to turn it into this:

game.requestQuitGame();

Within this function, the Game object would set its "ready" property to false, 
emitting its associated property change signal so that Loaders can set active 
to false. Then, QMetaObject::invoke would be called with Qt::QueuedConnection 
to ensure that the Loader's deleteLater() calls would have been carried out 
*before* tearing down the game and its objects.

In order to confirm that invokeMethod() works the way I thought it did, I added 
the following debug statements to QEventLoop:

diff --git a/src/corelib/kernel/qeventloop.cpp 
b/src/corelib/kernel/qeventloop.cpp
index dca25ce..7dae9d0 100644
--- a/src/corelib/kernel/qeventloop.cpp
+++ b/src/corelib/kernel/qeventloop.cpp
@@ -151,6 +151,7 @@ bool QEventLoop::processEvents(ProcessEventsFlags flags)

 \sa QCoreApplication::quit(), exit(), processEvents()
 */
+#include 
 int QEventLoop::exec(ProcessEventsFlags flags)
 {
 Q_D(QEventLoop);
@@ -200,8 +201,11 @@ int QEventLoop::exec(ProcessEventsFlags flags)
 if (app && app->thread() == thread())
 QCoreApplication::removePostedEvents(app, QEvent::Quit);

-while (!d->exit.loadAcquire())
+while (!d->exit.loadAcquire()) {
+qDebug() << Q_FUNC_INFO << "--- beginning event loop";
 processEvents(flags | WaitForMoreEvents | EventLoopExec);
+qDebug() << Q_FUNC_INFO << "--- ending event loop";
+}

 ref.exceptionCaught = false;
 return d->returnCode.load();

It turns out that I misunderstood the documentation; it only says that the slot 
is invoked when control returns to the event loop of the receiver's thread. So, 
as I understand it, it's possible that the invocation could happen *before* the 
deferred deletion of the Loaders' ite

[Interest] Can't login to bugreports.qt.io / OpenGL bug

[Yves Bailly]

Hello all,

Not sure where to ask, so I post here

I'm trying to report a bug, but I can't login to bugreports.qt.io nor 
login.qt.io.
I gave a mail address, a password, but then I'm stuck at the page " This will 
be your username at blabla": when I click "Set username", it ends with a 
"Internal server error" page.

Tried on Windows 7, 64bits, Firefox & IE.

Any hint is welcome...

And just in case, here's the bug:
- Download and install Qt 5.6.0 for Windows, 64bits, Visual 2013
- Open \5.6\Src\qtbase\examples\opengl\qopenglwidget\ qopenglwidget.pro example 
in QtCreator
- Build, run: fine.
- Set the screen colors to 65536 (16bits), from "Display/Resolution/Advanced" 
monitor property.
- Build, run: crash.
Tested in Windows 7, 64bits, GPU nVidia Quadro K2000. In can give a call stack 
is needed.

Regards,

--
Yves Bailly
Software developer

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Ensuring that a queued invocation occurs after deferred deletion

[Curtis Mitch]

From: Sina Dogru [mailto:sinado...@gmail.com]
Sent: Tuesday, 22 March 2016 10:09 PM
To: Curtis Mitch 
Cc: interest@qt-project.org
Subject: Re: [Interest] Ensuring that a queued invocation occurs after deferred 
deletion

Hi, I saw your bug report. I encountered the same problem last week and I found 
a workaround by passing the properties that belong to another object one by one 
to JSon object. For example,

setSource("qrc:/LoaderItem.qml", { "color": theGame.player.color })
But in my case there was only one property. So instead of passing the object, 
passing the property was easy. But for more complicated situations that would 
be a pain...
Sina



Hi.

That’s a good work around, but you’re right in that it’s more difficult in my 
situation. I have a handful of objects that I need access to, each with their 
own objects as properties, and so on.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Using Normal QPainter for Qt3D

[Sean Harmer]

Hi,

On Wednesday 23 March 2016 06:48:08 Mohd Z|eeshan Farooque wrote:
> Hi,
> Req: Print out of 3D structure through QPainter with in QRect. How cam I use
> normal QPainter for Qt3D rendering because I want to take print (or render
> somewhere else like on any widget, window,etc) of current static 3d
> Structure on  root entity. Or is there any other better way to do this.
> Because I already have my reporter class which gives QPainter and QRect So
> that next user use this QPianter to render any thing within this QRect. And
> the rest of the thins like printing, saving rendered object on pdf, etc is
> already handled by this reporter class.Please let me know if you want any
> other info . Thank you Mail: zeeshanc...@yahoo.in

There is nothing out of the box for this at the moment. The usual trick is to 
draw a hi-res version of your scene in a tiled manner using a custom camera 
frustum into a texture attached to a framebuffer object. That can all be done 
with some manual tweaking of a framegraph. The bit I am unsure of at the 
moment is reading back the rendered pixel data to the CPU side.

Could you file a JIRA request for this please and we will see how best to fit 
it 
into our plans?

Thanks,

Sean

--
Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest