Follow Slashdot stories on Twitter


Forgot your password?
The Internet Books Media Book Reviews

Review:Developing Linux Applications with GTK+ and GDK 85

Eric Harlow, author of Developing Linux Applications with GTK+ and GDK has written a book well worth reading. A good first round of things, click below to find out how to write more of applications/widgets/whatever. Thanks to A.M. Kuchling for the review.
Developing Linux Applications with GTK+ and GDK
author Eric Harlow
publisher New Riders
rating 6
reviewer A.M. Kuchling
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.
REVIEW: Developing Linux Applications with GTK+ and GDK
Eric Harlow
New Riders

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.
Rating: 6/10
A.M. Kuchling
The Scenario-->

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

  1. Introduction to GTK+
  2. GLIB
  3. Developing GUI Applications
  4. Basic Widgets
  5. Menus, Toolbars, and Tooltips
  6. More Widgets: Frames, Text, Dialog Boxes, File Selection Dialog Box, Progress Bar
  7. Writing a Calculator Application
  8. Developing a Simple Word Processor
  9. Minesweeper
  10. Graphics Drawing Kit
  11. Styles, Colors, Fonts, Cursors, and Referencing
  12. Molecule Viewer Using GDK
  13. Sprites and Animation
  14. Trees, Clists, and Tabs
  15. Creating Your Own Widgets
This discussion has been archived. No new comments can be posted.

Review:Developing Linux Applications with GTK+ and GDK

