Slashdot Mirror
Review:Developing Linux Applications with GTK+ and GDK
Nutshell
Review: 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- 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
BTW although my sig may have been confusing. I'm not RMS I was just poining out an event with RMS in it.
Sorry for any confusion,
Paul
Is anyone else disappointed that, of all the widget sets out there, this is the one we're going to be stuck with for the next 5 years? But it's object-oriented, really. No inheritance, operator overloading, assignment/copy construction, automatic destruction or obvious class hierarchy, but it's object-oriented. Honest!
It supports all those basic constructs.
I don't think so! ;)
Paul
I bought this book a couple of weeks ago and I have to confess, I was less than impressed...
There are countless API calls in GTK, and the documentation is not particularly great, so Mr Harlow would have done well to provide a better description of the API calls, even as an appendix.
The opening part of the book is basically a regurgitation of the GTK+ tutorial available with the source code...the last part of the book is just source code to fill out the book...
I would agree with Mr Kurchling that the absence of screenshots is curiously sparse, perhaps this has been covered before since the author's website
has screenshots
(http://www.bcpl.lib.md.us/~eharlow/book/)
I would also agree that the vast amounts of code fills out the book without giving any insight into the real meat of the software that the author has written.
The calculator/minesweeper clone/defender game are all pretty nifty but I don't want to wade through hundreds of very sparsely annotated code to find useful tricks, I could download any GTK+ app from the Net and do the same, for £30 cheaper...
Finally, in response to Larien, I'm not missing a CDROM, since in the UK we pay VAT on CDROMs with books, and in this case, GTK+ is downloadable from the Net, the GTK+-1.2 release was made after the book was published (contrary to the author's hints that you should use it) so all that could have been included on the CDROM is an outdated version.
Overall I think the book rates a 5, some neat ideas, but there is not enough sparkle or technical information, just reams and reams of code to fill out the book.
I am now looking forward to the Programming QT book...
> Is anyone else disappointed that, of all the widget sets out there, this is the one we're going to be stuck with for the next 5 years?
:-( But there was hope, a wrapper for a more object oriented language, called GTK--. And I got disappointed once more, it's just the same :-((
Yes, I can't believe that everybody's trying to market that crap as the standard interface for unix/X11. No other API is worse, even MFC is nicer to program with
No way, I won't code programs with function names that won't fit into a typical 80 cols terminal, with 5 underscores in them, encapsulated with macros all over.
I'm gonna have a look at Qt and kdelibs and I really hope that that stuff is nicer to programmers. Any experiences with that?
Not to mention the examples are not *greatly*
usefull.. They show the most obvious ways to
use the API but doesn't illuminate the interior
much.
I've learned more reading the many gtk sources
that are out there.
They are *excellent*. They will be linked off of /html/index.html
Slashdot tried to process it as an URL ;-) That's:l
wherever-you-installed-qt/html/index.htm
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.
In case you hate GPL stuff:
Solaris is a nice system. You can get it cheap
if you just want it for personal use. The same
goes for UnixWare.
More costly options include Digital UNIX, HP-UX,
AIX, and Irix.
With so many good choices, you don't have to
run BSD anymore.
Pissing all over Motif is about the quickest way to look foolish that I can think of in this kind of discussion. Saying you prefer something else is just fine - but please don't imply that Motif is a piece of garbage or something.
Use Lesstif if you want a free toolkit. Yes it's still a little buggy, but it's far, far richer. GTK+ is not nearly as capable. And the Motif API which Lesstif shares is vastly better documented than GTK+ or Qt.
I have about 2000 pages of Motif books at home, inluding both O'Reilly volumes. Plus a few 1000's more of supporting Xt and Xlib books - about eight or nine books in all. You don't have to wait for the first GTK+ book to come out, only to find it's a little weak. You can go right into a large bookstore and walk out with armfuls of classic X/Motif books and be way ahead on the path of learning.
Mike Greaves
The problem I have with Motif isn't a lack of capabilities but a lack of productivity. Simply put, it is a PITA to code with. I guess that most of the problem is due to Xt. I haven't used Gtk+ much, but development definately seems easier/quicker than with Motif. Qt is a real joy to code with; IMHO much better than either Motif or Gtk+. Qt is probably a tough choice for a free software author due to the religious wars over C++ and Troll Tech, which is really unfortunate. FWIW, I don't like MFC much either, but in terms of overall ease of use and productivity, Inprise/Borland's VCL wins hands down over both MFC and anything in UNIX land.
Dave K
daking at infinet dot com
(1) Virtually all of Unix/Linux/whatever is written in C
(2) Not everybody knows C++ or cares to learn
(3) C is simpler to use and understand than C++
(4) GTK+ is written in C
(5) X is written in C
I found the writing style too choppy as well, with too many multiple sentences that would have flowed better as one.
I still find it more pleasant to read books than online material. The book also has more info on Gdk than you'll find online (the present Gdk docs are pretty shameful.)
That is exactly the problem with Motif...It needs to be vastly documented to be able to use it. It is way too complicated to learn compared to GTK or QT while not offering not much more advantages than being the defacto toolkit for Unix. To me Motif is to QT (of GTK) as TLI is to sockets.
You wont believe how many computer books I have on my bookshelf! Many of them I still haven't finished reading because a new one comes up before the old one is finished. I must be some kind of computer book addict.
Anyone interested in working on Dylan language bindings for GTK+ is encouraged to join us:
http://gwydiondylan.org/gui.phtml
With a little work, we should have a great interface for programming GTK+ applications.
(Dylan is an advanced, object-oriented language that can be very efficiently compiled. Gwydion Dylan is an open-source, optimizing Dylan compiler for unix systems.)
is not a very good implementation,
but still it's a good start, but not worth the attention of a book.
I agree that GTkaint that good, in actualality it can give you nightmares, it really is an awfull api!!!
If you think you hated win32 then look at this, and dontknock win32 unless you have coded it and knw how to code, coz gtk isnt better, but its the best thing we got, so just likein the early 80's when we wereleft with so so tools, this is all we have, or you could go with zinc.com
Which is not acceptable discussion on SlashDot ;-) On SlashDot Gtk like rulez, d00d.
'nuff said
C++ is an over featured language. Somethign like Java is much better. It is OO and yet isnt a baroque load of cruft that has gone through some mutated organic growth. C++ also leaves to much to be "implementation defined". C can be quite easily "objectified" if necessary, C++ on the other hand is still bloated even if you dont use the OO features. C++ is for application development, not for systems development. Write your application in C++ if you really need to, but leave system (ie the OS, widgets, Windowing system etc) to C. Then everything runs nice and fast, doesnt hog memory and is more portable. Write wrapper libraries for your applications in what ever language you want.
That way non OO programmers dont have to get lumped with stupid languages (and all the screwed crap like implementation defined exception handling and the like) implementations and their cruft.
thats a matter of opinion. Linux isnt the best OS in the world. Linux's weak spots are multimedia, 3d, DVD, and all the stuff that makes up our future of desktop OSs. Perhaps we should get our asses moving on making THAT better then windowsNT?
Dont say "Well, we allready have Voodoo2 support" bah, that doesnt mean dick, esound isnt that good as mixing audio, direct sound is accually better, and a bunch of other things.
but i dont say "Well Linux sucks because it doesnt do those things"
I run linux myself, its the only OS I run. And I like it, i just wish we'd push it into the future, rather then sit on our asses and say "uh uh, this is cool" (not that the kernel people sit on there asses, but we should get a group together developing linux's DVD/Audio/3d video)
You are SO wrong!
I've written a lot of win32 code. Win32 is really, really bad. In comparison, GTK shines.
I won't get into all the problems since they are already brought up over and over again.
I haven't found a good general book either, but the Qt online docs (they also come with the source) are quite helpful, and with each object being comparatively well documented, it's quite easy to stumble through. I've had no bottlenecks in my development due to difficulty with Qt; they've all been stupidities in my non-gui code. typical, I guess, but still..
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
Thanks, Paul.
While I have your attention, is there any
chance for a Beetles reunion? And congrats
on your RRHoF induction last week.
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.
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.
Brian Fundakowski Feldman
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.
--- Journals are boring; Go to my web page instead
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 glade.py to Pythonize them, and bind your events to Python functions. Neat!
Remember that what's inside of you doesn't matter because nobody can see it.
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.
--
Ben Kosse
Remember Ed Curry!
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.
/proc (which would probably be easy to modify for Solaris), but otherwise I haven't seen anything else Linux specific yet.
There is an example that uses
'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.'
/mill
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.
What we need more of is science!
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
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
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
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
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.
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)
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).
--Karl Nelson
Gtk-- contributor
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.
Congrats!
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..
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?
JET Program: see Japan, meet intere
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 will protect you from ideals to save you from defeat
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 gnome.org, or gtk.org, 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.
_Deirdre
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.
Erik
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.
Erik
How come someone moderated this to a -2?
Erik
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.
D
----
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--.
-- Some things are to be believed, though not susceptible to rational proof.
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.)
-- Alastair
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.
This is my signature. There are many signatures like it but this one is mine..
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.
This is my signature. There are many signatures like it but this one is mine..
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 http://www.bcpl.lib.md.us/~eharlow/book/
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 http://www.fltk.org/.
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; http://www.research.att.com/~bs/blast.ht 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!
Anyway this customisable slashdot is brilliant.
Thanks Rob!
--
--
Beer is best!
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 )
!!!
Opinions change daily as new information arrives. Stay tuned.
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.