Often I complain that GTK+ documentation (non-reference) is non-existent. The few GTK+ books that were ever written are now old and most of their included source code does not even compile anymore. All hail “Foundations of GTK+ Development” by Andrew Krause.The book, published under the “open source” series by Apress, features over 600 pages and has a suggested retail price of $50 (although it can be easily found for $32). The book starts by explaining the need for the creation of GTK+ 10 years ago and the libraries and frameworks it needs in order to function.
To follow the book you will need some good C knowledge. The author writes in a well-paced manner, along with explanations, source code, screenshots and hints’n’tips. We had no problem following the source code examples and exercises at the end of the book.
Andrew Krause is known for having developed OpenLDev, a GPL’ed IDE. Not surprisingly, most of the book’s content is very UI-driven. The book starts by explaining the widget hierarchy of GTK+, signals and callbacks, events and then the widgets: buttons, container widgets, dialogs, tree and text views, menus and toolbars and even offers a primer to dynamic UIs and custom widgets. In the midst of all this you will be introduced to GLib’s functions, data structures, memory management, and pipes among other things.
Towards the end of the book you will find a GTK+ appendix which will help you easily find indexed information about widgets, properties, events, signals etc.
The book is very valuable for taking the new programmer by the hand to introduce him to GTK+ in a top-down approach, but at the same time it doesn’t take him far enough. The truth is, many new developers would also require a primer on Gnome libs, not just GTK+. And if that’s beyond the scope of the book, a primer to explain how to setup and write simple programs in gtkmm, C# or pyGTK would have also been useful.
Overall, we highly recommend getting this book if you must write your application in GTK+ but have given up trying to make sense of it by reading just the reference. Additionally, it offers a good guide for existing GTK+ developers who would like to expand their knowledge of the toolkit. As long as you understand some C, this book is a must-have.
Rating: 8/10
9 dead amerikan oil crusaders in eye-raq:
http://tinyurl.com/2o6mpj
fantastic news
> 9 dead amerikan oil crusaders in eye-raq:
It is fantastic indeed when the US nazi agressors army force gets depleted man by man, but I sincerely doubt that those men killed were in Iraq voluntarily. On the other side, they were there in order to kill random unknown people on command for money, so I won’t shed a tear.
Their deaths may also have an positive effect after all: a accelerated withdrawal of the US nazis from arabia.
Edited 2007-05-23 13:46
Actually, the first book about gtk2 is less known outside China mainland. It was published by Tsinghua on 2002, and talks about various gtk widgets during gtk 2.0.x era!
This is the URL about that first book (in chinese): http://www.bookssearching.com/product/100001/263329/
Not to be picky,but how would you expect that a book written in Chinese to be so well known … outside China?
Funny thing is that there’s no translation whatsoever of the said book in the link you posted.
Don’t take it personally, was just a remark. Something like “my 2 cents”.
It’s an older book, but I still like “Developing Linux Application with GTK+ and GDK” by Eric Harlow. It has a very friendly, conversational style, but provides a good overall introduction to GTK+.
My own take on GTK+ development was mixed. I come from a C++/Java background, so I found GTK’s semi-object-oriented programming a little strange. I would probably use GTKMM, the C++ wrapper framework. In Windows I preferred MFC C++ development rather than Win32 API C programming.
Of course, these days I prefer Java and .NET. Coding for VM’s seems to be the rage, you know. Go Parrot!
>I would probably use GTKMM, the C++ wrapper framework.
i agree. Sadly there is no Gtkmm book available and i prefer learning with a book.
Also a strong argument against Gtkmm, at least for me, is the missing feature to connect automatically the signals defined with Glade.
>Of course, these days I prefer Java and .NET. Coding for VM’s seems to be the rage, you know.
That’s the nice thing about Gtk+. You don’t have to code in C, you can code in C++(gtkmm), Python(PyGTK), Java(java-gnome), C#(Gtk#),…
That’s really great and it always remembers me about a statement from Owen Taylor (RedHat):
“And of course, the number 1 tip for GTK+ programming is: Don’t use C; In my opinion, C is a library programming language not an app programming language.”
There is only one problem in my view. This works really well as long as you use compiler-languages (C, C++, Java with gcj,…). But if people start using Python, Java, Mono and other interpreter- or VM-languages than it becomes really bad for memory usage. Imaging you are using 3 applets, on written in Python, one in Java and one in C# than you have all the time one interpreter and two VMs in the background.
Edited 2007-05-23 15:46
Good point.
That makes GTKmm more compelling.
But if one is going to with a higher level VM language, I would go with SWT / Eclipse RCP.
SWT is an API that in turn calls native APIs of three (currently) different native APIs: Win32, MacOSX, and GTK.
Thus, with SWT, you can make GTK native looking Java desktop apps.
Then with Eclipse RCP, you have all the advantages of JFace, the Eclipse workbench and plugin architure (abstractions on top of SWT), and you can use the Visual Editor.
Of course, then you can package your app for Windows and Mac, very easily.
In short, you get great native looking apps, with good performance (it’s using native widgets).
As for GTK# – while it’s technologically nice, and Miguel and the Mono crew have done an outstanding job – GTK# is extremely dangerous. It’s inviting lawsuit, or intimidation and/or extortion from Microsoft. The recent Fortune magazine article, which contains MS’s latest patent threats, makes this crystal clear.
But if one is going to with a higher level VM language, I would go with SWT / Eclipse RCP.
SWT is an API that in turn calls native APIs of three (currently) different native APIs: Win32, MacOSX, and GTK.
I personally really like Qt Jambi, the Java language bindings for Qt. And the best thing is, you can even use them with Scala (http://www.scala-lang.org/). Scala is a modern general purpose programming that integrates features of functional and object oriented languages and it runs on the Java VM.
>GTK# is extremely dangerous. It’s inviting lawsuit,
>or intimidation and/or extortion from Microsoft.
Why? Come on, that’s FUD. GTK# is NOT copying a Microsoft product. If GTK+ itself is NOT threatened, then why is a thin wrapper using a de jure standardised language threatened?
If there are any problems, it will be in the WindowsForms or ASP.Net side or other stuff that isn’t in the ECMA standard.
Give Microsoft *some* credit for open standardisation where they’ve done it.
> The recent Fortune magazine article, which contains
> MS’s latest patent threats, makes this crystal clear.
Go-one, be specific. MS can threaten wherever they have patents, but GTK# is no more and no less likely to be infringing than any random bit of code, so far as I can see.
James
>Thus, with SWT, you can make GTK native looking Java desktop apps.
swt doesn’t look native in a Gtk environment. Just look at eclipse and you will find many things which looks different than in a native Gtk+ environment.
Personally i would use SWT only if i know that a write a program mainly for windows and/or MacOS users. But for all programs which i write for myself and/orf for the X11 platform i would always use java-gnome.
>As for GTK# – GTK# is extremely dangerous. It’s inviting lawsuit, or intimidation and/or extortion from Microsoft. The recent Fortune magazine article, which contains MS’s latest patent threats, makes this crystal clear.
Please don’t start the 1001th Mono flamewar. Gtk# is just a wrapper around Gtk+ if this violates any (MS) patents it high likely that Gtk+ itself violates the patents, because all the logic is in Gtk+ and not in Gtk#. Also MS is one of the smallest problem if it comes to patents. Today almost every program violates patents and the most danger comes from companies which large patent portfolio and without own “products”. MS is one of the most harmless in this regard.
GTK# is extremely dangerous. It’s inviting lawsuit, or intimidation and/or extortion from Microsoft. The recent Fortune magazine article, which contains MS’s latest patent threats, makes this crystal clear.
Incorrect and misleading.
You *might* be referring to System.Windows.Forms in Mono which is something else.
gtk# is inviting lawsuits as much as gtk+ or qt is.
If you think like that I guess you would really like to hear about Vala
http://vala.paldo.org
it is a programming language designed to be something like a To Gtk+ Translator. It looks a lot like C# and compiles to C Code using Gtk+ (and it compiles rather cleanly, except for a feature or two that needs some weird C code to work)
It is really great and I guess it could use a bigger mindshare right now to be useful to its full extent.
But if people start using Python, Java, Mono and other interpreter- or VM-languages than it becomes really bad for memory usage. Imaging you are using 3 applets, on written in Python, one in Java and one in C# than you have all the time one interpreter and two VMs in the background.
It’s actually not that bad. I have mono, java, and python apps running at the same time on a modern machine and it does fine.
The last couple of applications I’ve written in GTK+ started as PyGTK or Ruby-Gtk2 apps. I roughed out the architecture for each application in an easy OO language (the bindings are wonderful) and then, for speed and memory reasons, reimplemented in C. It really is dead simple, too. The naming conventions follow the Principle of Least Surprise and map directly to those in the bindings, so the only real extra work in C is reinforcing types and memory management.
Gtk really is a fun library to work with. In fact, it’s a nice (re)introduction to C for those brave few out there. I like to write my apps in C because it severely reduces the number of dependencies a user will have to install.
That said, I would love to have the big three interpreted languages (Perl, Python and Ruby) standardize on Parrot
“Gtk really is a fun library to work with. In fact, it’s a nice (re)introduction to C for those brave few out there. I like to write my apps in C because it severely reduces the number of dependencies a user will have to install. “
Same here, too. Additionally, I’d like to mention thatt GNUstep is an interesting alternative for those who do not have problems using Objective C.
See my post above about Vala and you may thing it very interesting. High level (though not as high as python or ruby) but compiles directly to almost-as-readable-as-you-would-write-your-own C code with GObject and Gtk+
This is just fantastic news. While I generally use ruby-gtk2 or pygtk, the bindings are very true to the C API and this will help tremendously.
I gave up developing GTK2 (by when 2.0 was out) after extreme frustration with the API, and not being able to get anything done. This mainly due to the very bad shape of the documentation, and me spending hours into the source to figure out how to get anything done. I tried Gtkmm too, but I found it used a very complicated api. with lots of templates and zero documentation. I had to do some changes to a project about 2 years ago, and found that while improved, the docs were still in very bad shape.
I’d give it a chance again some day, but I am very happy with Qt, as I develop C++/python. If GTK/GTKmm was to ever have such a clear and useful documentation as Qt does, with tons of examples and every function well detailed, compared to others, and not stating obvious things that to me are not obvios at all. I’d think about it, but I always felt this was always an attitude of the GTK developers (for some reason, to not provide good docs, which to me are always more importantant than even the cleanest of the API designs).
About books.. many of us OpenSource developers, live in countries where it is just too expensive to purchase something from overseas, so online docs are our only hope to understand an API.
>GTK# is extremely dangerous. It’s inviting lawsuit, or >intimidation and/or extortion from Microsoft. The recent >Fortune magazine article, which contains MS’s latest >patent threats, makes this crystal clear.
I read the article you mention but it doesn’t say anything about GTK#. Could you be more specific I’m interested to know.
“I read the article you mention but it doesn’t say anything about GTK#. Could you be more specific I’m interested to know.”
I can’t be specific because MS refuses to be specific about it’s patents. MS won’t sue anyone, it just wants to play the FUD game. I just see Mono/GTK# (and especially WinForms and ASP.Net) as more MS FUD opportunity. And yes, the CLR and C# are published ECMA standards. However, MS still owns patents on them. Nothing legally stops them from trying to collect license fees, or suing. Being ECMA standards does not stop that.
In any case, there are already really really good GTK binding alternatives. So why bother with GTK#?
But that’s all besides the point, and I regret bringing it up. So as far as I’m concerned, for the betterment and health of this thread, please forget I brought it up.
The thread is about GTK, this nice new book about GTK, and GTK bindings.
I was singing the praises of SWT / Eclipse RCP, because SWT directly accesses GTK on *nix platforms. I think it looks great and performs great and blends with the Gnome and Xfce desktops quite nicely. Thus, I consider it a great choice for higher level GTK/Gnome/Xfce programming (it’s actually SWT programming, but it’s using GTK under the hood).
Another poster mentioned QT Jambi. I think QT is great, and QT/Java bindings already exist. So QT Jambi has great potential. However, it’s still in alpha/beta stage, AFAIK.
PyGTK is great, too. There is already a plethora of really good PyGTK apps, many of which are already deployed with Gnome oriented Linux distros.
Finally, Gtkmm is really nice, too.
The reason I sing the praises of SWT / Eclipse RCP, in particular, is because:
1) Eclipse is a very powerful IDE/platform. It has a huge ecosystem, many plugins, and lot’s of mind share.
2) It’s trivial to repackage an Eclipse RCP app for another platform.
3) The SWT visual editor is really good, and IMHO, easier to work with than Glade + GTK + whatever binding, and better than MonoDevelop.
4) The Eclipse license is extremely Linux/GPL friendly.
5) All companies who are members of the Eclipse Foundation are also extremely Linux friendly.
6) Eclipse, SWT, and Eclipse RCP can be run fully with gcj, if one wants to blend with gcc, or not use the Sun JDK/JRE for whatever reason.
7) Eclipse is already fully available on many distro’s repositories (Ubuntu, Debian, Fedora, SuSE, more).
8) Even if you don’t download from a distro’s repo, downloading and installing Eclipse from the Eclipse website, onto Linux, is brain dead easy on any Linux distro, so long as there is a JRE/JDK (Sun’s or IBM ecj or gcj).
8) Eclipse is already super popular, and continues to grow and get even more popular. There are so many Eclipse based tools, plugins, and Eclipse RCP apps, it’s not even funny. Heck, even Adobe’s FlexBuilder is Eclipse based. Zend’s PHP IDE is Eclipse Based. RadRails (a Ruby on Rails IDE) is Eclipse based. BEA WebLogic Workshop, WebSphere WASAD, and Borland JBuilder are all Eclipse based. It goes on and on. Eclipse is rapidly becoming a de facto standard for development tools. It’s even exceeded the popularity of MS Visual Studio.
So it only makes sense for GTK/Gnome/Xfce/Linux to piggy back on all that popularity, momentum, and mindshare. Gnome/Xfce/GTK devs using Eclipse will bring in more developers to the GTK world.
And yes, the CLR and C# are published ECMA standards. However, MS still owns patents on them. Nothing legally stops them from trying to collect license fees, or suing. Being ECMA standards does not stop that.
Umh, ugh, not really.
Microsoft owns patents on the implementation of these, and on some features of C# — which is indeed correct — but the ECMA standards are not patented. If something is described in the ECMA standards, it is not patented, and can be freely implemented.
Microsoft *can* sue Miguel & co. for their implementation of Windows.Forms, for instance, but the chances of wining are quite thin. You cannot patent things like variable names and function names. If it would be shown that Mono’s Windows. Forms includes *code* from Microsoft — yes, that would be something else.
Therefore, you cannot sue anyone for using Gtk#. The only escape way is probably C# (afaik Microsoft owns patents for some of its features) — but Mono/.NET != C#. [edit] You can use Gtk# with Boo, for instance.
Edited 2007-05-23 22:55
The ECMA absolutely does not require patent grants. Furthermore, patents have nothing to do with lifting actual code. You’re confusing patents and copyrights.
Let’s say that a particular standard specified an algorithm to accomplish something which is necessary to conform to the standard. If that algorithm is patented, it is not sufficient to write your own implementation of it from scratch. You would have to create a qualitatively different algorithm that produces the same results. In many cases, this is simply not possible.
I am not saying that there necessarily are patent traps in the .Net specification. I am only saying that being a published standard does not preclude patent traps. Just look at MP3.
Edited 2007-05-23 23:22
I think Mono is scary because it’s led by Microsoft which has a very devious history, which the recent patent noise should illuminate as NOT going away. From the little antitrust document called PX09509 from 1991 where they see themselves as being a natural monopoly. The ‘goal’ they refer to is a natural monopoly.
“To accept this goal means to provide leadership for apps other ways besides delivering software such as Windows. We must do other (perhaps less profitable) tasks which contribute to the same goal. For example, we should take the lead in establishing a common approach to UI and to interoperability (of which OLE is only a part). Our efforts to date are focussed too much on our own apps, and only incidentally on the rest of the industry. We want to own these standards, so we should not participate in standards groups. Rather, we should call ‘to me’ to the industry and set a standard that works now and is for everyone’s benefit. We are large enough that this can work.”
In this same document, they decry industry standards like X11 and POSIX. Please let this tell you where their strategy in other efforts like .NET and the crippling of Java is.
Edited 2007-05-24 01:08
1991?
That’s _16_ years ago.
nice book,
———————————————
iPhone
http://www.iphonetools.org/