[Interest] QML blocking popup menu
martin.haker at gmail.com
Mon Jun 17 13:17:43 CEST 2013
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
I had to insert the code in Popup::Show just before the return statement.
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>
> > 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
> > 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
> > 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
> > effect)
> > The case (2c) fails for the other two implementations and one has to
> > the other square twice in order bring up the popup. Interestingly, the
> > receives the OnPressed event, but neither the OnClicked nor the
> > 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
> > set the file path for Popup.qml. I hope I have set it correctly for
> > 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...
More information about the Interest