Despite your colorful descriptions there is a huge laundry lists of why it is a good idea to write an OO frame in a non-OO language. The most basic is freedom to design without the inherent restrictions of the OO framework the language provides. See the gnome FAQ if you want more.
But this is beside the point as we are to be comparing a C++ toolkit with another C++ toolkit. Gtk-- interfaces to C++ completely including STL defined methods. Qt on the other hand, implements its own set of list, strings, and containers that are not nearly as well as the STL ones. Further, gtk-- works within the C++ defined framework to construct its signal system instead of building in with MOC a meta compiler. So honestly, gtk-- is more C++ than Qt. It you want to interface a C++ library to Qt, you will have even more cost that we do interfacing to C.
If you honestly looked at gtk--, you would find it is a very clean toolkit class set. You can derive widget freely without worrying about the gtk+ internals, so what is your beef? And with our signal frame, your application will still be portable without a meta compiler.
You will also discover that the extra layer accounts for all of one extra function call in 90% of the cases. This is hardly a huge overhead. If you read through the fine book More Effective C++, you will discover that C++ implementation of its own internal mechanisms is far higher than this.
Both the printing needs and the gdk interface are properties of gtk and not just gtk--, so saying gtk-- sucks because you don't like the underlying gtk+ is being overly specific. It is like saying that you hate all Taurases when you mean you hate all Fords.
I understand that we don't have the interfaces you require, but that functionality is the domain of gnome, not gtk. If you think the documentation is bad feel free to contribute some more usable docs. We welcome participation in our project.
I am not sure about the canvas widget with printing support, but gnome canvas is the current work in that direction. The fact that DrawingArea is worthless for your printing usage is no surprise. It was meant for as a quick way for the user to add graphics without the overhead of writting a new widget. Comparing a canvas with a drawing area is misleading, as they have different purposes. You should compare a gnome canvas/print with the qt canvas.
But neither of your arguments have anything to do with gtk--. Those are functions of gtk+ and not of the wrapper on top.
There is nothing inherently a kludge in writting OO code in C and then wrapping it in C++. No one has ever cited a document showing that all wrappers must be bad. As gtk+ already has an excellent OO design very little changes were needed to make a good wrapper. Besides both Qt and Gtk-- wrap the OO X code in C so the point is mute. Both are wrappers of some sort.
I am not sure what you mean when you say "gtk-- is such a piece of crap." Could you please be a little more specific as to what you find missing? Free software such as gtk-- only improves if we know what is wrong.
Currently Gtk-- provides
A good signal system comparable with Qt.
C++ mechanisms to the gtk+ toolkit.
C++ access to gnome widgets.
A lowlevel interface to X drawing primatives.
We have been making vast improvements in the documentation and the code readablity in the last two weeks. And we are preparing for a stable release to correspond with Gtk+ 1.2.
Is there something more you desire, or is there some feature that we are missing that we should add? We would really like to know before we realease 1.0. Also when was the last time you looked over the interface?
Does anyone know if there is a method for contesting a patent prior to issue. Then we could just have a few people skim over abstracts of potential patents, and if they look threating to our cause post it to a public web site. We can then find the prior art before the patent is issued and defeat it in advance. It might be cheaper than fighting about it later.
GtkGLArea is definitely the way to go. There is also a Gtk-- (C++) wrapper for it that I mantain, but I have been too busy with the rapidly pace of gtk-- to keep it up. Gtkglarea can do both rendering in a window and a pixmap. Any GL command seems to work well. (I even got the chose a line working properly.)
Slashdot Mirror
But this is beside the point as we are to be comparing a C++ toolkit with another C++ toolkit. Gtk-- interfaces to C++ completely including STL defined methods. Qt on the other hand, implements its own set of list, strings, and containers that are not nearly as well as the STL ones. Further, gtk-- works within the C++ defined framework to construct its signal system instead of building in with MOC a meta compiler. So honestly, gtk-- is more C++ than Qt. It you want to interface a C++ library to Qt, you will have even more cost that we do interfacing to C.
If you honestly looked at gtk--, you would find it is a very clean toolkit class set. You can derive widget freely without worrying about the gtk+ internals, so what is your beef? And with our signal frame, your application will still be portable without a meta compiler.
You will also discover that the extra layer accounts for all of one extra function call in 90% of the cases. This is hardly a huge overhead. If you read through the fine book More Effective C++, you will discover that C++ implementation of its own internal mechanisms is far higher than this.
Both the printing needs and the gdk interface are properties of gtk and not just gtk--, so saying gtk-- sucks because you don't like the underlying gtk+ is being overly specific. It is like saying that you hate all Taurases when you mean you hate all Fords.
I understand that we don't have the interfaces you require, but that functionality is the domain of gnome, not gtk. If you think the documentation is bad feel free to contribute some more usable docs. We welcome participation in our project.
--Karl
But neither of your arguments have anything to do with gtk--. Those are functions of gtk+ and not of the wrapper on top.
There is nothing inherently a kludge in writting OO code in C and then wrapping it in C++. No one has ever cited a document showing that all wrappers must be bad. As gtk+ already has an excellent OO design very little changes were needed to make a good wrapper. Besides both Qt and Gtk-- wrap the OO X code in C so the point is mute. Both are wrappers of some sort.
--Karl
Gtk-- Contributor
Currently Gtk-- provides
- A good signal system comparable with Qt.
- C++ mechanisms to the gtk+ toolkit.
- C++ access to gnome widgets.
- A lowlevel interface to X drawing primatives.
We have been making vast improvements in the documentation and the code readablity in the last two weeks. And we are preparing for a stable release to correspond with Gtk+ 1.2.Is there something more you desire, or is there some feature that we are missing that we should add? We would really like to know before we realease 1.0. Also when was the last time you looked over the interface?
--Karl
Gtk-- Contributor
--Karl
--Karl