Linked by Thom Holwerda on Sat 14th Feb 2009 12:55 UTC
Thread beginning with comment 348963
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
More News »
Sponsored Links



Member since:
2008-12-26
Not to mention how coding for QT is just plain UGLY compared to objective-c, vala, c#, or pretty much anything else I can think of, well maybe, MFC is almost as bad as QT.
Qt code actually flows really well - I wouldn't call it ugly at all. It's a telling fact that PyQt ui code is not all too different C++ Qt ui code (to the point where PyQt documentation is pretty much a copy of the Qt documentation). Managing that in "writing to the metal" language like C++ is no mean feat.
The alternatives you present are proprietary/specialized languages for a small target group (ok, C#'s target group is large but still limited mostly to one segment of computing, Windows), while C++ is a standardized "universal" language that delivers pretty much the best performance on all platforms.
Regarding the choice of Gtk for chrome - the toolkit choice doesn't really play a big part here, it will use Chrome's custom stuff for almost everything. It's mostly about file selection dialog & the likes. I believe this is the same situation with Firefox and OOo.