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

[Jérôme Godbout]

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