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

[Sina Dogru]

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/ae33db17/attachment.html>