We have a sizable code base in Perl. For the forseeable future, our codebase will remain in Perl. However, we\'re looking into adding a GUI-based dashboard utility. We are consi
Interesting project: I would opt for loose-coupling and consider an XML-RPC or JSON based approach.
You can spawn a child process and use an IPC mechanism like sockets or STDIO, or even embed one interpreter in the other.
But why switch languages when Perl offers several Tk (Tk, Tkx, and Tcl::Tk) bindings and a very capable Wx binding?
I have written and distributed GUI projects with Perl's Tk and Wx libraries.
If you are need the ability to create stand-alone executables, check out PAR::Packer, ActiveState's PerlApp, and Cava Pacakger.
Try the CPAN distribution Python (pyperl) for interfacing with python code.
Well, if you really want to write the GUI in another language (which, seriously, is just a bad idea, since it will cost you more than it could ever benefit you), the thing you should do is the following:
But honestly, I really suggest you taking a look at the Perl GTK2 binding, it is awesome, including features such as implementing a Gtk class entirely in Perl and using it as argument to a function written in C - for instance, you can write a model class for a gtk tree entirely in Perl.
I hate to be another one in the chorus, but...
Of course, I only say all this because you said "Dashboard" which I read as "Corporate", which then makes me assume a Microsoft AD network...
I'd avoid inter-language calls if possible; fragility and massive increases in dependencies await you down this road. However, there is...
Inline::Python
If python must be used, the Inline::*
series of modules have been generally well received. This lets you write python inside a perl script. You still have to write perl but it would let you use python libraries inside perl scripts. It will make things more difficult to debug, though.