As others noted, Qt and Vala do not work hand in hand, but this does not mean that it is impossible to get them to work together. This is mainly about understanding what is happening under the covers.
Vala generates C code, which is then submitted to gcc (or another installed compiler) to create the binary. Please note: one of the main goals of Valβs designers was for Vala to create C-based libraries. Then they can be used by other languages ββthat accept C-based bindings - Python, Ruby, Java, etc.
So, you can use Vala to encode the C-based library that your Qt C ++ GUI application accesses. The Vala compiler creates an .h file in which your Qt application simply # includes.
The problem is that Qt and Vala use different object systems: QObject for Qt, GObject for Vala. (Vala allows other backends, and even some thought that Vala is releasing Qt C ++ instead of GObject-based C, but this is far in the future.) QObject and GObject are incompatible, and so for QObjects to discuss with GObjects, you need to do a lot of manual work based on C. (Writing a GObject in C is pretty verbose, so Vala's appeal hides it all.)
But it can be done. Note that Qt will even use the GLib event loop rather than its own , allowing the code to integrate in an event-driven application.
I cannot heartily recommend the above, but theoretically this is possible, mainly because C ++ code can easily call C code.
Another noteworthy feature is to make Vala code a DBus server and your Qt code DBus client. DBus is a fancy IPC, and therefore this is not suitable for all applications, but it may be for you. This is attractive because Vala can easily create DBus clients and servers (they look like regular objects). Qt DBus binding tools are also available. Please note that this means that your Vala code works as a separate process and is not a library in the process. See http://live.gnome.org/Vala/DBusServerSample and http://live.gnome.org/Vala/DBusClientSamples
source share