Slashdot Mirror
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."
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())};
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?