tags:

views:

221

answers:

2

I have to connect a Qt4 application to a mono Application. The current proof of concept uses network sockets (which is nice, I can debug using nc on the command line).

But I am open to new suggestions. What are my alternatives?

Edit:

The original application stack is split into two parts: server + client. The client is supposed to show pictures and videos. Since we found that this is not possible in a sane way in Mono, we split the client into two parts:

server -> client -> GUI

In the original implementation the client+GUI were the same application. Now client is in C# (running on Mono), and the GUI is Qt4. Rewriting the client in Qt4 is not an option.

Right now the communication between the client and the GUI is been done using TCP sockets through localhost. I am looking for better implementations.

Edit2: While the application currently runs on linux, I would like to get this system on windows as well. The client (which has a listening socket...) does work on Win32, and Qt4 is cross platform.

A: 

You can write complete project in C# using Qyoto, you don't write code in 2 diff languages, accessing native api in C# is very complicated task and it takes a lot of time.

You can use Qyoto, which C# bindings for Qt. There is a Qyoto addin for MonoDevelop named 'QyotoDevelop'.

Sharique
I am downvoting this since you are not answering my question. The problem is that an original application has been written in C#/win32 and now the linux port does work except the GUI. Noe the client splited the GUI application into two, the backend which talks with the server, and the GUI which I am wriging.They do not want to touch the backend - and I accept that decision. Now my problem, is to communicate between the backend and front end.
elcuco
You must specified this in question. In which language backend is written? Did u checked you application with MOMA?
Sharique
A: 

You can:

  1. Embed Mono in your (presumably C++) Qt 4 app using the Mono embedding API.
  2. Invert (1) by exposing a C API from your GUI so you can control it from the Mono code using P/Invoke.
  3. Use a mixture of (1) and (2) - embed Mono, invoke it using embedding API, have it call back using P/Invoke.
  4. Use other IPC mechanisms such as Unix sockets or shared memory, which might be faster, and would avoid blocking an IP port.

I'd recommend (3).

mhutch
I don't think that event loop of Qt will like beeing inside a Mono process. Same for the other way, is this documented anywhere? as this been tested at all?
elcuco
Why should that matter? Just think of it as calling Mono methods from C/C++ and calling C functions from Mono. Sure, you could block the mainloop in a Mono method, but you could block it in a C++ function just as easily (especially with TCP IPC). Qyoto runs the QT mainloop from Mono, GTK# runs the GTK mainloop from Mono, etc.
mhutch
Well, I assume this is possible, but this means mixing two different sub-domains in the same application. I am not happy about this, see the response I wrote to the Qoyoto project by Sharique.I assume (4) is the best way....
elcuco
As long as you have a clean well-defined interface between the two language domains, I don't see how it's different to using IPC. It'll be a lot faster, and you won't have to dead with the headaches of running two processes.
mhutch
To understand how similar it *could* be to IPC, consider defining a single C# method byte[] MakeCall (byte[] data). Your C++ code would obtain a handle to the MonoMethod, then for each call you would encode arguments into a MonoArray, invoke the MonoMethod, and decode the resulting MonoArray. That would not be much different from synchronous network IPC.
mhutch
But things could be a lot easier if you break the boundary a little bit - e.g. define an identical struct in C++ and C#, pass a struct pointer to the C#, then use unsafe C# to deference it and write values directly back. Or define 'extern "C"' API on your host C++ program, and the Mono code (*when* you call it) could call back out really easily using P/Invoke.
mhutch