[Interest] QML blocking popup menu
416365416c at gmail.com
Wed Jun 12 02:23:21 CEST 2013
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
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
> (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
> 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
> Any ideas on how to solve this? My preferred implementation would be (1).
> Thanks in advance for any help.
> Best regards
> 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
More information about the Interest