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

[Jérôme Godbout]

Hi Dmitry,
not much problems, except this is a modal way for interacting with the
user. I'm not a fan of modal (as matter of fact I hate it, you prevent your
user for copy/paste, check something from the real work window), but the
Qml Dialog callback make it even worst. It seem ok for a single question
for a dual action path, but when thing get a little more complex, this is a
code nightmare (not as hard to code, but hard to follow what is going on
when not written by you, it's a succession of callback and setting the Qml
Dialog callback function and call it over and over, you have to understand
the function that can be called in which order, because creating 5 of them
for a single sequence seem to be dumb and not helping the function workflow
anyway).

As for the C++ invoke, not much was required, your Qml will not react or
respond to the mouse event until you come back from the call as expected.
Unless you have timer base actions or your main loop feed something
external (which I think you should never do), this work well.

We had some issue with Qt 5.5, with mixing QWidgets/Qml for menu/window
position, but that seem to be fixed into 5.6.
Jerome

On Tue, Apr 26, 2016 at 8:45 AM, Dmitry Volosnykh <
dmitry.volosnykh at gmail.com> wrote:

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