The C-based GTK+ cross platform toolkit has now reached version 2.0. This version is the basis of Gnome 2.0 as well and its libraries are not compatible in either source or binary form with previous GTK+ applications. FAQ and release notes. The C++ bindings for GTK+ 2.0, called Gtkmm, is expected to be released very soon too. UPDATE: On a related note, Gnome 2 Beta 2 released for general testing.
GTK+ 2.0-Final Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
http://www.lysator.liu.se/~alla/files/testtext.png
Is it just me, or is this the ugliest toolkit known to man?
How close are the porting efforts for this to reach the BeOS side?
For that matter, how difficult is it to use this toolkit? Anyone currently using it, please mention here, interested parties want to know.
Thanx all!
-Chris Simmons,
Avid BeOS User.
[email protected]
The BeOS port is probably dead, just like the OS.
>How close are the porting efforts for this to reach the BeOS side?
GTK+ 1.2 for BeOS needed some months more of engineering. It is now an abandoned project, AFAIK.
I think the way to go is to create a good, rootless X server for BeOS, and port GTK+/Qt on that. The current X server for BeOS is old, slow and badly done.
>For that matter, how difficult is it to use this toolkit?
Personally, I believe it is a pain to learn and use. This is why they had make EasyGTK, a wrapper for GTK+, which simplifies it somewhat.
I like Qt much better. Qt is pure C++, has more features, it is truly cross platform and for all you BeOS devs, it is the toolkit that is “closer” to the BeOS way of doing things, than any other toolkit in the “market”.
heck, it is even uglier than motif!
if we compared all the unix toolkits, gtk would be the class geek, motif would be the hottie of the school and Qt would be a supermodel
Firstly, nothing… I repeat, NOTHING is more ugly than Motif.
Secondly, GTK 2.0 is not about looking good (obviously). It’s not a facelift, it’s many changes such as internationalisation and anti-aliased fonts by default without hacks, etc. GTK itself can look pretty (example http://kde-look.org/content/preview.php?file=881-2.jpg“>1″ rel=”nofollow”>http://kde-look.org/content/preview.php?file=881-1.jpg”>2</a&…)
let’s all vote for the ugliest gui toolkit in the computing world!
nominees are:
Motif
Qt
GTK
Win32 MFC
BeOS
Java Swing
Java AWT
QNX
NeXT
OS/2
Mac OS
Mac OS X
Amiga
SGI
Windows 3.1
awaiting your votes!
Actually, I like the GTK+ look. The new toolkits have gotten too cluttered for my taste. All the gradients and chrose look ugly IMHO. GTK+ is flat, but looks professional and powerful.
Systems programming should never be done in C++. There is just too much overhead. GTK+ is object oriented, but its just not done in an object oriented language with much less overhead than if it had it been done in C++. If you want it to be fast, it’s going to be a little ugly; however, I don’t think it looks all that ugly. They’ve done a fine job.
edit on previous post…
Whoops… I read the posts wrong. I was refering to the cleaness of the API, not the look of the widgets themselves.
There is far more to a toolkit than its external appearance. Most of the GTK2 pictures that have been released were designed to demonstrate what GTK2 can do, particularly in the way of text handling and internationalisation. They are not a demonstration of how GTK2 looks. Most pictures show GTK2 with its default theme, which is designed to be simple, fast and inoffensive (why do you think Windows looks so ugly?). GTK2 won’t look much different from GTK1, and like GTK1 it will be fully themeable.
Want to know what GTK can look like? Take a look <a href=”http://www.themes.org/skins/gtk/“>here.
>Systems programming should never be done in C++. There is just too much overhead.
If you write exactly the same code for C and later for C++, you get exactly the same result. The “C++ is slower” is a myth. But I won’t go into details as it is offtopic.
Why would you want to write the exact same code in C++ as in C ? Aren’t we somewhat missing the point of using an object-oriented language then, and aren’t we missing the point completely when it comes to comparing the output of the two languages ?
But as you said, this is off-topic and a neverending discussion.
I personally prefer C++ instead of C. It’s more powefull and featurefull. I don’t think it’s slower then C. But as you said, it is off-topic
If you believe the myth that “systems programming” should not be done in an OO language, maybe you should speak to some of the guys at Xerox PARC and ask their opinion. Do you know what Smalltalk is, or why is was invented?
Hmmm, NEXTSTEP was built entirely on OO technology, even the driver model was ObjC – and it was definitly not slow, esp. when considering the underlying m68k hardware!
This is a company that does stuff in the field of real time and they do write ups of what they learn for the community. Here is a 2 part comparison between C and C++ on the issues of Performance.
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/
Im sorry, I posted too soon.
The comparison shows that what features you use of C++ decide what kind of performance you get. The Fiasco microkernel (an L4 implementation) is object oriented. They just avoid virtual functions due to the speed penalties for the pointer tables. But it does give you the flexibility of taht if you need OO things like virtual functions to simplify the code, they do exist.
Umm, the poster who said that C++ is inherently slower than C is retarded. Given a good compiler (not gcc) C++ can be every bit as fast as C, or even faster. First, all of the object-oriented stuff condenses to regular functions with an extra object parameter. Same as GTK+’s object system, only cleaner looking. Most of the type conversion stuff can be inlined (and what can’t be wouldn’t be inlined in C either). What’s left is virtual functions and some stupid C++ features. Virtual functions, for their uses, are very bit as fast as code that does the same thing in C. If you take a look at the Linux kernel, there are function pointers everywhere. In fact, all drivers are implemented with objects that compile to (essentially) the same thing as a C++ class with virtual functions. The only thing that is really slower is RTTI and exception handling, and the former you shouldn’t be using and the latter (in a good implementation) will never be in the critical path. C++ has the potential to be faster as well. I’m writing a kernel in C++, and I’ve found tons of places where it helps. First, generic data structures using templates. Using templates, each data structure can be optimized (by the compiler) for each object type. For example, say you have i-node objects and process objects. You want to insert them into a tree. You need a comparison function to do this. i-nodes are compared to each other differently than process-objects. So the tree function takes a pointer to the comparison function it needs to call for each object. That’s an indirect function call for each iteration. In C++, you just define an operator for each object that needs comparison. The compiler can then go ahead and inline that operator. Larger? Slightly, but RAM is cheap. It is certainly a ton faster, though. The only way to do the same thing in C would be to maintain a seperate lookup function for each object-type. Then, there is the fact that operator-new can be overloaded for each object type to allocate from specific pools instead of the (slow) general allocator. This can be done from C as well, but its so much cleaner in C++. Then, there is the fact that C++ objects initialize themselves. Stupid bugs (like forgetting to initialize list-heads to NULL) are unavoidable. Any language features that make these bugs less likely can only help the resulting product.
If you follow that argument, why waste your time with C++ at all? Why not just go all the way and use a real OO language like Smalltalk? I mean, get some more RAM and write decent code, and it’ll be fast enough.
how bout gtk? =)
Sigh… I have over-simplified my opinion as I usually do, making me sound like a total idiot. I will clearify myself this time around.
“Umm, the poster who said that C++ is inherently slower than C is retarded. Given a good compiler (not gcc) C++ can be every bit as fast as C, or even faster.”
First of all, it’s not necessary to resort to name calling (how old are you? 14?). Secondly, I didn’t claim that C++ was inherently slower though I wasn’t clear either. What I meant to say was that if you use features such as polymorphism, you will have slower code due to having to bind types at run time. C++ will never be faster than C, but if you program C style in C++ you will wind up with the exact same code. Thus, it will run the same speed. Also, GCC is a great compiler. Where do you have support for claiming that it isn’t?
“If you take a look at the Linux kernel, there are function pointers everywhere.”
Function pointers aren’t the same thing as using virtual functions. Virtual functions requires a lookup table which hurts speed and also bloats memory usage.
“Using templates, each data structure can be optimized (by the compiler) for each object type.”
Templates are for reducing redundant code. They don’t create any speed gains; however, it doesn’t cost in speed either. The same thing could be done in C (as can most anything). Admitidly, it’s far easier to do in C++.
Perhaps, after rethinking, using C++ for systems programming in itself isn’t bad, but using certian features of C++ in systems programming would be bad. Yes, the automated initialization of objects would reduce the occurence of “stupid” bugs with no real cost in efficiency. Yes, there is no penalty for using classes instead of structs (since they ammount to the same thing). However, C++ isn’t for increasing speed, it’s for reducing redundency and increasing code reusablity. I think I have been biased in my opinion on C++ due to an article I read about the linux kernel that sided on C (really bad reason too).