| |||||||||||||
A GNOME 3.0 planA GNOME 3.0 planPosted Apr 2, 2009 19:38 UTC (Thu) by nix (subscriber, #2304)In reply to: A GNOME 3.0 plan by Cyberax Parent article: A GNOME 3.0 plan
I far prefer Qt to Gtk, but even so your arguments are specious.
Your 'benchmark' is two entirely different applications, so the speed differences could be (and probably are) due to implementation differences completely unrelated to the choice of toolkit.
And your microbenchmark compares something that uses OpenGL (thus hardware
(Log in to post comments)
A GNOME 3.0 plan Posted Apr 2, 2009 20:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Yes, it's hard to find a real-world comparison for QT and GTK. I just gave one example of a QT program which works fast enough.
"And your microbenchmark compares something that uses OpenGL (thus hardware
That's not the point of my argument. QT can use accelerated OpenGL tesselation (it can draw complex curves and polygons with hardware acceleration), but Cairo can't do it. Architecture of QT right now is simply much better.
For example: http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-...
"Again, unrelated to
Cairo is not a part of GTK, but GTK uses it draw majority of widgets
A GNOME 3.0 plan Posted Apr 2, 2009 21:25 UTC (Thu) by drag (subscriber, #31333) [Link]
But anyways saying "x application starts up in one second" and "y takes 30 seconds" is completely and utterly useless. It is just so worthless it is not even worth the time it takes for me to type this. Well, just barely.
Well not any more.
Well anyways. What I am saying is that you take a pure Gnome or Pure GTK desktop and have it perform X number of tasks and run for X number of minutes.. record the statistics, then do the same thing with KDE. It isn't that difficult, but any time I see it done it is never really conclusive. I've seen benchmarks comparing XFCE vs KDE vs Gnome and depending on the user's requirements XFCE used several dozen less megs of RAM to several dozen more megs of RAM compared to KDE or Gnome doing the same tasks.
Then after you compare KDE and Gnome you can then go onto explain why LXDE kicks the ever living crap out of both in terms of speed and resource usage and yet still uses GTK.
What does seem conclusive is the amount of features you have the amount of resources that is used up increases. It does not matter what language your using. The more the software does the more it is going to use up doing that.
In fact the benefits of C++ over C for the sake of having a object oriented language is so dubious at this point it's just silly getting into these language wars. C++ was written in C. There is nothing at all that you can do in C++ that you cannot do just as effectively in C. Saying otherwise is just rubbish. Any good programmer is perfectly and 100% capable of writing programs in a pure object oriented manner using C language.
The _REAL_ difference, then, between the two languages then is the amount of time and effort that you save in using C++ over C.
So that is the metric that you really need to look into. If your starting a new program then that is something that you should look into in a huge way, I mean it would be silly to start a new project in C if you needed a usable product in the foreseeable future if you thought that C++ was more efficient language.
Seeing how GTK exists in C right now, and it is already written, then I don't really see the benefit in rewriting it for the sake of using C++. Your not saving any time, your not saving any effort. In fact it would require a huge amount of effort, and years before you would even get back to the same level that you are already at.
Look at what happenned to KDE4. It has been almost FOUR YEARS since the last major KDE3 revision, 3.5... and yet KDE4 is still not up to were that was in 2005, in terms of usability and feature set. (and I am not talking about QT or KDE lib feature set, like plasma or whatever, I am talking about actually regular folks using software on it and getting work done). This was just a significant ABI/API change, not a complete rewrite or language change or anything like that.
The way things stand now is that GTK is established, it's compatible with all it's applications, it has lots of good language bindings so that people can use a multitude of different languages.
I can accept a change and getting rid of depreciated interfaces and thus abandoning compatibility with applications that have not been updated for years and years in a effort to improve usability and performance, but really I just don't see the benefit in what you guys are saying.
A GNOME 3.0 plan Posted Apr 3, 2009 4:36 UTC (Fri) by qg6te2 (guest, #52587) [Link] There is nothing at all that you can do in C++ that you cannot do just as effectively in C. Saying otherwise is just rubbish. Any good programmer is perfectly and 100% capable of writing programs in a pure object oriented manner using C language.Using the same logic one could argue that "there is nothing at all you can do in C that you can't do in assembler", including having an object oriented approach. There is a multitude of reasons why C++ exists, one of them being that much of the drudgery of handling objects is taken care of by the compiler.
There is ONE exception Posted Apr 3, 2009 6:01 UTC (Fri) by khim (subscriber, #9252) [Link] Using the same logic one could argue that "there is nothing at all you can do in C that you can't do in assembler", including having an object oriented approach. Unfortunatelly it's not true at all. Yes, you can implement OOP in assembler (heck, TASM 3.0 included a lot of OOP-oriented constructs), but in the end the acholess heel of assembler is the fact that you can not write portable program in assembler. You even may need to call functions differently under different OS with the same CPU! Thus C makes sense as "high-level-portable-assembler". There is a multitude of reasons why C++ exists, one of them being that much of the drudgery of handling objects is taken care of by the compiler. Unfortunatelly it only means you must fight the compiler tooth and nail to make it produce somewhat sane code. Take a look on this and compare it with the same things in sane languages (Java or even GObject - even if it's not language it's must easier to make it do what you want and not what it wants).
There is ONE exception Posted Apr 3, 2009 6:16 UTC (Fri) by qg6te2 (guest, #52587) [Link] Unfortunatelly it only means you must fight the compiler tooth and nail to make it produce somewhat sane code. Take a look on this and compare it with the same things in sane languages (Java or even GObject - even if it's not language it's must easier to make it do what you want and not what it wants).I'm not sure about "fighting the compiler tooth and nail". If one does that, it generally means one is fighting against the language rather than using it properly. Any language can be abused, and C++ is no exception. Furthermore, the link provided above leads to much Qt-specific code, which shouldn't be equated with all of C++ code. Qt has far more specific idiosyncrasies than gtkmm, for example.
There is ONE exception Posted Apr 3, 2009 13:06 UTC (Fri) by nix (subscriber, #2304) [Link]
Actually, most of the stuff in that link is about not violating the
compiler's invariants regarding class definitions that change. As this is technically a violation of the One Definition Rule in the C++ Standard, it's unsurprising that it's a bit of a nest of snakes... but you come across *exactly the same problem in C* if you have a system that makes heavy use of structures and you want to change some of them without recompiling all their users. The rules just *look* odder because the structures are automatically built for you by the compiler: if you had to build them by hand, *all the same issues would arise anyway*.
There is ONE exception Posted Apr 3, 2009 15:07 UTC (Fri) by cybernytrix (guest, #5727) [Link]
If you see how QT throws away almost everything C++ provides and it reinvents all these:
1. Why do you need MOC? Debugging is a royal pain! 2. Why doesnt it use C++ strings? 3. Why do you need to implement introspection? Isnt C++ "high level" to provide this. 4. STL??? So on... GTK and GObject arguably does the same. What is the point of using C++ when your toolkit simply does not use many language features and invents a whole lot of crap? Qt is a fine library and now it is even licensed as LGPL. The only feature of C++ they seem to be actively using is automatic calling of destructors and exceptions. Why bother with C++ for just these?
There is ONE exception Posted Apr 3, 2009 15:24 UTC (Fri) by boudewijn (subscriber, #14185) [Link]
1) No, actually not. Debugging is painless -- at least, that's my experience over the past ten years.
2) Because they aren't half as poweful as QStrings. 3) No, C++ isn't highlevel enough. 4) All Qt container classes are compatible with the STL.
And about the features of C++ Qt uses... Well, that was just silly hyperbole, right, not an honest
A GNOME 3.0 plan Posted Apr 3, 2009 14:39 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Plans to release GTK sometime next year are complete fantasies. It's also going to take several years (remember GTK1 -> GTK2 migration). In this aspect it won't be much different from QT3 -> QT4 migration.
I'll even make a prediction: by the time GNOME3 is released, it will be in the process of being abandoned in favor of KDE.
KDE4 was not just a significant ABI/API change, it was a major rewrite of most of parts of software. KDE 4.2 is fairly feature-complete now, with lots of new features compared to KDE 3.5.10.
On the other hand, you can count on GNOME to remove few features just to be "less confusing" to user.
A GNOME 3.0 plan Posted Apr 3, 2009 21:53 UTC (Fri) by drag (subscriber, #31333) [Link]
A. Gnome 3.0 is not going to be a nearly as significant of a change as GTK1 to GTK2 or from KDE3/QT3 to KDE4/QT4. It'll be a revamp of some UI features and depreciation of old features in a effort to remove dependencies and improve performance.
B.If QT is good and it is using C++ then what is the point to having two QTs? Why not just use KDE instead of Gnome? Why not just get rid of Gnome altogether if you think it should be all C++ or that it should be QT.. you already have everything you want, right?
A GNOME 3.0 plan Posted Apr 4, 2009 18:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
A) It's better be significant or GNOME is going to lose to Windows 7 and KDE4.
B) I would just throw out all GTK code right now If I could. But of course, there's just too much legacy code in GTK. So it's better to provide a clean migration path from GTK to QT.
A GNOME 3.0 plan Posted Apr 5, 2009 3:58 UTC (Sun) by Ze (guest, #54182) [Link]
>>B.If QT is good and it is using C++ then what is the point to having two QTs? Why not just use KDE instead of Gnome? Why not just get rid of Gnome altogether if you think it should be all C++ or that it should be QT.. you already have everything you want, right?
How about because QT is nearly as hacky as GTK+? Some of us would like a nice C++ library that uses standard libraries (or boost) and not some Hack that relies on Macro's and throws away type safety.
A GNOME 3.0 plan Posted Apr 5, 2009 3:50 UTC (Sun) by Ze (guest, #54182) [Link]
>>Seeing how GTK exists in C right now, and it is already written, then I don't really see the benefit in rewriting it for the sake of using C++. Your not saving any time, your not saving any effort. In fact it would require a huge amount of effort, and years before you would even get back to the same level that you are already at.
Yes it'd be more work to rewrite the library than to use the existing one but that is always true. The whole point is that GTK+ is a horrible hack to write object oriented code in it. It takes far longer than using gtkmm and that is only slightly less ugly.
The fact is that c shouldn't be the implementation language ,it should be just another binding.
Ideally we'd end up with a C++ as the implementation language with bindings for other languages and GTK+ v2 compatibability library.
C as OO Posted Apr 5, 2009 6:20 UTC (Sun) by quotemstr (subscriber, #45331) [Link]
While it's true that writing OO code longhand in C might take up more characters than the same program written in C++, most of the time we spend coding isn't spent typing. The difference is immaterial. Personally, I'd prefer C++, but there's something to be said for writing in the linga franca, C.
C as OO Posted Apr 6, 2009 1:07 UTC (Mon) by Ze (guest, #54182) [Link]
>>While it's true that writing OO code longhand in C might take up more characters than the same program written in C++, most of the time we spend coding isn't spent typing. The difference is immaterial. Personally, I'd prefer C++, but there's something to be said for writing in the linga franca, C.
It's got a lot more to do than just the typing. It's all the type safety and general model. GObject is a PITA and deserves to die a quick death (to save the rest of us poor souls from using it).
|
|||||||||||||