First off: I'm new to both Qt and SWIG. Currently reading documentation for both of these, but this is a time consuming task, so I'm looking for some spoilers. It's good to know up-front whether something just won't work.
I'm attempting to formulate a modular architecture for some in-house software. The core components are in C++ and exposed via SWIG to Python for experimentation and rapid prototyping of new components. Qt seems like it has some classes I could use to avoid re-inventing the wheel too much here, but I'm concerned about how some of the bits will fit together.
Specifically, if I create some C++ classes, I'll need to expose them via SWIG. Some of these classes likely subclass Qt classes or otherwise have Qt stuff exposed in their public interfaces. This seems like it could raise some complications.
There are already two interfaces for Qt in Python, PyQt and PySide. Will probably use PySide for licensing reasons. About how painful should I expect it to be to get a SWIG-wrapped custom subclass of a Qt class to play nice with either of these? What complications should I know about upfront?
PyQt exposes C++ code to Python via SIP; PySide does so via Shiboken. Both have roughly the same capabilities as SWIG (except that they only support "extended C++ to Python", while SWIG has back-ends for Ruby, Perl, Java, and so forth as well). Neither SWIG nor SIP and Shiboken are designed to interoperate with each other. You couldn't conveniently use SWIG to wrap any code using the C++ extensions that Qt requires (to support signals and slots) and I have no idea what perils may await you in trying to interoperate SIP-wrapped (or Shiboken-wrapped) and SWIG-wrapped code.
Why, may I ask, have you chosen to use two separate and equivalent ways to wrap different parts of your C++ codebase (Qt via SIP or Shiboken, everything else via SWIG)? If you can still reconsider this weird design decision I would earnestly recommend that you do so.
If your choice of SWIG is carved in stone, I predict big trouble any time you're wrapping C++ code using Qt extensions (i.e., slots or signals) and a generally thoroughly miserable time for all involved. If you pick one way to wrap, and stick with it, the problems should be enormously reduced. I have no real-world experience with Shiboken (it's a bit too new, and I hardly ever do GUI apps these days any more... my world's all web app!-), but have used SIP in this role in the past (way back before it was decently documented -- these days it seems to me that it's splendidly documented, and superficial perusal of Shiboken gives me the same impression) and I can recommend it highly (indeed if I could choose it would be an option probably preferable to SWIG even if no Qt code was involved in a project).
Related
I recently asked this question https://softwareengineering.stackexchange.com/questions/129076/go-instead-of-c-c-with-cgo and got some very interesting input. However there's a mistake in my question: I assumed cgo could also be used to access c++ code but that's not possible. Instead you need to use SWIG.
The go faq says "The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. "
my question:
Is it possible to access high-level c++ frameworks such as QT with SWIG + Go and get productive? I'd like to use Go as a "scripting language" to utilize c++ libraries.
Have you any experience with go and swig? Are there pitfalls I have to be aware of?
Update/Answer: I've asked this over IRC too and I think the question is solved:
SWIG is a rather clean way of interfacing c++ code from other languages. Sadly matching the types of c++ to something like go can be very complex and in most cases you have to specify the mapping yourself. That means that SWIG is a good way to leverage an existing codebase to reuse already written algorithms. However mapping a library like Qt to go will take you ages. Mind it's surely possible but you don't want to do it.
Those of you that came here for gui programming with go might want try go-gtk or the go version of wxWidgets.
Is it possible? Yes.
Can it be done in a reasonably short period of time? No.
If you go back and look at other projects that have taken large frameworks and tried to put an abstraction layer on it, you'll find most are "incomplete". You can probably make a fairly good start and get some initial wrappers in place, but generally even the work to get the simple cases solved takes time when there is a lot of underlying code to wrap, even with automated tools (which help, but are never a complete solution). And then... you get to the nasty remaining 10% that will take you forever (ok, a really really long time at least). And then think about how it's a changing target in the first place. Qt, for example, is about to release the next major rewrite.
Generally, it's safest to stick to the framework language that the framework was designed for. Though many have language extensions within the project itself. For example, for Qt you should check out QML, which provides (among many other things) a javascript binding to Qt. Sort of. But it might meet your "scripting" requirement.
A relevant update on this issue: it is now possible to interact with C++ using cgo with this CL, which is merged for Go 1.2. It is limited, however, to C-like functions calls, and classes, methods and C++ goodies are not supported (yet, I hope).
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
I have read a few articles in the cross-platform tag. However, as I'm starting a fresh application (mostly a terminal/console app), I'm wondering about the easiest way to make it cross-platform (i.e. working for Linux, Mac OS X, and Windows). I have thought about the following:
adding various macro/tags in my code to build different binary executables for each operating system
use Qt platform to develop a cross-functional app (although the GUI and platform component would add more development time as I'm not familiar with Qt)
Your thoughts? Thanks in advance for your contribution!
Edit: Sounds like there are a lot of popular responses on Java and Qt. What are the tradeoffs between these two while we're at it?
Do not go the first way. You'll encounter a lot of problems that are already solved for you by numerous tools.
Qt is an excellent choice if you definitely want C++. In fact, it will speed up development even if you aren't familiar with it, as it has excellent documentation and is easy to use. The good part about it is that it isn't just a GUI framework, but also networking, XML, I/O and lots of other stuff you'll probably need.
If not necessary C++, I'd go with Java. C++ is far too low level language for most applications. Debugging memory management and corrupt stacks can be a nightmare.
To your edited question:
The obvious one: Java has garbage collection, C++ doesn't. It means no memory leaks in Java (unless you count possible bugs in JVM), no need to worry about dangling pointers and such.
Another obvious one: it is extremely easy to use platform-dependent code in C++ using #ifdefs. In Java it is a real pain. There is JNI but it isn't easy to use at all.
Java has very extensive support of exceptions. While C++ has exceptions too, Qt doesn't use them, and some things that generate exceptions in Java will leave you with corrupt memory and crashes in C++ (think buffer overflows).
"Write once, run everywhere." Recompiling C++ program for many platforms can be daunting. Java programs don't need to be recompiled.
It is open to debate, but I think Java has more extensive and well-defined library. The abstraction level is generally higher, the interfaces are cleaner. And it supports more useful things, like XML schemas and such. I can't think of a feature that is present in Qt, but absent in Java. Maybe multimedia or something, I'm not sure.
Both languages are very fast nowadays, so performance is usually not an issue, but Java can be a real memory hog. Not extremely important on modern hardware too, but still.
The least obvious one: C++ can be more portable than Java. One example is FreeBSD OS which had very poor support for Java some time ago (don't know if it is still the case). C++/Qt works perfectly there. If you plan on supporting a wide range of Unix systems, C++ may be a better choice.
Use Java. As much bashing as it gets/used to get, it's the best thing to get stuff working across any platform. Sure, you will still need to handle external OS related functions you may be using, but it's much better than using anything else.
Apart from Java, there are a few things you can run on the JVM - JRuby, Jython, Scala come to mind.
You could also write with the scripting languages directly( Ruby, Python, etc ).
C/C++ is best left for applications that demand complete memory control and high controllability.
I'd go with the QT (or some other framework) option. If you went with the first you'd find it considerably harder. After all, you have to know what to put into the various conditionally compiled sections for all the platforms you're targeting.
I would suggest using a technology designed for cross-platform application development. Here are two technologies I know of that -- as long as you read the documentation and use the features properly -- you can build the application to run on all 3 platforms:
Java
XULRunner (Mozilla's Development Platform)
Of course, there is always the web. I mostly use web applications not just for their portability, but also because they run on my Windows PC, my Ubuntu computer, and my Mac.
We mainly build web applications because the web is the future. Local applications are viewed in my organization as mostly outdated, unless there is of course some feature or technology the web doesn't yet support that holds that application back from being fully web-based.
I would also suggest Github's electron which allows to build cross platform desktop applications using NodeJs and the Google's Chromium. The only drawback for this method is that an electron application run much slower than a native C++ application due to the abstraction layers between Javascript and native C++.
If you're making a console app, you should be able to use the same source for all three platforms if you stick to the functions defined in the POSIX libraries. Setting up your build environment is the most complicated part, especially if you want to be able to build for multiple platforms out of the same source tree.
I'd say if you really want to use C++, QT is the easiest way for cross-platform application, I found myself using QT when I need an UI even though QT has a large set of library which makes pretty much everything easier in C++.
If you don't want to use QT then you need a good design and a lot of abstraction to make cross-platfform application.
However I'm using more and more Python bindinq to QT for medium size application.
If you are working on a console application and you know a bit of python, you might find Python scripting much more comfortable than C++. It keeps the time comsuming stuff away to be able to focus on your application.
I heard Qt API is written in pretty outdated C++ language. Is it true?
Are there any plans to make it use more modern C++ language? Are there any official information on this?
Are there any projects with the aim to wrap current Qt API constructs with more modern C++?
UPDATE
That's more to this question than templates and that's not the question only about the current state of affairs (that's why I tagged it with the future tag).
UPDATE
I'm especially concerned with Qt API as this is what users of this framework work with.
Using modern C++ language in API makes it more robust, flexible and easier to use.
What kind of C++ is used inside Qt is far less important to me.
Qt is known not to use templates, one very useful modern c++ feature. But that does not mean that there is a need for a wrapper to Qt's API. Qt uses in-house precompilers to address the same issues. Some don't like this approach, but Qt's API is very simple and efficient, and i don't believe there is a real need to modernize it.
In particular, signals&slots, a very impressive feature from Qt, can be achieved using templates (see boost.signals library), but the way Qt has implemented it is still much more efficient.
I'd say "don't worry and use Qt as is".
EDIT:
Sorry i forgot about template containers provided with Qt. But still, Qt's API makes very little use of template classes. This does not mean that they don't use them inside Qt though or that their way of coding is obsolete.
Boost.Signals are probably more powerful than Qt signals/slots but, as far as i can tell, there is no arguing about which is simpler to use. One very convincing implementation of the KISS principle.
Qt uses modern variants of the C++ language - currently C++98, and yes Templates are also used where it's appropritate. Qt has some support for STL. See e.g. http://qt-project.org/doc/qt-5.1/qtcore/containers.html - and convenience functions for e.g. std::string. It's all in the docs: http://qt-project.org/doc/qt-5.1/qtdoc/index.html ;) The question about templates vs moc is one we get so often we have added it to our documentation; http://qt-project.org/doc/qt-4.8/templates.html
Qt sources contain the pattern "template <" 1280 times in src/corelib alone. I fail to see how this can be mistaken as "Qt is known not to use templates"
Unlike Boost.Signals, Qt's implementation of signals/slots is thread-safe via the use of queued connections. On May 2nd, 2009, however, Boost.Signals2 was released and brought with it the much-desired thread-safety. From the developer point of view, Qt's implementation of signals/slots is much easier to use, mostly due to the fact that it does not use templates. For an in depth read of why Qt uses moc instead of templates for signals and slots, here's a page from their documentation.
For those wondering why Qt has its own set of container classes, I'm pretty sure that the main motivation was to offer implicit sharing. All of the container classes are implicitly shared, so whenever a QList is copied, only a pointer to the data is copied. See here for more information on shallow copying within Qt.
To directly answer your question,
Qt's API is comprehensive. I'm pretty sure they'll come out with a QApp::ParkMyCar() function some time. They sometimes implement multiple ways of doing the same thing, with different positions on efficiency vs ease of use. Check out their (excellent) documentation. It is as comprehensive, and has saved my ass more than once.
From what I've seen of the Qt source code, the code is highly efficient.
Take a look at the features in the install configuration - you can turn on/off support for various features (including STL, threading and even the GUI). Further, when the Trolls made Qt 4 ground-up, they did not trade off features against code-jazz -they just delivered more of both. Given the quality of their programmers and their way of updating major versions, I don't think we need to worry about Qt (or parts) getting outdated.
Qt's target market (for desktops) is the MamaPapa company that makes Hello Kitty desktop alarm clocks, and wants to Code once and rest assured that it runs on all "sane" systems - Windows 98 and above, popular Linux distros and Mac OS X. This means pandering to the LCD of all the main compilers in each kind of system. If this means keeping template-wizardry in their code to a minimum, so be it.
Throughout the Qt 4.x lifetime, I doubt that it makes sense to rewrite parts of Qt to use e.g. "more modern" C++. This is because of the premise that all releases in the same major version of Qt should still be binary compatible. We also can not just obsolete or deprecate classes that the customers still use (although it is perfectly fine to introduce new stuff, even for a limited set of supported compilers).
If finally Qt 5 is almost out of the door, and the modern C++ constructs and features are finally available in the targeted supported platforms and compilers, and doing so will help C++ developers and customers to write better and more powerful code, then why not?
I really don't like the way Qt managed to implement its signals/slots mechanism. Their 'moc' precompiler really smells like a hack to me, and it doesn't even support standard C++.
I think it would be great if Qt could modernize itself to use at least the STL classes. What would be really awesome would be for Qt to use Boost whenever possible (especially Boost.Signals).
I, too, don't like the way Qt adds voodoo magic to C++. It uses so many macros that it awfully reminds me of C. At the moment, there is nothing to indicate that Qt would be kinder to C++ features in the future. I would really like to see it be more like C++ and not a language of its own (e.g. Why do we need std::vector<> and QVector<>? Or Qt signals, Boost.Signals and sigc++?)
Qt is a library and needs to support a wide range of compilers. It still supports MSVC6, e.g. (I think Qt Software is phasing out support for this, though). This limits the more modern C++ features, Qt is able to use.
But this does not mean that you can't use them in your Qt program.
I am a C# programmer who started using ubuntu about 2 years ago. I'm wanting to learn GUI programming in either C or C++. I don't really like mono, it tends to crash on my system. I have a basic understanding of C++. I have never worked in C, but it looks cool. Which toolkit should I learn/use? Give Pro/Cons of each. Thanks!
I could be accused of bias since I do help contribute to gtkmm, but I was a user first, so... In any case, I would highly recommend gtkmm if you're comfortable with C++. Memory management is much easier with gtkmm than with GTK+ because reference-counted objects are managed automatically with smart pointers. You can also instantiate objects as auto variables (e.g. on the stack) and have their lifetime determined by their scope. So in practice, it's much easier to avoid memory leaks with gtkmm than with GTK+.
Another huge advantage of gtkmm over GTK+ (in my opinion) is the use of a type-safe signals framework. In GTK+, you constantly need to pass things as void pointers and then cast them around to the type you think they should be. In gtkmm, you dont need to do this, and can take advantage of the compiler enforcing type-safety on your signal handlers.
Another big advantage over C/GTK+ is the ease of deriving new classes. In GTK+, you need to write a lot of boilerplate code and basically re-implement things that you get for free in C++ as part of the language (e.g. inheritance, constructors, destructors, etc). This is more tedious and error-prone.
greyfade mentioned that gtkmm is incomplete, and he's right to a certain extent -- gtkmm does not cover absolutely everything in the GTK+ API (though it gets awfully close). But in practice this is not a problem because you can always use the C/GTK+ API directly from your gtkmm code. This C compatibility is a huge advantage of C++ over something like C# or python bindings where you would have no alternatives if the binding didn't cover part of the API.
The only real reasons to choose GTK+ over gtkmm (IMO) are that gtkmm has a little additional overhead since it is a wrapper on top of the C library (but this is generally just a single function call, which is going to have negligible impact), or if you hate or can't use C++.
If you're a C# programmer, why don't you take a look at Vala?
I use pygtk for most of my Linux GUI applications, but Python was simply too slow for the project I'm working on right now, so I was trying to pick one of GTK+ and GTKmm. Then I met Vala.
It's a pretty new language, and therefore documentation is pretty limited at the moment, but I think it has the best of both worlds: C# syntax with C speed.
Since C++ is more familiar to you, you may find GTKmm to be a better fit, since you can use idioms like RAII. Unfortunately, GTKmm is a little incomplete and is missing a few of the lesser-used parts of GTK.
GTK+ on its own, however, essentially exposes an object model similar to what you find in C++, but with only C functions. Things like construction and destruction in C++ are done explicitly in the C API and instances of widgets are handled via pointers exclusively.
Try both and see which fits your project better.
Like many have said, Gtkmm does provide you with good memory management, reference counted objects, etc. It does fall down in one department, though. Documentation. The whole of the Gtkmm project suffers from the "undocumentation" phenomena, where the posted (and reposted on 3rd party sites) documentation is simply a javadoc scan of the header files.
Just wanted you to know what you'd be getting into. For instance, the Scrolled Window is one of the better documented classes in Gtkmm.
I would suggest to learn vala with gedit.
http://www.valaide.org/doku.php : vala
https://launchpad.net/valable : Eclipse
http://code.google.com/p/vtg/ : Gedit
http://abderrahim.arablug.org/blog/ : anjuta
I think the best way to go would be first learn gtkmm! After you are done with the basics of gtkmm, GTK+ should be fairly straightforward to learn(provided you know C and are comfortable with pointers).
In case you don't know C, you can learn it quickly by reading The C Programming Language by Dennis Ritchie
I recommend you to learn gtkmm first because it is specially designed for C++, which is somewhat similar to C# since both are Object Oriented, so gtkmm will be relatively easy to learn first than GTK+.
After gtkmm, you can move on to GTK+
Most of the open source companies use GTK+ rather than gtkmm, so GTK+ is worthwile to learn!
Have you looked at Qt?
It's nice C++ design, cross platform and LGPL