Why Use GTK+?
An anonymous reader writes "IBM DeveloperWorks is running an interesting student article that introduces users to the world of GTK+. It explains what GTK+ is, why you should consider using it, and the benefits it provides. Together with the rest of the series, this installment provides enough introductory information that, if you decide to use GTK+ in your own projects, you'll know where to look for further materials."
GTK is fine, but as long as it takes a few megabytes to download, only Linux applications will use it. Take a look at The GIMP for example: it is ok to download GTK because it is a big program, but who would develop a small application ( 1MB) if it depends on 6-8 MB for GTK ? On the other hand, Linux users rejoice, as they have good distributions with good dependency resolvers.
It's interesting that they advocate using it vs Win32 in their examples. You really don't have a choice of the overhead for a Win32 system. You do have a choice of ignoring the overhead for GTK+. This overhead is why the POSIX and OS/2 implementations in Windows NT and later were never particularly useful. They used additional overhead (and they translated into Win32 function calls anyways!). GTK+ doesn't have this second problem (as far as I know) but it will still require additional overhead. If that's not a problem, then use it to your hearts content. Otherwise, Win32 seems to be the answer.
a better question might be.. "why use a gui"
For in house stuff I've been on a command line, or straight GLUT kick if I need to display graphics or data in a quick and dirty fashion. Obviously that's not going to work for everything, but you'd be suprised how far it goes.
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
..don't panic
to start a Gtk+ vs. Qt Flamewar here. Gtk+ is easier to install & handle (moc can be a real PITA sometimes), but until Gtk+ gets a really GOOD documentation and API, I'll stick with Qt. No, neither google nor devhelp are adequate. I want a reference as well done as the Qt one. Does such a thing exist?
This sig does not contain any SCO code.
No, I'm not kidding: a dialog box with three buttons should be:
D(H:50,W:200){M:"Quit without saving?",B1:"Save"(do_save()),B2:"Don't Save"(no_op&exit()),B3:"Cancel"(drop_quit())};
It doesn't seem to give any information about GTK+ itself, even what the difference between GTK+ and plain GTK is (I am guessing that GTK+ is simply the C++ bindings for GTK).
:).
Basically, I think this introduction is too simplified and high level. I imagine that anyone who ever even considered writing their own GUI code directly above X or raw devices would immediately see the advantage of using a toolkit, and the only questions remaining would be "which one?" and "why GTK+ rather than e.g. GTK or QT?". Possibly it is aimed purely at Windows developers. I remember that several years ago Windows GUI code was a beast to write, and I was amazed at how simple GTK was. If Windows is still that bad, I guess just listing GTK+'s features would be enough to make win32 developer's mouths water, but I'd still prefer the article if it made it clear that win32 is what it is comparing GTK+ to, and did a proper compare and contrast. That way I'd actually have a summary of what Microsoft has been up to in the last decade
Hey u all forgot wxWindow. That's strange. I think it is a strong competitor of GTK+ and Qt. Isn't it
Leaves me wondering if you could successfully play linking games to keep your software non-GPLed when you distribute it. Construct a general database interface API (or find a compatibly licensed one - not GPL...), write your app to use that API, and distribute it. Also distribute a module that is GPLed that talks to the mysql database. The user links the module with the app, and the GPL asserts itself on this new derivative work; the end user cannot distribute this work without distributing full source; but the end user is restricted from distributing it anyways, if it's a commercial product. If not, then they can distribute it unlinked anyhow. The interface is not a work based on the GPLed work; the GPLed work wasn't involved in it's construction, it's just an database interface tailored to the needs of your app. Your app is only based on the interface; the interface isn't GPLed, no problem. The code that translates your interface to the GPLed work is based on the GPLed work; it must be under the GPL if you are releasing it. That does not, however, do anything to the licensing of the interface or your app. When linked, they are a derivative work, and therefore cannot be copied, distributed, modified and all that except under the GPL; nobody cares. This happens well after you'd want to do any of those with it - it doesn't keep you from using it. This is actually the scheme that the madwifi project uses to get their FCC-mandated binary module into the kernel; it doesn't particularly interact with the kernel, it interacts with their code, based on an interface which is licensed such that the GPL doesn't apply.
One issue that I like to look at when I'm thinking about GUI toolkits is the question of what programming languages does it support.
I often need to rapidly prototype a graphical UI, and one that's not just a standard set of static attributes. I find that for these cases the graphical layout tools fall down pretty quickly, and I'm back to writing code to make the UI.
Now, if I'm going to be writing code for GUI prototypes, I want code that I can write, test, and show off fast. I don't want to start a language war, but to me that says "not C++."
So a big question for me is "what other languages does your toolkit support easily?" Is there a good perl interface? python? scheme? What can I use to lash it together quickly?
For this kind of thing, sadly enough, it seems like the venerable Tcl + Tk combination is still hard to beat.
And when you need an alternative language APIs, we need documentation that is native to those languages. All too many of these toolkits provide some rudimentary alternative UI, but it's just an export of the C++ API, and the programmer is expected to read the C++ documentation, and mentally convert that to the appropriate perl, python or what-have-you alternative.
So what are the easy cross-platform, scripting UI alternatives? Tcl + Tk, python + wxWidgets, and what else? Any way to get at those Swing libraries without heavy lifting with Java?
No, I can ship a closed-source software product designed to use the Microsoft or Oracle ODBC drivers without having to either distribute the ODBC drivers or pay a nickle to Oracle or MS. Sure, the enduser is paying them, but that's likely why they want to use my software in the first place.
However, if I understand the MySQL/FSF position correctly, I can't do the same thing with MySQL drivers because my application is considered to be a "derived work" of MySQL. Neither Oracle or MS claim any rights over my software program, but MySQL does. This may or may not be legally correct, but it is certainly a "gotcha" for folks used to commercial library licences.
Business. Numbers. Money. People. Computer World.
Badly written Tk looks horribly Motif like and dated. Good Tk (with theming thanks to the tile project http://tktable.sourceforge.net/tile/ ) can look quite nice an modern, take a look at the screenshots. Its just the little extra polish thats often missing in Tk apps, because the authors are adding features instead of polishing the GUI.