IPC: Communication entre les processus Qt et MONO (sous Linux)

Je dois connecter une application Qt4 à une application mono. La preuve de concept actuelle utilise des sockets réseau (ce qui est sympa, je peux déboguer en utilisant nc sur la ligne de commande).IPC: Communication entre les processus Qt et MONO (sous Linux)

Mais je suis ouvert à de nouvelles suggestions. Quelles sont mes alternatives?

Edit:

La pile d'application d'origine est divisé en deux parties: + serveur client. Le client est censé montrer des images et des vidéos. Puisque nous avons constaté que ce n'est pas possible d'une manière saine d'esprit en Mono, nous avons divisé le client en deux parties:

serveur

-> client -> GUI

Dans la mise en œuvre d'origine du client + GUI était la même application . Maintenant, le client est en C# (en cours d'exécution sur Mono) et l'interface graphique est Qt4. La réécriture du client dans Qt4 n'est pas une option.

À l'heure actuelle, la communication entre le client et l'interface graphique est effectuée à l'aide des sockets TCP via localhost. Je suis à la recherche de meilleures implémentations. Alors que l'application fonctionne actuellement sous linux, j'aimerais aussi avoir ce système sur Windows. Le client (qui a une prise d'écoute ...) fonctionne sur Win32, et Qt4 est multi-plateforme.

Source

2010-05-07 elcuco

QT prend-il en charge les tuyaux nommés? – kenny

oui, il voit: http://doc.trolltech.com/latest/qlocalsocket.html – elcuco

Vous pouvez:

Intégrer Mono dans votre (probablement C++) Qt 4 application en utilisant le Mono embedding API.
Inverser (1) en exposant une API C à partir de votre GUI afin que vous puissiez le contrôler à partir du code Mono en utilisant P/Invoke.
Utiliser un mélange de (1) et (2) - incorporer Mono, l'invoquer à l'aide de l'API d'intégration, le rappeler à l'aide de P/Invoke.
Utilisez d'autres mécanismes IPC tels que les sockets Unix ou la mémoire partagée, ce qui peut être plus rapide et évite de bloquer un port IP.

Je recommande (3).

Source

2010-06-07 19:26:26

Je ne pense pas que la boucle d'événements de Qt sera comme dans un processus Mono. Pareil pour l'autre, est-ce documenté n'importe où? comme cela a été testé du tout? – elcuco

Pourquoi cela devrait-il être important?Pensez simplement à appeler les méthodes Mono à partir de C/C++ et à appeler les fonctions C à partir de Mono. Bien sûr, vous pouvez bloquer le mainloop dans une méthode Mono, mais vous pouvez le bloquer aussi facilement dans une fonction C++ (en particulier avec TCP IPC). Qyoto exécute la boucle principale QT à partir de Mono, GTK # exécute la boucle principale GTK à partir de Mono, etc. –

Eh bien, je suppose que c'est possible, mais cela signifie mélanger deux sous-domaines différents dans la même application. Je ne suis pas content à ce sujet, voir la réponse que j'ai écrite au projet Qoyoto par Sharique. Je suppose que (4) est le meilleur moyen .... – elcuco

-1

Vous pouvez écrire un projet complet en C# en utilisant Qyoto, vous n'écrivez pas de code en 2 langues différentes, accéder à l'API native en C# est une tâche très compliquée et cela prend beaucoup de temps.

Vous pouvez utiliser Qyoto, dont les liaisons C# pour Qt. Il y a un addin Qyoto pour MonoDevelop nommé 'QyotoDevelop'.

Source

2010-05-11 06:51:54 Sharique

Je suis downvoting car vous ne répondez pas à ma question. Le problème est qu'une application originale a été écrite en C#/win32 et maintenant le port Linux fonctionne à l'exception de l'interface graphique. Noe le client a divisé l'application GUI en deux, le backend qui parle avec le serveur, et l'interface graphique que je suis en train de wriging. Ils ne veulent pas toucher le backend - et j'accepte cette décision. Maintenant, mon problème, est de communiquer entre le backend et le front-end. – elcuco

Vous devez spécifier ceci en question. Dans quel langage backend est écrit? Avez-vous vérifié votre application avec MOMA? – Sharique

IPC: Communication entre les processus Qt et MONO (sous Linux)

Répondre

Questions connexes