Hat jemand schon Erfahrung damit?
Ich würde gerne meine Software nach dem MVP ( Model View Presenter) Pattern designen um die Logik komplett von der GUI zu trennen. Gleichzeitig möchte ich das Frontend (GUI) der Software flexibel und austauschbar halten. ZUnächst soll eine Qt Gui angeschlossen werden, diese soll jedoch wiegesagt austauschbar sein.
Daher würde ich gerne den threadsicheren Signal and Slot Mechanismus von boost benutzten (boost::signal2). Jetzt die Frage kann ich Qt Komponeten mit den Boost Signals2 verbinden?
Qt Signals/Slots und boost::signals2
Prinzipiell kein Problem.
Qt-Slots sind normale Methoden, die auch normal (also nicht nur aktiviert über ein Qt-Siganl) aufgerufen werden können. Insbesondere können sie auch per Referenz oder boost::bind etc. an einen boost::sighnals(2) angeschlossen werden.
Umgekehrt ist es etwas aufwändiger. Wenn deine GUI nur für ein non-QT-Objekt (nicht Klassse!) von Interesse ist, kannst du eigene Wrapper-Slots in deiner Gui implementieren, die du auf Qt-Signals connectest, welche selber direkt Methoden aus deiner core-Klasse aufrufen.
Wenn allerdings mehrere Objekte (insbesondere auch unterschiedliche Klassen) interesse an State-Änderungen der GUI haben, bleiben dir zwei Lösungen:
Deiner Gui ebenfalls ein boost::signals2-Objekt verpassen, auf welches sich non-Qt-Klassen connecten können, deine Qt-Signals fängst du in nem Slot ab und löst das boost::signal(2) aus.
Oder (in meinen Augen das praktikablere) du schreibst für die core-Klassen eigene Wrapper-Klassen, die selber mit Qt-Signals und SLots umgehen können (ergo von QObject erben) und intern mit dem boost::signals2 deiner core-Klasse arbeiten. So verlagerst du das eigentliche Problem in eine eigene Klasse aus, wodurch deine Gui-Klassen rein in Qt und übersichtlich bleiben.
Qt-Slots sind normale Methoden, die auch normal (also nicht nur aktiviert über ein Qt-Siganl) aufgerufen werden können. Insbesondere können sie auch per Referenz oder boost::bind etc. an einen boost::sighnals(2) angeschlossen werden.
Umgekehrt ist es etwas aufwändiger. Wenn deine GUI nur für ein non-QT-Objekt (nicht Klassse!) von Interesse ist, kannst du eigene Wrapper-Slots in deiner Gui implementieren, die du auf Qt-Signals connectest, welche selber direkt Methoden aus deiner core-Klasse aufrufen.
Wenn allerdings mehrere Objekte (insbesondere auch unterschiedliche Klassen) interesse an State-Änderungen der GUI haben, bleiben dir zwei Lösungen:
Deiner Gui ebenfalls ein boost::signals2-Objekt verpassen, auf welches sich non-Qt-Klassen connecten können, deine Qt-Signals fängst du in nem Slot ab und löst das boost::signal(2) aus.
Oder (in meinen Augen das praktikablere) du schreibst für die core-Klassen eigene Wrapper-Klassen, die selber mit Qt-Signals und SLots umgehen können (ergo von QObject erben) und intern mit dem boost::signals2 deiner core-Klasse arbeiten. So verlagerst du das eigentliche Problem in eine eigene Klasse aus, wodurch deine Gui-Klassen rein in Qt und übersichtlich bleiben.