Comments Filter:
  • by Anonymous Coward

    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 [] at the Commonwealth Institute, London W8
    Tuesday 23rd March, 1999 at 7.00 p.m. - 9.00 p.m
    Sponsored by UKUUG []

  • by Anonymous Coward
    Thanks, Paul.

    While I have your attention, is there any
    chance for a Beetles reunion? And congrats
    on your RRHoF induction last week.
  • by Anonymous Coward

    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.

  • by Anonymous Coward
    Am I the only one who thought Eric's writing style left a lot to be desired? The way this book is written, I had to read the code examples to figure out what the hell he was trying to say.

    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.
  • BSD is still the best. You didn't back up your arguments with any actual facts, but instead listed nothingness as your reasoning (which isn't actually a reason, might I add). Think before you type and you won't sound so dumb next time.
  • Believe me when I say you don't want to learn the raw XWindow programming stuff... toolkits exist for a reason, namely to provide a source of sanity for the poor developer.

    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. :^)
  • and is published / will be published by O'Reilly... y'know, Right Tool For The Job. GTK was written for GUI programming in C. Gtk-- is at 1.0 and I even installed it, but I hain't tried writing anything funky with it.

    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 to Pythonize them, and bind your events to Python functions. Neat!

  • Unless you're writing your own toolkit, in which case you will need raw X knowledge.

    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.
  • Not to nitpick, but O'Reilly's X books are older than 5 years ... I think first publishing was in like '87 or so ...

    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 ...
  • Sorry, but have you ever actually written Motif code or used Motif apps?

    It's garbage. Plain and simple.
  • OK, maybe not *everything*, but close to it.

    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 ...
  • So don't get so uppity.
  • I'll say that gtk+ certainly isn't a *great* widget set, but then again, what else out there could we choose from?

    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.
  • I checked out this book in the store and decided not to buy it. Nothing really new in the book, actually. I'd stick with the gtk tutorial that's already out there, it's pretty good. Also, download any gtk applications which do similar things with gtk that you might want to do, and grep their sources when you need more examples. Of course, having the gtk source itself is a must, especially if you're going to write your own widgets or extend the existing ones.

    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.
  • Well, ahem, there it's not typos that are the problem. It's the lack of content.

    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.

  • I don't know where you're coming from, but I like Gtk quite a bit. I have done some win32 programming. Gtk is quite elegant in comparison, IMO.
  • I wasn't referring to your book, Erik, but to the GNOME docs in particular.
  • The title was probably chosen to be trendy as you suspect. Something like _Unix GUI programming with Gtk and Gdk_ would have been more accurate, but wouldn't have the Linux cachet.

    There is an example that uses /proc (which would probably be easy to modify for Solaris), but otherwise I haven't seen anything else Linux specific yet.
  • '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 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.

  • 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.

  • Hi there,

    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

  • 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.

    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

  • I don't think GTK+ will be the only alternative for the next while. With the recent changes to the QPL, there's no longer a license-related reason to avoid Qt, so you can choose on the more interesting grounds of programming model, and interface attractiveness. I suspect that GNOME and KDE will move toward merging their efforts, or at least interoperability, so choosing a toolkit probably won't also dictate your choice of desktop.

    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.

  • It seems to me that most graduates come out of
    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

    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.


  • I've noticed several criticisms of the existing GTK docs in the comments posted so far.

    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.
  • 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.

    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)

  • That is your problem. You used SunOS 4 and actually liked it. No wonder you use FreeBSD instead of Linux: FreeBSD has the same flaws.

    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.

    In case you hate GPL stuff:

    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).

  • 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.
    Gtk+ is referenced counted, not scoped like that of C++ objects. They destroy when they are no longer referenced. This is for a very good reason. That being ease of use. In Gtk-- though, you can happily have the C++ section scope through normal rules.

    Can I derive a new widget from an existing one and not have to worry about implementing inherited methods? Nope.
    I don't understand what you are saying here. Deriving methods in gtk+ or gtk-- is that same as any OO model. Why would you worry about what you inherited? You can always override them. (You could make a point that gtk+ uses concrete widgets as abstracts, but that is minor.)

    Can I integrate widgets easily with the STL? Nope: I'm supposed to use glib.
    Gtk-- does not use glib. We use STL or provide STL complient containers. Most of these issues are resolved with the restriction that you should not take containers outside of local scopes. What STL algorithms are you planning to run on these widgets?

    Can I overload operators so I can treat these "objects" just like native data types? Nope.
    That is a language feature not a OO issue. In C++, that works without effort. See the glade-- examples for details.

    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...
    I thought that we have covered all of the basic widgets, but if you know of one that is missing I would be happy to see if we can get a wrapper for it. As for gtk-- readiness, it is suitable for moderate tasks. There are still many changes in the underlying structure planned. But this is common of tools early in their development.

    and I'd argue that the apparent difficulty they are having with writing C++ wrappers at all merely proves my point.
    The largest difficulty in writting a good C++ wrapper has been that Gtk+ keeps moving so swiftly and we have no documentation to go by. We are all just people interested in using the kit for our own projects, and so we only make changes at the rate that we discover problems.

    --Karl Nelson
    Gtk-- contributor

  • They thought of everything when they designed X. Really.

    Anti-aliased text? Window management that doesn't break down when your WM gets swapped out?

  • I'm just trying Gnome 1.0 (GTK 1.2, on SuSE 6) and I find the most impressive of it's features to be the great themability that raster (among others) have added.
  • I was planning on writing a review on this for /., but haven't got round to reading it properly yet, so I got beaten to it..:)

    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.

  • Where does one find information about programming GTK in C++ ? I sometimes find it hard to believe that there is still so much C developement going on..
  • I just want to thank everyone who has posted a comment about the book - even the negative comments. Hopefully, I can improve the book as later editions come out. Writing a book is a lot of work especially when you have a moving target like GTK+ to write about. GTK+ is *so* big that I couldn't possibly write about the entire toolkit. I just want to expose people to the capabilities of the toolkit.

    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.

  • The problem I had with the book is that the code examples contain many errors:

    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?
  • I think Gtk+ is OK, and better than any other toolkit other than (perhaps) Qt, which has other kinds of problems (that its in C++ primarily).

    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.
  • You seem to be mixing up library design and language features.

    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).
  • I remember a few months ago downloading the 1st few chapters of this book, i still have it, but i think only in printed form.
    as i can remember this beta version i downloaded was also covered by /.
    maybe it was on, or, i don't know....
  • If you're looking into programming with Xlib and its friends, O'Reilly published a nice series of books about X about five years ago. Since X hasn't had revolutionary advances ( although it certainly has undergone evolution ), the API specs and docs there should be decent. I think I remember Raster talking about them a few times.

    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.
  • Trust me, you WANT to learn to code to the widget sets. Raw X programming (that's NOT "X windows" btw) is painful.

    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.

  • While I agree with your idea concearning open source documentation, this book is probably copyrighted (and I doubt it's an Open Source(tm) compatible copyright). If it were posted for free online, I'd be the first to send in whatever corrections I could find. But this is a for profit book. Correcting is the job of the editors, not the users.

  • While I agree with your idea concearning open source documentation, this book is probably copyrighted and I doubt it's an Open Source(tm) compatible copyright (I don't have the book so I don't know this for a fact). If it were posted for free online, I'd be the first to send in whatever corrections I could find. But this is a for profit book. Correcting is the job of the editors, not the users.

  • How come someone moderated this to a -2?

  • Granted, the book had some really annoying errors (as discussed in some of the other reviews), but I'd checked out GTK on the web, decided it was too difficult to bother figuring out, and did nothing.

    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.


  • Anybody know of a good book for learning X windows programming. Been trying to find one that will let me write programs that are not dependent on certain widget sets.

    I am going to get this book and learn gtk+ though :)
  • IMHO the *best* thing about GTK+ is that it doesn't require you to program in C++. If you want to use C++, use GTK--.
  • Open/closed issues aside (because there's Lesstif), what exactly is wrong with Motif?

    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.)
  • by Mr T ( 21709 )
    You seem to be confused when it comes to object orientation. You're complaints are complaints about C, not about a non-object oriented design. If you can list some design aspects of GTK+ which keep it from being object oriented, I'm all ears.
  • I'm not sure how much it is exactly, but about half of it is devoted to code examples that aren't very exciting or even that original. I love code samples, I mean I really love them, but pages and page and pages of code don't make for good books. That stuff belongs on a disc, it's not book, at the very least the whole code should be in the appendix and not in the main chapters. It's not much in the way of a reference either. I kind of feel that it was quickly put together in hope of making some bucks on the void in GTK+ documentation.

    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.

  • I still have a copy of the whole site, which I downloaded with wget. I'm very sorry it's not available anymore though.

    It seems only the samples are still at the site. They're at

  • Personally, I don't think gtk is quite as bad as you make it out to be here; but I do agree with you somewhat. It's not necessarily the cleanest most well-designed Toolkit on the planet. It sure as hell beats Win32, but that doesn't say much. (GTK was largely designed by an undergrad student in his spare time. Win32 was designed by a large team of professional full-time experienced programmers. Ack!)

    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.

  • 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 [].

  • They're so dang expensive in my country, I stopped buying 'em a long time ago. It's typically between 400 and 500 rand for a computer book. Divide by +/- 6.2 to get US$. That's a crapload of money. Last computer book (not counting textbooks) I bought was about six years ago, a book on x86 assembly language.
  • Since you insist on making some stuff up; ml [].

    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.

  • gtk+ is a good widget set, but I'll hold off on declaring it not great until I look more into it. Gtk-- was very nice when I used it last almost a year ago so I'm sure it's only gotten better. About Athena (Xaw), it was never meant to be a major widget set, but one for quick programs and getting used to X toolkit programming. Programming it is similar to Motif since both of them are based on Xt. I, too, am considering writing another widget set, but first I need to discover if gtk+ has what I want or at least if not, what I want is addable (is that a word?). :) Cheers!
  • Now I've created myself a user account. It'll avoid all the confusion in the future.
    Anyway this customisable slashdot is brilliant.
    Thanks Rob!


  • When I saw the apps being made with GTK+, I took one look and said "NICE". GTK+ makes sexy apps, no doubt about it. I used Qt for a small app, but it somehow looked bulky. No other way to explain it.

    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 )

  • Introduction to the X Window System by Oliver Jones. this has been my #1 resource for the past 10 years. it is very clear, concise, and provides an excellent foundation for raw X programming.

    Toolkits are nice, but they never do exactly or entirely what you want. then you have to go down a layer or two.

Seen on a button at an SF Convention: Veteran of the Bermuda Triangle Expeditionary Force. 1990-1951.