[Interest] [QtQuick] Interaction with user from C++

[Jérôme Godbout]

>>I wrote a simple code where a timer increment an int and a text showing
that int in QML. And from that QML called a C++ function which blocks it.

Take care, animation and rendering seem to be different thread. The Qml
main thread should block. Maybe I don't get it what you tried here.

>> How about using a promise object(Javascript concept)?

It would surely help if you go with the functions inline. But those message
box are normally part of sequence or can even be deep into an object
function that know nothing about the caller or it's sequence status. Maybe
promise can help here but doesn't change the real problem which is you need
an answer before you can continue this action (like a mutex on that
sequence, until answer is receive you want to hold in place).

The current Qml async way to make this is more like signal/slot, but to
write something that branch a lot based on the answer, make coverage hard
to follow.


On Wed, Apr 27, 2016 at 1:12 PM, Sina Dogru <sinadooru at gmail.com> wrote:

> Seems like it is undefined behaviour to have QFileDialog without a parent.
> Sometimes it becomes "ApplicationModal" but sometimes "NonModal" (I
> experienced it with a simple code on Linux.)..
>
> Also Shawn warned that would block QML thread. So to try what is the
> behaviour of engine when the thread is block, I wrote a simple code where a
> timer increment an int and a text showing that int in QML. And from that
> QML called a C++ function which blocks it. But seems like engine keep
> working while it suppose to block (tried on 5.6).
>
> Now I need to choose between "bouncing between QML and C++" or "breaking
> in multiple functions". Thanks for helping and acquired a vision.
>
> Sina
>
> 2016-04-26 22:32 GMT+03:00 Jérôme Godbout <jerome at bodycad.com>:
>
>> We have QWidgets as base window (QMainWindow) that have the QQuickView
>> into it. For the parent, we use the QMainWindow. Maybe this explain why it
>> work well in our case. We have some tools that are still into QWidgets
>> (TreeView mostly with dock window, the Qml TreeView, is somewhat... painful
>> in the current state).
>>
>> In the case of a Qml ApplicationWindow, I don't known if this would work,
>> it's a QObject and not a QWidgets, the QDialog call require a QWidgets
>> pointer as first argument. hummm, I did not realized that until now. Good
>> point Sina Dogru.
>>
>> Not sure what is the behavior if the first argument is null if only have
>> a Qml ApplicationWindow. If this work let me know, I'm curious to see if
>> this work or not.
>>
>>
>> On Tue, Apr 26, 2016 at 3:17 PM, Sina Dogru <sinadooru at gmail.com> wrote:
>>
>>> Yes I got your points. At least there is no any bouncing between QML and
>>> C++.
>>>
>>> 2016-04-26 20:11 GMT+03:00 Jérôme Godbout <jerome at bodycad.com>:
>>>
>>>> We are mostly using QFileDialog and QMessageBox. Note the Qml type but
>>>> the one from QtWidgets/QFileDialog
>>>>
>>>> *Q_INVOKABLE QString getSaveFileName(...); // .h*
>>>>
>>>>
>>>> *QString MySingletonDialog::getSaveFileName(...) // .cpp*
>>>> *{*
>>>> *  return QFileDialog::getSaveFileName(...);*
>>>> *}*
>>>>
>>>
>>> What is the parent argument for QFileDialog? I guess this is needed to
>>> modal window work properly?
>>>
>>> The only way I see it is a follow (not tested just the way I see it into
>>>> Qml Dialog):
>>>>
>>>> *Dialog*
>>>> *{*
>>>> *  id: myDialog_*
>>>> *  contentItem: null*
>>>>   // Dummy content can be from anywhere or you could have a static
>>>> object with options as property here
>>>> *  property Item myDialog1: Item { ... }*
>>>>
>>>> *  property Item myDialog2: Item { ... }*
>>>>   // dynamic functor
>>>> *  property var acceptedCallback: null*
>>>> *  property var rejectedCallback: null*
>>>> *  onAccepted: { if(acceptedCallback) acceptedCallback(clickedButton);
>>>> }*
>>>> *  onRejected: { if(rejectedCallback) rejectedCallback(clickedButton);
>>>> }*
>>>>   // ... add other wanted handler for all the possible signal here
>>>> *}*
>>>>
>>>> // inline callback (you can create function per sub function but that
>>>> make the code look like a big goto mess). It's only 2 calls to interact
>>>> with user and not branching does nothing else and it's already messy.
>>>>
>>>> *function myAction()*
>>>> *{*
>>>> *    myDialog_.contentItem = myDialog_.myDialog1;*
>>>> *    myDialog_.rejectedCallback = function(button) *
>>>> *    {*
>>>> *       console.log('error');*
>>>> *    };*
>>>> *    myDialog_.acceptedCallback = *
>>>> *    function(button)*
>>>> *    {*
>>>>         // Do some stuff, need to ask something else
>>>> *        myDialog_.contentItem = myDialog_.myDialog2;*
>>>> *        myDialog_.rejectedCallback = function(button) *
>>>> *        {*
>>>> *            console.log('error 2');*
>>>> *        };*
>>>> *        myDialog_.acceptedCallback = function(button) *
>>>> *        {*
>>>>            // Do some stuff further
>>>>            // continue to dig a grave here by calling more dialog...
>>>> *        };*
>>>> *        myDialog_.open();*
>>>> *    };*
>>>> *    myDialog_.open();*
>>>> *}*
>>>>
>>>
>>> That is one of the other thing that I was trying to avoid while asking
>>> the question actually. Then there should be too many function definitions
>>> for different kind of scenarios :S. Seems like your first solution is the
>>> best one we have. Thank you for helping.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160427/147bf95b/attachment.html>