| |||||||||||||
A GNOME 3.0 planA GNOME 3.0 planPosted Apr 2, 2009 15:49 UTC (Thu) by qg6te2 (guest, #52587)In reply to: A GNOME 3.0 plan by Cyberax Parent article: A GNOME 3.0 plan
Moving wholesale to QT may not be the best idea. It's a nice toolkit in many ways, but it also feels like it's pretending to be an operating system. A more useful question for Gnome would be the wider adoption of C++. While it can be argued that C++ presents a somewhat larger barrier to entry than C, the payoffs in terms of increased productivity cannot be underestimated. Speaking from personal experience, moving from coding directly with GTK+ to using the gtkmm wrapper was an eye opener. Our code shrunk by a factor of two, while also becoming more readable.
(Log in to post comments)
A GNOME 3.0 plan Posted Apr 2, 2009 16:09 UTC (Thu) by drag (subscriber, #31333) [Link]
Well, like you pointed out, you can already do C++ in Gnome in the form of GTKmm bindings.
While C++ is not a 'official' language for Gnome it does end up getting used in a lot of Gnome-related stuff. Abiword, I am told, does C++ and is part of Gnome Office.
The 'official', or maybe better called 'Tier 1', languages for Gnome right now, as in the stuff that Gnome ships with by default, are going to be C, Python, and C#. Then there is a Gnome-specific language being created called Vala.
Of course bindings for other languages are avialable, like Java or Ruby.
The advantage to maintaining the low-level stuff in Gnome as C is that, well, C is can be made to be very fast and thus work is on the low level in terms of optimization and memory usage will extend greatly and affect all Gnome applications (so it is time well spent compared to the typical time spent on full sized C-only applications). Maybe more importantly, it is (relatively) easy to use C to create bindings for most other popular languages. It is still possible to do it for C++, but I think (in my very limited experience) that it is not nearly as nice especially during the compalation process. The third possible benefit to sticking with C is that your dealing with a mature code base with lots of years worth of bug chasing and optimizations.
Feel free to disagree, of course. It's not like I am a expert on the subject. This is all just a impression I get.
A GNOME 3.0 plan Posted Apr 2, 2009 17:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
QT is now actually _faster_ than GTK and eats less memory. And Vala and C# are just another ways to leak memory.
A GNOME 3.0 plan Posted Apr 2, 2009 19:12 UTC (Thu) by drag (subscriber, #31333) [Link]
> QT is now actually _faster_ than GTK and eats less memory.
Really? Got numbers? I keep people saying this and they have lots of nice micro benchmarks and whatnot.. but I never really seen a fair comparision of memory usage under real-world situations. (and no fair including applications like Firefox or OO.org.. they are not Gnome apps.)
Anyways (assuming that is true) just because QT is faster then GTK does not mean that GTK rewritten in C++ is going to be faster then GTK written in C.
A GNOME 3.0 plan Posted Apr 2, 2009 19:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Real world usage...
Well, for example QT Creator launches in less than a second on my computer (from a hot cache) and is very snappy. Anjuta on the other hand, works noticibly slower.
As for microbenchmarks - compare QT tesselator which supports OpenGL and software-only Cairo.
Of course, it's possible to write large projects in C. But in case of GNOME they are now just re-inventing the wheel, trying to create objective language on top of C.
A GNOME 3.0 plan Posted Apr 2, 2009 19:38 UTC (Thu) by nix (subscriber, #2304) [Link]
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
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).
A GNOME 3.0 plan Posted Apr 5, 2009 10:36 UTC (Sun) by oak (subscriber, #2786) [Link]
> Well, for example QT Creator launches in less than a second on my
computer (from a hot cache) and is very snappy. Anjuta on the other hand, works noticibly slower.
Without any info about your test setup, this comment is completely
[1] Many distros setup KDE to force some horrible Qt theme on Gtk. I.e.
> As for microbenchmarks - compare QT tesselator which supports OpenGL and
Cairo uses Xrender which can also be HW accelerated (due to complexity of
Cairo and GL also have different targets. Cairo aims for re-producible
A GNOME 3.0 plan Posted Apr 5, 2009 12:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
QT Creator does not depend on any KDE software. It's completely self-contained. It used GTK theme which is the default theme on QT 4.5 when running in GNOME environment.
Of course, Anjuta was launched from a hot cache too, without any heavy background processes, etc.
X Server uses proprietary NVidia drivers, but I don't think it makes any difference. I've just retried it with NV driver (no acceleration at all) and there's no difference.
Cairo can use XRender (and OpenGL for that matter) only for compositing, it can't accelerate tesselation and curve drawing. QT also can use slower software renderer if you want quality.
A GNOME 3.0 plan Posted Apr 2, 2009 19:17 UTC (Thu) by me@jasonclinton.com (subscriber, #52701) [Link]
That's some unsubstantiated FUD if I've ever seen it.
A GNOME 3.0 plan Posted Apr 5, 2009 7:45 UTC (Sun) by jengelh (subscriber, #33263) [Link]
The effort of moving from gtk to gtkmm, I would catiously say, is as big as having moved to any other C++ toolkit (± a few per-toolkit subtleties).
I pray wxWidgets, because I can switch underlying toolkits as I like (currently it seems like just a recompilation of the end-user program away). Now if there was a wxQt, you would get world domination as a bonus. I wonder whether anything will be done in that direction, because GNOME left a bad mark when Linus flamed it years ago for the interface doctrine.
|
|||||||||||||