[Interest] QML blocking popup menu

[Martin Haker]

Hi Alan,

I see your point that it would be best to avoid the blocking behavior
entirely. We'll see to that.

Regarding the approach to re-issue the event: You did point me into the
right direction there. Thanks! Sending the event via the scene to the root
item did not work. Instead I sent it to the scene via QCoreApplication.
Since onPressed was called anyway, creating a mouse release event was
enough.

 QGraphicsSceneMouseEvent releaseEvent(QEvent::GraphicsSceneMouseRelease);

releaseEvent.setScenePos(QPointF(m_x, m_y));

releaseEvent.setButton(Qt::LeftButton);

releaseEvent.setButtons(Qt::LeftButton);

releaseEvent.setModifiers(Qt::NoModifier);

QCoreApplication::sendEvent(m_pScene, &releaseEvent);


I had to insert the code in Popup::Show just before the return statement.

Thanks again
Martin


On Wed, Jun 12, 2013 at 2:23 AM, Alan Alpert <416365416c at gmail.com> wrote:

> A declarative language doesn't really mesh well with "blocking", and
> you should find that once you migrate entirely to QML that you no
> longer need that behavior of controlling imperative code flow. A
> responsive C++ API, such as a well-written back-end for a QML UI,
> should have waiting done through signals and slots instead of
> blocking, e.g. where you summon the dialog in one method and connect a
> slot to a dismissed signal (much like JS callbacks), because any time
> you block you can mess up a fluid UI or slow down the user experience.
>
> If you can't fix all usages in your C++ code, then what I'd recommend
> to try with your mockup is to pass the whole event into the dismissal
> function and then re-issue it. Manually running an event loop (even
> the main one) can mess up the QtQuick event delivery. But you can
> check if the event was accepted, and if not then resend it to the root
> item of the scene (probably using
> http://qt-project.org/doc/qt-4.8/qgraphicsscene.html#sendEvent ).
>
> --
> Alan Alpert
>
>
> On Tue, Jun 11, 2013 at 5:26 AM, Martin Haker <martin.haker at gmail.com>
> wrote:
> > Hi everyone,
> >
> > in the process of porting an existing widget-based application to QML I
> > would like to implement a blocking popup menu (similar to a context menu
> > using QMenu), i.e. code execution waits for the user to provide input or
> > dismiss the popup menu.
> >
> > I have created a mockup (find it attached) with three different
> > implementations:
> >
> > (0) - non-blocking (shows the desired behavior)
> > (1) - blocking using QEventLoop (when the popup is dismissed setting
> > mouse.accepted = false should allow further processing of the event by
> other
> > items below the popup; this fails, however)
> > (2) - blocking using busy waiting and QCoreApplication::
> > processEvents() (same effect as in (1))
> >
> > The three implementations can be activated in Popup.cpp. There is a
> #define
> > IMPLEMENTATION at the very top (that does make the code a bit harder to
> > read, sorry). Currently implementation (0) is active.
> >
> > The mockup shows a green and a red square. The following should happen:
> >
> > (1) - Clicking a square creates a popup with the respective color.
> > (2a) - Clicking the popup lets the popup disappear (user input).
> > (2b) - Clicking the same square or the white background lets the popup
> > disappear (cancel).
> > (2c) - Clicking the other square lets the popup disappear (cancel) and
> > instantly creates a popup for the other square (mouse.accepted = false
> takes
> > effect)
> >
> > The case (2c) fails for the other two implementations and one has to
> click
> > the other square twice in order bring up the popup. Interestingly, the
> item
> > receives the OnPressed event, but neither the OnClicked nor the
> OnReleased
> > event.
> >
> > Any ideas on how to solve this? My preferred implementation would be (1).
> >
> > Thanks in advance for any help.
> > Best regards
> > Martin
> >
> >
> > PS: If have tested the mockup on Mac OS. There is an #ifdef in Popup.cpp
> to
> > set the file path for Popup.qml. I hope I have set it correctly for
> anyone
> > testing on another OS.
> >
> > _______________________________________________
> > 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/20130617/8d0ef8ff/attachment.html>