Qt-interest Archive, September 2007
Integrating a QT GUI with a non-QT application
Message 1 in thread
I am integrating some work done in a single threaded QT UI into a non-QT
Application and I have read through the threading documentation. I am
trying to avoid changing everything over to QThreads running event loops.
I have the following situations:
1) Non-QT/GUI thread creating/deleting a QGraphicsScene/QImage based
display.
2) Non-QT/GUI thread wants to update the display.
3) GUI thread must notify Non-QT/GUI thread of events.
2 can be solved with qApp->postEvent().
1 might be solved with a stub and using qApp->postEvent() to create the
object and fill the stub (with thread safe protections).
3 seems that the notification must be done purely in the QT/GUI thread
calling the non-QT/GUI threads thread safety protections.
Again, I'm trying not to rewrite the non-QT application just to
integrate this piece.
Thank you,
Jonathan
--
[ signature omitted ]
Message 2 in thread
On torsdag den 6. September 2007, Jonathan Smith wrote:
> I am integrating some work done in a single threaded QT UI into a non-QT
> Application and I have read through the threading documentation. I am
> trying to avoid changing everything over to QThreads running event loops.
>
> I have the following situations:
> 1) Non-QT/GUI thread creating/deleting a QGraphicsScene/QImage based
> display.
> 2) Non-QT/GUI thread wants to update the display.
> 3) GUI thread must notify Non-QT/GUI thread of events.
>
> 2 can be solved with qApp->postEvent().
> 1 might be solved with a stub and using qApp->postEvent() to create the
> object and fill the stub (with thread safe protections).
> 3 seems that the notification must be done purely in the QT/GUI thread
> calling the non-QT/GUI threads thread safety protections.
>
> Again, I'm trying not to rewrite the non-QT application just to
> integrate this piece.
You can do it this way, and you would definitely be able to get the system
running.
However, I think I would introduce a bridge system between your Qt gui and the
legacy code. The bridge should do the communication between the two systems,
and it would be two classes that each is a Facade pattern on the other part.
This way you won't have to scatter all the communication between the parts
all over your code.
It's possible that you can get away with just one bridge class, that handles
all communication, but I think that is going to be a bit too cluttered.
Bo.
--
[ signature omitted ]
