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."
Does gimp still use GTK+ of some version or some other for its toolkit?
One interesting consideration when determining what toolkit to go with is that the GUI toolkit for Nokia's new internet tablet is GTK+.
Save your wrists today - switch to Dvorak
GTK+ is a graphical user interface (GUI) tool kit.
Why does yahoo do this
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
What the hell is wrong with printf?
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())};
A comment from the article: "That was almost 10 years ago." Nothing against it, but GTK+ is very old news. As a reminder, this is Slashdot, "News for Nerds. Stuff that matters", not Digg, "News for Newbies. Stuff that matters if you're a stoned teenager." Besides, if you really want a portable GUI toolkit, it's called a web browser. Time to get AJAXing, happy smurf.
I don't want to start a flamewar "GTK+ versus ..." either but IMO IBM would be well adviced to look into wyoGuide (http://wyoguide.sf.net/) especially if they target Windows users. At least wyoGuide also has development guidelines, can be used as a simple tutorial and the provided sample code is not only a "Hello world" but a fully featured application usable as a starting code base for others projects.
So if you plan to start a new project either on Linux, Windows, MacOSX or whatever, first have a look into wyoGuide and mkae up your own mind.
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
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
If I was looking x-platform I would be using wxWidgets and not GTK+.
As someone who has worked heavily with user interface kits and technology since the mid eighties, it is shocking and depressing to see the sorry state of Linux, and to a somewhat lesser extent, Windows application/desktop API/Runtimes like GTK+.
I really hope Apple is quietly working on getting the OS X application runtime working on both Linux and Windows. To able to build one fat binary on either Linux or Windows that runs on both Windows and Linux would turn the computing world on its head.
Both Microsoft's and the open source desktops/UI toolkits like GTK+ are absolute garbage - and jarringly painful to use if you have spent any time with OS X as either a user or developer.
And don't start spewing bullshit about it only being due to 'pretty skins'...
After the Intel Macs crash and burn, they will, Apple should have something ready to go and ready for anyone. Free complete set of developer tools and Apple runtime for both Linux and Windows. One click multi-platform support right in the Apple devtools from the same code base. And throw in a complete open source version of Safari that can be built and run right out of the box.
Are there any cross platform (linux, mac, windows) GUI RAD tools ala Builder, yet?
Yes -- wxDesigner is a very nice RAD for use with the wxWidgets GUI-building environment. wxWidgets is a cross-platform GUI framework which uses native widgets. On Linux, it uses GTK+. On Windows, it uses Windows widgets. On Mac, it uses Mac widgets. There are other somewhat-supported platforms. This approach contrasts with that of the Qt framework -- another cross-platform builder (which is excellent), which implements all its own widgets on each platform. Also unlike Qt, wxWidgets is not bound by the GPL -- you're pretty much free to do as you like with it (i.e. incorporating it into commercial apps, without the requirement that you release your source code, or pay any licensing fee). wxDesigner is a very nice GUI RAD builder for wxWidgets. It's not free, but it's cheap. You definitely get your money's worth.
Also it would be one less function that has to be written and maintained across the thousands of projects that use GTK.
for as long as MS/windows holds over 95% of the desktop market there is absolutelly no poit in using gtk. Gtk+ performs pretty bad on windows and yes it is a huge pain to include an 8mb lib just so you can run a small program. That said gaim i great and I use it all the time but programming in c with custom classes over c++ ... you have to be joking. Yes I know there are c++ wrapper but the programing lang. is the least of the problems that gtk+ has. Apparently the gui libs are developed by the same natzi who are leading the gnome project to it's inevitable doom. You cannot contantly mess with the UI and change things arroud just because someone though that it would be better. First of all OSS projects do not have enough money in order to actully condict a study on what the user thinks is best and 2nd if the gnome and gtk+ teams don't realize that software is written for the end user and NOT for the developer, both of these projects would stand no chance against any competition. For crying out loud this is one of the first principles in any OS textbook and those people are supposed to be way above a textbook level.
SO should you use gtk+ I really don't think so. After all there are qt and wxwidgets and they both do a better job. Oh and I cannot stress enough how important documentation is. But I guess some people don't think so ... sad ...
> GTK+ is a graphical user interface (GUI) tool kit.
And all this time I thought everyone was talking about a game called "Grand Theft Potassium Ion".
Sheesh, evil *and* a jerk. -- Jade
These days any serious developer doesn't use plain GTK+ anymore. If you want to get productive on Linux you either use gtkmm (http://www.gtkmm.org/) or wxWidgets (http://www.wxwidgets.org/), both based on GTK+. If you also develop for Windows you're better off with wxWidgets.
2 263&cid=14343909
see also http://developers.slashdot.org/comments.pl?sid=17
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
GTK may not be a single line of code, but at least it was a single cut-and-paste from the standard docs. (I did find Delphi v2.0 was in principle very easy to use, but in practise it's bugs tended to bite).
That only works on ANSI terms.
What the hell is wrong with a piece of pressed rice paper and lead shavings?
True, wxDesigner is an alternative on Linux I haven't thought of. Thanks :-)
2 263&cid=14343999
BTW see http://developers.slashdot.org/comments.pl?sid=17
See http://wyoguide.sf.net/papers/Cross-platform.html
I agree with many of your objections but GTK+ is still useful for all the underlying technologies. As I said here (http://developers.slashdot.org/comments.pl?sid=17 2263&cid=14343999) serious developers don't use plain GTK+ but without it, these wrappers wouldn't be possible. There wouldn't be Pango or ATK etc. if GTK+ wouldn't exists.
7 2263&cid=14343909) but it needs some time until all the enthusiast and fans recognize its value. So instead of just complaining help improve it so we all have something better in the future.
About your UI rants there is a solution I explained here (http://developers.slashdot.org/comments.pl?sid=1
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
No, the current stable win32 GTK+ runtime is 3.5 MB. Here's the download page.
The article lost me when it degenerated into text message territory.
When you're creating software for all to use, keep three keywords in mind: internationalization, localization, and accessibility (commonly abbreviated i18n, l10n, and a11y, respectively).
I just want to mentioned that there's a Cocoa port in wxWidgets for the Mac albeit I don't know its current state. It probably isn't much work to do the same for Linux if Apple really releases it's runtime. That means any wxWidgets application which currently can be build either with GTK or Motif on Linux will build on Cocoa as soon as it's available. Nice isn't it?
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
Hey u all forgot wxWindow. That's strange. I think it is a strong competitor of GTK+ and Qt. Isn't it
Why not wxWidgets? It's more flexible if you ask me. It simply wraps the native GUI stuff, or an other toolkit like GTK+.
I don't have any numbers, but I think the performance would be better and the distribution size shouldn't suffer much (as with Qt or GTK+).
I'm always game to discuss the state of the art in cross-platform GUIs, as it's always changing and usually for the better... but this is not an article. My first grade homework was twice as deep. This article reeks of GTK+ advocacy for the sake of it... "why GTK?" and no mention of the alternatives? It doesn't say more than gtk.org's main page, for heaven's sake. It's more like "why should you read my next article"!
Maybe if the following parts say something interesting, it would be worthy of making it to the developers section, if that.
accessibility - GTK is not accessible on Windows, X11 accessibility still fishy (just exposing 50 actions via screen-reader is not enough to make a GUI usable, a document/action framework and workflow manager is required).
portability - No native Mac OS X port, Win32 port still lacking.
extendability - Wow, ever tried subclassing and extending a widget? Last time, I spent 20 minutes just copy/pasting strange macro definitions and debugging my crashes.
IBM seems to skip over one of the biggest reasons to NOT use GTK+ - it just doesn't look right on Windows. I'm not sure who said it but a commentator suggested a while ago that one of the reasons open-source programs weren't overtaking closed source was due to a lack of polish (which does of course cover more than just appearance); he used GAIM vs. MSN Messenger as an example. The jarring difference between controls in GTK+ or Java or even Mozilla to some extent vs Win32 is important when you're creating an application for normal end users. In my opinion, that difference can look unprofessional. I would figure that the issue of appearance could be mitigated but it hasn't yet so I don't know for sure.
A question for someone who knows more about GUI toolkits: What are the issues involved in matching the appearance between toolkit controls and the native controls?
Indeed, GTK+ for instance. :)
Why you shouldn't use the Library GPL for your next library
http://www.gnu.org/licenses/why-not-lgpl.html
No one distributes software on floppies any more. 6-8MB added to your installer isn't a BIG deal. It translates into another 30sec worth of download. If its a burden on anyone, it's a burden on your webservers.
I think you meant to say it IS a big deal, since it translates to 30 MINUTES of extra download time on a dial-up line, which unfortunately most users are still stuck with. Even broadband lines aren't all 1.5Mb/s.
Why would anyone use third-rate GUI toolkits like GTK or QT when MS is giving away the best GUI toolkit ever (Visual Studio) for free?
http://msdn.microsoft.com/vstudio/express/
The latest GIMPs all are 2.8 exclusively and if you try to run on 2.6 you get all sorts of problems.
Even the new GAIM 2 beta is 2.6 and if you try to use 2.8 you get all kinds of problems.
I REALLY HATE WHEN DEVELOPERS CREATE DLL HELL.
> It has no support whatsoever for colors or blinking text!
<shamelessplug>
Want colors and blinking text in your output? Use the Useful Terminal I/O Library! You get all that and the other things you have been missing since you traded DOS and conio.h for Linux.
</shamelessplug>
the free VC++ distribution is by far not the full VC++ distribution. It's enough for compiling but not for debugging.
2 263&cid=14343999
Besides MFC is not cross-platform and even on Windows you are IMO better off with wxWidgets.
see also http://developers.slashdot.org/comments.pl?sid=17
O. Wyss
See http://wyoguide.sf.net/papers/Cross-platform.html
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?
I was looking at crusty old Xt/Motif (in combination with ViewKit) the other day and it seems to me that most 'modern' toolkits basically do the same thing that Motif did 900 years ago. Other than AA fonts and widget themes, (stuff that could have been implemented in Motif way back when, and now actually has been for the most part in its Open Source versions) I'm not convinced that GUI programming has moved on a lot since Motif was dropped on GIMP 0.54.
In fact it seems to me that the only stand-out toolkit is Tk, with its excellent Text and Canvas widgets and dead-simple syntax.
- It took western civilisation 2000 years to ensure popular literacy, and now we work with icon driven GUI's. Go figure.
Basically its archaic. GUI development is one of the few areas where object oriented design makes a big difference to the programmability of the system. This has been known for the better part of 15 years. All those little buttons/menus/combo boxes/etc with the hundreds of properties to control behavior. The need to override behavior, the need to hook events. The list goes on. Sure you can make it work in a non object oriented environment, but I could be writing everything in assembly too. I don't choose to write everything in assembly, and I'm not going to use a GUI tool kit that isn't object oriented. You can argue that GTK is object oriented C but that completely misses the point since object oriented languages assist in a particular design methodology. Oh, and i'm aware of the C++ wrappers for GTK+ which are just that wrappers, plus they are ugly and poorly maintained. I'm not going to spend all my time debugging the wrapper when I could be getting useful work done.
I haven't read the article, since GTK+ is already my preferred GUI toolkit. And this in spite of the fact that I run KDE as my primary desktop! I run both Gnome and KDE, and my choice of KDE over Gnome is based more on organization and flexibility than it is on the underlying GUI toolkit.
As background: My wrote my first GUI programs back in the days of Window 3.1, and while most of my work is on data-crunching engines, I do write quite a few GUI applications. I need to rapidly generate an interface, back it with code, and have it presentable on Windows and Linux.
As a programmer, I don't like QT. It feels klunky, bloated; nor do I find QT Designer all that friendly. Beyond matters of taste and comfort, TrollTech requires a commercial license for certain tools (e.g., a MathML widget) that I can obtain under GPL for GTK+.
I'm rather fond of Glade. Most of my GTK+ GUI programs are in C, some in C++; I define an interface in Glade, fill in the appropriate functions, and I'm ready to rock and roll.
GTK+ 2.8 brought with it Cairo, a very nice drawing toolkit. I just put together a little interactive graphics application, just to better familiarize myself with Cairo, and the result is quite nice.
In the near future, I'll be writing some very extensive OpenGL applications, and I'll likely wrap these in a GTK+ GUI. If something better comes along, I'll try it -- but for now, GTK+ provides what I need. Your mileage may vary.
All about me
I happen to use GTK+ to run both The Gimp and Gaim on XP, so the overhead isn't that big a deal. I even sat there and downloaded Gaim with GTK+ over 33.6kbps dialup. The whole point is that the Windows ports of these toolkits give cross-platform compatability; win32 defines cross-platform as "other versions of Windows."*
.NET framework which Microsoft touts as the alternative to Java (and in some ways it is), but that is 23.1 MB for v1.1 and 22.4 MB for v2.0, and this doesn't even include the Windows Installer you might have to upgrade first. How about that overhead?
.NET has some amount of compatability with other platforms too thanks to Mono, but why not opt for a truly cross-platform toolkit?
For instance, you have the option of downloading the
*Microsoft's
I like GTK and use it both with C and with python (pygtk).
I also used other toolkits, like tk, wxwindows, QT, java swing.
I like the native C API + language bindings for every taste, so I can
program GTK at the abstraction level I want. I like the pango markup. Also interface prototyping is fast enough (though not as fast as with tk) [...]
Among the few things I do _not_ like are the new GtkTreeView, which is very general and powerful, but it makes doing very simple things too complicated, and the terrible new gtkFileChooserDialog.
However, I can still avoid those using some deprecated widgets (for now).
so true, so true
I'm surprised that nobody seems to have much to say about how GTK+ compares with other toolkits other than Qt. How does GTK+ compare to Tk and and WxWidgets? I'm curious in part because, after a long period of doing no graphics programming other than some tweaks to old programs, I went from using raw Xlib to Tk. I've studied GTK+ a little but haven't really used it. My impression is that GTK+ may have the advantage when you need very fine control, but that otherwise Tk is much faster to write and requires less code because it takes care of many of the details for you and chooses good defaults. The only comparisons of this larger set that I've seen are rather dated.
i've programmed a number of these toolkits over the years, quick reviews..
;-)
gtk - really nice, but low lots of low level OO encapsulation ( ala treewidgets, omg.), which means any signifigant application is going to be developing its own abstractions on top of the base apis. using it in C is painful imho, but it has really nice language bindings in just about every language (python,csharp,ruby,java,etc) where its OO nature can shine through. The biggest issue with gtk is the lack of portablity imho, as regards the lack of native widgets on windows or the lack of a solid mac port, on win32, you'll need to distribute with WIMP themes to make it resemble native, but thats not always a viable solution. on OSx you have to run it as an X11 app ( read shitty mac end user experience), although some preliminary work by imendio to port it native to OSx has been done, its still at least a year away from being solid, and it still doesn't look or feel native. as far as gui design tools go glade is pretty weak, it works, but its useability and functionality are behind the times, tools like stetic and gazpacho are alternatives i'd recommend. gtk's secret weapon are in all its cross-platform extensions accessible (mozembed, spell, sourceview, canvas).
tk - its dead, forget about it, its really low level, and looks like ass everywhere.
qt - imho, this is the best solution for cross platform applications. the toolkit api is very well thought out and useable, and includes mondo functionality (db access, xml parsing, network, etc), and looks good on win32 and osx. the accompanying toolset in qtdesigner/linguist are strong. qt 4.1, makes printing a snap with pdf output. it scales very well to larger programs and the gpl version of QT is now available for all platforms ( embedded, linux, osx, win32).
wxwidgets - for good looking cross platform apps, this is a strong contendor, without the dual license (GPL or Commercial) nature of Qt, however its API designs are imho much weaker, and can turn larger apps into a mess unless you've got strong experience with building GUI apps. ie. the cost to maintain and extend wx apps are higher imho then qt or gtk. the non commericial gui builders for wx are all pretty weak imho, and most wx apps i've seen tend to just lay things out programatically. that said if you want to build cross platform, non gpl compatible apps, then its worth a strong consideration. the chandler project, over the last year, has been doing sponsorship of getting wx's osx support up to production standards, and it works well now.
incidentally all of the above have first class bindings to python
most people you are concerned with have broadband now
Are you sure that this is true? True, 63.8% is more than half, but you're still cutting 36.2% out of your market. In fact, if your application involves communication, the lack of network effect means that you're limiting your market even further, as users who have broadband need to communicate with users who do not have broadband. For a word processor, this means a compatible file format. For instant messaging, this means a compatible wire protocol. As network effect tends to apply quadratically, I'd estimate that a broadband-only application is only 100% * .638^2 = 40.7% as useful as an application that is practical over both broadband and dial-up.
Microsoft recommends using C# for gui apps now.
Developers of applications distributed to the public over the Internet typically won't use a language that depends on the .NET Framework until the .NET Framework takes significantly less than an hour to download over a dial-up Internet connection. (I am permitted under trade secret law to state this benchmark result only because I have not installed the .NET Framework and thus have not accepted its EULA.) The GTK+ package (GTK+, GDK, Glib, Pango, etc.) currently has a much smaller download size footprint than the .NET Framework.
Another variant for Tcl/Tk with Tclkit:
http://www.equi4.com/tclkit
Create a starkit with:
sdx wrap myapp
Run it on any of the supported platforms for Tclkit (30 or so http://www.equi4.com/pub/tk/downloads.html) with:
tclkit myapp.kit
Or do a transaction safe differential update of the app from the internet server with:
sdx update myapp.kit
And yes, you can build fat binaries which can include compiled C libraries for use on Mac/Linux/Windows. If they use the Tcl Stubs mechanism you do not even need the same Tcl version for the runtime you used for the libraries, no recompile of library packages for minor version changes. (thats currently 7 years of no recompiles for most Tcl extensions).
I'm using XDS Modula 2 and would like to be able to use GTK+ easily. Thanks
GTK widgets are ugly...
Gaim far more adwanced than Messenger and look crappy than messenger...
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
The Qt license requires that if you start the development with the GPL version of the library, that you ONLY develop it with the GPL version, and that if you release the code, that it be released under a GPL license. You can't decide after starting development that you might want to sell it, and then buy a commercial license. If you start with a GPL version, you must then stay with that version. This isn't a requirement imposed by the GPL, it's imposed by Trolltech. (And I suppose that technically it's a condition of the license of their commercial library rather than of their GPL library.)
So don't use Qt as an example here. They have added their own wierdnesses.
I think we've pushed this "anyone can grow up to be president" thing too far.
Everything it touches is also made open by default.
Why, hello, Mr Ballmer! Welcome to Slashdot.
You are right of course, if by "touching", you mean intentionally and laboriously incorporated into your own source code files. The disingenuous implication is that developers will wake up one morning and find a surprise in their code. "Oh my! How did THAT get in there!"
GPL code is never made open by default, but by choice.
How can someone dare to call that poor advertising piece an "article"? There is no useful information in the text that can not be obtained at GTK.org or after five minutes of web searching.
And they rated it "intermediate". Spare me the "low" ones...
--- Signature? You must be kidding!
- A steering wheel for ease of navigation!
- Four wheels providing good stability, even while turning!
- Car seats, so you don't fall though the floor!
- There is even a vibrant community of fuel stations than can refuel your Ferrari!!!
Yet another slashdot article referring to a product without explaining the purpose of said product.
GTK+ is a toolkit for GIMP.
GIMP is an open sourced graphics manipulation package (think Photoshop but free as in speech and beer).
I am government man, come from the government. The government has sent me. -- G.I.R.
...none of them seem to offer an easy, consistent, and cross-platform solution to reports printing. I think this area of GUI toolkits is a bit lacking. There are third-party solutions like GNOME-Print, JasperReports (Java), ReportLab (Python), one other toolkit which QT-based, plus two other wxWidgets-specific solutions and yes, there's the expensive and Windows-only Crystal Reports. But they offer either a steep learning curve to use (Jasper) or tend to be a lot more fundamental in the features offered.
It's pretty easy to create a nice GUI program with all of these toolkits. But when it comes to implementing report generation and printing, it's a total nightmare. I know GUI toolkits should stick to GUI-specific objects and functions, but printing (and report generation) should be taken into consideration too.
So far, the only workable solution I have come across is using ReportLab as the report generation backend, with either PyGTK+, PyQT, or wxPython at the GUI frontend.
With GTK+ - like most modern widget toolkit - you can replace the widgets if you don't like them. There are literaly hundreds of different so called "Themes".
And you don't have to pay for them - unlike Windows Widgets kits which usually cost $$ and the development kit isn't free either.
Martin