Is it possibly to use the Qt toolkit with Julia?
I've read that Julia supports calling c and python functions. How would I go about using pyqt/pyside or c's Qt bindings from within Julia?
The most stable option right now is to call PySide via Python, for which there is already a meta-wrapper with some helpful functions (event loop integration, etc.).
Longer-term, there is a C++ FFI under development, and it has a very minimal demo of calling Qt directly from Julia. If you are feeling adventurous, this could be something to look at, but understand that it is still pre-release software so be prepared to file bugs and don't be surprised if some features are not available yet.
Related
I have written a piece of R-code that performs a numerical computation. Now, I want to implement it into a nice GUI. I know that there are some R-packages, that allow to create GUIs from within R (e.g. gWidgets, RGtk2, ...). However, they seem to be rather limited in the capabilities and complicate to build. So I thought about going the other way round and writing a windowed-program that incorporates my R-code.
Is it possible to write a nice GUI (for example in Visual Basic.NET or Java) that allows to gather some user inputs, call the R-computations and display the results?
I ask for Visual Basic because there is this new R-Open that comes along with Visual Studio which makes me think the two must offer natural ways of collaboration with each other. I also hope that I would be able to compile an exe with it in the end.
Thank you very much for you Help!
Bernd
You can embed R in C++ code. There are examples in the R source code and documentation.
Very briefly, you'll need to build a shared DLL version of R (i.e with the --enable-R-shlib option) from the source code, using the Windows Tools. This is how GUIs like RStudio function.
The R Admin manuals have detailed instructions. The RInside package might make this a bit easier.
With the shared DLL you could probably embed R in other languages (it works for R in Python).
I am trying to write a GDB frontend. I use GDB for debugging embedded targets, especially with ARM processors. I have used Eclipse before, but I didn't like it very much. At work, we use Lauterbach Trace32, which is one of the most comfortable debuggers I have ever used. That's why I started a project where I try to implement a very similar application as a GDB frontend, which is specialised to embedded debugging.
However, I already have implemented some very basic commands, like viewing the source code, viewing registers of the target etc., which works well. Currently, I am implementing breakpoints. But for this I need some help.
I use Qt (with Qtcreator) on Linux for my project, so I have set up a QProcess for the gdb running in the background. I use the GDB Mi2 interface to communicate with gdb. Then, using write() I can send commands and with a SIGNAL, I can receive the responses from GDB. This works well, but the answers from GDB in this MI format are very ugly to parse. Could anyone give me a hint how this can be done in a elegant way? I tried BOOST to build a parser, which worked, but this is a much too complicated way in my opinion. Is there some better way to parse the GDB responses?
There's no truly great way to parse MI. MI is quite old and so predates the widespread adoption of XML and JSON. Also, even more unfortunately for you, there are a few known MI emission bugs in gdb (search bugzilla and the list archives) -- spots where gdb's MI output doesn't conform to the MI grammar. These have gone unfixed because it was judged that changing the output (without bumping the MI version number, something nobody seems to want to drive) would break existing parsers without much corresponding benefit.
The good news is that there are a few reusable parsers already in existence. So I would suggest using one of those. The parser in nemiver is written in C++ and is a reusable library. However as you're already using Qt you might check out the parsers in Qt Creator or KDevelop.
It might also be possible to roll your own gdb interface by programming gdb in Python. However, there are likely to be some holes in gdb's Python API, so I would only recommend it if you also want to get into hacking on the gdb Python layer as well.
There is the pygdbmi python library for exactly this purpose (it did not exist when you originally asked your question) https://github.com/cs01/pygdbmi
gdbgui is a frontend that utilizes pygdbmi: https://github.com/cs01/gdbgui
Have fun!
Disclaimer: I am the developer.
Qt Creator itself has a parser for (some superset of) the MI protocol, see plugins/debugger/debuggerprotocol.{h,cpp} in its sources. This (superset) protocol also used to capture data from Qt Creator's "pretty printing" produces and also serves as the debugger->frontend channel for the LLDB integration.
The protocol implementation is fairly well separated from the rest of Qt Creator's debugger plugin. It should be re-usable.
It looks to me that qthaskell is not being actively developed/ is abandoned.
Does it support QtQuick ?
Are there plans / any development in supporting qt 5 ?
Does anyone uses qt with haskell at all, or is gtk2hs the current favorite ?
QtHaskell supports Qt 4.6 and thus QtQuick, at least the early lighthouse build version. Note that this version of QtQuick is completely different from the current QtQuick version; most elements and properties have completely different names.
GTK support for Haskell is being actively maintained. As you have seen for yourself, the same cannot be said about Qt. One of the main reasons is that GHC cannot import foreign C++ code by itself; you need to generate wrapper C code that is then called by GHC, and there isn't a general method for wrapping C++ code as C, so a new tool has to be developed for C++ in this case. So, the "current favorites" for GUI libraries in Haskell are GTK and WxWidgets.
It would be very interesting to use Qt in Haskell, for example because the Qt sockets system could be used to link into FRP (functional reactive programming) libraries, and because Qt has an interface that is very referentially transparent and that supports immutable data structures.
There is actually a library to use Qt Quick from Haskell, though I didn't (yet) try it myself:
http://hackage.haskell.org/package/hsqml-0.1.1
http://www.gekkou.co.uk/software/hsqml/
http://www.haskell.org/pipermail/haskell-cafe/2012-September/103350.html
It is maintained as of now, with the latest release being in september 2012. There is also a demo program published on hackage.
That version doesn't yet support emitting Qt signals from Haskell code, there is however a fork which is supposed to offer that feature:
https://github.com/travitch/hsqml
But the fork appears less maintained than the original package, and in addition the author of the original package stated that he intends to add that feature in the future (and also support Qt5 when it will be available).
UPDATE now happily using this library, although it didn't get much traction, it works great for me.
Put shortly: For those familiar with language bindings in Qt and Gtk+. E.g. python and ruby. Are there any quality or capability difference?
More background: I know C++ and Qt very well. Minimal experience with Gtk+. I know C++ is not ideal for language bindings due to the lack of a well defined ABI (application binary interface). I also read that Gtk+ was designed to be bound to other languages. So I wonder how this manifets itself in practice. Are the Gtk+ bindings better maintained or work better in some way than their Qt counterparts?
I am presently quite interested in the Go language, and they have started developing Gtk+ bindings. However C++ bindings is far away. It makes me wonder whether learning Gtk+ is worth it.
I've used GTK and Qt in C++ and also PyGTK and PyQt in Python quite extensively.
Qt beats GTK hands down - its a much more flexible, modern and clean API. GTK is also lacking some features that are important to me. From a framework point of view, I'd recommend Qt.
As for langauge bindings (I can only speak about Python, since I've never used the Ruby equivalents), I think PyGTK (using Glade and a wrapper like Padraig Bradys libglade) make GUI programming insanely easy and fun. However, if you can GPL your software (or pay the license fee), then PyQt is also a good option, and while not quite as friendly as PyGTK + Glade (in that with GTK you can define your UI in Glade as a separate XML file, so you can tweak the UI without touching code; in Qt if you want to use QtDesigner, you have to generate code using uic, if I remember correctly) the API itself is really really nice to use and mirrors the Qt frameworks clean design very closely.
Over all, I'd probably recommend using PyQt over PyGTK, but I may be biased since I much prefer Qt over GTK nowadays, though you could try both out and see which you prefer - they are both almost trivial to get working.
If you are looking for a great book on PyQt, I'd recomment Rapid GUI Programming qith Python and Qt.
To summarize: IMHO Qt beats GTK in both quality and capability. Both PyGTK and PyQt are of excellent quality and capability mirrors the underlying framework, though PyGTK can load Glade xml files.
I think that GTK bindings are older than Qt ones (and so a bit more mature) but they are both usable and your previous knowledge of Qt should be the main factor in your choice.
I developed small GUIs using both Qt and GTK with their python bindings and found the two equivalent. Some regrets though on the PyQt bindings with Qt container (QVector, ...) that are not translated into regular python data structure and thus add a bit of complexity to the code. I didn't recall the same issues using PyGTK.
I have worked with both PyQt and PyGTK and I would say they're both regularly mantained and synched with their parent frameworks. However, and this is completely subjective, I found more rewarding working with PyGTK than with PyQt, even if I hadn't previously written any code using GTK. If you know well Qt, go with Qt though.
I have been trying a few combinations around Qt : RubyQt, JRuby + Jambi, PyQt. The first one quickly ends up in various segmentation-faults. My Qt skills may be the problem but all in all the seg faults are not quite readable. The forum for RubyQt is nearly dead so don't expect to find much information there.
So I moved to JRuby + Jambi. This worked until well, I reached some missing functions here and there. Plus I had to implement a proper signal/connect for JRuby. So, more or less a hack. Not convincing.
Finally I moved to Python (wich I don't like very much). But woooh, what a difference. Bindings are up to date, I have still to ecnounter a segmetatio fault, error messages are most of the time very explanatory. So as far as I'm concerned Python+Qt is a clear winner.
Please note that I was trying these combinations in order to find a proper language/qt binding so that I can create a production ready with my commutation hours (roughly 2 hours a day). So my tolerance to small-but-annoying problems such as segmentation faults is 0. I also have to develop on Windows and Linux. So Windows installation is necessary (and once again, Python is a clear winner here).
there are C++ gtk+ bindings. Google for gtkmm.
I'm writing an application that is currently a pure QT4 app. It is designed to run cleanly on both Linux and Windows.
However I plan to integrate it a bit into KDE in future and here come the problems with localization/translations.
QT4 uses its own tr()/tr().arg().arg() mechanism and .ts/.qm files.
KDE4 uses gettext and i18n/i18np mechanism and .po files.
How, easily, can I use KDE4's mechanism in my QT4 application without having to closely integrate it with KDE now (apparently making it non-runnable on Windows)?
Is it at all possible?
Thanks!
Starting version 4.5, Qt will support both .po and .xliff;
http://doc.trolltech.com/4.5/qt4-5-intro.html#qt-linguist-improvements
I think you will need to just pick one and go with it, if it is a cross platform app, I'd go with QT's method. The reason why is that KDE wraps it's internationalized string with i18*() macros and QT uses tr() macros, since a macro can't produce another macro, there is no way unless you have #ifdef's all over your code, or a massive string table...both of which suck.