Hi Volker,
On Wed, Feb 8, 2023 at 11:20 AM Volker Hilsheimer <volker.hilshei...@qt.io>
wrote:
>
> Hi Stefan,
>
>
> Where do you see the advantages of synchronously waiting for a state to be
> reached, when instead you can connect to the respective state’s entered()
> signal? The former might make your code look more linear of course, with
> less complexities due to object lifetimes etc.
>
There you have your answer right there ! :-)
> When the QtState Machine framework was added it was done so in the context
> of a UI framework, so a core design choice was to drive the state machine
> asynchronously so that the UI doesn’t freeze. And since then, we had no
> compelling reason to modify that architecture. It seems to work well enough
> in the context of a UI framework, where state transitions are triggered by
> events. Or maybe people have silently migrated to alternative state machine
> frameworks.
>
Right. I'm unable to tell. However, a point Roland brought up is the
overall philosophy of an "application framework". If Qt were just a UI
framework where everything was gravitating around a single global event
loop, that might work fine, i.e. having to wait for a signal is just one
more callback to add. But I believe Qt is trying to be way more than a UI
framework. State machines may have a life of their own, outside the global
event loop. ..
>
> QStateMachine could live in it’s own thread which can run its own event
> loop. States emit signals, so objects interesting in state enter/exit
> notifications can connect to those signals even if they live in threads
> other than the state machine. And a QSignalTransition could operate on a
> sender living in a different thread as well (QEventTransition can’t support
> that though). So asynchronicity could be achieved that way as well, but it
> doesn’t solve your problem of stopping your code until a state has been
> reached. The design of Qt State Machine is that you put that code into a
> callable connected to the respective signals.
>
> That is a general question. We probably don’t want more waitFor… style
> APIs in Qt. If we would add such APIs, they might very well be implemented
> by a local QEventLoop that runs until the signal you are waiting for gets
> emitted. So your solution is reasonable. Why is it not in Qt? Because
> nobody asked for it, needed it, or contributed a solution so far. And
> perhaps it’s ok to leave that solution to the client, as not every waitFor…
> use case might want to e.g. ExcludeUserInputEvents.
>
Thank you ! That's the answer I have wanted to hear. :-)
>
> Co-routines might at some point become the standard tool also for Qt
> application developers to solve that kind of problem. What that could look
> like continues to be a subject of research. Ville has commented on that in
> the past [1] and has recently played with Qt and sender/receiver (i.e.
> P2300), which got even Eric Niebler excited [2].
>
That's good to hear indeed. Yes, co-routines will hopefully help us work
more efficiently with multi-core systems, finally !
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
