Hi Jérôme,
On 26 April 2016 at 21:00, Jérôme Godbout <jer...@bodycad.com> wrote:
> 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).
>
>
How about using a promise object(Javascript concept)? Do you think it could
simplify the workflow?
> 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.volosn...@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 <jer...@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 <jer...@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 <sinado...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> 2016-04-26 12:11 GMT+03:00 Shawn Rutledge <shawn.rutle...@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@qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest@qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
