Review:Developing Linux Applications with GTK+ and GDK 85
| Developing Linux Applications with GTK+ and GDK | |
| author | Eric Harlow |
| pages | |
| publisher | New Riders |
| rating | 6 |
| reviewer | A.M. Kuchling |
| ISBN | |
| summary | A reasonably good first book on GTK+, though it's not likely to become the definitive one unless the second edition makes some minor improvements. |
|
The GTK+ GUI toolkit was developed for the GIMP, and was subsequently adopted by both the current Mozilla codebase and the GNOME project. I believe this is the first formally published documentation for the GTK+ toolkit. (It is not a generic guide to application development under Linux, even though the spine of the book reads only "Developing Linux Applications".)
The book provides good coverage of the fundamentals that you need to know: the basic data structures provided by GLIB; the overviews of buttons, menus, dialog boxes, and all the other major widgets; and four sample applications -- a calculator, text editor, Minesweeper game, molecule viewer, and a simple Defender game. Harlow's development of each topic is understandable and helpful, making the book a vast improvement over struggling through the toolkit's source code, and well worth purchasing if you want to program with GTK+.
My one major problem with the book is, surprisingly, wishing there were more screenshots in it. The opposite is true of most computer books, because a screenshot and a paragraph of text can be made to fill a whole page, and helps immensely in padding out a book to make it look bulky and comprehensive. This book goes to the opposite extreme; there's no screenshot of the calculator application at all, and only one or two screenshots for each of the other sample programs.
Another flaw is that the book seems to contain every single line of code for the sample applications. As a general rule, in any given C program, 90% of the code is uninteresting; only 10% contains the heart of the program, and the rest is all scaffolding. I would have preferred to see a dissection of the central portions of each program in pseudocode and small chunks of C code, relying on the Web to get the complete distribution, instead of having to flip past page after monospaced page of program listings. So What's In It For Me?-->
This book rates 6 out of 10 points, because it covers GTK+ quite well, and provides you with the basic information you'll need to hack with it. It would get 7 out of 10 points if there were fewer pages of code and more illustrative screenshots.
Purchase this book over at Computer Literacy.
Table of Contents
- Introduction to GTK+
- GLIB
- Developing GUI Applications
- Basic Widgets
- Menus, Toolbars, and Tooltips
- More Widgets: Frames, Text, Dialog Boxes, File Selection Dialog Box, Progress Bar
- Writing a Calculator Application
- Developing a Simple Word Processor
- Minesweeper
- Graphics Drawing Kit
- Styles, Colors, Fonts, Cursors, and Referencing
- Molecule Viewer Using GDK
- Sprites and Animation
- Trees, Clists, and Tabs
- Creating Your Own Widgets
A farily accurate review (Score:1)
I bought the book and I'd agree with most of the points in the review. I used this book to learn GTK programming and although not perfect certainly taught me what I needed to know.
--
Richard Stallman
Free Lecture [ukuug.org] at the Commonwealth Institute, London W8
Tuesday 23rd March, 1999 at 7.00 p.m. - 9.00 p.m
Sponsored by UKUUG [ukuug.org]
BTW I'm not RMS (Score:1)
While I have your attention, is there any
chance for a Beetles reunion? And congrats
on your RRHoF induction last week.
Agreed (Score:1)
FYI I'm the original poster. I get very nervous on this forum speaking out against the "common wisdom", so anonymous I remain.
The problem is that the linux "market" can only bear one or two widget sets. Right now, the choices are GTK, QT and Motif/lesstif (with Motif quickly fading into obscurity). The QT license seems to bother a lot of people, and QT has a few design problems of its own (for one thing, it doesn't use "standard" C++, you have to run your code through a special pre-processor to implement the signals & slots). It just gets very disheartening to see these particular widget sets "winning". It's the 1980s all over again.
Sure, one could choose to use another of the 10-15 widget sets out there... and ghettoize yourself. The major distributions are certainly only going to include the glib/gdk/gtk+ shared libraries (and perhaps the qt-libs when those turn free.libre). That is, like it or not, going to result in a de facto "standard" where apps not using GTK or QT are going to be snubbed, ignored... and considered worthless. That is, I'm afraid, Human nature... and the nature of the linux community, doubly so.
And yes, I've thought about writing my own widget set for my applications. I've even thought about ditching gtk+ and writing one on top of gdk (it's a good wrapper over the raw Xlibs). But before I even started I could hear the screams. "WHY ARE YOU WRITING ANOTHER WIDGET SET!?!?". Why bother.
I'm also sick of hearing GTK proponents claim that gtk+ is object oriented. IT IS NOT. Do widgets automatically destruct when they come out of scope? Nope. Can I derive a new widget from an existing one and not have to worry about implementing inherited methods? Nope. Can I integrate widgets easily with the STL? Nope: I'm supposed to use glib. Can I overload operators so I can treat these "objects" just like native data types? Nope. The GTK-- wrapper, despite the heroic efforts of the GTK-- team, is not really ready for prime time. A few basic widgets aren't even implemented yet... and I'd argue that the apparent difficulty they are having with writing C++ wrappers at all merely proves my point.
GTK is just like motif: It allows the programmer to create and manipulate persistent data structures within a shared library. This is a good design paradigm to use when you are creating a widget library in C. But that does NOT make it object-oriented. Anyone claiming that gtk is object oriented is either trying to pull the wool over people's eyes, or does not understand what object oriented programming is.
What about writing style? (Score:2)
There are also a bunch of simple stupid mistakes such as using one function name in a paragraph and using a slightly different one in the code example. It wasn't hard to figure it out but I shouldn't have to do that, it should be correct.
Damaged by SunOS (Score:1)
Trust me, use the toolkit. (Score:1)
If it weren't for GTK I'd probably be programming Motif (well, OK, actually I'd be programming in QT, but that's besides the point). Motif is much like raw X Window System calls, except that Motif is MUCH MUCH WORSE! Motif is much like the stinky dead fish that your dog insists on digging up every time you try to throw it away. The world needs more Motif applications like I need a hole in my head. I can go on and on about this. Really, I can.
Moral of the story: Learn a toolkit. Believe me on this one. I've made dumber comments, but few have been more true. Just don't do Motif.
That one's called "Programming with Qt" (Score:1)
I was monkeying around with the FLTK a while ago and it seemed wonderful, too. PyGTK is my new favorite RAD language, though. Slap things together in Glade, use glade.py to Pythonize them, and bind your events to Python functions. Neat!
Trust me, use the toolkit. (Score:1)
X is a beautiful thing. The API is sometimes a little clumsy but they cover just about everything. I have on many, many occasions run into some difficulty that I realized X had already solved, in a way that I didn't expect but turned out to be quite clever.
They thought of everything when they designed X. Really.
If you're sophisticated, I'd recommend the O'Reilly books. They are so thorough it is unreal. Compare that to Windoze programming books which think that if they tell you how to program the most simple of applications, they have done their job. I don't know how many times I have wished for a book as good as the X series from O'Reilly for the Windoze platform.
But if you're new to graphics programming (and even if you're not) you may find the O'Reilly X books to be a little terse. It takes a few readings to really understand everything. But it's absolutely top-notch once you get it.
Kinda like Unix.
BTW, I agree about Motif. I think it was the worst thing to happen to Unix, ever. I think it did more to harm Unix as a platform than anything else that ever occurred during the 30+ years that Unix has been in existence.
This looks promising but... (Score:1)
But, the books are certainly up-to-date, because X hasn't changed hardly at all since the last revision of the books, in '90-something
Please don't bother slamming Motif (Score:1)
It's garbage. Plain and simple.
Trust me, use the toolkit. (Score:1)
And it's possible to do the things you mentioned with diligent programming. It may not be built into X, but it's *possible*.
If your WM gets swapped out you've got more to worry about than X
But he wanted to be like you. (Score:1)
Agreed (Score:1)
Gtk-- is basically undocumented at this point. At least they've hit 1.0 (I hope it's a _real_ 1.0, not a Gnome 1.0).
Motif/Lesstif is arguably worse than gtk, and I programmed a lot of Motif.
OpenLook was just plain goofy (IMHO).
Xaw is ugly (but I've never programmed with it, so perhaps it's great from a programming standpoint), Xaw3d looks okay, but again, never programmed Xaw so it might just suck.
Qt may be okay now with the new license, the whole signals/slots thing looks interesting.
wxWindows always rubbed me the wrong way, it just never seems to look right on the host platform.
Oh, well. Maybe I should quit complaining and go write my own so we can have yet-another-widget set. That's what I'll call it, YAWS.
The best gtk docs are all free (Score:1)
I hear O'Reilly is working on a gtk book. I'm sure it will be better, O'Reilly's stuff is usually quite good.
OSS documentation quality (Score:1)
Now for a lot of things I subscribe to the "Either write it yourself or stop whining philosophy," but when it comes to documentation of libraries, I feel the authors should document their own code. Anything is better than nothing.
Gtk rocks. (Score:1)
Clarification (Score:1)
Platform Dependant Book? (Score:1)
There is an example that uses
FUD fighting. C++ rules :) (Score:1)
This is why I call C++ bloated. Too many "features". When was the last time you used things like "mutable" or "explicit"?
Of course at the end it all comes down to how well versed the programmer is with C++ and how good of a designer he/she is. The problem is just that when working with others everyone else get affected by lack of proficiency with C++ features. This is a far greater problem working with C++ than C because of the "features" in C++. Even more so in a largely distributed project like most Free software projects are.
Platform Dependant Book? (Score:1)
Is "Linux" in the title just to be trendy, or is this book really that pathetically platform dependant? Last time I checked, gtk+ worked fine under Solaris and a slew of other Unixen.
Bah humbug.
Trust me, use the toolkit. (Score:1)
Regarding your Windows woes, why don't you just use the ported GDK and compile your GTK programs for Windows? Isn't that port in pretty good shape? Alternately, you could learn to program Qt, which is rock-solid on Windows. I'm sure it's much easier than the Microsoft Foundation Classes (though I've never touched them, I've listened to many, many other developers complaining about their Byzantine structure and their many obscure and obfuscated APIs). Hey, program in Qt and Windows users won't even notice the difference!
If you really want to be portable, you could use Mozilla's NSPR wrapper for all your threading instead of explicit Win32 and POSIX threads.
Oh, well, that's just my $.02. I hope you find it helpful.
Beer recipe: free! #Source
Cold pints: $2 #Product
This looks promising but... (Score:1)
The Wxwindows toolkit is designed to do just that. I don't endorse it (since it forces you to use icky C++), but you might like it.
Beer recipe: free! #Source
Cold pints: $2 #Product
GTK+ The awful truth (Score:1)
Therefore, I'm currently trying to decide between GTK+ and Qt. It's a difficult decision; both are popular and likely to be maintained for a while to come, both have fairly complete Python bindings, and both are pretty attractive. I'm trying to assess them both from a programmer's perspective, and will review the upcoming O'Reilly Qt book, unless someone else beats me to it.
GTK-- Book? (Score:1)
college knowing more about how to program C++
than C.
The methods of design are quite different.
I'll not argue about the merits of either, but
on a practical level it seems that projects
written in C++ will develop more rapidly due to
all the new talent available.
I know there are other factors involved but
doesn't the strength and rapid development of the
KDE project stem from it being in C++?
I'd be interested to know how the programmers
demographics compare, C against C++, Gnome against
KDE.
Gtk-- is good, and very important for Gnome for the reasons above. It could still do with some
better documentation though. I'm still trying to
get my head round the signalling stuff.
Hope the O' Reilley book covers gtk-- as well.
--
Stephen
OSS documentation quality (Score:2)
I hope that all the people who posted them have communicated them to the authors. In particular, told the authors about:
- typos
- broken cross refs
- unclear examples
OSS documentation (which is notoriously poor) ought to be able to benefit from the same review-rewrite-release strategy as the code.
So, don't just complain (fun though it is to let off steam). Send in corrections.
I notice in the latest GTK tutorial there is an open invitation for contributions. I also notice more than a dozen named contributors.
This is BTW the best way for people who are not ueber-hackers to contribute.
Platform Dependant Book? (Score:1)
I havn't read the book, I have skimed some of the chaptor drafts during writing. Nothing looks like it was written to only work on Linux, but there are no long discusions of how to get GTK+ for other platforms. There didn't seem to be any Linux specific syscalls or lib calls used, but it's networking code won't work without BSD-style sockets (which Linux and SysVR4 has, but R3 doesn't).
In other words it wasn't written for "all Unixes", but applys to most of them anyway. IMHO, a fine way to write a book that isn't about "Unix Portability" (and no, I don't use Linux, I use FreeBSD, and BSD/OS...and SunOS 4.0.3 holds a special place in my heart, not that I have used it since '92ish)
Damaged by SunOS (Score:1)
What was my choice pre-92ish? I think Linux existed then, but few had heard of it (I hadn't!). If I had I probbably would have run it. Besides I really liked it because of the OSes i had been payed to hack on at the time (pre-MacII MacOS, DOS, SunOS, Ultrix, AOS (IBM's BSD port, not AIX)) it seemed to be the best.
I don't. I'm not overly fond of SysV flavored Unix, which Solaris is, and Lunix's userland tends to slanted towards. I don't have anything against Linux, I just happen to like FreeBSD better. I may even change my mind someday. It's a personal choice. I don't think your a moron for using Linux. I do think your a moron for expresing yourself that way.
Besides if I hated GPL, large parts FreeBSD would be unusable (like the C and C++ compilers).
Agreed (Score:1)
--Karl Nelson
Gtk-- contributor
Trust me, use the toolkit. (Score:1)
Anti-aliased text? Window management that doesn't break down when your WM gets swapped out?
GTK themability is excellent (Score:1)
Congrats!
Some extra comments (Score:1)
Anyway, I have a few criticisms of the book. Firstly, he needs to get his acronyms sorted out; he lists two definitions of GIMP, one in the preface and one in chapter two. I don't have the book here, so I can't tell you what they are offhand.
Secondly, there is no CD/floppy of the sources. Admittedly, there is a URL for downloading the sources over the net, but having a CD/floppy would have been nice, especially if it had come with source of GTK/glib as well, just for completeness.
Other than this, it covers the basics of creating windows, buttons and other widgets pretty well. For those of you wanting to learn GTK/glib, this is the only book which covers this at the moment, and is probably a must buy unless you can use the gtk tutorials on the web.
As someone else said, GTK is available under Solaris and other platforms, so calling this a linux book is a misnomer. There is nothing (as far as I have seen) which makes this a linux-only book.
--
GTK-- Book? (Score:1)
Thanks for the comments (Score:2)
By the way, GTK+ is cross platform, but I don't have a Sun or other *nix to play with. I just work with Linux and want to see more Linux apps out there. I hope this gets some people started down that road.
Some extra comments (Score:1)
o "gtk-config -libs" instead of "gtk-config --libs"
o using the callback function destroy() without defining it
Granted, I was able to figure these out, but come on. These weren't code fragments, they were complete programs, couldn't somebody have taken the time to try compiling them before comitting to paper?
God preserve us from the half educated (Score:1)
What I really take issue with is the idea that operator overloading, constructors and reference counting are OO features. They're features of C++ and its half-arsed class libraries - mostly added to try to hack around the problems with the whole design of the language.
The things you really need to be OO are encapsulation, polymorphism and inheritance. The only thing GTK+ does not quite do properly is polymorphism (and interface inheritance). The rest is perfectly OO.
GTK+ The awful truth (Score:1)
GTK+ *is* OO. And, much to your dismay, it does have a class hierarchy. However, these are not representable is "standard" C, so macreos are used. If you use Objective-C or C++ bindings to the GTK+ libraries, you'll find them more "natural".
(NB, I've only *briefly* looked at the objective-C bindings, but the C++ bindings were quite nice).
The first chapters were downloadable (Score:1)
as i can remember this beta version i downloaded was also covered by
maybe it was on gnome.org, or gtk.org, i don't know....
This looks promising but... (Score:1)
Why you would choose to use Xlib for anything but window manager coding is beyond me, so I'll address the other possibility of your post-coding for multiple toolkits.
You pretty much have to do the same kind of things you do for making code portable across platforms. Preprocessor directives specifcy regions of code certain to one set of platforms. You autoconf to find out which regions are required by the host, and then build.
You can also make things much cleaner by putting on abstraction layers to windowing calls and then compiling the implementations to the abstractions separately for each function. Makes the code cleaner.
*sigh* The easiest thing would be to look at programs that have build targets of both QT and GTK. But those are few and far between, probably due to QT silly C++.
oh, back to yor question. Look for books on writing portable code. Best place to start.
This looks promising but... (Score:1)
Better yet, pick a language with good bindings (I like python but you're free to choose what you're comfortable with) and dabble a little with each widget set.
_Deirdre
OSS documentation quality (Score:1)
Erik
!Open Source(tm) (Score:1)
Erik
Why was this put at -2? (Score:1)
Erik
Another book idea (Score:2)
I checked out this book in the bookstore, and was off and running within an hour after having read the first few chapters. It's true that I ran into a bunch of snags because he didn't describe all the API calls, but it was good enough to get me excited and start me writing code.
Incidentally, I really liked his examples, since many of them described things that I wanted to do with GTK, so they gave me a nice head start.
I'm thinking it might be worth writing "Cross-Platform Database Programming using GTK+ and mySQL", using my new email handler/PIM application as a guide. Anyone think that would be interesting? There have been a lot of interesting pitfalls that I think would be worth documenting. And - an exciting thought indeed - it might be possible to do the development on Linux or even SGI Irix, and then send the result straight to Windows, Linux, Irix and SunOS without having to (ugh!) develop on a Windows system. If that would work, I'm pumped.
D
----
This looks promising but... (Score:1)
I am going to get this book and learn gtk+ though
What a great reason not to use Qt! (Score:1)
What, precisely, is wrong with Xm? (Score:1)
The times I've seen people here rant against it, it's always wonderfully objective and highly technical arguments like "Motif is like a stinky dead fish".
Back when WW I (widget war I) was ongoing, I like OpenLook better, but Xol and Xm both build on Xt so converting from one to the other wasn't that big a deal. (WW II is Qt vs GTK, I guess). But I haven't heard any complaints that don't amount to "its big and complicated, too hard for li'l ol' me to understand because it's nothing like MFC".
So really, what can you do in Qt or GTK[+] that you can't do in Motif? (Hmm, themes maybe. Yawn.)
Agreed (Score:1)
I was disappointed by this book. (Score:1)
I like GTK+, it's not too bad. (Being a professional win32 guy by day I'm not sure what more I'd want to make it a "great" widget set, I'm happy with it) but it like most OSS projects suffers from a lack of good documentation, that's the only reason I bought the book. I was hoping that this guy was going to have dug around in the code and learned about GTK+ and have some real insight but that isn't the case. There are better examples online and the GTK+ reference online is better. If I could do it over, I wouldn't buy this book.
Dang (Score:1)
It seems only the samples are still at the site. They're at http://www.bcpl.lib.md.us/~eharlow/book/
Choice, C vs C++ etc. (Score:1)
But despite it's imperfections, it *is* a good toolkit.
But I wouldn't say we're "stuck with it". There are a number of fairly decent toolkits to choose from (Qt, FLTK, wxWindows, Notif (not Motif).) Some are C, some are C++, many have bindings for several languages. GTK+ has C++ wrapper classes as well.
I remember going on irc on #gimp once quite some time ago (before the release of gimp 1.0) and I somehow got involved in a debate with the gtk and gimp developers about C versus C++. I was the only guy rooting for C++. Those guys were so anti-C++ it wasn't funny. They made some good points, though; for example, about the portability issues of C++ at that time, the lack of decent/unbuggy compilers etc. There was not much evil to say about C++ (the language), but quite a bit about C++ in terms of the compilers available, etc. And some lame argument about C++ not having a signal-slot mechanism. As if C has one, duh.
Me I would have preferred to have it done in C++.
I don't really see how some of the things you mentioned (like operator overloading) can make for a much better widget toolkit though. Personally I think C++ classes should be kept lean. Overloading every operator just for the sake of it is a waste of time.
Try FLTK (www.fltk.org) (Score:1)
I've been looking recently at FLTK ("fast light toolkit") - it looks pretty good from what I can see. It's quite small, it's efficient, and its cross-platform (Windows, X and OpenGL) and includes built-in OpenGL widget support.
I'm quite impressed with it (it's very easy to setup, install and compile on both Windows and Linux), although it is a little bit lacking in higher-level widgets (toolbars for example) and has a somewhat primitive looking file-chooser. Nothing a few weekends coding/contributing (it's LGPL) couldn't fix though. It also includes a GUI-builder.
URL is http://www.fltk.org/ [fltk.org].
You can afford books? (Score:1)
FUD fighting. C++ rules :) (Score:1)
Since you insist on making some stuff up; http://www.research.att.com/~bs/blast.ht ml [att.com].
Considering gtk+, do you really believe that C is better for this type of thing?
Throwing thousands of macros into your code to do typecasting is not only ugly and a waste of time, but also not nearly as safe as allowing the compiler to do type-checking.
Please back up your statement that C++ is somehow bloated. There is no theoretical reason (poor compilers notwithstanding), that applications would be somehow more bloated in C++ than in C.
In C, you would have something like this:
some_function_call_maybe_a_gtk_one( TYPECASTMACRO(some_struct_pointer), int parameter );
In C++, you would have, say:
some_class_pointer->some_function_call( int parameter );
These should compile to the exact same assembly (ie two parameters should be passed in both cases, the address of the struct/class, and the int.)
Dereferencing members of structs and of classes have the same overhead. The obvious exception to this would be virtual functions, which use a virtual method table. The vmt is constructed once, and function virtual function calls go through only one extra layer of indirection - almost negligible on today's computers, and by far worth the benefits it brings to the coder's ability to design code.
So only a bad compiler wouldn't generate efficient C++ code.
Sure if you start talking about exception handling your overhead increases quite a bit. But (a) nobody forces you to use it if you don't actually want that overhead, and (b) it isn't there at all in C, you gotta "do it yourself" there. You gotta weigh the pros and cons - if you're such an amazing C programmer that your programs will never need the extra layer of safety and/or ease-of-error-catching, then go with C. Most coders will admit, however, that no coder is perfect.
It is easy enough to produce inefficient code with C++ IF AND ONLY IF YOU HAVE A BAD DESIGN. Learning how to refine your OO designs properly can take years of practise (which can of course be counted against the language, or at least against OOP). And, of course, OOP in many ways forces you to do something that many C hackers aren't that interested in doing: PLANNING. I suspect this is one of the real reasons C advocates don't like OOP - you have to actually carefully think about your designs and plan them out BEFORE you start producing code. Shame.
Some things should also be kept out of "class wrapping", if for example repetition of calls amounts to too much overhead. (The use of QString in KDE's kmail program comes to mind - it is veeeery slow to show very long email attachments when it interprets the attachment as text, such as when getting the latest WINE update via email.) But once again this comes down to the design. The programmer should have thought "doing this will be too slow let's not use QString here". Note it is also easy enough to do a bad design here in C. Probably easier to fix it, though, in C.
I agree only with your first point, that C++ may be "overcomplicated". It has way too many little "fine points" and rules. It takes years to start truly nailing down and "mastering" C++, whereas C can be learnt in days, and "mastered" in a matter of months.
This is a weakness of C++, and in this way Java is a lot better. C++ becomes less accessible(sp?) to the masses because of this - fewer people know it well, and many people in a world where RAD is so popular don't have the time/energy to learn it all.
But I learnt C++ because I found it fun. And I really enjoy programming with it. I don't advocate it blindly - you should use whatevers best for each task. If you don't enjoy it, fine, don't use it. But please avoid spread of misinformation.
The kernel, I agree, should remain C.
Agreed (Score:1)
BTW I'm not an AC anymore ;) (Score:1)
Anyway this customisable slashdot is brilliant.
Thanks Rob!
--
GTK+ The awful truth (Score:1)
HOWEVER, even with this book, Glib and GTK+ are about 50% undocumented. What I really needed was a book like this one with about 500 pages of describing all the functions. Better yet, I'd like to see the HTML documentation get finished! The documentation for glib that is downloadable is awful. Most of the links point back to the link that pointed you to the first link. The reference manual is good, but it isn't tarballed!
I have yet to see an authoritative reference in HTML for GTK+. Period.
Sure there are example programs and tutorials, but when I want to do something beyond making an app with a picture button I end up trapsing through GTK+ header files.
Qt's library is fairly well documented (at least I never had to look at a header file).
Oh, and one last thing: better font support is needed! I want to be able to type
gtk_create_font( "Times", 14, BOLD )
!!!
This looks promising but... (Score:1)
Toolkits are nice, but they never do exactly or entirely what you want. then you have to go down a layer or two.