Then you have all the power of the gtk+ widget architecture with the convient syntax of C++. No long names, nicely mapped as STL concepts, and a tutorial.
Just a note of the status. The port of gtk-- was just contributed recently but has not yet made it to the distribution. Unfortunately, it is only available in static form because of the incomplete port of gtk+. Gtk+ support of windows platform is just starting to be incorperated back into the source base. It will likely not be considered completely supported until the release of gtk+ 1.4 later this year.
Of course, you should evaluate for yourself whether static linking would be a problem for your application.
Yes, there are bindings for gtk+ in C++, gtk--. They are located on sourceforge. They are currently finishing the last beta before releasing 1.2 which will likely ship as part of GNOME.
They may not be quite the same quality as the professional Qt toolkit, but they are useful, free, and designed to fit well with STL and C++.
Do you care to elaberate on what you find so missing from gtk--? What version did you try?
I can name a lot of traits where I think Gtk-- has done better that Qt. (I don't try to compare it to all of KDE, because that is comparing the work of 3 guys going bindings to a magnitude more.) The use of templates to form signal/slot mechanism and the embracing of STL style within the code are most often mentioned by our users. We also strive for GUI independence be not forcing out types onto the users at all if we can help it. Thus you won't find Gtk::String creaping into your non-GUI code.
If you what improvements you need to supply feedback.
I got zilch, as did my friends and family members. I am beginning to wonder who got any. Anyone have the odds of getting the VA Linux through E*Trade? It is probably over 10 to 1.
Use preprocessor macros. Lots of them. (I was actually on a project where someone suggested using cpp to define macros. For Java. Absolutely brilliant!) The key is to use a single macro for multiple statements, in effect using macros as function calls. Example:
Far better is to use some preprocessor which is not even included in the language. For example choose some obscure preprocessor whose notation is in direct conflict with internals of the language. This causes the source code to become meaningless programmers. Then write long procedures into macros and construct them into massive unformated and unreadable procedures. If you are really good, have the macros change throughout the code or perform different functions depending on hidden arguements. Redefine keywords to match macro definitions so that you can't tell the difference between the preprocessor and language. I can personally recommend m4 for the task.
Althrough this seems rather boring, my personal favorite when I have a very large number of computers to name is to use the periodic table. Just start from hydrogen and work your way down the table.
Most people have a good clue what the first 18 are. You can name up to half a class C with it. It is unique enough that each person can remember the names of machines without confusion. It has little sexual bias or other connotations, unlike series like authors and inventors in which you may end up picking too many males and be accused of sexist names. There are a reasonable number of really cool sounding element names in the series, unlike trees. They sound reasonably professional.
There may be some problems doing that. Most notably the signal system libraries between Gtk-- and Qt are not compatable, nor can they coexist easily. Qt does not properly respect namespaces and thus wipes out names used by the other. This forces the user to have to chose to use the Gtk-- signal system or not. (Gtk-- signal system is now seperate from Gtk-- as Libsigc++ so that it can be used for such cross toolkit uses.) Libsigc++ does avoid the Qt keywords when it detects them, but it does degrade use slightly. (Apparently Qt was granted sole license of the word "emit" even though I can't find it in any standard.;-)
If you could comment more on what you find annoying about programming in Gtk--, I would be glad to hear it. We are working to complete version 1.2 very soon now with improved speed, features, and documentation. Any feedback would be greatly appreciated.
As one of the main coders on the Gtk-- project I am always glad to get feedback whether I agree with it or not. You said that gtk-- was currently as slow as hell. I was wondering which version in perticular you tested. Was it the stable version or the development version?
The development version should be considerably faster as all the hash table lookups were eliminated and all the excess size (often many K) of signal stuffs has been eleminated. If you still find it slow (compared to gtk+ as I can't fix stuff outside my layer), please send me a demo program and I will mark it as a hot spot to do optimization. Thanks in advance.
It is highly unlikely that there would be such a merger as the technical difficulties are huge.
Creating a "universal kit" which functions perfectly in C and C++ is not very likely. If one starts a code base in C, it will not be able to use some of the C++ features like static casting to get a particular virtual. This is a fundimental pitfall. If it is written in C++ it could not be used to derive a type or override a virtual unless some C++ mechanisms are not used. As a writer of the C++ wrapper for gtk+, I can testify to the difficulty. The only way it can work is if the data structures are shared and the front end is written by a code generator for both (thus allowing for both to make good use of their language features.)
Thus the "best" C kit and the "best" C++ kit may not be the same thing. Therefore, one side would have to settle for a downgraded functionality.
Personally, I don't think either gtk+ or Qt are perfect even in their own languages and therefore there may be room for such a kit. However, switching to it would involve converting thousands of lines of code and debating over which implementation is better for all the duplicated functionality. It would slow the progress of both kits for a long time and since the point of both is to provide a good unix desktop in the near future such a merger would hurt both.
This is just my opinion. And I would be glad if someone pointed out a good way to use derived types, multiple inheritance, exceptions and virtual overriding in a C wrapper of a C++ kit, or full use of virtual upcasting in a C++ wrapper. (I could use both.)
--Karl Gtk-- Contributor and Libsigc++ author
Re:I'm looking forward to the day they ditch X
on
Some KDE news
·
· Score: 1
Use the right tools for the job. OpenGL/Mesa which is rapidly getting built into XServers as an extension. It has most of the things you request and doesn't envolve a complete rewrite of the system.
Rather than chucking X, most improvements can be don't by extending the X protocol, or substituting replacements to the underlying system. (CORBA for X protocol for example.) That should be the direction rather than chucking out the entire very mature system. I am all for chucking the X drawing API.
It certainly is not done yet, but it really isn't all that hard to do. The Qt signal/slot implementation can be replaced entirely with libsigc++. The whole point of libsigc++ is to provide a tool to build reusable libraries with. Libsigc++ is a complete superset of Qt signal system.
Now how does this work... the old system would be removed from Qt and its replacement from Libsigc++ can be used in its place. Internally, this a bit of work depending on the number of close interactions within Qt with the signal system. It is certainly doable as a similar task is being done with Gtk-- right now to upgrade versions of signal system. This can be done to applications with a simple flex/bison program that converts the code once, rather that over and over again like MOC. They just toss out the source for MOC and use the translated source directly. Considering the code had to be preprocessor safe to start it is not a great task.
Since libsigc++ is LGPL incorperating it in this fashion is not breaking any licences and Troll Tech is able to use the modified Qt both in the free and comercial versions. Of course, it can never be as closely incorperated as another GPL project can, but it is certainly workable. GPL/LGPL projects can just directly incorperate Libsigc++ into the code base if they want and build stronger interactions to their benifit. However, I feel that it is complete enough that most projects won't have to do that.
Since some of Qt tied code is tied by the Qt types and signal system, replacing these with free pieces is of great benifit to the free software comunitee. You could then take a piece without having to keep it linking back to Qt. Reuse is our strength and libsigc++ was built to encourage that reuse by making library callbacks very easy to do. (Not that Qt under the new license is all that restrictive, but it is not directly GPL compatable which the new piece is.)
This of course will have to wait til Qt 2.2 or something when the KDE developers have time to make the changes. It is not a feature of Qt 2.0, because libsigc++ was not even seperated from Gtk-- til after Qt 2.0 went to Beta! As fundemental as the signal/slot implementation is to Qt, to applications it was only just another API.
The way I see it, this situation basically boils down to this--either a.) the two projects merge and we have a unified code-base, b.) the two projects do not merge, but cooperate closely with each other so that they are more or less completely compatible, or c.) they cooperate somewhat, but not very much(like now) and the two remain partially, but not wholly, compatible.
I believe that (a) is strictly out. The projects are built on different philosophies on how everything should work. One wants C and other C++. One intends to be strictly LGPL while the other tends toward GPL. Both sides seem to want the other to give up their widget sets. Talking to both, I think hell will freeze over first. Unless some super kit comes allong that is far better than both and it equally usable for both C and C++, it is not going to happen.
Therefore, it will always be (b) or (c). The best hope is that CORBA will saturate the 2 frameworks and thus the interoperablity comes down to the API which they are working on. This of course means more of (c) the most likely outcome. Since the underlying technology (different widgets sets, different framework libraries) is so different, they will most likely just share some compatablity between file formats and such. But at that level the user will always need both library sets installed for the user to run applications from both under one desktop.
Of course, I don't really mind that solution as long as it doesn't bloat them both out as you mentioned. The simplest workable solution should be the one that they adopt. I feel a continued competition between the desktops is good to inspire inovation (unlike those who feel it a waste of effort.)
Asside from this development, there has also been some talk on irc between members of the KDE crew and myself on sharing the signal/slot implementation between Gtk-- and Qt. Although the meeting was slightly dampened by my over competive nature, it generally ended with a positive step towards working together. This would further interopablity between KDE and GNOME by allowing the KDE C++ code and C++ GNOME code to share library elements that do not depend on the widget sets.
Sharing of signal/slot implementations would benifit KDE by removing the MOC preprocessor and improve the flexiblity of their signal/slots. GNOME will get the benifit that KDE libraries and applications will be less tied to Qt and thus more easily reused. Since libsigc++, the Gtk-- signal system, is a close translation of the capablities of gtk+ signal system, this should also reduce the burden of programmers trying to understand the two kits. For projects with multiple frontends, this would be a great help.
Unfortunately, this development is not set to be planned until after the summer when the KDE people start a developers cut of Qt. Assuming that people are interested I can give some directions as to how the translation can be made, but I don't have time to work on it heavily myself. (Preliminary specifications have already been sent to Mosfet.) I can mail more info to other interested programmers.
--Karl
Re:Quality product? (buahaha)
on
qt 2.0 released
·
· Score: 1
Boy, we really pulled the zealots out of the woodwork today!
First of all just because A exists doesn't mean that B is {useless, unjustified, worthless,...}. There is always room for two competing products. Without such competition progess slows and stagnates (refer to Microsoft). Saying "GNOME works, there is no justification for KDE anymore" is exactly the same logic that someone used to tell me that Gtk-- wasn't needed because Qt existed. Qt does not exclude gtk+, KDE does exclude GNOME. There can be coexistance.
Second, templates can be used as a strength to make code much, much better. On the other hand it can be used to blow both legs clean off. It can produce faster and smaller code then C. On the other hand one can produce large, slower more bloated code with it. Does that mean it is bad? No. The irony of this is that gtk+ uses macros like templates more that Qt uses templates at all! (there are only 16 templates in all of Qt.)
--Karl
Re:The *authors* think gtk-- is not ideal for C++
on
qt 2.0 released
·
· Score: 1
The *authors* think gtk-- is not ideal for C++
Who? I am one of the main authors, go look on the authors pages. If you are referring to Guillaume Laurent comments, I suggest you go back and reread. He said that all wrappers have problems with maintainablity and that they don't solve all the problems. Neither of these imply the Gtk-- can't be a good C++ widget set. Only that there are problems that must be addressed.
Signal/Slots are just a tiny little part of a GUI toolkit.
Huh, whenever someone points out the great features of Qt they always place the signal/slot mechanism as one most the important features. I consider the intergration of printing and drawing systems to be a close second. The fact that I call my system a callback framework insulted some of the KDE developers. (Signal is too overloaded already.) So it is a very important piece. Without signal/slots most of the ease of use goes out the window.
As far as all these users, how many real apps are written in Gtk--?
As with any free kit, who knows! Unless people mail you saying we use this or place that fact prominently on their web site, there is no way to know. Since I released the libsigc++, I have only now discovered that 4 projects were using the old Gtk-- signal system (without Gtk--) in their projects. Had they not mailed me with comments, I would likely have never known unless I sat down to compile one of them.
Do you seriously think that all projects which compete with a more mature product are a waste of time?
Where in my message did I say "our software stinks " -- IT DOESN'T. I said if the user dislikes the other so much and feels ours needs improving, why doesn't he come to help. Obviously, any distiction is lost on you.
Second, we have a large number of users so obviously it does stink all that much. The reason for writing free software is in general dissatisaction with what is currently available, something the first author was obviously expressing. Or because writting code is fun and enjoyable hobby, certainly that is my reason. Or perhaps that not everyone is going to stop using gtk+ tomorrow and some people would just as well use C++ with the gnome framework.
Personally, I find the Qt signal system to be poor compaired to what is possible. It lacks the flexibly of a full callback system and requires a code generator to parse the code. Both of which are definite drawbacks. And if you for some reason think that I don't know what I am talking about go visit my comparison between Qt's signal system and my own. Qt's system may be nice but one can do far better. (Of course one peice does not the whole make.) They can certainly turn arround tomorrow and use libsigc++ in Qt, of course that only proves my point that people should always be working on alternatives.
--Karl
Re:Debian and KDE, the current situation (IIRC)
on
qt 2.0 released
·
· Score: 1
I hadn't heard that RMS was now saying that they couldn't add an ammendment to the license. I will have to look it up.
As for dealing with modified licenses, I would look at the libraries that come with the gcc compiler. A large number of them are under the GPL (not LGPL) with the exception that they can be used with the propriatary software. The way this works (to my understanding) is that for anything other than what the extension covers it falls back to standard GPL. This would be a sensable addition to the KDE library. Thus combining KDE code (without Qt goes to GPL.) If you want to combine new GPL code into KDE, you must ask to extend the license. As a programmer, I would perfer to be asked to extend my license. Just as I am sure if Windows spliced windows code they released under some non-GPL license got spliced in.
If they don't want to rush, I understand, but the least they can do is to mark those things in dispute as such and add the waver to the rest, so this whole silly issue it at least making progress. (From what I have seen of RMS, I don't think he is going to declared Qt a system library and resolve the issue. Then again I could be wrong.)
(I am also pleased they dropped the patch requirement.)
--Karl
Re:Debian and KDE, the current situation (IIRC)
on
qt 2.0 released
·
· Score: 1
The question has never been about the intent of the KDE authors. They always intended to distribute with Qt regardless of the license. And the only way that could really work is if they put a waver in the license. (RMS said several times that the system library clause was meant for propriatary libraries on propriatary systems, not for distributing propriatary libraries on free systems!)
Thus if the KDE folks added a waver to their license everything would be fine. There in lies the problem. They can't add that waver because they don't own all the code. The borrowed some of their basic starting code from other GPL projects and linked it to Qt (which is illegal.)
There is only two ways to clean up this mess. Remove the others code, or ask permission from the authors which they took it from. Personally, I don't see why they don't do this. It can't be all that insurmountable task if someone put their mind to it. (However, some of them feel it is a none issue so they just ignore it.)
--Karl
Re:QT is free (beer) software
on
qt 2.0 released
·
· Score: 1
Gee, I was just about to point out that we finally managed to get through a single Qt thread without belittling the Gtk-- project. But the I found this. (BTW I believe wxWindows has been arround for even longer that gtk+, it is just the Gtk wrapper which is new.)
If you feel that Gtk-- is immature and poor, why don't you stop by and help mature it. We are currently in a major overhaul mode which makes much of our code autogenerated (improving the maintainablity which is the downfall of so many wrappers.) We are reintegrating it with the recently released libsigc++ library, which is a very modern C++ callback frame. It can use a lot of grunt work converting over procedures and improving the code generator.
If you can't see that the underlying language that the code is written in is irrelevent (if though is given how to make wrappers easily), then I don't see what will convince you. By the way much of the berlin code I have looked at is wrappers on the C OpenGL API. So saying things that use C are inferior hits a lot more than you know.
How it the state of the Gtk-- wrappers say anything about the signal system that is now split from it? This was part of Gtk-- and is now seperate. So I am not comparing Gtk-- to Qt (which would end up with Gtk-- getting its ass kicked.) Libsigc++ is a real toolkit and I have compared everything it has with Qt, not just one function. Class data members serve the same function in a non-string base implementation, so there is no difference there.
FUDing by association is hardly a rational argument.
What you are describing is C callbacks. Please read my glossary of terms for my callback library. You will find that I know exactly what a signal/slot is. Signal/Slot is little more than an abstraction of a Caller and a Callee, with the additional concept of multiplicity. It can be done as a simple extension of Hickey's callback model when combined with lists.
My comparison is completely fair as I was comparing a signal/slot implementation with another signal/slot implementation from the Gtk--. Both have multi-callbacks. Both have signal concept. Gtk-- skips the slot concept, but any function can be used as a slot. One just happens to be 30 times faster. Since they do the exact same thing, I can definately say although Qt is a very nice library, it is not the most efficient C++ library out there.
For independent confirmation of what I have said please read this usenet post. That user found a 25 times difference between template based (gtk--) and string based (Qt) signal/slot implementations. We have improved since then.
But you are quite capable of testing it out for yourself. Grab my library, libsigc++. I think you will be surprised by exactly how much a callback system can do. Qt was only scratching the surface.
Most efficient? My benchmarks as well as others show a very different picture. Qt's signal system is quite slow in comparison with a modern callback system, over 30 times slower. It is a good kit with a clean design and a good ease of use, but it is hardly the end all be all toolkit. (My yet unreleased benchmark page is available for review on request.)
Hopefully at some point we can all agree on a kit that truly is elegantly designed, most efficient C++ lib. Unfortunately, Qt at this time is not it. (But neither is any other C++ kit.)
We already know how to reset the telomere clock. There is an enzyme called telomerase which has a direct effect on the length of those sequences. I would be surprised if one couldn't pretreat a cell to reset this part of the clock before using it in the cloning process. (But then the researchers were hoping the enzymes were in the embreyo to erase the DNA gene memory.)
Slashdot Mirror
Then you have all the power of the gtk+ widget architecture with the convient syntax of C++. No long names, nicely mapped as STL concepts, and a tutorial.
--Karl
Of course, you should evaluate for yourself whether static linking would be a problem for your application.
--Karl Nelson, Lead Developer of Gtk--
Yes, there are bindings for gtk+ in C++, gtk--. They are located on sourceforge. They are currently finishing the last beta before releasing 1.2 which will likely ship as part of GNOME.
They may not be quite the same quality as the professional Qt toolkit, but they are useful, free, and designed to fit well with STL and C++.
--Karl Nelson, Lead Author of Gtk--
I can name a lot of traits where I think Gtk-- has done better that Qt. (I don't try to compare it to all of KDE, because that is comparing the work of 3 guys going bindings to a magnitude more.) The use of templates to form signal/slot mechanism and the embracing of STL style within the code are most often mentioned by our users. We also strive for GUI independence be not forcing out types onto the users at all if we can help it. Thus you won't find Gtk::String creaping into your non-GUI code.
If you what improvements you need to supply feedback.
--Karl Nelson, Lead Gtk-- Developer
--Karl
Far better is to use some preprocessor which is not even included in the language. For example choose some obscure preprocessor whose notation is in direct conflict with internals of the language. This causes the source code to become meaningless programmers. Then write long procedures into macros and construct them into massive unformated and unreadable procedures. If you are really good, have the macros change throughout the code or perform different functions depending on hidden arguements. Redefine keywords to match macro definitions so that you can't tell the difference between the preprocessor and language. I can personally recommend m4 for the task.
--Karl
Most people have a good clue what the first 18 are. You can name up to half a class C with it. It is unique enough that each person can remember the names of machines without confusion. It has little sexual bias or other connotations, unlike series like authors and inventors in which you may end up picking too many males and be accused of sexist names. There are a reasonable number of really cool sounding element names in the series, unlike trees. They sound reasonably professional.
--Karl
If you could comment more on what you find annoying about programming in Gtk--, I would be glad to hear it. We are working to complete version 1.2 very soon now with improved speed, features, and documentation. Any feedback would be greatly appreciated.
--Karl
The development version should be considerably faster as all the hash table lookups were eliminated and all the excess size (often many K) of signal stuffs has been eleminated. If you still find it slow (compared to gtk+ as I can't fix stuff outside my layer), please send me a demo program and I will mark it as a hot spot to do optimization. Thanks in advance.
--Karl
Creating a "universal kit" which functions perfectly in C and C++ is not very likely. If one starts a code base in C, it will not be able to use some of the C++ features like static casting to get a particular virtual. This is a fundimental pitfall. If it is written in C++ it could not be used to derive a type or override a virtual unless some C++ mechanisms are not used. As a writer of the C++ wrapper for gtk+, I can testify to the difficulty. The only way it can work is if the data structures are shared and the front end is written by a code generator for both (thus allowing for both to make good use of their language features.)
Thus the "best" C kit and the "best" C++ kit may not be the same thing. Therefore, one side would have to settle for a downgraded functionality.
Personally, I don't think either gtk+ or Qt are perfect even in their own languages and therefore there may be room for such a kit. However, switching to it would involve converting thousands of lines of code and debating over which implementation is better for all the duplicated functionality. It would slow the progress of both kits for a long time and since the point of both is to provide a good unix desktop in the near future such a merger would hurt both.
This is just my opinion. And I would be glad if someone pointed out a good way to use derived types, multiple inheritance, exceptions and virtual overriding in a C wrapper of a C++ kit, or full use of virtual upcasting in a C++ wrapper. (I could use both.)
--Karl
Gtk-- Contributor and Libsigc++ author
Rather than chucking X, most improvements can be don't by extending the X protocol, or substituting replacements to the underlying system. (CORBA for X protocol for example.) That should be the direction rather than chucking out the entire very mature system. I am all for chucking the X drawing API.
--Karl
Just save him the search and go here.
Now how does this work... the old system would be removed from Qt and its replacement from Libsigc++ can be used in its place. Internally, this a bit of work depending on the number of close interactions within Qt with the signal system. It is certainly doable as a similar task is being done with Gtk-- right now to upgrade versions of signal system. This can be done to applications with a simple flex/bison program that converts the code once, rather that over and over again like MOC. They just toss out the source for MOC and use the translated source directly. Considering the code had to be preprocessor safe to start it is not a great task.
Since libsigc++ is LGPL incorperating it in this fashion is not breaking any licences and Troll Tech is able to use the modified Qt both in the free and comercial versions. Of course, it can never be as closely incorperated as another GPL project can, but it is certainly workable. GPL/LGPL projects can just directly incorperate Libsigc++ into the code base if they want and build stronger interactions to their benifit. However, I feel that it is complete enough that most projects won't have to do that.
Since some of Qt tied code is tied by the Qt types and signal system, replacing these with free pieces is of great benifit to the free software comunitee. You could then take a piece without having to keep it linking back to Qt. Reuse is our strength and libsigc++ was built to encourage that reuse by making library callbacks very easy to do. (Not that Qt under the new license is all that restrictive, but it is not directly GPL compatable which the new piece is.)
This of course will have to wait til Qt 2.2 or something when the KDE developers have time to make the changes. It is not a feature of Qt 2.0, because libsigc++ was not even seperated from Gtk-- til after Qt 2.0 went to Beta! As fundemental as the signal/slot implementation is to Qt, to applications it was only just another API.
Hope this clears things up a bit.
--Karl
I believe that (a) is strictly out. The projects are built on different philosophies on how everything should work. One wants C and other C++. One intends to be strictly LGPL while the other tends toward GPL. Both sides seem to want the other to give up their widget sets. Talking to both, I think hell will freeze over first. Unless some super kit comes allong that is far better than both and it equally usable for both C and C++, it is not going to happen.
Therefore, it will always be (b) or (c). The best hope is that CORBA will saturate the 2 frameworks and thus the interoperablity comes down to the API which they are working on. This of course means more of (c) the most likely outcome. Since the underlying technology (different widgets sets, different framework libraries) is so different, they will most likely just share some compatablity between file formats and such. But at that level the user will always need both library sets installed for the user to run applications from both under one desktop.
Of course, I don't really mind that solution as long as it doesn't bloat them both out as you mentioned. The simplest workable solution should be the one that they adopt. I feel a continued competition between the desktops is good to inspire inovation (unlike those who feel it a waste of effort.)
--Karl
Sharing of signal/slot implementations would benifit KDE by removing the MOC preprocessor and improve the flexiblity of their signal/slots. GNOME will get the benifit that KDE libraries and applications will be less tied to Qt and thus more easily reused. Since libsigc++, the Gtk-- signal system, is a close translation of the capablities of gtk+ signal system, this should also reduce the burden of programmers trying to understand the two kits. For projects with multiple frontends, this would be a great help.
Unfortunately, this development is not set to be planned until after the summer when the KDE people start a developers cut of Qt. Assuming that people are interested I can give some directions as to how the translation can be made, but I don't have time to work on it heavily myself. (Preliminary specifications have already been sent to Mosfet.) I can mail more info to other interested programmers.
--Karl
First of all just because A exists doesn't mean that B is {useless, unjustified, worthless, ...}. There is always room for two competing products. Without such competition progess slows and stagnates (refer to Microsoft). Saying "GNOME works, there is no justification for KDE anymore" is exactly the same logic that someone used to tell me that Gtk-- wasn't needed because Qt existed. Qt does not exclude gtk+, KDE does exclude GNOME. There can be coexistance.
Second, templates can be used as a strength to make code much, much better. On the other hand it can be used to blow both legs clean off. It can produce faster and smaller code then C. On the other hand one can produce large, slower more bloated code with it. Does that mean it is bad? No. The irony of this is that gtk+ uses macros like templates more that Qt uses templates at all! (there are only 16 templates in all of Qt.)
--Karl
Who? I am one of the main authors, go look on the authors pages. If you are referring to Guillaume Laurent comments, I suggest you go back and reread. He said that all wrappers have problems with maintainablity and that they don't solve all the problems. Neither of these imply the Gtk-- can't be a good C++ widget set. Only that there are problems that must be addressed.
Signal/Slots are just a tiny little part of a GUI toolkit.
Huh, whenever someone points out the great features of Qt they always place the signal/slot mechanism as one most the important features. I consider the intergration of printing and drawing systems to be a close second. The fact that I call my system a callback framework insulted some of the KDE developers. (Signal is too overloaded already.) So it is a very important piece. Without signal/slots most of the ease of use goes out the window.
As far as all these users, how many real apps are written in Gtk--?
As with any free kit, who knows! Unless people mail you saying we use this or place that fact prominently on their web site, there is no way to know. Since I released the libsigc++, I have only now discovered that 4 projects were using the old Gtk-- signal system (without Gtk--) in their projects. Had they not mailed me with comments, I would likely have never known unless I sat down to compile one of them.
Do you seriously think that all projects which compete with a more mature product are a waste of time?
--Karl
Second, we have a large number of users so obviously it does stink all that much. The reason for writing free software is in general dissatisaction with what is currently available, something the first author was obviously expressing. Or because writting code is fun and enjoyable hobby, certainly that is my reason. Or perhaps that not everyone is going to stop using gtk+ tomorrow and some people would just as well use C++ with the gnome framework.
Personally, I find the Qt signal system to be poor compaired to what is possible. It lacks the flexibly of a full callback system and requires a code generator to parse the code. Both of which are definite drawbacks. And if you for some reason think that I don't know what I am talking about go visit my comparison between Qt's signal system and my own. Qt's system may be nice but one can do far better. (Of course one peice does not the whole make.) They can certainly turn arround tomorrow and use libsigc++ in Qt, of course that only proves my point that people should always be working on alternatives.
--Karl
As for dealing with modified licenses, I would look at the libraries that come with the gcc compiler. A large number of them are under the GPL (not LGPL) with the exception that they can be used with the propriatary software. The way this works (to my understanding) is that for anything other than what the extension covers it falls back to standard GPL. This would be a sensable addition to the KDE library. Thus combining KDE code (without Qt goes to GPL.) If you want to combine new GPL code into KDE, you must ask to extend the license. As a programmer, I would perfer to be asked to extend my license. Just as I am sure if Windows spliced windows code they released under some non-GPL license got spliced in.
If they don't want to rush, I understand, but the least they can do is to mark those things in dispute as such and add the waver to the rest, so this whole silly issue it at least making progress. (From what I have seen of RMS, I don't think he is going to declared Qt a system library and resolve the issue. Then again I could be wrong.)
(I am also pleased they dropped the patch requirement.)
--Karl
Thus if the KDE folks added a waver to their license everything would be fine. There in lies the problem. They can't add that waver because they don't own all the code. The borrowed some of their basic starting code from other GPL projects and linked it to Qt (which is illegal.)
There is only two ways to clean up this mess. Remove the others code, or ask permission from the authors which they took it from. Personally, I don't see why they don't do this. It can't be all that insurmountable task if someone put their mind to it. (However, some of them feel it is a none issue so they just ignore it.)
--Karl
If you feel that Gtk-- is immature and poor, why don't you stop by and help mature it. We are currently in a major overhaul mode which makes much of our code autogenerated (improving the maintainablity which is the downfall of so many wrappers.) We are reintegrating it with the recently released libsigc++ library, which is a very modern C++ callback frame. It can use a lot of grunt work converting over procedures and improving the code generator.
If you can't see that the underlying language that the code is written in is irrelevent (if though is given how to make wrappers easily), then I don't see what will convince you. By the way much of the berlin code I have looked at is wrappers on the C OpenGL API. So saying things that use C are inferior hits a lot more than you know.
--Karl Nelson
FUDing by association is hardly a rational argument.
-Karl
My comparison is completely fair as I was comparing a signal/slot implementation with another signal/slot implementation from the Gtk--. Both have multi-callbacks. Both have signal concept. Gtk-- skips the slot concept, but any function can be used as a slot. One just happens to be 30 times faster. Since they do the exact same thing, I can definately say although Qt is a very nice library, it is not the most efficient C++ library out there.
For independent confirmation of what I have said please read this usenet post. That user found a 25 times difference between template based (gtk--) and string based (Qt) signal/slot implementations. We have improved since then.
But you are quite capable of testing it out for yourself. Grab my library, libsigc++. I think you will be surprised by exactly how much a callback system can do. Qt was only scratching the surface.
--Karl
Hopefully at some point we can all agree on a kit that truly is elegantly designed, most efficient C++ lib. Unfortunately, Qt at this time is not it. (But neither is any other C++ kit.)
--Karl
Here are some links for more information.
--Karl