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

[Dmitry Volosnykh]

Jérôme, thank you for your input. Just for self education... Did you face
some problems with such approach which you may want to share with us? Any
UI performance issues since you may have blocked scene renderer?

On Tue, Apr 26, 2016 at 3:39 PM Jérôme Godbout <jerome at bodycad.com> wrote:

> We also have expose those blocking C++ QMessageBox and QDialog for linear
> workflow via Q_INVOKABLE from C++ singleton. 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. 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).
>>
>> 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.
>>
>> On Tue, Apr 26, 2016 at 5:58 AM, Sina Dogru <sinadooru at gmail.com> wrote:
>>
>>>
>>>
>>> 2016-04-26 12:11 GMT+03:00 Shawn Rutledge <Shawn.Rutledge at qt.io>:
>>>
>>>>
>>>> You shouldn’t need to do this.  Just write onAccepted/onRejected
>>>> handlers which call back to QML and/or C++ code as necessary.  Is there
>>>> some reason why that is difficult?
>>>>
>>>> Well the problem is (like I tried to explain on the email to Dmitry)
>>> while using QFileDialog's and QMessageBox's static functions, program can
>>> continue to flow from where those functions called.
>>>
>>> Let me please explain myself with a piece of code;
>>>
>>> void App::saveAs(const QString &path)
>>> {
>>>     bool cont = true;
>>>
>>>     while (cont) {
>>>         if (path.isEmpty())
>>>             cont = false;
>>>         else {
>>>             QFileInfo fi = path;
>>>
>>>             if (fi->exists()) {
>>>                 int wantSave = QMessageBox::warning(nullptr,
>>> tr("Warning"), tr("File %1 exists.\n"
>>>                                                     "Do you wish to
>>> overwrite it?").arg(fi->fileName()),
>>>                                                     QMessageBox::Yes,
>>> QMessageBox::No);
>>>                 if (wantSave == QMessageBox::Yes)
>>>                     cont = false;
>>>                 else
>>>                     path = QFileDialog::getSaveFileName(nullptr,
>>> tr("Save As"));
>>>             }
>>>             else
>>>                 cont = false;
>>>         }
>>>     }
>>>     if (!path.isEmpty())
>>>         doc->save(url);
>>> }
>>>
>>> For example, when the user press the save as tool button of the QML
>>> ApplicationWindow, this slot is called onAccepted handler of the
>>> FileDialog. But depending on the user input, application might need to do
>>> something else.
>>>
>>> But I am not sure if I am violating the "UI and business logic
>>> seperation" with this approach?
>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160426/1cbfa976/attachment.html>