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 <4163654...@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.ha...@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@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
