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

[Jérôme Godbout]

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(...);*
*}*

here the return error would lead to empty string. The error can be from
cancel from user, file is not accessible, already exist, etc. If you want
more precision, add more check, you need to return a *VariantMap with {
'file': 'pathToFile', 'hasError': true; 'errorStr': 'operation cannot
access file' }* for example. We do those check into Javascript and expose
those file manipulation check into C++ singleton too.

Would be nice to throw through the Q_INVOKABLE call into javascript. It's
possible if you return a QJSValue that you eval into the JS (but this is
another story).

As Shawn suggest, it would be nice to have a QML component and trigger it
with procedural call.

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();*
*}*

On Tue, Apr 26, 2016 at 9:14 AM, Sina Dogru <sinadooru at gmail.com> wrote:

> Hello Jérôme,
>
> I am trying to understand how you made it possible,
>
> 2016-04-26 15:39 GMT+03:00 Jérôme Godbout <jerome at bodycad.com>:
>
>> We also have expose those blocking C++ QMessageBox and QDialog for linear
>> workflow via Q_INVOKABLE from C++ singleton.
>>
>
> I might misunderstand, do you actually using QMessageBox with QML
> application? or do you mean MessageBox QML type?
>
>
>> This avoid the callback spaghetti mess of Qml Dialog and made the code
>> more readable. If you have many options to offer to user in particular
>> sequences of may or may not be requested, the declarative way is a
>> nightmare. In fact I think we have 0 Qml Dialog into our 5 CAD
>> applications, but many call to those C++ blocking dialog invoke.
>>
>
>> On Tue, Apr 26, 2016 at 8:34 AM, Jérôme Godbout <jerome at bodycad.com>
>> wrote:
>>
>>> I can tell what we did, we made a FileSystem C++ singleton that expose
>>> most file system file/url check, we made those check inside Qml javascript
>>> now.
>>>
>>
> Do you mean instead of sending the user input to FileDialog and checking
> this url in C++, you directly check if the file exists in QML?
>
>
>> This way you can make callback and GUI logic into Qml. We expect C++
>>> function to be call with valid argument all the time. Else we always return
>>> error (unexpected error, since the Qml code should have validate before
>>> making the call, this is a developer issue).
>>>
>>
> I am sorry, you return error from what?
>
> Side Note: We also have experiment with throw from C++ that get evaluate
>>> into Qml, it work, but it would be nice to have a proper keyword with throw
>>> type to indicate this and the exception get transfer to into Q_INVOKABLE.
>>> Would allow for better error handling.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160426/130b3bd5/attachment.html>