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
Related
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
I am choosing a GUI toolkit for C++ to learn. I have done some searching online and most people suggest GTKmm for C++ over GTK+. Despite that fact, I have seen some C++ applications made using GTK+.
Therefore, I just want to know the specific reasons for this:
1. Why GTKmm is preferred for C++?
2. What are the limitations I will face if I use GTK+ for C++ applications instead of GTKmm?
gtkmm allows you to write code using normal C++ techniques such as encapsulation, derivation, and polymorphism. As a C++ programmer you probably already realize that this leads to clearer and better organised code.
gtkmm is more type-safe, so the compiler can detect errors that would only be detected at run time when using C. This use of specific types also makes the API clearer because you can see what types should be used just by looking at a method's declaration.
Inheritance can be used to derive new widgets. The derivation of new widgets in GTK+ C code is so complicated and error prone that almost no C coders do it. As a C++ developer you know that derivation is an essential Object Orientated technique.
Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with by use of pointers. As a C++ coder you know that pointers should be avoided where possible.
Less code. The GTK+ C object model uses prefixed function names and cast macros. For instance: gtk_button_set_text(GTK_BUTTON(button), "sometext"); gtkmm C++ code is shorter and clearer. For instance: button.set_text("sometext");
There's no need to worry about GTK+'s inconsistent reference-counting policy.
Source: http://live.gnome.org/gtkmm/FAQ
I feel like writing a (rich) text editor mainly to be used for note-taking, in either C or C++, using most probably GTK or Qt for the UI.
The problem is that I can't really decide what to use. I know both C and C++, C a little better. I've never used Qt but I'm completely fine with learning, and I have some experience with GTK.
Is there any particular combination you would give preference to and why? In particular, do you think there is any advantage to using C++, or will C do just fine?
I'm writing an editor myself, and I too have choose C++ and Qt.
The reasons for this:
C++ is CPU- and memory-efficient. I hate slow text editors with a passion.
Supporting libraries are almost always written in C or C++, so I can interface nicely with them (and extend them if needed).
Qt is a great, well supported, cross-platform/-system GUI library, and it contains a lot of generally useful base classes/algorithms. It makes C++ actually fun to use.
Personally, I would go for C++/Qt.
The reason for my bias is that unlike GTK, Qt is not only a UI toolkit, but provides a lot of other features like networking, database access, xml parsing... which could benefit you a lot. And all that with a consistent API.
The main fault of Qt is that it is a replacement for standard C++ library in a sense that it has its own list, string, map, hash... classes. Those have much nicer API than STL and are (IMO) much more pleasant to work with, but if you learn C++ this way, it will be much more difficult to return to standard C++ if you ever need to.
If you want a gentle introduction to OOP with C++ and Qt, see this book (free to download):
http://cartan.cas.suffolk.edu/oopdocbook/
C++ is probably, better suited for RAD (Rapid Application Development) than C. This is because of its additional features such as classes and objects. C I think would just handicap you because, you do not have some stuff like classes and objects.
Usually, OO languages are suited for GUIs and what not whereas, languages like C are for low-level driver stuff where efficiency is of great importance (even though its a little debatable).
C++ is a better C. C++ can do whatever C can do and in addition supports object-oriented and generic-programming design paradigms. 'SUPPORT' here means the language itself and the facilities around it provide ease, pleasure and productivity for the programmer to achieve these design goals. Go for C++ and you won't regret.
If you choose Qt, you must also choose C++ because Qt is a C++ library. If you are programming a rich text editor, I don't know how much it's left for you to do on top of Qt's text editor which well supports rich text. You probably only need to concentrate on adding domain-specific features of your interest.
I'm looking to be able to build GUI applications quickly and painlessly as possible. I'm competent (though not expert, and have no formal training) in C++, but have never used a GUI building toolkit or framework or anything. I am not a professional programmer and am totally inexperienced and ignorant when it comes to building GUI apps. Have spent hours researching trying to figure out what to do; only getting more confused and discouraged though.
Qt and wxWidgets seem like the most popular options for cross-platform apps, though cross-platform isn't necessarily all that important to me; Windows-only is fine if that means the fastest learning curve.
Qt seems cool and the Qt Creator is sweet looking with lots of good demos, except it has its own classes for everything, and I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally. I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
I was thinking Visual Studio would have the smallest learning curve, but when I open a test GUI app, I see a bunch of foreign looking stuff like carats (^) all over the place - I found online that these mean "handles", which I have trouble even understanding the definition or purpose of ("sort of like pointers but not really" is basically how I've read people define them).
I know pretty much nothing about wxWidgets, or how it compares with Qt.
So every option has a big learning curve - and ideally I'd like to know which one minimizes the time you have to spend learning the toolkit/framework itself. Since I'm likely never going to be making money from the programs I create, the time I spend learning a specific toolkit would be pretty costly. I just want to be able to make a functional program using the C++ knowledge I have, but in GUI form. At the moment it seems if I want to make a GUI app, I'd have to spend way more time learning the GUI framework I'd use than writing the functional part of the app itself.
Any input from people wiser and more experienced than me would be appreciated :)
First and foremost, start simple. There's a lot to the subject. If you are finding it hard, don't try and take it in all at once.
Most of the good GUI packages have tutorials. The best advice I can give is that you try each of them, or at least a couple of them. They are the best short introduction you can have to the library you choose and if they are any good they narrow down what you need to absorb at first. That will give you some basis for comparison, because they are each trying to do very similar things (and you will see some of them before you are done), but they have different feels. You will likely find you have a preference for one and that's the one to get serious with. It will also give you a sense of what's hard about GUI programming as separate from the particulars of one package, which, if you have only used one, you won't have seen. Personally I find this sort of knowledge very helpful, because it makes me less intimidated by particulars.
Here's a list of tutorials in one place, though you have likely seen them already:
Qt's tutorial
WxWidgets' tutorial
Gtkmm book. Not quite a tutorial, though there are lots of examples.
.NET tutorials, either for WinForms or for WPF.
Second, it sounds to me that you need to get some in depth understanding of the concepts of GUI programming, not just a particular library. Here there is no substitute for a book. I don't know all of them by a long shot, but the best of the bunch will not just teach you the details of a toolkit, they will teach you general concepts and how to use them. Here are some lists to start with though (and once you have titles, Amazon and Stack Overflow will help to pick one):
List of Qt books
WxWidgets book (PDF version)
There are tons of WPF and WinForms books. I can't make a good recommendation here unfortunately.
Third, take advantage of the design tools (Qt Creator, VS's form building and so on). Don't start by trying to read through all the code they generate: get your own small programs running first. Otherwise it's too hard to know what matters for a basic program and what doesn't. The details get lost. Once you've got the basics down though, Do use them as references to learn how to do specific effects. If you can get something to work in the design tools, then you can look at particular code they generate to be able to try on your own hand-written programs. They are very useful for intermediate learning.
I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally.
I second the comment of GRB here: Don't worry about this. You are going to need to learn a lot specific to the toolkit no matter which toolkit you use. But you will also learn a lot that's general to GUI programming with any of the decent toolkits, because they are going to have to cover a lot of the same ground. Layouts, events, interaction between widgets/controls, understanding timers -- these will come up in any GUI toolkit you use.
However do be aware that any serious GUI package is an investment of time. You will have a much easier time learning a second package if you decide to pick one up, but every large library has its personality and much of your time will be spent learning its quirks. That is, I think, a given in dealing with any complex subject.
I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
You do not need most of the non-GUI classes of Qt to use Qt's GUI properly. There are a handful of exceptions (like QVariant) which you'll need just because the GUI classes use them. I found you can learn those on a case-by-case basis.
Which is the easiest to learn is really going to depend on how you personally learn.
Personally, I've found Qt to be the easiest to learn so far. The GUI classes are rather nice to use, but I've found the non-GUI classes to be excellent, making it easy to avoid a lot of common issues you'd normally get with a more basic API. The documentation is excellent, IMO, as are the books, the examples, etc. It's also being very actively developed, with a few new technologies coming in the near future (like DeclarativeUI).
I've found Visual Studio/Windows API/.Net to be a good bit more complicated to learn. The API documentation on MSDN is rather complicated and not really organized in a manner that I find intuitive.
I've tried learning WxWidgets a few times, but I've never liked the API documentation.
All this is just my personal experience, YMMV of course. I'd say just dabble in all of them and see which one takes you the furthest, it won't hurt to try multiple.
As a person who learned C++ through Qt, I can only say that they work very well together. C++ purists (like I have become) will find lots of things in Qt not to their liking (the moc preprocessor, e.g., and the continued absence of exceptions for error reporting), but looking back, Qt provided a very gentle introduction to C++ for me.
And if you're like me, you throw in a handful of boost libs in each Qt project, because we want to write "real" C++, not the softened thing Qt uses :)
I would suggest wxWidgets. To me, it's pretty intuitive and looks nice.
Code::Blocks was built with it, so check that out to see if you like the graphics.
There are also a slew of bindings for wxWidgets, such as wxPython, wxErlang, and others, so if you decide to switch off of C++, you can take wxWidgets with you.
I also use wxWidgets and use it all the time for Windows-only applications (the only downside is that wxWidgets is notorious for large .exe filesizes, which may or may not be a problem for you). I found it very simple to use from the start, especially when combined with a GUI designer (personally I use wxDev-C++).
I've never used Qt, so I can't speak to its simplicity, but I doubt the difficulty is on a vastly different scale than that of wxWidgets. However, what I can say is that no matter what API you use (wxWidgets, Qt, WinAPI, etc) your code will be "locked into" that particular platform, so don't worry if you feel that learning Qt will lock you into the Qt platform (because the same thing will happen with any of those APIs).
If you're working solely on Windows however, you may want to do a few simple programs with WinAPI first. That way you have a basic understanding of the lowest level of Windows GUI programming before you move onto Qt/wxWidgets. That said, if you're really into cross-platform programming, then don't worry about that and go straight into Qt/wxWidgets.
I can't intelligently comment on the learning curve aspect, but a quick survey of StackOverflow questions shows about twice as many Visual C++ questions as Qt questions. Probably means that there is a larger support group in place for Visual C++. Might make learning it a little easier if there are more folks to help out.
No matter what you pick, I am quite sure it won't be easy and painless.
Having said that, I know that in some schools they use FLTK because they consider it relativelly easy to learn. I have never tried it.
In my everyday work I use WTL which is as close to the system as it gets while still providing some level of abstraction over pure Win32. I am not sure if I would consider it easy to learn, though, especially given the lack of documentation.
I recommend codegear C++ builder (previously known as borland C++ builder) from codegear which comes with a 30 trial. The nicest thing about it is that the GUI provides you with components that you drop onto a form in a WYSIWYG fashion and make functional by adding code to handle the events it fires. It comes with a whole bunch of compontents out of the box and you can add 3rd party components to it too, like the awesome ExpressQuantumGrid from devexpress, or write your own. It's very powerfull if you know what you're doing but intuitive enough that a beginner can write a database CRUD application in about 20 lines of very simple code.
Since nobody has mentioned it yet, for the sake of completeness, have a plug for the Fox toolkit. This is the one I used last time I did any C++ UI work of my own volition. There are also binding for this to Ruby and Python (the latter being many years out of date, though).
In general, the choice of a toolkit for self-directed work comes down to personal preferences for
the layout manager style
the event handler registration style
How native the widget set looks/can be made to look
If cross-platforming is not necessary, try .net + msvs or delphi. easy, all-in-one, no pain.
Qt is the best option for you. It's the easiest to learn, the most elegant and powerful and it is completely free.
Visual C++: This is an IDE, but it comes with its own GUI library called MFC. MFC is an old library with many quirks and it is difficult to learn and use. Many C++ programmers use it on Windows because it comes from MS, it's fast and it's free if you buy Visual C++. Since VC++ is an IDE, you can also use wxWidgets and Qt with it, although in your particular case I would recommend Qt Creator instead.
You seem to have experimented with Managed C++. Don't use that, even MS recommends that you only use Managed C++ as glue between C++ and C#.
wxWidgets: This one was a strong contender up to the day when Qt became free for commercial projects. It was always in the shadow of Qt and it is known that the documentation is not very good and the API is not as easy to learn as Qt's. Cross-platform MFC would be a good way to describe it.
C++ Builder: Borland made too many mistakes with C++ Builder and ended up getting out of the dev tools business altogether. It was a good product and I originally learned Windows GUI programming in one of the first versions, but I won't use it any more. There are better options and it is too expensive.
Does someone know of a book or tutorial explaining Qt for Delphi / C++ Builder / VCL developers?
What would be the best approach for a developer with that background to learn Qt? I'm particulary interested in how to accomplish things that I know how to do in Delphi with Qt.
For example, what is the Qt equivalent to Delphi Frames? What about Forms/Frames inheritance? Should I use Qt Designer, Qt Creator or hand code for such tasks?
Another thing is Qt Widgets and objects life cycle. Does Qt take care of widgets and objects destruction or shoul the programmer do it manually? Or may be Qt does that for some types of objects but not for other types?
As a side note I do know C++, so the language itself is not an issue. I'm concerned with the library.
One way might be to study the source for the FreeCLX open source project. It contains an implementation of the VCL using Qt. So if you are curious which Qt widget maps to a VCL type, that should get you on your way. Note, however, that Qt 2.x.x used multiple inheritance (no longer true in current Qt), so the FreeCLX interfaces to Qt via a special library to flatten this out.
To further what Javier says - concepts from one windowing toolkit to another map even less well than languages. It's especially confusing since there are only so many words (frame,window,widget etc) that get reused.
I would go through the (excellent) examples and tutorials included in the QT distribution (you might have to download the source dist) and then think - how would I have done that in VCL?
the easiest and fastest way to learn something new is to put all the old things aside. don't try to think in Delphi when developing in C++.
first learn some C++ (it's not hard, really) then pick Qt. you don't have to know ALL of C++ and STL to get to speed with Qt, just get comfortable with the syntax and fundamental concepts (like pointers, structs vs. classes, these kind of things).
If I remember correctly, Qt Assistant has some good beginner tutorials, which step you through the basic structure of an increasingly complex Qt GUI app. You also get introduced to the parent/child hierarchy, the signal/slot event system, both of which are key to understanding Qt applications.
I'm with the others who say not to try to map Delphi metaphors to Qt metaphors. However, you will likely find many similarities along the way where your Delphi experience will give you perspective.
Good luck!
EDIT: QtCentre is the best online forum for Qt development in my opinion. You'll find many knowledgeable people there.