Can someone suggest a good GUI programming toolkit that relies on C or C++ for use in linux? I was thinking I'd give GTK+ a try. Any reason I shouldn't?
Printable View
Can someone suggest a good GUI programming toolkit that relies on C or C++ for use in linux? I was thinking I'd give GTK+ a try. Any reason I shouldn't?
GTK+ and Qt are the two biggest toolkits for Linux. If you're okay with programming UI in C, then GTK+ is fine, otherwise use Qt which uses C++.
There is a C++ version of gtk+, "gtkmm". IMO though, if you are comfortable with C and competent enough in C++, you might want to learn the base C gtk API and create your own wrappers. I learned gtk in C, then C++, then started using gtkmm, but didn't like the API as much. Since then the occasional GUI stuff I've done I've used C++ with my own gtk classes instead of gtkmm. I'd like to do more of that I just don't have time or a purpose for it right now. I'm sure some people will scoff at me for saying this, but building your own C++ lib out of a C API is more interesting and flexible than just using a C++ lib. Of course, you can probably screw that up pretty badly if you don't get some experience with the C API first, so maybe that is bad advice.
If you do go for gtk/gtkmm, learn version 3 not 2. I have not done this yet myself, but while they can (apparently) co-exist on the same system, API 3 is not backward compatible with 2 (looks extremely similar tho, at a glance). 3 is the future. So if you write your app in 2, a few years from now once most stuff is ported over and all the distos ship with gtk 3, you are going to have to re-write it, or install gtk 2 just to run one application. Obviously, when you go looking for a tutorial, don't use them unless the explicitly say version 3 [looks like there aren't many on google, ouch]!
http://developer.gnome.org/gtkmm-tutorial/3.3/ <-- hopefully that should do it
Beyond that, I'd recommend wxWidgets over qt. It's a C++ base, cross-platform, and makes use of gtk on linux. Qt apps I've seen look pretty ugly on gtk systems, and most linux systems are gtk based. I'm lazy and avoid installing qt unless I absolutely have to (the new laptop is 3-4 months old and still no need for qt).
my company has been kicking itself for the last 4 years because of a mistake like this (not saying that yours is a mistake, but ours was). the person who wrote the wrapper classes did it in one mountain-dew-fueled weekend, and it didn't work properly, and it created lots of problems for us, going forward. if we had done a little more research, instead of simply going with the first cross platform gui toolkit we found, we would have been in a much better spot.Quote:
Originally Posted by MK27
I can't speak to ugly appearance on gtk-based systems (gnome), because we're basically an all-KDE shop. I can; however, say that Qt is a very good toolkit for C++. I've only recently started using it, and after using wxWidgets, I find that I prefer Qt. it has excellent support from nokia, and there is a great number of high quality development tools, both proprietary and open source, available for it. I found that the same tends not to be true of wxWidgets. because wxWidgets is a fully open-source project, the free tools for it are generally useless (to me), and the commercial ones come at an unacceptable price.Quote:
Beyond that, I'd recommend wxWidgets over qt. It's a C++ base, cross-platform, and makes use of gtk on linux. Qt apps I've seen look pretty ugly on gtk systems, and most linux systems are gtk based. I'm lazy and avoid installing qt unless I absolutely have to (the new laptop is 3-4 months old and still no need for qt).
Is it an acceptable practice to write "wrapper" functions for these GTK functions? Some of them seem pretty long like "gtk_container_set_border_width()" or should I keep typing out these long function names?
What you could do with some stuff like that is use macros:Quote:
Originally Posted by Syscal
But don't over do it; ie, don't start out doing that for every function, don't do it at all until you notice what functions are good candidates. Those "long names" are communicative, and follow a sort of namespace pattern (eg, consider Gtk::Container::set_border_width) -- this is a lot better than a large API with functions called set_bw(), etc.Code:#define NORMAL_PAD 5
#define SET_BW(w) gtk_container_set_border_width(GTK_CONTAINER(w), NORMAL_PAD)
[...]
GtkWidget *frame = gtk_frame_new();
SET_BW(frame);
So wait until you are sure this is going to be a macro that actually gets used more than once or twice. Don't assume you will -- because, eg, I don't think _set_border_width should get called that much. If you are, you are probably not making enough use of the box/frame padding inner padding. IMO, more repetitive than the long names are some of the long argument lists. gtk_box_pack_start would probably make a good macro, because most of the time you will use the same last three args:
In general don't write wrapper functions just to shorten a name. That is sort of a bad, obfuscatory habit. You are better off using a tool with some form of autocompletion. Eg, with vim, look at :help E535. You add a line like this to vimrc:Code:#define PACK_ST(box, widget) gtk_box_pack_start(GTK_BOX(box), widget, FALSE, FALSE, NORMAL_PAD)
And then if you type "gtk_c" and hit ctrl-p, you'll get a scrollable pop-up window of candidates (searched from . = current file, b = files in other tabs, i = #included files; there are more options in the help, eg, you can use k for a dictionary file you write and "set dictionary="). There are other forms of completion for vim, but that is the simplest one; most IDE's have some similar feature which is automatic (meaning, I guess you aren't using one of those...). And if you're using neither vim nor an IDE, what the heck are you using?Code:set complete=.,b,i
If you are using vim, btw, there is a set of syntax highlight files for gtk/glib/xlib:
gtk-vim-syntax - Syntax highlighting for GLib, Gtk+, Xlib, Gimp, Gnome, and more. : vim online
Which is pretty handy, because you'll notice if you mistype one of those long function names (when spelled correctly, they are highlighted). Does not count toward completion, tho.
This solution may not be in your interests, however, I use Java for GUI programming because SWING is really good at being a GUI, and I use Netbeans to create/design/produce the GUIs, which makes it awesomely easy., and it looks good.Quote:
Originally Posted by Syscal
You can get started with netbeans here:
Lesson: Learning Swing with the NetBeans IDE (The Java™ Tutorials > Creating a GUI With JFC/Swing)
What I've identified with C++/C GUIs is that it's not very easy to create a simple GUI, IMO. Plus, Java SWING has good documentation.
with Qt, it's actually VERY easy to create a simple gui program, not to mention, C++ is almost always compiled to native code, which means it's many, many times faster than java will ever be in an equivalent environment.
But gets exponentially difficult to create a complicated one.Quote:
Originally Posted by Elkvis
Not that I'm advocating java or something... but even Qt is trying to move away from C++ and use QML for creating eh GUI.
that has not been my experience. it's likely that you and I have different standards for what makes a difficult task.Quote:
Originally Posted by manasij7479
this is true, and I'm all for using QML for designing the interface, and using C++ for the backend "horsepower." I see it as being a very similar concept to what WPF is to .Net. what QML does better, in my opinion, is that the designer code is much more similar to the back end code. javascript has a whole lot more in common with C++ than XML does with C# or VB.Quote:
Originally Posted by manasij7479
I consider everything that takes more time to implement (subtracting troubleshooting) than to properly plan, unnecessarily complicated.Quote:
Originally Posted by Elkvis
that's not necessarily a good indicator though. often times, especially if there's complex mathematical functions, particulary calculus, it's easier to define the formula on paper than in code. difficulty of implementation is not the same thing as complexity, and is certainly not proportional to time required. I've had many situations where I had a task that I thought was extremely difficult, but took only a couple of hours to finish coding, and other times where something was quite easy, but took a long time. another forum member (can't remember who) once put it this way: rebuilding an automatic transmission in a car is difficult, but can be done by an experienced technician in a few hours, whereas digging a mile-long ditch is relatively easy, but would take weeks for a single person with a shovel.Quote:
Originally Posted by manasij7479