Intel Dev: GTK's Biggest Problem, and What Qt Does Better

Freshly Exhumed writes "Phoronix has an article about how Dirk Hohndel of Intel's Open-Source Technology Center has stirred the hornet's nest with a talk at Australia's Linux.Conf.Au (MP4 file) about what he views as the biggest problem with the GTK: he finds dealing with upstream GTK/GNOME developers to be tough, with frequent abuse and flame-wars, with accusations from the developers that "you're doing it wrong." Conversely, he found the Qt development community to be quite the opposite: willing to engage and help, with plenty of application developer documentation and fewer communication problems than with their GTK counterparts."

Comments

GTK is trash

[JDG1980]

I don't understand why anyone would use GTK. It's not noticeably easier to use than other toolkits. It doesn't have a "native" look and feel on any system (if you run GIMP on Windows, you'll notice how all the dialogs are much different than what you're used to seeing in other applications). It's cross-platform, but so are Qt, WxWidgets, and probably a bunch of other GUI toolkits that don't come to mind at the moment. So what's the appeal?

Re:GTK is trash

[Anonymous Coward]

pissing you off, mainly.

Re:GTK is trash

[Anonymous Coward]

Many years ago it was the only FSF-approved cross platform toolkit, so it gained a fair amount of momentum because of that. Qt has since moved to a more favorable license but a lot of people have yet to migrate.

Re:GTK is trash

[Anonymous Coward]

One word: C++.

Re:GTK is trash

[Anonymous Coward]

> It doesn't have a "native" look and feel on any system
It's a problem in some cases, and an advantage in other.

Besides, GTK looks really neat and runs quite well on the major popular linux distros, that are all using GTK3 in their own way, that's another big reason to use it.

Re:GTK is trash

[Anonymous Coward]

GTK was written (at least initially) by someone who thought they could 'code' better than anyone else so they didn't bother to use any knowledge gained from anyone else and just hacked together a windowing system based on an ugly ass application which decided any conventional user interface standards that existed were not worth following at all, regardless of reason. So instead of reusing an existing toolkit, they wrote from scratch and then pulled a toolkit out of their app and GTK was born.

Thats pretty much 100% ass backwards from the proper way to do it.

It is an example of one of the 'problems' with MOST open source projects. Doing because you can, not because you should. Sure its FAR more professional today than 10 years ago, but the legacy still holds true due to its very nature and the fact that its followers WANTED that in the first place.

GTK is for people who think its cool to run Linux because its not Windows, not for any real reason. They just want to stick it to the man!3@%! kind of thing.

--BitStream

Re:GTK is trash

[Anonymous Coward]

That was because the FSF was spreading FUD about Trolltech. Trolltech was free software friendly and was never going to make Qt non-free.

Re:GTK is trash

[Anonymous Coward]

The appeal is/used to be license. Qt was/is free beer, Gtk libre.

Re:GTK is trash

[pe1rxq]

Unfortunatly it took them years to formalize that.
Trolltech turned out to be ok, but untill you have the licenses actually reflect that you just can't be sure and it would be foolish to blindly trust them.

Re:GTK is trash

[Anonymous Coward]

The API is pure C. It's much easier to create wrappers of GTK+ library than Qt in other languages (as a replacement of Tk GUI), because C++ doesn't fit well with others.

Re:GTK is trash

[loonycyborg]

Qt and wxwidgets aren't particularly good at blending in with native apps either. Qt5 have dropped any use of native widgets beside for backwards compatibility afaik. All gui toolkits suck in different ways. Qt doesn't appeal to pure C programmers because it's C++, personally I don't particularly like it as C++ programmer because it doesn't use the language to its full potential and employs hacks like MOC. But it's the only more-or-less complete cross-platform C++ GUI toolkit atm.

Re:GTK is trash

[0123456]

It is an example of one of the 'problems' with MOST open source projects. Doing because you can, not because you should.

How's that any different from many closed source projects? I've read plenty of stories about the brain-dead misfeatures in Windows which were added just because someone thought it was a good idea.

Re:GTK is trash

[benjfowler]

Jamie Zawinski calls this the 'Cascade of Attention-Deficit Teenagers' (CADT) development model.

http://www.jwz.org/doc/cadt.html

CADT also brings us cheesy, amateur-hour user interfaces, butt-fuck-ugly skins and themes, and terrible usability.

And of course, terribly high levels of techie arrogance, inherited from old-timer UNIX neckbeards.

Re:GTK is trash

[Anonymous Coward]

Years? Less than a year and a half after the FUD started, version 2.0 released in June if 1999 was under the Q Public license which was a "free software license" just not GPL compatible. And by version 2.2 of the X11 version just a few months later it was GPLv2. So in less than 2 years any and all issues were more than solved. The only reason GTK stuck around wad ego and NIH.

Re:GTK is trash

[Desler]

And yet Qt has language wrappers for 16 different languages. Doesn't seem to be all that hard.

Re:GTK is trash

[realityimpaired]

CADT also brings us cheesy, amateur-hour user interfaces, butt-fuck-ugly skins and themes, and terrible usability.

GTK isn't inherently riddled with those problems though. I mean, yes, most of the time when you see it, it's pretty god-awful, but it *is* possible to design a UI in GTK that looks pretty good, and which has a degree of UI uniformity. Take a look at elementary OS for an example of how it's possible to do GTK right. (and yes, I realize I'm cherry-picking an example, and that it's incredibly easy to find examples of GTK done horribly horribly wrong)

Of course, to throw a little gasoline on the fire, I prefer Enlightenment... ;)

Re:GTK is trash

[znanue]

That was because the FSF was spreading FUD about Trolltech. Trolltech was free software friendly and was never going to make Qt non-free.

Licenses matter, especially for businesses. You have to know that this piece of software you want to build things around, to rely on, isn't going to be taken from you. And, you shouldn't have to be a "judge of character" for a business in order to have that security. FUD is a heavy characterization that seems to devalue the perspective of those who do feel they need to operate under license security.

Re:GTK is trash

[Kjella]

That was because the FSF was spreading FUD about Trolltech. Trolltech was free software friendly and was never going to make Qt non-free.

Qt was free on a free platform (Linux), if you wanted a Windows/Mac license then for a long time you had to pay for that priviledge. They were trying to balance being open source and making money and RMS isn't exactly known for ideological compromise. Eventually they went GPL on all platforms and later LGPL, but it also killed off most of the income Trolltech used to have. That wouldn't have been so bad if Nokia had been their sugar daddy using it as their "Android", but I really wonder if Digia can surivie as being the non-native alternative all around. After all Android uses Dalvik/Javaish, iOS and OS X uses ObjectiveC/XCode, Microsoft uses C#/.NET and Qt is essentially trying to be what Java tried to be on the desktop. And I guess we all know how many Java desktop apps we use, right? Good product, not sure it hits a market.

Re:GTK is trash

[znanue]

One would argue that many people think they can code better projects and do (Say, an unknown Finnish student in 1992). There is a ton of duplication in the software space, but that might not be a bad thing. I think it is so easy to forget that we're building things that may last centuries, millenia. Individual information problems may morph under hardware changes, but a lot of these things we're figuring out could go the distance. I hope the open source movement never loses that audacity, even if it a times it is blind, arrogant, and wrong.

Re:GTK is trash

[Chrisq]

One word: C++.

That's three!

Re:GTK is trash

[gbjbaanb]

Often its because the closed-source project doesn't leave feature decisions to developers, most of them are decided upon through user requirements.

Now Windows, that's a different beast - that's gone full circle back to where ego matters.

Re:GTK is trash

[Chrisq]

CADT also brings us cheesy, amateur-hour user interfaces, butt-fuck-ugly skins and themes, and terrible usability.

GTK isn't inherently riddled with those problems though. I mean, yes, most of the time when you see it, it's pretty god-awful, but it *is* possible to design a UI in GTK that looks pretty good, and which has a degree of UI uniformity. Take a look at elementary OS for an example of how it's possible to do GTK right. (and yes, I realize I'm cherry-picking an example, and that it's incredibly easy to find examples of GTK done horribly horribly wrong)

Of course, to throw a little gasoline on the fire, I prefer Enlightenment... ;)

The question is "in GTK projects that do look good did the developers find that they were fighting the toolkit as much as using it?". I don't know the answer but that's key - "possible to" is not enough for good interfaces to be common-place.

Re:GTK is trash

[Chrisq]

The API is pure C. It's much easier to create wrappers of GTK+ library than Qt in other languages (as a replacement of Tk GUI), because C++ doesn't fit well with others.

I think that "much easier" is an exaggeration here - its not hard to wrap an object interface with a flat "c compatible" interface.

Re:GTK is trash

[satuon]

In case you mean that's an advantage for Gtk - the next commercial Gtk app I see will be the first.

Re:GTK is trash

[hubie]

inherited from old-timer UNIX neckbeards.

Old-school UNIX guys had full beards.

Re:GTK is trash

[satuon]

Qt4 didn't use native widgets either, so Qt5 didn't 'drop' them.

Re:GTK is trash

[tibit]

Do you even know what "existing toolkits" looked like at the time? They were solid crap. I'm no fan of GTK, but man, reuse of platform-provided functionality in a multi-platform toolkit is usually something you do at the beginning and then quickly backpedal on. There is a very good technical reason why Qt comes with its own raster rendering code, its own event loop, its own containers and atomics, and a host of other things: the platform stuff, if present, is broken in its own way on each platform Qt runs on. Or, if it's not broken, the standards the platform libraries follow simply leave too much to undefined- or implementation-defined behavior to, you know, actually use in practice. For C++ standard library that may be a bit of a less of a problem with modern compilers, but remember that even Qt 4 has to compile on some very broken compilers and very quirky platforms.

Re:GTK is trash

[tibit]

The pure-C api is what makes it harder to use, because you have humans doing the work otherwise done by a C++ compiler. If that's not retarded, I don't know what is.

Re:GTK is trash

[tibit]

You're someone who doesn't value your own productivity if you resort to calling code generators hacks. It's not a hack, it's something that lets the machine do the work a machine can do, instead of forcing a human intervention in generating introspection data. Calling moc a hack is like calling a lexer or parser generator a hack. Now I'm not commenting on the quality of the moc code itself, just on the general approach of leveraging computers in all aspects of software development, not merely to run the resulting machine code.

Re:GTK is trash

[cheesybagel]

Until it was LGPLed it was problematic to use it as a system library. It would mean many commercial programs would have to pay Trolltech just to have a GUI which is not something you see in other development platforms. They only did that after they were bought by Nokia AFAIK. They would have little business otherwise.

Re:GTK is trash

[Anonymous Coward]

Oh I could go on for a very long time on the problems of GTK/GNOME/GIMP. But there a lot of "it's not my/our fault" going on there too. For example, GTK is "GiMP toolkit" not "GNOME toolkit." Why GNOME decided to use GiMP toolkit I don't know. It's an application library. And it's certainly one that doesn't well enable having multiple versions of it in the same running OS. GNOME's window managers use GTK. What happens when you want to use CentOS (which uses an older version of GTK) and a current version of GiMP?? It doesn't work. You can compile your own dependency libraries but it becomes a deep, deep rebbit hole to dig through and when you do, you will find that even after all that, the window decorations don't work which makes the program look really strange.

Had GNOME "forked" GTK, then everything would be okay. But they didn't. So the wrongness of the situation really comes to light when running under this particular and fairly common configuration.

Is it GiMP's fault? No. The library is for GiMP even though the GTK project has spun off on its own now but they didn't care even before it did. Is it GTK's fault? Yeah, pretty much. They are very aware of how GTK is being used and they don't care. Is it GNOME's fault? Yeah, I think it is. GNOME and GTK are influenced and guided heavily through RedHat. RedHat doesn't seem interested in the problem(s).

Why GNOME/GTK/RedHat/GIMP refuses to listen to the user community is beyond me. They seem to have this "you don't like it? use something else or write your own fork!" kind of attitude. This is their game and their ball and they will play their way only. It kind of sucks really.

Re:GTK is trash

[cheesybagel]

Well GTK+ was better than Motif that's for sure.

Re:GTK is trash

[Anonymous Coward]

Not written in C++.

Re:GTK is trash

[twocows]

It's also usable in C, for what that's worth. Calling it cross-platform is a laugh, though. The last Windows version is an outdated version of an outdated version (an old version of the 2.0 branch). Granted, I haven't checked for a few months, but last I knew, the only dev working on the Windows version had abandoned it a while ago.

For my personal projects, I'm moving toward D for the backend and WxPython for the frontend where feasible. Even back when I did almost all of my projects in C, though, I never stuck with GTK. GObject and GLib seemed like decent projects, though.

Re:GTK is trash

[cheesybagel]

I like GTK+'s way of doing things better than Qts. Qts main advantage is that it is better at cross-platform and supports C++ by default. Little else.

Re:GTK is trash

[cheesybagel]

It is a hack because it does nothing useful that you could not do with later versions of ANSI C++. For whatever reason Trolltech decided they couldn't trust ANSI C++ compilers to be present on the system.

Re:GTK is trash

[jythie]

On the other hand, it is GTK is LGPL rather then GPL, which means many projects favor it for pragmatic or philosophical reasons. WxWidgets, while the license is pretty permissive, has some pretty sketchy bindings (ok, I am mostly thinking wxPython, which makes my life miserable). So GTK can be a 'best worst option'.

Re:GTK is trash

[twocows]

wxWidgets isn't particularly good at blending in with native apps? That's news to me. The whole appeal of wxWidgets is that it's entirely native. Maybe you're thinking of a different project? For what it's worth, I don't like C++ either (see my above post where I said I'm moving to D for backend, that's specifically because I can't stand C++). That doesn't mean there aren't some solid projects built in it, though. wxWidgets and Qt are both very well done and seem to have accomplished what they set out to achieve. Saying they "suck" is just wrong.

GTK does suck, though, for so many reasons. I really wanted to like GTK because I wanted a good toolkit solution I could use in C, but it's really quite terrible. On Windows, you're better off just handling the interface using the WinAPI, it's that bad (assuming you're stuck using C for the frontend for whatever reason).

Re:GTK is trash

[Anonymous Coward]

This is actually untrue. Trolltech moved to GPL years before the Nokia buy out. Having it GPL instead of LGPL also lead to issues as a system library though.

Re:GTK is trash

[Anonymous Coward]

There is nothing non-native about C++ on Android or iOS/OSX.

Re:GTK is trash

[t_hunger]

Sorry, but that is just not true: moc does add meta data on objects (their methods, properties, etc.) that is _not_ available in ANSI C++. Not even with C++11.

Re:GTK is trash

[t_hunger]

Qt on the other hand is available in LGPL, GPL or proprietary licensed form. You are free to pick whatever works best for your project. I really fail to see how GTK can be better than that on the licensing front.

Re:GTK is trash

[tibit]

You really should keep your mouth shut if you neither understand what C++ can and cannot do, and what moc actually does.

Re:GTK is trash

[angel'o'sphere]

Well,
I'm a Mac "user", that means if I have to program something running on my Mac I use Java. I don't really plan to dig into either Objective-C nor the Apple frameworks.
As I'm looking forward to write a simple App for iOS (and Oracles Java FX seems still far in the future) I strongly consider Qt.
As long as I only have to pay once and not for every sold App or Application I don't realy care about buying a commercial license. Bottom line it is only fair. However: it seems a "all platform" license is indeed very expensive!

Re:GTK is trash

[squiggleslash]

No, they were being careful. The FSF couldn't bless a project that wasn't free software, period. There were just too many dangers involved. They didn't bless Java until Java was finally released under the GPL, and it's not as if the FSF had any reason to be particularly antagonistic towards Sun, a major and early contributor to free software.

Re:GTK is trash

[cheesybagel]

Qt is LGPL now. It used to have the Q Public License, then GPL, now LGPL. They switched to GPL after they saw MySQL managed to retain profit with a GPL license and they switched to LGPL after the Nokia aquisition AFAIK.

Re:GTK is trash

[tibit]

Yep. The best the C++ standards folk has come up so far is a bunch of proposals that try to get some of moc's functionality into C++. Normal people, who have some perspective, would call moc visionary and ahead of the time (if Common LISP is ignored, of course). Clueless people, well, remain clueless. It makes me a bit happy that I could, if I were looking for work, sell myself to the employers with full knowledge that a large bunch of behind-the-times folk are proclaiming that staying less productive is somehow better. Good for me, bad for the GP :) The educator in me cringes, the employee side of me smiles.

Re:GTK is trash

[cheesybagel]

The license issues were bad enough at one point that the KDE developers themselves started developing their own OSS version of Qt called Harmony. After Trolltech made the license more open Harmony folded.

Re:GTK is trash

[squiggleslash]

In the context of X11, what, exactly, is a "native widget"?

OFFS: Slow Down Cowboy! Slashdot requires you to wait between each successful posting of a comment to allow everyone a fair chance at posting a comment. It's been 4 minutes since you last successfully posted a comment Chances are, you're behind a firewall or proxy, or clicked the Back button to accidentally reuse a form. Please try again. If the problem persists, and all other options have been tried, contact the site administrator.

Re:GTK is trash

[cheesybagel]

C++ has RTTI typeid and dynamic_cast. People usually deride MOC not only because it makes compilation loads slower but because Qt's signal and slots mechanism sucks. I personally think it is WORSE than the GTK+ signal mechanism. GTK+ doesn't need a pre-compiler either.

Re:GTK is trash

[cheesybagel]

Boost manages to do signals in C++ without a precompiler as well.

Re:GTK is trash

[AvitarX]

Not in a cross platform way, at least as I recall.

The Windows version of (Free) software used buggy ports of the Linux library.

Re:GTK is trash

[t_hunger]

Yeap. But Boost does not allow to inspect which signals/slots and properties are available on any given object.
That is the information moc generates. Signals and slots in Qt just use that information, just as a host of other things including the language bindings, some runtime debugging tools and lots of other things.

Re:GTK is trash

[savuporo]

I dont like either, but gtkmm is more C++ than Qt's SIGNAL/SLOT preprocessor

Time for a completely new take that actually uses what C++11 ( and boost bits ) have to offer

Re:GTK is trash

[cheesybagel]

MOC sucks period. You can implement all of those paradigms in C++ without the use of a pre-compiler. I mean GTK+ does it in C so you surely can do it in C++. And it doesn't take forever to compile code with it.

As for ANSI Common LISP I haven't programmed it in yonks and the reasons are usually the same. Generally shitty compilers which produce slow native code, bad GCs, fragmented support for ANSI Common LISP features, poor interfacing with C system libraries, etc.

Re:GTK is trash

[savuporo]

Exactly. Plus C++11 has given us new tools to do sig/slots way more efficiently now.

Re:GTK is trash

[caseih]

The appeal of GTK is that from a programmatic pov (and I haven't yet watched the talk so I could be wrong, but this is my experience) and API than Qt, and much much better than wx. Furthermore GTK has much better bindings in various languages than Qt, mainly because it's C-based. PyGTK (now replaced with Pyobject) is very pythonic, whereas PyQt is really just C++ transliterated to Python.

GTK's biggest problems come from trying to develop new GTK objects in C. A ton of boiler plate code. But nowadays you can use Vala to generate gobject-derived classes and compile them to straight C.

I rarely use GTK from C these days at all, though. I prefer to use Python, C++, C#, or Vala if I need to be down at the C level.

Though I prefer GTK from a programmer's point of view, I will be choosing Qt in the future for projects that matter. Much better cross-platform support, and the API is more stable. It's signal model is close enough to GTK that it's not a big jump, though it's packing model takes some getting used to (springs instead of packing boxes). For my own little throwaway projects in Python, I'm sticking with glade-3 and GTK.

Re:GTK is trash

[Anonymous Coward]

Until it was LGPLed it was problematic to use it as a system library. It would mean many commercial programs would have to pay Trolltech just to have a GUI which is not something you see in other development platforms. They only did that after they were bought by Nokia AFAIK. They would have little business otherwise.

Get out of here.

Re:GTK is trash

[marcosdumay]

It's not different from the many closed source projects that do the same.

It's different from QT.

Re:GTK is trash

[t_hunger]

No, GTK does not do what moc does in C.

Gobject introspection does something similar to what moc does. Gobject introspection is a code generator that reads XML files and produces code from that. Moc takes similar information right out of the header. Both use that information to generate code.

Signals/Slots in Qt just make use of that information that moc generated. Note that Qt 5 does allow you to use signals/slots without that information as well. But you still need the information moc generates for other purposes (language bindings, introspection, some debugging tools use it, etc.).

Re:GTK is trash

[CritterNYC]

The Q Public license not being GPL compatible made it mostly useless, since the GPL/LPGL was 75%+ of all open source software at that time.

Re:GTK is trash

[jbolden]

Not being GPL compatible was a problem since KDE was GPL. Debian legal was where the "FUD started" and because they had serious questions about whether any 3rd party deployment wasn't a copyright violation under the mixture of licenses. I think RMS made this much more hostile and heated than it needed to be, but let's not pretend there wasn't a serious underlying issue.

Re:GTK is trash

[s1d3track3D]

instead of reusing an existing toolkit

GIMP version 0.54 (January 1996) "It had a dependency on Motif for its GUI toolkit, which made efficient distribution to a lot of users impossible."

A New Toolkit - The 0.60 Series:
Peter got really fed up with Motif. So he decided to write his own. He called them gtk and gdk, for the Gimp Tool Kit, and the Gimp Drawing Kit. Peter tells us now that they never intended for it to become a general purpose toolkit - they just wanted something to use with GIMP, and it "seemed like a good idea at the time". GIMP History

Re:GTK is trash

[jbolden]

Digia is a consulting business that does custom work. They have a different revenue model than Trolltech. Trolltech built up IP value till they got bought. Digia is primarily selling labor.

Re:GTK is trash

[jbolden]

Why GNOME decided to use GiMP toolkit I don't know.

Because they wanted to get Gnome 1 out very fast before KDE pulled too far ahead as the standard GUI for Linux. They were under tight time pressure and starting from behind.

Re:GTK is trash

[jythie]

oops. I was actually thinking of PyQt, which does not have the LGPL option. I had forgotten that the underlying QT implementation did.

Re:GTK is trash

[bluefoxlucid]

It's not C++, so it can be used from C applications and bound to other languages more easily. C++ is a horrific language anyway; the guy who invented it says the defining characteristic of his life is shame.

Re:GTK is trash

[Anonymous Coward]

All platforms except VxWorks are available as open-source (LGPL). You don't have to pay anything if you don't want support.

Re:GTK is trash

[Mr Thinly Sliced]

I don't know if it still is - but IIRC VMWare's Linux client was GTK based.

I haven't seen any others though tbh - but I don't use a lot of commercial software on Linux.

Re:GTK is trash

[Kremmy]

Try as I might, the full beard is being suppressed by the antics of all these big corporations who are shitting on their userbase by changing their mainline products to suit a pointless agenda.

Re:GTK is trash

[flyingfsck]

The appeal? GTK is simple and it works. Nuff sed.

Re:GTK is trash

[tibit]

Qt 5 does allow you to use signals/slots without that information as well.

Not quite. Qt 5's templated QObject::connect enforces that the objects in question are valid QObjects and a signal-method call still needs the information generated by moc for the target object. This is necessary for the thread safety, at least - you don't want a random target object disappearing under you, as it would if it were non-QObject. The internal implementation also assumes that calls to slots have a valid method index, and that comes from moc-generated metadata.

If you want to call a method on a random non-QObject, you have to wrap it in a lambda, otherwise it won't compile. You also better be using a shared smart pointer, otherwise your code will have undefined behavior (likely it'll crash) as soon as the target object ceases to exist.

QSharedPointer<NotAQObject> p(foo); // foo better be a shared pointer, too!
connect(src, &SrcClass::aSignal, [=](int arg0){ p->member(arg0); });

The copy of the shared pointer embedded in the lambda-generated functor will be destroyed in src's destructor.

Re:GTK is trash

[Anonymous Coward]

Clementine, Calibre, and VirtualBox all use Qt, and they're fairly popular.

Re:GTK is trash

[Anonymous Coward]

That was because the FSF was spreading FUD about Trolltech. Trolltech was free software friendly and was never going to make Qt non-free.

Not only that, but after Qt went GPL, there was this very awkward period where free software advocates STILL advocated for GTK/Gnome even though it used a less free license than Qt/KDE.

Now Qt is available under the exact same license as GTK, so they can't even pretend there's a licensing advantage to GTK. But the FUD damage was done.

Re:GTK is trash

[Arker]

From your link: "Fixing bugs isn't fun; going through the bug list isn't fun; but rewriting everything from scratch is fun (because "this time it will be done right", ha ha) and so that's what happens, over and over again."

Yeah, Jamie hit the nail on the head with that one.

Re:GTK is trash

[Anonymous Coward]

> it's not as if the FSF had any reason to be particularly antagonistic towards Sun, a major and early contributor to free software.

Is this a joke? Have you read about sun's behavior during the unix wars?
A mixed-bag at best, openly hostile to compitition at worst, depending on your perspective.

Re:GTK is trash

[fatphil]

You must appreciate, however, that some people see '++' as a disadvantage (watch TFV for example).

Re:GTK is trash

[Anonymous Coward]

Well, currently there also this thing http://qt-project.org/wiki/New_Signal_Slot_Syntax

Re:GTK is trash

[Anonymous Coward]

LGPL was added by Nokia so you have a choice of 3 licenses: Commercial (must purchase from Digia), GPL, or LGPL.

Many that would have purchased the Commercial License (~$5k/year for all platforms) are now using the LGPL license. Some (like myself) are a bit more leary as there is no clarity on where the line between LGPL and requiring the Commercial license stands - especially since most use Qt unmodified as shared libraries (DLL, *.so).

Re:GTK is trash

[Anonymous Coward]

And, you shouldn't have to be a "judge of character" for a business in order to have that security.

Even if you could make that judgment that shouldn't set your mind at ease. Businesses can get acquired by other companies that decide to disregard "gentlemen's agreements" from previous owners/management in an effort to maximize monetization of the products you've come to rely on (*cough* Sun *cough* Java *cough*).

Re:GTK is trash

[McDutchie]

Adobe Reader and Flash for Linux are GTK-based.

Re:GTK is trash

[innocent_white_lamb]

The GCC digital cinema server, used for playing digital movies in theatres, has a GTK-based front-end for its user input such as setting up playlists, scheduling, managing the content on the server and so on.

I know because I've got one and use it every day.

Re:GTK is trash

[Anonymous Coward]

Trolltech was very Nokia (now a mickeysoft(tm) company). They are shaking every Android manufacturer down on technology that was created 15 years ago. Now that Android is starting to use different file systems, someone (perhaps Google) will start to press against their shakedown-racket patent-troll tactics. Its reasonable to avoid using QT until you know they won't come back later and after initially offering 'everything free' coming back later and shaking you down for all your profits, investments and half of everything else, and call that a down payment, and telling you that they will be back later in the week for the desks, pens and light fixtures.

Re:GTK is trash

[innocent_white_lamb]

Is it really, though?

I prefer to program in C. Not C++. Therefore, if I want a GUI I'm pretty much stuck with either motif or GTK+ and since I'm not really a huge fan of either one I avoid the issue whenever I can and try to do most of my stuff with ncurses.

However, one advantage that motif has over GTK+ is its inertia. In most cases I can compile a motif-based program that was written ten or twenty years back on an up-to-date Linux system and it will just work without modification. GTK+, on the other hand, changes so rapidly that an application written five years ago stands a really good chance of not working without modification. "Function X has been deprecated, now use function Y. Function Y has been deprecated, now use function Z and newly-added function A to do what it used to to."

Some of my software from written in the late 80's is still in use today doing things like logging oil well drilling and counting "beats" from water meters. None of that has a GUI, but it still works in the same way that it did on the first day it was installed.

C hasn't changed in any really fundamental way since the days of K&R, either. Why can't I have a long-term, slow-moving GUI framework like that, too?

Re:GTK is trash

[Anonymous Coward]

No, that's not it. Two guys were trying to build a graphics program for Linux when none existed. They wanted to build GIMP. There were *no* free graphical tool kits for Linux at the time. None. Mosaic would run on LInux, but they wanted a $6800 license fee 'up front' and a small $20,000 distribution license if you wanted to 'share' your application with anyone else. Since there was nothing, they created something from scratch (oh and if you don't like it, go ahead, write your own from scratch). It was initially callled 'Gimp Tool Kit', and they made it free so that other people could improve it. One of the first window managers that used it is called Gnome. Hindsight is 20/20, but I'm not going to knock people for putting out stuff where none existed before. It might look a bit old and crusty now, but it was a bazillion times better than what came before. Oh, and as far as GIMP and GTK are concerned, if there are things about them that you don't like, step up, the code is open, put your changesets where your mouth is.

Re:GTK is trash

[t_hunger]

That is non-sense. Trolltech was very much not Nokia!

And even if: Both Trolltech and Nokia are no longer in the game. Nokia sold the Qt trademark (along with most of the Qt devs) to Digia about two years ago. Qt was long gone when Microsoft bought Nokia.

I am still pretty sure Digia will not come after you to shake you down for all your profits. Digia is a small company (compared to Nokia at least). Heck, Digia does not even own patents AFAICT.

Re:GTK is trash

[Anonymous Coward]

Where is this list of 16 languages. How robust are the bindings?
I know PyQt / PySide are pretty feature-complete and rich but what about the others?
The Go langauge has a C interface, no C++ interface... impossible to use Qt.

Re:GTK is trash

[maxwell demon]

Well, while never having been an advocate for either side, I liked Gnome better for a long time. However, after that, the Gnome people made every effort to break everything I liked about Gnome ...

Re:GTK is trash

[sjames]

Developing a GUI toolkit to fit the needs of a non-trivial GUI program is very much a defensible choice.

You should look at the choices for cross platform GUI toolkits that were compatible with GPL software in 1996 (that is, none) before you criticize them for reinventing the wheel. Perhaps you would have preferred it be Unix only on Xaw?

Re:GTK is trash

[Anonymous Coward]

That grossly overstates the importance or impact of the Harmony project. It was not "the KDE developers" in masses recognizing a problem with the Qt licensing and rushing to create a "free" replacement. Harmony was never able to gain a critical mass of contributors because in fact most KDE developers were busy coding instead of discussing different degrees of freedom in the various open source licenses.

Re:GTK is trash

[unixisc]

Aside from that, the Harmony people at least had the sense to wind down the project once it was redundant as a result of Qt getting a more popular license.

Same thing should have happened to GNOME - once Qt became GPL, the reason to have GNOME went away. Even more so after they stopped following the mission embedded in their name - to create a Network Object Model Environment and simply tried to become a simple UI for the platform, which resulted in GNOME2. Instead, we now have a plethora of GTK based DEs - GNOME2/Mate, GNOME3, Cinnamon & XFCE. LXDE & Unity were there as well, but headed to Qt.

I like the Qt solution to DEs - KDE if one needs all the bells & whistles of a rich desktop environment, and Razor-qt if one just needs something simple. I'm guessing that one can use Qt based software like Calligra Suite on top of Razor-qt w/o any issues?

Re:GTK is trash

[Tough Love]

While there are indeed cultural issues with GTK, its biggest problem is being written in C, which lacks many facilities to support good software engineering practices, and has next to no offsetting advantages. The result is a horrible kludge of a design full of ad now hacks trying to approximate proper OOP, and a disgusting, fragile code base. Among other things, implementing reasonable defaults in a GTK program is a lot of work, whereas is mostly just happens naturally in QT, which is partly by good design and partly because C++ supports sophistated mechanisms to manage defaults.

Re:GTK is trash

[Tough Love]

What I don't understand is why Red Hat has not yet jumped off the sinking GTK ship. Ego involved?

Re:GTK is trash

[Anonymous Coward]

The appeal of GTK is that from a programmatic pov and API than Qt, and much much better than wx.

What?

Re:GTK is trash

[msobkow]

Licenses for the version of code you downloaded and used to build a product are not revocable. If the upstream provider changes the license to something non-free, you can still use the old code and maintain it yourself.

The problem is not whether Qt was under a sufficiently free license, but whether businesses could guarantee to leech off the future maintenance and enhancements. A different kettle of fish entirely.

Businesses also balked at the idea that they would have to pay for Windows licenses for the toolkit, even though the prices for Qt were eminently reasonable compared to similar cross-platform products of it's early years, such as Neuron Data's Open Interface (now shipped by Blaze Software, I think.)

Businesses are greedy. Period.

Re:GTK is trash

[Issarlk]

Also being pure C, it's much faster to compile! And that is an often overlooked advantage. My only gripe about GTK is they didn't go all the way and implement it in assembly to make development even faster.

Re:GTK is trash

[unixisc]

I don't understand why anyone would use GTK. It's not noticeably easier to use than other toolkits. It doesn't have a "native" look and feel on any system (if you run GIMP on Windows, you'll notice how all the dialogs are much different than what you're used to seeing in other applications). It's cross-platform, but so are Qt, WxWidgets, and probably a bunch of other GUI toolkits that don't come to mind at the moment. So what's the appeal?

Simple rms answer: it doesn't have to be good at all: it just has to be 'libre'. In other words, as he said about GNU here, even if GTK+ had no technical advantage over Qt, it would have a social advantage, allowing users to cooperate, and an ethical advantage, respecting the user's freedom.'

Of course, today, w/ even Qt licensed however one would like it - be it GPL, LGPL, QPL or commercial, even that's no longer an advantage. For this reason, GTK should have reverted to being the library for just GIMP, and let GNOME wither on the vine. As I noted elsewhere on this page, GNOME no longer has its original mission, and has forked so much that it's just a distraction for 'the community'

Re:GTK is trash

[umghhh]

yes I looked at that many times. With all this duplication the common part is - almost fitting commercial or open source tools have this small little thing i.e. they are not a perfect fit. They cover maybe 90% of needs leaving 10% unattended of which maybe small part but still is vital for the project. You can chose to dig into it, write new version yourself or buy commercial tools. In big corporation I worked for we did all three paths sometimes: commercial software to cover our asses in case all other options backfire, open source fixes and hacks to make transition and at the end almost always own tools - that did not fit exactly either but were good enough. For stability and high load tests that was usually a blessing because you almost always had at least two sets of tools that you could use and double amount of servers which almost always was necessary to achieve meaningful load levels in SUT.

That was my experience. ymmv of course.

Re:GTK is trash

[Anonymous Coward]

Hey, it would be great if your favorite technologies never changed or became obsolete, but if you're not willing to learn what's on the forefront, that is to say "get into the 21st century," then you're in the wrong profession.

Re:GTK is trash

[Dahamma]

Can't resist.

http://i2.kym-cdn.com/photos/images/original/000/519/368/cb9.jpg

Re:GTK is trash

[Darinbob]

Well there were those purist Linux distributions, the ones with no binary objects without source code, who refused to allow Mozilla, flashing warnings if the kernel was tainted, etc. So GTK was the politically correct choice for the true believers.

Re:GTK is trash

[Darinbob]

Trolltech grew up long before Nokia got in the picture and the licenses had settled down by then. Nokia acquired Trolltech to ensure that Qt would remain supported (an inexpensive purchase which they assumed woudl be a long term benefit back before the Windows Phone debacle).

Re:GTK is trash

[Darinbob]

So in other words, GTK not being used as a cross-platform toolkit in those cases.

Re:GTK is trash

[Tough Love]

the Harmony people at least had the sense to wind down the project once it was redundant as a result of Qt getting a more popular license.
Same thing should have happened to GNOME - once Qt became GPL, the reason to have GNOME went away.

You mean, the main reason to have Gnome went way. The other reason to have Gnome was to have a fiefdom. Red Hat wanted a fiefdom (and was willing to subsidize developers to have it) and Gnome devs wanted to have a fiefdom for their own personal glory, self image, and paycheck. Damn the greater good.

Re:GTK is trash

[Darinbob]

Mostly because a GUI tookit and system can be so complex that you want some additional language features. Even if you're not doing object oriented designs, you can use C++ to more easily manage the complexity by lumping things into modules and abstract data types (via namespaces or classes).

And I say that as someone who's using only C for about 5 years now. I'm not a big fan of C++ in many ways but I am missing a lot of the stuff that is a better-C-than-C.

And C has changed fundamentally in many ways. Old K&R code will not compile on most compilers today, except by using a legacy switch perhaps. Newer standard C is now vastly more portable than K&R, precisely because it is standardized. Older K&R had big portability issues, even across Unix variants. Standard C has more strict typing, semantics of operations are more strictly defined, a standard library is defined and expanded, etc.

Re:GTK is trash

[Hognoxious]

last I knew, the only dev working on the Windows version had abandoned it a while ago.

Probably still fighting his way through Metro trying to find the compiler.

Re:GTK is trash

[serbanp]

BS.

Motif was a very consistent and well-polished toolkit, probably the best one based on X11/Xt (at that time). I still can recompile tools I have used 15 years ago. Back in the day, the biggest hurdle using it in the free software context was that this was a commercial product; that's why some guys started (and completed!) rewriting a fully-compatible variant, only to see their effort being squashed by Motif changing to a permissive license (forgot which one, maybe LGPL).

OTOH, GTK+ is a moving target. I'm using a analog signal viewer that was originally written for GTK/guile. It's un-compilable on modern machines, therefore, for all practical purposes, that useful tool is dead; I don't have the energy to rewrite it for a more modern toolkit (I'm just the user, not the original author).

Anything written for GTK is disposable code.

Re:GTK is trash

[raster]

you really are not aware of gtk's history are you? your comment pretty much says it (fyi i don't develop on or for gtk - i have contributed long ago, so i'm neutral on it - but spreading the kind of comments as above is creating fiction likely from someone who never saw the motif version of gimp, and didn't know that it was motif, xt, or "diy" in those days. gimp had tried motif and that was pretty damned bad. xt was worse. qt was not an option as you needed to hunt down binaries of qt for your os as you got no source, and this was a real problem for people running it on solaris, sunos, ultrix, etc. etc. - you could talk openlook - but that was pretty much the same as motif/xt in terms of viability, so the only option left was "diy" and thats how gtk was born).

Re:GTK is trash

[raster]

qt is the same - you wrong for qt2 way back. it broke by qt3, then again in qt4 and again in qt5.

motif is stable because it goes nowhere. it gains nothing new. nothing is improved. you could use gtk2 or gtk1 - if your app was written against it and do the same - install the older gtk and compile against it. presto. that's the same situation you have with motif. motif is just gtk1 and it never moved beyond that.

Re:GTK is trash

[raster]

when gtk was written c was a major advantage over c++ - MAJOR. you could actually compile things. i rememebr back in 1997/98 when gnome was moving to "Corba" and the orb being used was mico (from memory). only people with a big budget for lots of ram (64m+ at the time) could build it... everyone else was in swap land for so long their machines gave out. so redhat compiled mico for people just so the dream of corba could happen (corba was c++). orbit was finally some sanity.

and today, to compile webkit you no longer can do it on a 32bit machine. it literally needs >4gb ram to compile. sorry. c++ has downsides. it also takes the better part of an hour to do so. much bigger c codebases compile with tiny fractions of the ram in tiny fractions of the time. rebuild times and resources to make it happen affect developer productivity a lot. the argument of "c+ is just as good as c in every way and then some" is wrong. there ARE upsides. there ARE downsides. you make your choices intelligently and not just with a "oh c++ is a magic silver bullet to fix all things". the magic bullet attitude is not useful.

Re:GTK is trash

[Tough Love]

Hi Raster. If you go "compiles faster" and "has designated initializers" you are getting really close to the end of the list of advantages C has. Meanwhile the C++ list of advantages is too long to list here. Start with just one: classes. Horrible filth pervades GTK from top to bottom because there is no good way to make up for that lack. I will accept a longer compile to end up with a better result, thankyou. BTW, much of the C++ compile overhead is expanding macros. Nobody forces you to use those bloated things.

Re:GTK is trash

[Areyoukiddingme]

And a thousand years from now, audio on Linux will still be goddamn broken, and defaulting to exclusive open of the sound device.

Re:GTK is trash

[Anonymous Coward]

In the context of X11, what, exactly, is a "native widget"?

Athena widgets, obviously. What else could it possibly be?

Re:GTK is trash

[Anonymous Coward]

No, it's See!

Re:GTK is trash

[goose-incarnated]

The pure-C api is what makes it harder to use, because you have humans doing the work otherwise done by a C++ compiler. If that's not retarded, I don't know what is.

The pure-C api is what makes it portable - I dare you to use a C++ written lib*.so at runtime from sbcl, guile, pyNewLanguage, Perl or whatever the the hell is the language of the day.

Re:GTK is trash

[Anonymous Coward]

You can use Calligra on top of every desktop environment, as well as Windows.

Re:GTK is trash

[Chrisq]

The guy who moderated this off-topic is a moron. probably a Muslim.

Re:GTK is trash

[DuckDodgers]

Java on the desktop never took off because the initial push happened when the JVM was dramatically less resource-efficient than it is now and computers were dramatically less powerful than they are now, and the Java language had (even) fewer useful features.

C++, on the other hand, has tons of warts but with the right tools and libraries it's no worse to use than Java for many applications and resource efficiency is not a problem. I think the real problem is that so much stuff is moving to web-based that C++ and Qt are poised to be the clear best choice for developing new apps in a constantly shrinking space.

Re:GTK is trash

[DuckDodgers]

Going your own way is one of the best things about open source. 50 people come up with 50 different approaches to solve a problem, 45 suck, 3 end up more or less the same as previously existing solutions but with a slightly different set of headaches, and 2 innovate.

I've never dealt with the GTK source code or their developer community, so I'm just speculating. If in fact the code is poorly written and especially if the community is rude and unhelpful, then that's a problem. But there's nothing inherently wrong with trying to do your own thing when creating a library. If "doing your own thing" makes something that sucks, people just won't use it.

Re:GTK is trash

[raster]

i'm just saying that compiling faster.. or compiling at ALL is a major bonus. as i said - you can't build webkit on a 32bit machine. you can build vastly bigger c projects on those machines easily. literally stopping you from compiling is a MAJOR minus.

and for expanding macros? you don't read much c code. it's macro heaven. :)

and you can do classes rather well in c - multiple inheritance and more. it just depends HOW. but that's ok. i'm never going to convince you that you're taking a fairly extreme position as your mine is made up already.

Re:GTK is trash

[loonycyborg]

I have heard that all of those toolkits suck for some people for various reasons. And GTK accomplished what it set out to achieve too. So you're just showing double standard to GTK here. Personally I ever used Qt for any more or less serious GUI work and I'm kinda tired of their preprocessor hackery. Maybe I seriously should check out wxwidgets then.

Re:GTK is trash

[david_thornley]

How does LGPL work on iOS? On most desktop OSes you just provide the LGPL component as a shared library and provide the source code, so a user can theoretically change and recompile the LGPLed stuff and drop in the new shared library. You can't do that on iOS. I've seen arguments about whether GPLv2 and hence LGPLv2 are legal in the App Store, but it's very clear that GPLv3 and hence LGPLv3 are not.

Re:GTK is trash

[david_thornley]

Who wants to compile webkit and doesn't have a 64-bit machine? Seriously, my phone is 64-bit. The only 32-bit computer in my house surprised me by showing up on my LAN once. I hadn't realized it was still plugged in to power and ethernet.

Any decent development machine nowadays is 64-bit with plenty of memory to compile webkit (RAM is cheap). You can use 32-bit bearskins and stone knives if you want, and they're just fine for a whole lot of things, but not for serious development.

Sure, you can do object-oriented C. I've done it. It includes extra stuff that you have to remember to write, and which is something you can get wrong. C++ classes are a lot easier to write correctly. C++ classes allow for easy resource management. std::unique_ptr and std::shared_ptr will do 95% of the resource management you'll ever need, and std::weak_ptr will do much of the rest when judiciously applied. C++ templates, while hideous when written, allow things that C can't do at all well. std::sort is potentially much faster than qsort(), and easier to use. The C++ container/iterator/algorithm model from the STL is extremely powerful.

C++ has a whole lot more ways to handle program complexity than C does, and when you get into large code bases that makes a real difference.

Re:GTK is trash

[david_thornley]

There have been two versions of ISO C++ (there never was a separate ANSI one): the 1998 and 2011 versions. There will be another standard this year, with relatively minor changes.

That means that anything written significantly before 2011 could not take advantage of anything that could be called a later version of standard C++. (Many features were available earlier, either in Boost or compiler extensions, but it took time for everything to settle down. A feature called "concepts" was pulled almost at the last moment, for example.)

I find it irritating that libraries have their own string libraries, rather than using std::string (quite usable despite the design issues), or their own containers, but a lot of them were started well before C++98 was readily available.

Re:GTK is trash

[Tough Love]

I meant, expanding templates. Macros on steroids. Disgusting hack of a language, but annoyingly useful.

Respecfully, anyone who claims you can do classes well in C has no experience with C++. You imagine you can do classes well. The truth is that you rely on a lot of conventions that the programmer must implement in meatware, that have little to do with software engineering. And what you get is not the real thing - you can't subclass properly for example. To someone who has only ever written C code it feels like what they imagine object oriented programming must be like, and that seems to be corroborated if things are actually getting done, better than if there were no ad hoc infrastructure. But the value of it pales beside the real thing. I have been there myself. If you want to argue that you can do OOP in C, you better get some experience with C++ first, and then you will assuredly realize that you are actually just helping the old cripple limp along, not setting it free.

Re:GTK is trash

[Anonymous Coward]

I think RMS made this much more hostile...

I think when there is a need to complain about Freedom and software, there is always the opportunity to trash-talk about Dr. Richard Stallman.

Re:GTK is trash

[serbanp]

Theoretically you're right. Practically speaking though, I can take today the Motif source code and compile it for a modern computer and OS without any glitch. The prerequisites (straight X11 and Xt libraries) are still around.

OTOH, GTK+ is a pile of junk that depends heavily on other piles of junk and there is currently no repository from where I can pick ALL the bits and pieces to build it. For mere mortals, it's un-compilable.

Re:GTK is trash

[Hognoxious]

Isn't it D?

Re:GTK is trash

[jrumney]

Version 2.2 was not GPLv2. It was GPLv2 with an exception that made it incompatible with the GPL. If you used Qt in a program targetting Windows, they claimed that the GPL did not apply, you had to pay Trolltech for a commercial license. It was many years before they changed this and adopted a standard GPL license.

Re:GTK is trash

[Anonymous Coward]

And of course, terribly high levels of techie arrogance, inherited from old-timer UNIX neckbeards.

Your bias is showing. One has nothing to do with the other. If anything it's the reverse - inherited from old-time Microsoft arrogance. GUI oriented programmers for a long, long time have lacked even basic skills in organization and design.

Re:GTK is trash

[Wolfrider]

--I don't have modpoints ATM, but I'll give you a +1 Funny for that :-)

Re:GTK is trash

[Anonymous Coward]

C++ has RTTI typeid and dynamic_cast. People usually deride MOC not only because it makes compilation loads slower but because Qt's signal and slots mechanism sucks. I personally think it is WORSE than the GTK+ signal mechanism. GTK+ doesn't need a pre-compiler either.

Gtk+ does not requires a pre-compiler simply because it's the job of the developers to fill these data.
People using gtk+ do everything "manually", including filling the "virtual function table" by hand.
In that way you don't need an moc.
Actually gtk+ does need a pre-comiler when you try to define new signals.
Glib-genmarshal is the command for that. You need to write makefile rules for it, too.
Please don't comment on something that you don't even know.

Woot!

[Anonymous Coward]

There hasn't been a good GTK / Qt flamewar around here for ages!

Now that Qt is free, shouldn't we be migrating away from GTK?

Re:Woot!

[snookiex]

He he, you reminded me of this .

Re:Woot!

[Anonymous Coward]

And who the hell is writing new desktop software these days anyway?

Linus Torvalds, for one.

I recently licensed WebStorm (one license for Mac, Linux and Windows) and Acronis 2014. Maybe native software isn't as dead as you think.

Re:Woot!

[Anonymous Coward]

You licensed a Javascript IDE that's used for making web applications. This is your proof that native desktop software isn't dying? Why isn't your company distributing Qt-based binary applications, rather than inherently slower Javascript, then?

Re:Woot!

[Anonymous Coward]

I'll start one now!

The people who were so worried about QT's licensing had no problem jumping into bed with Microsoft
to get Mono.

Re:Woot!

[randallman]

Thanks for the nostalgia and laughter.

It's exactly why GTK was born!

[Anonymous Coward]

Because Qt guys were doing it wrong, Motif guys were doing it wrong, C++ guys were doing it wrong, .....

Re:It's exactly why GTK was born!

[MickyTheIdiot]

What is the matter with all of you? Curses got it right...

Re:It's exactly why GTK was born!

[Anonymous Coward]

Ho, ho, hey, hey! My apps run on Tcl Tk!

Re:It's exactly why GTK was born!

[dkf]

Motif guys were doing it wrong

To be fair, anyone who has ever worked with Motif should think that its implementers were doing it wrong. It's the nastiest toolkit I've ever used as a programmer (that's because I never worked with anything else layered on top of Xt, except as a user).

Re:It's exactly why GTK was born!

[cheesybagel]

Xaw. That's nasty too.

Re:It's exactly why GTK was born!

[Millennium]

It's kind of scary just how much saner Tk still manages to be than most other toolkits, even with the cruft and stagnation.

Re:It's exactly why GTK was born!

[MarcoAtWork]

I worked quite a bit in Motif ages back at a fairly involved level, I wrote a 'cross platform' (which at the time meant 'different versions of unix') GUI creator in Motif (compatible with several versions of Motif too) where you could drag & drop motif widgets, resize them wysiwyg etc. and I didn't find it too bad to use. From a user perspective there were also some really really really nice scientific commercial widgets you could buy that made it really stand out for some applications.

I do agree it could've been made easier to use in some scenarios though, for example from the subclassing perspective, I managed to create a working text widget subclassed from XmText that did rectangular highlighting but that was quite hard to get to work correctly.

I still have the O'Reilly complete X programming series of books on my shelf, I spent quite some time with them, fun times...

Re:It's exactly why GTK was born!

[Kremmy]

Completely agreed. I find that Python's Tkinter has made it more of a delight to use than pretty much any other windowing toolkit.

Application management with C++

[zackhugh]

I've coded applications with Qt and GTK and I prefer Qt because of its native C++ support. GTK has a C++ interface called GTKMM, but at the time I used it, it had serious issues dealing with third-party libraries.

I prefer C when I'm doing embedded/high-performance computing work. But for large, complex GUIs, I prefer C++. So that's why I go with Qt.

GTK+ is a C library

[i ate my neighbour]

The only reason to use it now is if for some reason you want to avoid C++ and develop in pure C.

Re:GTK+ is a C library

[Anonymous Coward]

Yes that's true, if you're part of the morons who can't understand how POO works...

Re:GTK+ is a C library

[Greyfox]

I've found with C++11 and Boost that I prefer to develop in C++ than Java. Or pretty much anything else for that matter. Design your code reasonably well and it can be solid, and fast. I've left my applications running constantly for months on end and never seen a resource leak, and the compiled binaries are tiny. I just got done stamping the last of the ruby code out of the code base I have to maintain and my new code runs significantly faster, is so much more maintainable that the previous developers of the code really ought to be ashamed of themselves and takes under a minute to deploy. In about the time it takes gem to warm up, I've deployed my files, verified md5sums on 4 different systems and left to get a donut. Mmmm..... Donut.....

I don't care for GTK or QT. I kind of wish the boost guys would write a widget toolkit so I don't have to do that myself, when I finally get to that item on my to-do list (It's sitting down around 4 or 5 on the list right now, so it'll be a while.)

Re:GTK+ is a C library

[Daniel Hoffmann]

I don't have enough C++ or C development experience to say this for certain but I think that most people that say "Thank god I don't have to use C++ anymore" actually hated using the API calls, like POSIX and Win32 because they did things in a very C way (which made passing and returning strings to functions a pain in the ass for example). Today there are several libraries to abstract that stuff away so you can actually do things in a proper C++ and/or object oriented way (unless you are dealing with some very specific scenarios). Plus the C++11 stuff.

Re:GTK+ is a C library

[sandertje]

Your argument is invalid. Qt has good open source bindings for Python as well: PySide.

Re:GTK+ is a C library

[tibit]

moc exists not because C++ is a shitpile, it simply takes some manual, boring boilerplate out of the code you write. Boilerplate that's all over code that uses GTK, by the way. Code generators exist to make you more productive. Some platforms even go as far as giving you a compile-time code generation support: C++ has a rather limited, functional-style metaprogramming. In LISP you get the full power of the language available at compile time, and to me that's still unmatched by any other mainstream platform.

Re:GTK+ is a C library

[HiThere]

The main reason I don't like C++ (and C, for that matter) is the way they handle unicode. The next reason is the way they handle pointers. (For C++, Templates come in there, too.)

Vala keeps promising to be a good language, but it's been between alpha and beta quality for 5 years now. D is pretty good, but lacks library support. (You can roll your own to C or C++, but it's a real disincentive. And can be quite difficult if your header files have macros.) Ada is ok, and has decent library support, but it's quite verbose, and hard to document (I'm talking about developer documentation, like Javadoc or Doxygen, or even RDoc, not end user documentation). Also, I really like garbage collection, though that's partially a matter of taste.

If I don't need the performance, I generally pick Python as the "least bad". It's not as good as D, but it usually supports the libraries that I need. It's not as good as Vala promises to be, but it's working and well documented NOW. But even Ada has better unicode support than do C and C++.

Re:GTK+ is a C library

[tibit]

Qt 5 and C++11 play ball together, there's much less of boost needed beyond application-specific stuff if you use Qt. I'd suggest you have a look at Qt, it provides you with a whole lot of functionality. It'll cost the "boost guys" as much time as it cost Qt folks to come up with Qt: in other words, what you ask for is completely unrealistic unless you've just won a lottery and have some money to burn on developers.

Never mind that boost by itself still can't provide what Qt has provided for a long, long time now: introspection into the methods available on an instrumented object. It also has a metatype system that lets you construct and destruct instances of registered types, completely under program control and without having to sprinkle type-specific knowledge all across the project. This makes for much easier integration with scripting languages, for example.

Re:GTK+ is a C library

[satuon]

That's right, when people are comparing languages, they really are comparing the libraries available for them. And for C++, Qt is a damn good one.

Re:GTK+ is a C library

[twocows]

PySide is dying. The new company that owns Qt has almost gone as far as saying they don't care about it. Best to move to PyQt if licensing permits.

Re:GTK+ is a C library

[Anonymous Coward]

No, the C stuff is okay. The error handling through return codes is irritating but other than that it's all pretty straightforward. C is a nice low-level language -- it'll shoot you in the foot when you mess up, but it's small enough that you can have a pretty good idea of what it's doing under the hood.

C++'s problems are where it tries to be a high-level language and it fails. C++11 filed off some of the rougher edges but the core design problems remain. There is no encapsulation, either at compile time (you need to recompile your code if you touch any code where the private members change) or run time (feel free to modify those so-called private members, though; all you need is their memory location). The support for exceptions is the worst implementation of that feature in any language that has tried to implement it -- jesus, you don't even get a fucking stack trace. Exceptions leak memory unless you wrap everything in a "smart pointer" and for over a decade the standard smart pointer, std::auto_ptr, was garbage. The iostreams library is still garbage, full of multiple inheritance and overloaded bit shift operators and error handling through status variables rather than exceptions. There is only just now, in C++11, standard library support for absolutely basic shit like multithreading and hash tables; other stuff like, I dunno, networking is still missing. There's finally garbage collection in the standard library through std::shared_ptr but it's just reference counting, so just forget about, e.g. lock-free multithreaded data structures. The ABI isn't standardized so if you want to dynamically load some compiled code at runtime, you don't have any way of knowing what the name-mangled symbols will look like (that's "implementation dependent") so you need to create a C API for your C++ code in order to dynamically load it. The grammar is astonishingly complex, making it difficult to create refactoring tools. There's no reflection, or any portable and standards-compliant way to add it.

The worst part, though, is the same problem GTK has. If you mention any of these failings to a community of C++ developers, their first response will be to tell you why you don't actually need the feature that you need, and their second response will be to call you an idiot for wanting it.

Re:GTK+ is a C library

[Brandybuck]

When it comes to the UI, objects are natural. Every C toolkit goes through hoops to provide you with objects of some kind. Motif, GTK, etc. So why not just use an object oriented language to begin with?

You don't have to use the dark corners of the language. Qt sticks to just the Object Oriented parts of C++, with just a tiny bit of templates. Not a functor in sight (unless you wander toward the totally optional Qt::Concurrent framework). Internally it uses all of the language, but as an API it provides just the object oriented subset.

Re:GTK+ is a C library

[0123456]

So, basically, your complaint is that C++ isn't Java?

Re:GTK+ is a C library

[RightSaidFred99]

That's like saying sarcastically that someone's main complaint about a dump truck is that it isn't a Ferrari.

C++ sucks, it's as simple as that, but it's a necessary evil because sometimes you need the performance, or simple cross-platform mostly-compatibility, and it's still vastly better (in terms of developer efficiency) that C.

But if you're writing e.g. a commodity GUI or backend server app then Java (or even vastly superior to Java - C#/.NET) are incredibly much better in just about every way other than the above.

Re:GTK+ is a C library

[Anonymous Coward]

And the Qt python bindings are good enough and complete enough to develop enormous commercial applications like The Foundry's Mari with. Every time the GTK vs Qt flamewar gets an airing someone throws out this hoary chestnut. "GTK has high-level language bindings." Yes, it has -- so what? It's not a differentiator.

Re:GTK+ is a C library

[0123456]

That's like saying sarcastically that someone's main complaint about a dump truck is that it isn't a Ferrari.

Uh, yes. If you adopted all their suggestions, you'd basically end up with Java. Except maybe running native code, rather than byte code.

C++ sucks, it's as simple as that

Every language sucks if you try to use it to do the wrong things.

But if you're writing e.g. a commodity GUI or backend server app then Java (or even vastly superior to Java - C#/.NET) are incredibly much better in just about every way other than the above.

Ever used Eclipse? Its suckitude is primarily due to being written in Java rather than C++.

Re:GTK+ is a C library

[Grishnakh]

I've been working on a side project in Qt/C++ lately, and it seems to handle Unicode just fine. This shouldn't be something that's a fault of the language, but rather whatever libraries you're using. Pointers are a different matter.

Re:GTK+ is a C library

[Grishnakh]

While a lot of your criticisms seem valid, many of the other problems (lack of hash tables, networking, etc.; iosteams library sucking) are things that are solved by using libraries/toolkits. The Qt toolkit for instance has hash tables and networking, and lots more, and much better alternatives for iostreams. With C++, instead of expecting the language's standard libraries to have things you need, you pick a toolkit and/or libraries that contain the functionality you need, and use that.

Re:GTK+ is a C library

[Anonymous Coward]

Wow are you still in the year 2000?

http://qt-project.org/doc/qt-5.1/qtdoc/unicode.html

http://qt-project.org/doc/qt-5.1/qtcore/qtranslator.html

Re:GTK+ is a C library

[Anonymous Coward]

It combines the complexity of Java with the low-level unsafeness of C, while retaining the benefits of neither. In trying to be all things to all people, it excels at nothing. The language has too many ugly corners and "implementation-defined" areas to keep a clear idea of what the object code will look like, making it a poor low-level language, and it lacks a raft of features that have become obligatory in a high-level language. It's the worst of both worlds.

It still has a niche for large but performance-intensive systems, where it is the best of the available options, but that niche is shrinking.

Re:GTK+ is a C library

[Anonymous Coward]

Ever used Eclipse? Its suckitude is primarily due to being written in Java rather than C++.

Eclipse is a perfectly good IDE for Java. The Eclipse CDT is a terrible C++ development environment because C++ is nearly unparseable.

It's rather telling that the only way to get a decent C++ IDE is to start by using the clang compiler frontend.

Re:GTK+ is a C library

[GiganticLyingMouth]

Actually, the C++ community will call you an idiot because most of your complaints are simply a result of your misunderstandings.

There is no encapsulation either at compile time (you need to recompile your code if you touch any code where the private members change) or run time (feel free to modify those so-called private members, though; all you need is their memory location).

Your gripe about runtime encapsulation is idiotic; you would really have to go out of your way to get the memory address of a private variable (you would have to guess its location, which would be compiler-specific due to compiler-generated members like the vtable or alignment padding), or by requiring the class itself return a reference or pointer to the variable. C++ assumes you're competent and isn't going to stop you in pathological cases.

Exceptions leak memory unless you wrap everything in a "smart pointer" ...

Using RAII is standard, idiomatic C++. You can use smart pointers for dynamic memory or allocate your variables on the stack. That way, (as long as your destructor is correct), you won't leak memory, even in the face of exceptions. Pretty easy, right? As an added bonus, its performant and deterministic. What's not to like? auto_ptr is gone, and for "that decade" it was standard to roll your own smart pointers or use boost. Now you have unique_ptr and shared_ptr as your primary standard library smart pointers.

There's finally garbage collection in the standard library through std::shared_ptr but it's just reference counting, so just forget about, e.g. lock-free multithreaded data structures..

I guess you'd be pretty amazed to hear that there are portable, lock-free data structures written in C++ then! In fact, boost already has a few. Also, if you really want reflection, Qt has support for it (via MOC, though you'll have to jump through some hoops with QObject).

Re:GTK+ is a C library

[HiThere]

QChars are 16-bit chars. This is indefensible. Utf-8 is defensible. Utf-32 is defensible. Utf-16 is ... is only defensible on CPUs with 16-bit registers.

The Qt libraries seem to have been badly sabotaged by historical continuity. At one point there were good reasons for 16-bit characters. They no longer exist. Now the only reason is to be consistent with what they've been doing. (And I must also admit that I really dislike C++ iterators. Python, D, and Ruby have well designed iterators. C++ doesn't. Probably because it was the first to implement them. Again, it's being treated savagely by historical continuity. That's probably also the only reason it has that attrocious macro processor, and the abyssmal use of pointers. (C++ does at least allow ref references instead of pointers. C doesn't even allow that, or didn't the last time I checked.)

Additionally, the error messages are atrocious. This is partially the compiler, but it's also partially that the language design discourages intelligible error messages. (Still, some compilers manage decent error messages in many contexts. IIRC this is one of the arguments in favor of Clang.)

P.S.: Yes, I know that MSWind uses 16-bit characters. So does Java. This was once a reasonable choice, but is no longer such. Latin1 only covers a fraction of the characters that one must deal with. True, it's usually a very large fraction, but that doesn't suffice. Missing even one character is often intolerable, and it rarely happens that just one is missed. (That said, even full unicode doesn't cover everything. There are, e.g., Japanese poetic forms that aren't covered even by full unicode. But it's the closest we have without going into specialized character sets that while they cover one area more deeply, are narrow in their coverage.)

Re:GTK+ is a C library

[t_hunger]

I do not see what you are going at: UTF-8, UTF-16 and UTF-32 are all different encodings of the same unicode characters. All of them can hold all defined unicode characters. I fail to see how Latin1 comes into the discussion... that is a subset of unicode that is available (just as all other unicode characters) in all unicode encodings. For a programmer it makes very little difference API-wise whether a string uses UTF-8, UTF-16 and UTF-32 internally.

UTF-16 does use a more RAM to hold a ASCII string than does UTF-8 (in fact twice as much). OTOH it uses less space than UTF-8 for most non-ASCII languages. So what is better depends mostly on which nationality you code for.

Re:GTK+ is a C library

[Anonymous Coward]

UTF-8 is most compact but rather difficult to decode (decoding matters for responsiveness of an application) and hard to estimate the actual length of a string. UTF-32 is wasteful (a running application has limited space). UTF-16 is a compromise, with less waste than UTF-32 and dead-simple decoding for the entire BMP (bonus: within the BMP a string is always bytes/2 long). Which is why UTF-16 is the internal representation found in Java, .Net and probably many others.
So in reality UTF-8 is used for storage and serialization, where size matters, UTF-32 is used where space is plenty and performance is so crucial that no extra logic may get in the way, UTF-16 is used everywhere else.

Re:GTK+ is a C library

[Anonymous Coward]

Note that UTF-16 supports the entire Unicode range. It's an encoding. There is no limitation on the supported characters. There's also UCS-2, which is older, and uses surrogate pairs to get out of the BMP. And there are sloppy implementations that do UCS-2 without surrogate pairs, essentially only supporting the BMP. That is not a useful Unicode encoding though.

Re:GTK+ is a C library

[Daniel Hoffmann]

That is... really insightful, I had no idea. Thank you anonymous poster.

Re:GTK+ is a C library

[david_thornley]

The real problem I have with 16-bit characters is more how they're used: typically to support UCS-2 rather than UTF-16, meaning that Unicode code points off the basic plane are SOL. If you really need fixed-length characters, you need UTF-32. If not, a simple byte string (not zero-terminated) will serve for UTF-8 and UTF-16.

Re:GTK+ is a C library

[HiThere]

Well, most of my experience with 16-bit chars is with Java, since if I have the option of avoiding them I do. So perhaps I am being unfairly harsh on 16-bit characters. But, personally, I see no justification for them. If I need compactness, I use utf-8. If I need consistency, I use utf-32. And I'll switch back and forth between representations in the same program if there's enough reason. (Usually, however, if I'm going to use utf-32, the only conversions happen at I/O time, as I always use utf-8 on disk. Still, there are occasions where I'll decode a small chunk of a string from utf-8 into utf-32 to work with it. It's extremely rare that I will then re-encode the altered version into utf-8. If I were to need to do that, I'd probably just do all the work in utf-32 except the I/O.)

Re:It's true!

[Selur]

no not retards, simply 'old'-style linux users,...
Simply folks who think they lend a helping hand when they send you a friendly "RTFM" or multiple links instead of simply helping out even is they could help out and solve the problem in a few sentences. They might think that unless you fully understand every detail they didn't help properly and sure, some times you can only explain a problem roughly and tell folks to read the man-page / manual / wiki for more details, simply because:
a. the problem can't be explained/solved in a simple matter due to it's complexity
or
b. you can't explained/solved the problem in a simple matter, but instead of posting the infos and noting that you just posted the infos as a general help and can't help more you ended up posting just the infos and look like an ass to a newcomer
-> don't think it's only GDK or linux folks with this bad habit (some audio/video/apple forums/channels/mailing-lists/developers,... are not a bit better), but the qt community is made up of more of a variety of characters than the GDK community and so it often delivers a more friendly vibe.

Hostile Communities

[therealprologic]

Unfortunately developer communities can tend to get rather hostile. It only takes a few hostile folks to tarnish an entire community. Python is a classic example as well.

Re:Hostile Communities

[Chrisq]

Unfortunately developer communities can tend to get rather hostile. It only takes a few hostile folks to tarnish an entire community. Python is a classic example as well.

Why mention Python and nor Ruby. You Bastard! ;-)

"Intel Dev" in Headline is misleading

[t_hunger]

Dirk stated in his presentation that this is his own, private opinion he is presenting here and not that of his employer Intel.

So the headline is technically correct, but that Dirk works for Intel is not relevant in this context at all.

Re:"Intel Dev" in Headline is misleading

[RightSaidFred99]

It's not misleading at all, in fact I completely fail to see your point. Do you think there would be such an article posted if "Joe Schmegal, hobbyist programmer" had made a similar statement?

Re:"Intel Dev" in Headline is misleading

[smash]

Well, it does give some background that he is actually deemed to be employable by intel, rather than some hack pumping out shit in his bedroom.

Re:"Intel Dev" in Headline is misleading

[Anonymous Coward]

Or they could have described him as a long-time X Windows contributor. I've seen his name on bits of my systems for so long that I assume he was already contributing when I first touched Linux in 1993, though I'd have to do some web research to really know. I had no idea Intel had picked him up, but I see that as giving Intel more credibility, rather than this somehow giving Dirk credibility...

Re:"Intel Dev" in Headline is misleading

[t_hunger]

First I am almost 100% sure that there will be some idiots employed by Intel somewhere. Every big company has some of those around. So "works for company X or Y" is not a qualification in my book.

Second Dirk is making it very clear that he is speaking as a private person about a hobbyist project of his, not as an employee of some company. So there is no reason to bring the company into the discussion. People will misread the headline to mean that this is something that Intel is doing. Just check this thread: One misguided individual is asking: "How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing?".a couple of comments down. It is not Intel speaking, it is not even "their developers". It is just one single guy speaking about something that is not related in any way to what Intel does. These misunderstandings were needlessly created by the headline.

Seriously: This is slashdot. How many people here on slashdot bother reading more than the headline? :-)

Re:"Intel Dev" in Headline is misleading

[smash]

Sure, there are idiots in some companies. However, there's a lot more who are unemployed. Given the current economic situation (where companies are laying off the dead wood), and it is in his field of interest, I'd suggest that mentioning that he works for intel is relevant.

GTK+ is standalone

[Second_Derivative]

Qt, on the other hand, is its own universe. It's written in a weird dialect of C++98 (though I'm sure it works just fine in C++11 these days), it has its own object model, networking stack, container library, threading library, graphics primitive library (i.e. not Cairo). This object model also leaks into its language bindings if you don't want to write your software in C++.

It's the same problem that Java and C# also suffer from: they're not cross-platform, nothing is. What they actually are is their own platform built alongside a perfectly good already-existing one, and you can see the seams.

There's more to each platform's UI than what bitmap you skin buttons and checkboxes with. If you want a cross-platform application, then write a completely different UI for each platform using those platforms' native UI toolkits. Sadly "good enough" is the order of the day here, so you end up with platform-refugee applications that look like shit.

Re:GTK+ is standalone

[t_hunger]

I would argue exactly the other way around: Qt is stand-alone and GTK is not. If you want to write any app you need more than the UI. You actually want the application to *do* something but render a couple of widgets.

With GTK you end up hunting down a host of glib/gnome based libraries, all with slightly different peculiarities and all of them coming with little useful documentation. How is that stand-alone? With Qt you get everything in one convenient package (and are still free to leave out the parts you do not need in your binary packages).

Qt is a C++ library: Any C++ compiler can compile it on a wide range of platforms. How would that be possible if Qt was written in a weird dialect?

Of course the object model leaks into the language bindings. How could it not be? The same is true for "object-oriented" libraries written in C.

Yes, even with Qt you can not get perfect cross-platform applications. You will need to some platform-specific code in any non-trivial application. That is perfectly possible in Qt... and it still gets you at least 90% of the way! That was the other reason for switching that Dirk gave in his presentation: That GTK does *not* run properly on windows nor on Mac. He claimed that some core GTK people are actually opposing the toolkit working on those platforms and that independent teams are trying to maintain the cross-platform parts as good as they can against a hostile core team.

Subsurface was cross-platform with GTK and it looked like shit on *all* platforms incl. Linux. The Qt port looks way better -- they could finally get the UI they wanted but could not manage to implement in GTK -- and works equally well on all three target platforms. Check the demo right in the middle of the video: Dirk shows of the new UI and contrasts it with the old one in pretty gory details. So, yes, Qt is not perfect, but it is pretty good nontheless:-)

Re:GTK+ is standalone

[Gravis Zero]

it has its own object model, networking stack, container library, threading library, graphics primitive library (i.e. not Cairo).

the toolkit is split into modules that can be used completely independently of each other. If you only want the GUI stuff, you can use just the GUI module.

This object model also leaks into its language bindings if you don't want to write your software in C++.

binding are completely third party software to Qt. you might as well complain about gtkmm while you're at it.

It's the same problem that Java and C# also suffer from: they're not cross-platform, nothing is. What they actually are is their own platform built alongside a perfectly good already-existing one, and you can see the seams. There's more to each platform's UI than what bitmap you skin buttons and checkboxes with.

obviously you have not used Qt in the last five years.

where is the "-1 Ignorant" mod?

Re:GTK+ is standalone

[tibit]

There is no way other than having a meta-platform that can abstract things away from the physical platform it runs on. A platform is not merely the UI. If you really want to write cross-platform code that has native-API-using GUIs, you'll still find yourself having to use a platform abstraction for all the non-GUI stuff like events, threads, containers, strings/internationalization, etc. Even if this abstraction is provided by the standard C++ library, it's still an abstraction, and you can still choose who provides it - compiler vendors are just one in a crowd here.

There is a very good reason that Qt has its own object model etc. It's because all those things, done natively, are full of inconsistencies, bugs you have to work around, and other shortcomings that have you, the brave cross-platform coder, having to re-do things again and again.

No, using Qt core and networking for non-GUI platform abstraction is no different from using Boost. Just that with Qt you have the option of using the gui stuff, and platform-specific extras, and qt quick, and a whole bunch of other goodies that you get nowhere else.

There is nothing wrong, of course, with doing the core of your application using Qt's core and networking modules, and doing the UI natively. Often, though, you'll find that the native way will not give you as many advantages as you thought you had.

Never mind that even some "native" ways of doing things do it exactly the way Qt does it. For example, WPF on .net is not using native legacy winapi windows controls, since they render everything using GPU acceleration and conceptually are much closer to Qt Quick 2 controls. So even your own "stay native" argument flies in the face of what the "native" platform vendors are themselves doing!!

Re:GTK+ is standalone

[BravoZuluM]

How is this insightful? GTK guys modding this up? FUD. Qt is not written in some weird dialect. Where'd you pull that factoid from? I compile QT all over the place, Windows, Mac, LInux and embedded Linux using the VS C++ compile or gcc. On each of those platforms, it works VERY well. It's cross platform; more so than any other framework/language I've worked with. Qt apps look like Windows apps on Windows, Mac apps on Mac, Linux apps on Linux (if there really is such a thing)

Re:GTK+ is standalone

[Brandybuck]

"weird dialect of C++98" - WTF? What is this dialect you speak of? Do you need to pass --weird to G++ to get it to compile? Of course not! It's using the same C++ every other C++ app in the world is using. Both C++98 and C++11 are supported. It doesn't REQUIRE you to use C++11, but that is a benefit not a drawback.

"it has its own object model" - Of course it does, that's because C++ does not have one of its own. QObject is there to provide for the introspection that C++ lacks. Once you have that introspection you can start communicating with other objects. I fail to understand why this is a disadvantage in your eyes.

"networking stack" - Of course. Why should it not? It is an cross-platform application framework.

"container library" - When Qt began the STL was fragmented, not standardized, and poorly supported. Yet containers are useful. Qt kept them around because they turned out to be better than the STL containers. They're a balance between raw performance and the "bloat" of pure templatized containers. Externally they end up being 100% compatible with the STL.

"threading library" - It was only extremely recent that C++ got its own threading, and it's just very low level threading. Qt threading provides a nice usable wrapper around threads (which are native C++ threads underneath if built with C++11), and the ability to easily communicate between threads with signals/slots.

"graphics primitive library" - Why not? Seriously, why not? Isnt't that the whole point of a GUI toolkit? Underneath it draws widgets using the native controls, if available, or uses its own if not. That's why the widgets look like native controls on Windows and Mac, because they ARE native controls! On X11 it will draw its own. It doesn't use Cairo, why should it use Cairo, who made Cairo king that we all have to bow down before it?

Re:GTK+ is standalone

[david_thornley]

How would that be possible if Qt was written in a weird dialect?

To nitpick, some languages make it easy to make their own weird dialects. Common Lisp is outstanding in this, but C++ allows it quite nicely. Add some libraries with their own classes and operator overloading, and you've got a weird dialect that will compile fine.

Not all that surprising

[Octorian]

Gtk+/GNOME (in popular form) basically exists because of a flamewar, so is it any surprise that the community is still like that?

It always struck me as a bunch of stuck up C developers who outright refused to use C++, on principle alone. So instead, they implemented everything C++ does on top of C, using macros and coding conventions. They later managed to spin their crusade as "actually" being about the licensing issues with Qt at the time. While those licensing arguments may have been valid, to me they always felt like little more than a cover for a C vs C++ fight. However, it made their side of the story a lot easier to sell.

Re:Not all that surprising

[cheesybagel]

No. People just used GTK+ because GIMP used it as a toolkit. Eventually someone pushed GNOME around but that was later.

Re:Not all that surprising

[guacamole]

I think you're absolutely right. At the time of the KDE/GNOME conflict in about 98/99 I hanged around a lot of people who were fans of GNU and they were all whining about how much C++ sucks and plain C is better.

In the end, I absolutely hat both side in the GNOME/KDE war and I hope they both die a cruel flaming death. The QT folks were absolutely wrong to try to inflict the non-open source license on us. In the end they were proven wrong and were forced to release QT under an open source license. If these fools released QT under that license for KDE development earlier, the whol GNOME thing might not even have happened. On the other hand GNU/GNOME people were fools to insist on using plain C is the main language of implementation. Both sides were terribly wrong, but I think Trolltech were the dumbest ones originally to refuse to release QT under a insolence that's acceptable to OSS community.

Re:Not all that surprising

[Anonymous Coward]

Yeah, how DARE those filthy C developers take issue with glorious C++? How DARE they do things their own way, they should conform to the One C++ Way!

Regardless of whether it was about C versus C++ or about licensing, neither is a bad reason for making your own project. Other reasons that are not bad reasons for making your own project: because it's January, because you like the color blue, because you WANT to. You don't need a reason to make your own project. I personally think gtk+ is awful, but I also think C++ is awful. And if the GTK devs want to be an insular little circle and do their own thing, that's fine.

Re:Not all that surprising

[Anonymous Coward]

It always struck me as a bunch of stuck up C developers who outright refused to use C++, on principle alone. So instead, they implemented everything C++ does on top of C, using macros and coding conventions. They later managed to spin their crusade as "actually" being about the licensing issues with Qt at the time. While those licensing arguments may have been valid, to me they always felt like little more than a cover for a C vs C++ fight.
Ok then. Good enough. Since C is better than C++, we will stick with GTK for that reason alone then. It perhaps wasn't clear enough, but you stated that you can avoid the utter clusterfuck that is C++ and stick to C the way Kernihan, Ritchie, Thompson and God intended. It has always seemed that C++ was intended to deliver code that looked like an entry in the obfuscated code contest. With C you get clear code, no bullshit. Nuff said.

Re:Not all that surprising

[countach]

I don't know that anybody was saying C was better than C++. What they might have been saying is that C libraries are better as system libraries because they are easier to integrate into various languages. It's easier and more sensible to make a Python or Java or Scheme or whatever interface to a C library than a C++ one.

Re:Not all that surprising

[ChunderDownunder]

I don't know that anybody was saying C was better than C++

Linus? He's a well known critic. I thought Gnomers embraced the philosophy, i.e. that real programmers didn't need any fancy OO abstractions...

http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Re:Not all that surprising

[Octorian]

Along this line, I've often felt that if Qt existed under a "more free" license from the start, Java may not have taken over as the "language du jour" (with .NET riding on its coat tails).

Qt basically gives C++ a big part of Java's "real" advantage, which is a large common cross-platform framework that includes everything you actually need to write real applications.

And why are we listening?

[evilviper]

That's awfully big talk, from the company that unleashed EFI upon an innocent and unsuspecting public.

Open Source Culture

[EmperorOfCanada]

I never really thought about it but different OS project have vastly different cultures. I have long had a happy relationship with Qt; I was worried a bit after their Nokia purchase, and then really worried after MS bought Nokia; but all seems to still be good. For instance the Python culture is embroiled in a civil war with 2.x vs 3.x. And quite clearly some OS projects are very responsive to customers (For example the warning that git screamed after typing "git add ." disappeared. Other projects like Boost are definitely populated by academics, and so on.

I generally have stayed away from GTK and part of that reason might be that I sensed an unfriendliness there.

Re:Open Source Culture

[HiThere]

Saying "the Python culture is embroiled in a civil war with 2.x vs 3.x" is grossly misstating the position. Both Python2 and Python3 are currently supported, and, as much as feasible, fixes to Python3 are backported to Python2. A lot of people still use and develop in Python2, but it's no longer recommended for new projects. (It will be EOLed in a year or so. I believe 2.8 is intended to be the last version, but it could be 2.7, as I haven't kept current.) That said, 2.7 is stable and well supported on all major systems. But it's more inconvenient to use, e.g., unicode strings in Python2 than in Python3, and Python3 is generally faster (though not hugely so).

However, the two languages have been kept similar enough that it's often possible to write programs that work in both. If you're looking for help, however, it *is* useful to say which version you are using. And even which sub-version. And it's quite feasible to have BOTH installed on the same computer.

Personally, I prefer Python3, so I acknowledge that I'm a bit biased in that direction. But the main advantage that I see in Python2 is that there are libraries and tools (like Epydoc) that haven't been ported to Python3 yet. If you need one of those, you should choose Python2.

Re:Open Source Culture

[jbolden]

When MS bought Nokia, Nokia had already sold Qt to Digia.

Re:Open Source Culture

[EmperorOfCanada]

Python 2.8 is blasphemy to the 3.x crowd. Quite a few 2.7 people are calling for 3.x features to be backported into 2.8. The 3.x supporters say that this will kill 3.x if a 2.8 comes out that is backward compatible with 2.7 and has everything that people like about 3.

There is a huge fight about this. The two positions are fairly incompatible. The 2's insist on backward compatibility; while the 3's say that the 2's are missing the point and that backward compatibility involves too many compromises.

Many people are talking about their own fork to make a 2.8 that, in theory, does what the 2's want. But I doubt this has gone much past words but if that happens then it would be full on civil war.

Re:Open Source Culture

[EmperorOfCanada]

When the transaction was finalized; There were MS stores before that worried me. I thought that MS would ruin it over time but I thought that Digia was going to shoot it right in the face as they tried to monetize it. My thinking was that they would let the open source part rot and continue all further development in some fairly closed and expensive way. But the qt-project seems to be very separate from Digia and I am very happy.

Re:Open Source Culture

[HiThere]

There are, indeed, people with that opinion. Some of them are quite voceriferous. I don't, however, believe that there is any substantial number of them. If they are, then they are welcome to fork the code from my point of view. I don't know whether they would be allowed to keep the name, though.

As for backporting the Python3 features to 2.8...my understanding was that the reason that they weren't backported to 2.7 is that there wasn't any reasonable way to do so.

Re:Phoronix + link to audio ?

[UnknownSoldier]

Agreed 100%.

Yeah, it is pathetic how Phoronix will link "news" to an "earlier" article to itself instead of the actually dam off-site source.

Native Widgets

[robmv]

Can we stop spreading false information about QT?

the native widgets for OS X / Linux / Windows

QT doesn't have native widgets for any platform, QT draw the widgets with their own code, it only skins them with the platform APIs if they are available, Quoting myself:

Native controls means more than to have the same look, if that is the way to measure "nativeness", then Java Swing UIs (Windows/GTK L&F) are native because they call platform theme APIs.

When a toolkit draw controls by itself, the applications normally lose a lot of UI functionality, for example, if Android/iPhone controls add proper default assistive technology metadata to their controls, the toolkit (QT in this example) need to do the same for each control they draw, because the OS don't see buttons as buttons, It see them as a custom control. If the platform control change behaviour in a new OS release, the QT control will not see it, for example when Windows added default context menus to the text fields, self drawed controls don't expose that behaviour until applications are updated with a new version

Re:Native Widgets

[satuon]

In reality, I've never noticed practical differences between Qt and a native application on Windows, or on Gnome Linux. On Android currently it doesn't look native at all, but that's because it's not implemented yet, they plan on doing it later.

Re:Native Widgets

[Anonymous Coward]

If it looks native, thats all a user cares about. And it does look native.

Re:Native Widgets

[tibit]

You do know that Qt has had accessibility support for quite a while now, in both Qt 4 and Qt 5? You do realize that WPF itself is not using the native winapi controls, and is peddled as the "new native way" of doing controls on Windows? You do realize that Qt does way more beyond mere native-looking-skinning of controls? It does actually re-implement platform-specific behaviors on a lot of controls, often in ways that are much simpler to code for than whatever native legacy boondoogle of an API someone at MS or Apple has conceived?

There is something to be said for having uniform principles for the design of an application framework, and Qt is reasonably good in that department. My experience is that the non-nativeness of Qt-provided controls is something that is hard to notice if it can be noticed at all, if the application developer has done their homework.

Re:Native Widgets

[tibit]

Basically, Qt is doing controls on Windows the same way Microsoft is doing controls on Windows these days. So stop with the FUD.

Re:Native Widgets

[robmv]

Accessibility was an example, I was referring about updates to the OS Widgets not being inherited by QT because QT does not have native widgets. It doesn't matter if Microsoft is doing the same with WPF, QT doesn't have native widgets, plain and simple. is that good or bad? is your call.

Re:Native Widgets

[Anonymous Coward]

For the record, if you need a "fully native" toolkit, there's always wxWidgets and its various bindings.

Re:Native Widgets

[Brandybuck]

Android and iOS)are weird platforms because they treat all non-native toolits as second class citizens. You are EXPECTED to use Android/iOS APIs for everything. The idea that people might write apps in a non-Google/non-Apple framework simply did not occur to them. They are too busy trying to reinvent the world to bother with anything that is not invented in the hallowed halls of the Goolgeplex or Arcology.

Re:Native Widgets

[tibit]

Microsoft themselves doesn't use what passes for "native widgets" on Windows in any new development. Seriously. Only their legacy code with Windows 95/NT roots (explorer, old control panel items, legacy utilities) still uses it. There's really no reason to use native widgets on Windows. WPF is the new native, for better or worse, and Qt does a similar thing in Qt Quick 2 controls. Qt's widgets module does as well, although the renderer is still CPU-bound, not GPU-bound. If you really need to use native controls, you can, from within Qt, but what for?

I don't even know what "updates" to native widgets would you care for. Microsoft hasn't (and can't) alter their legacy controls functionality much if at all, and as far as look and feel goes, Qt has to be updated for new major Windows releases anyway. That's not new, and hardly a problem - someone else does this work :) By the way, Qt still uses native APIs to style the controls, that's why you don't get OS X or XP & newer look-and-feel with Qt on anything but the very platform it runs on. Heck, you can't get XP look-and-feel with Qt on anything but XP, in fact. That's also why, if you attempt to use stylesheets to restyle the controls proper, you lose all of the native style, since it's all-or-nothing - just as you can't programmatically change the thickness of a button's border on Windows XP, neither can you on OS X.

Re:Native Widgets

[phoenix_rizzen]

Not to mention that a lot of Microsoft software doesn't use the "native widgets" available on the OS. Just look at every new version of Office on the (at the time) current version of Windows.

Re:Native Widgets

[robmv]

You still don't get it, every OS release make changes of how widgets behave. One example, OS X "natural" scrolling behaviour, you run and old QT application on that platform and I am sure it will not behave the same way and users notice that. QT developers are good chasing every tiny update OS providers do, that doesn't mean that old applications are updated automatically. All applications need to be updated, specially on Windows and OS X where there isn't a shared QT runtime. If WPF is the new native, I am pretty sure that any modifications Microsoft make to old widgets are added to the new ones because I don't think they want an inconsistent experience for their users (sometimes I think they don't care after Windows 8)

I still write a lot of Java Swing code, so I know custom drawn toolkits have their advantages, if you are a good developer using them, and I am not against what QT do, I am only saying that QT are not native controls (only on platforms where it is the platform toolkit)

Is this QT or GTK? http://tirania.org/s/138c98b8.png

It is GTK, do GTK use native controls? NO

Re:Native Widgets

[twocows]

If it looks and acts native, that's all a user cares about. Unfortunately, Qt widgets do not always act native.

Re:Native Widgets

[Anonymous Coward]

Generally vendors do not go around breaking things. Only Apple will implement unnatural scrolling and call it a feature.

Re:Native Widgets

[Anonymous Coward]

On a Mac, you can immediately tell a Qt app apart because it underlines keyboard shortcuts for all the menu items, whereas the standard Mac toolkit simply writes out the keyboard shortcut next to the menu item. But as long as you don't look at the menu bar, the app window looks OK.

Re:Native Widgets

[Anonymous Coward]

You have the reinventing timeline backwards. iOS's code base is directly descended from NextStep, which was already commercially available in 1988. Qt's development didn't even start until 1991.

Re:Native Widgets

[tibit]

Nitpick: Qt is not a "custom drawn toolkit", it is a "custom behavior apart from drawing" toolkit. The drawing into a bitmap is done by platform libraries, that's why you can't get OS X look if you run Qt on Windows.

Qt and FUD

[Anonymous Coward]

> Less than a year and a half after the FUD started [...]

So it was good to start the FUD, I guess? Should we've started the FUD earlier?

don't impose your lang(QML) on device platforms

[keneng]

GTK is far from trash. It certainly compiles and links faster than a Qt app. It can build gui's entirely in your c++ code or integrate with glade-tool-created ui which is on par with qtcreator in that respect. It blends well with c++/c libraries.
I have recently delved into gui development with Qt on Ubuntu touch(ubuntu-sdk) and Qt on Android(Necessitas and Qt for Android). I'm not quite content with either. Newer Qt tools force developers to use QML/declarative script. The ide doesn't offer any easy way to use C++ for everything in Android. It's possible, but it's not very well documented. When compiling and Android app without QML/.ui files, the IDE isn't intuitive to use to get what you need to build the minimum .apk with the AndroidManifest.xml and other Android "deployment" characteristics for plain c++ built-apps.

gtkmm has no complications about assembling everything into an apk file. You just assemble everything c++ into your executable or keep them separate. It's the developers choice unlike android's forcing of everything into an apk. I just prefer desktop app development over mobile device development. Qt doesn't save you time with android. You still need to do your homework and learn everything android anyways. i.e. JNI to get access to special non qml apis. There has been recent discussion about difficulty using persistent storage api with qml. That's so 1990's an issue. There are so many ways of skinning that cat with c++ libs of all sorts. boost serialization and mongodb come to mind, but there are so many others. Even golang(higher-level C++-like) has less problems using gtk and serialization than qt/qml and it has even shorter compile/link times than c++. golang/gtk/serialization compile/link time c++/gtk/serialization compile/link time qt/qml serialization compile/link time.

To be blunt, I would rather compile with gtkmm with Ubuntu/Debian on any device mobile/desktop/cloud given the opportunity.
There will be an opportunity to see gtk on ubuntu touch. I would prefer gtk than qt toolkit on ubuntu touch because it would save enormous amounts of time iterating through compiles/links.

Don't call GTK trash and I won't trash QT. They both have their places, but platforms should not impose language choices on developers like android and ubuntu touch did by forcing everyone to use qt. That was a mistake. All this to say GTK has its strengths and weakness and so does qt/qml/declaratives. It's interesting and useful, but doesn't necessarily save the developer time and qt doesn't necessarily give the best runtime performance if an app has qml/declaratives in it when compared with straight c++. If the ubuntu touch team would have stuck with gtk for the touch interface, I believe they would have finished the ubuntu touch/ubuntu edge prototype completely by now. If Android would get rid of all the apk complexity, provided c++-only gui api and stuck to c++ rather than convoluted java/jni/c++, there would have been even more apps in their play store by now. golang will have greater importance on for building guis/apps on all platforms soon enough. go-gtk bindings exist. So do go-qt bindings. One thing is certain. I don't like QML and that's a subjective thing. Knock yourself out with qml if you want but don't impose it on everyone else. That's bad for business. People will walk away if it's the only developer tool option offered for a device.

Re:don't impose your lang(QML) on device platforms

[Anonymous Coward]

Qt for Android and Qt for ubuntu Touch are beta (at best).
  Hell ubuntu Touch is alpha.

  So go spread FUD elsewhere.

  You want to test the validity of QT vs Gtk compare things that are comparable.

  And the fact is I can make a QT crossplatform (OS X, Windows XP -> 7, Linux X11/Wayland) app 10 times faster than on GTK, and it will look nice in ALL enrironments. Is Qt perfect ? far from it, but it is way, wayyy better than Gtk.

  Oh and PS: I use Gnome 3 as my main desktop env. Still.

Anecdote of asshole Gnomes: libnotify timeout

[Anonymous Coward]

For the longest time the man page listed a timeout parameter but the godlike gnomes decided to simply ignore the parameter, because they knew better...

I couldn't find a good bug but this should give you a hint https://bugzilla.gnome.org/show_bug.cgi?id=665761

I guess the gnomes have taken alot of flak for gnome-shell but some of it is deserved and no excuse to act like total assholes. I wish Karen the best of luck herding these rude, stubborn cats...

That's Depressing

[zakkudo]

I feel like all the time I donated helping with gtk questions on the gtk irc channels was useless now. )-:

Re:That's Depressing

[Anonymous Coward]

I feel like all the time I donated helping with gtk questions on the gtk irc channels was useless now. )-:

You really should know by now that any amount of time spent helping anyone using any toolkit, library, platform, language, or framework is really just time spent pissing off fans of all the opposing toolkits, libraries, platforms, languages, and frameworks.

Re:It's true!

[t_hunger]

So Linus and Dirk are not compatible with 'old'-style linux users? That is hilarious.

QT Devs

[Anonymous Coward]

Explanation: QT Devs are not 13-year olds.

Re:QT Devs

[smash]

More diplomatically put: Qt was originally a for money project aimed at cross-platform application development. GTK is a toolkit that started out being branched off from one single application and is now developed by a bunch of people for Gnome, with little focus on actual application development, or any other platform other than Linux. Even other Unix platforms get shafted by Gnome.

You don't know.

[Anonymous Coward]

It's not retarded.

It's more retarded to redo every single backend process because each OS has its own "definition" of how to do IPC, for example.

Office has its own clipboard. THAT'S retarded.

Office on Mac has a large part of Windows libraries installed with it so that it can run on Mac as it does on Office. THAT'S retarded.

Compared to those, GTK's practically elite.

Where GTK is better than QT

[Anonymous Coward]

List of aspects and properties in which GTK beats QT:

Re:It's true!

[Grishnakh]

no not retards, simply 'old'-style linux users,...

Qt was initially released in May 1995. It's not exactly a product of young people, and is almost as old as the Linux kernel itself. GTK was initially released in April 1998, almost 3 years later. The GTK devs are the new kids on the block.

So maybe Canonical was right? Possibly?

[GrueMaster]

How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason? Are you now going to flame Intel because their developers are saying the same thing? I should also point out that this is a prime example of how open source development works; if you don't like what one group has to offer, switch to something else. It is the same reason GTK/Gnome came into existance, the developers didn't like QT (for licensing reasons). It is the same reason Cinnamon and Mate exist. It is the same reason MariaDB exists. And it is the same reason Mir/Unity exists. Note that I do not work for Canonical, but I do work with ALL of the major commercial distributions daily. For ease of installation and deployment to my customers and users, I can't beat Ubuntu.

Qt and C++

[Anonymous Coward]

I looked into Qt about 6 months ago and liked it until I read on one of the main Qt pages that they were not going to do any further development on the C++ side. Instead they were going to focus all their attention on QML. I know QML can be extended with C++ but now when I look at their info I can't find that language.

Have they reversed course on this? Can anyone tell me if Qt is planning on supporting C++ for many years to come or are they trying to get out of C++?

Re:Qt and C++

[t_hunger]

Sorry, but that is non-sense. C++ support has always been and will always be a focus of Qt development.

During Nokia times the QWidgets were considered to be "done" in the sense that there were no new exciting features expected to happen. But then widgets are pretty well used for years, pretty complete (all the standard stuff is there and you will need to write the rest anyway) and the APIs were hammered down ages ago. Bugs were going to be fixed as they are reported, so the code was and is fully supported. I think you are referring to this... it was awfully badly communicated back then and did raise quite a ruckus.

That was the state when Nokia was still at the helm: Digia is putting way more resources into "classic desktop parts" than Nokia did and with that widgets do see more love again.

Re: Qt and C++

[Anonymous Coward]

Yes...that is what I was referring to. When they considered them "done" however, the language they used could easily have been misinterpreted to mean we will leave C++ support dying on the vine. I'm glad that this is not the case because I'm still very interested in Qt.

Re:So maybe Canonical was right? Possibly?

[t_hunger]

How many people here flamed Canonical 3 years ago when their developers ditched working on Gnome3 in favor of Unity for this very reason?

Canonical did not ditch gnome3: They used all the bits and pieces and just replaced desktop itself. Unity was written in GTK, just like gnome, so there was no productivity win there. And the problem was IIRC more that way the switch was communicated (or better: not communicated) than the switch itself.

Are you now going to flame Intel because their developers are saying the same thing?

It is Dirk speaking here, not Intel. He makes that very clear during his presentation. Dirk just happens to work for Intel -- which somehow makes this newsworthy. This is definitely not Intel that made the announcement to not like GTK anymore.

Re: It's true!

[t_hunger]

You are aware that you this is a project founded by Linus himself and that Dirk is involved with open source development since 1988, often working at the kernel and other core infrastructure you are likely to use if you run Linux?

I somehow doubt that these two are not aware of how open source works. I am further convinced that they are bright enough to figure things out on their own by reading the code and/or using the internet.

Not unexpected...

[guacamole]

I remember reading an informal opinion/rumor by a Sun Microsystems developer that KDE/QT was the preferred environment, but they were sticking with Gnome/GTK for Solaris purely because of license issues.

Sorry, but coming up with something new is not

[Marrow]

the act of anarchy you seems to believe. There is value in starting from scratch. They weren't being paid, and they learned a lot as part of the process. Maybe you don't like the end product, but I'm sure they enjoy the fruits of their exploration: the knowledge and experience they gained.

It was like this a deacde ago, too.

[Lendrick]

My experience with asking for help with GTK was having random people rudely tell me that I should go read the documentation (which, incidentally, I *did* read, and it was woefully incomplete). Qt actually has good documentation, but in the rare instances when I need help, people are always happy to assist. I wouldn't touch GTK again with a ten foot pole.

Re:It was like this a deacde ago, too.

[Anonymous Coward]

I had the same experience with GTK and Gnome. Most non-trivial things are undocumented, and the documentation for trivial things is often wrong.

The biggest problem with both GTK and QT, is that they force you to use their event loop, and if you can't mutilate all your event sources into it somehow, you end up writing a controller thread simply to communicate between the shitty GTK/QT event loop and your programs real event loop. The source for GTK and QT code always ends up being inside-out because of the forced and unnatural programming model.

Re:It was like this a deacde ago, too.

[Lendrick]

It's undocumented, but I believe at one point someone showed me how to put Qt in your own event loop. I wish I could remember how to do it now.

Windows 8

[G3ckoG33k]

Windows 8 (and the entire Windows 8.x by extension) may be the prime example of that.

That interface on a desktop computer may be worse than anything else built by Microsoft.

Re:Windows 8

[DuckDodgers]

The future of most of consumer computing is mobile. Microsoft desperately wants a big piece of that market, so they did something they knew full well would enrage millions of loyal customers - they forced their mobile UI onto desktop and server devices as a way to get people who were avoiding Windows Phone 7 like the plague to get used to its user interface. Windows Phone has under 5% of the mobile market in the US but closer to 8 or 10% in other countries, and Microsoft is still spending money like water to grow marketshare.

If Windows 8 was merely Windows 7 2.0, it would have sold dramatically better and Microsoft's mobile future would be dead instead of alive but weak.

Re: It's true!

[the_B0fh]

What I got out of the talk, GTK vs QT:

GTK
1) Lousy documentation
2) Lousy code
3) Lousy developer community support

QT
1) Good documentation
2) Good design
3) Great developer community support

Are you really saying Linus Torvalds "feels ENTITLED to the time of open source volunteers, when they don't make every effort possible to answer their own question."?!?!?!

Any other developer, you might be able to say that, but Linus wrote the kernel himself, and still answers emails (I've had responses to questions I sent him!)

So, stop justifying and defending the GTK people.

Re: It's true!

[the_B0fh]

Put it another way. When Linus Torvalds and 3 of the core GNOME maintainers *CANNOT* figure out how to do something, and Linus asks for help from the GTK community and got a "meh", your community sucks.

Re: It's true!

[Anonymous Coward]

Are you getting payed to say this garbage? Go and read more about open-source before pretending you are involved in it.

Theo DeRaadt?

[drwho]

Theo now works for GNOME? huh.

Tkinter/ttk anyone?

[Anonymous Coward]

What about Tkinter (e.g. in Python 3: http://docs.python.org/3/library/tkinter.ttk.html)? The ttk widgets have a native look and feel across platforms, and yes, you have it in standard Python since 2.7.x or so. Yeah, it's is nothing compared to Qt or GTK in terms of complexity, but shouldn't we strive for simplicity anyway?

Watched the presentation, really liked it

[mrflash818]

Appreciated the presentation, demos of the application running on the different OS's and different GUI toolkits.

Also seems they discovered/re-discovered the concepts of the design pattern of Model-View-Controller while working on it : )

Bah!

[Anonymous Coward]

In my day we used Motif, or OpenLook, and we liked it. If'n you want something fancier, there's Tk.

Now all you kids get off my lawn.

Failure on Subsurface devs' part

[dhasenan]

The Subsurface developers failed to accomplish things that are common in many GTK+ applications. I'm not sure if that means the various GTK+ language bindings are a lot better than the native C library or what, but it looks like the main benefit of switching to QT was a forced rewrite of the UI.

In-place editing? Not that hard.

The ratings stars? Banshee has it. So does Rhythmbox.

Native look-and-feel is a valid complaint. If GTK+ used the native file dialogs in Windows and OSX, that would help a lot. Adding default themes for those platforms that better mimic native controls (and such themes exist) would also help.

Granted, that says nothing about the community, but from a technical perspective, that talk was worthless.

Re:Failure on Subsurface devs' part

[Anonymous Coward]

The Subsurface developers failed to accomplish things that are common in many GTK+ applications. I'm not sure if that means the various GTK+ language bindings are a lot better than the native C library or what, but it looks like the main benefit of switching to QT was a forced rewrite of the UI.

In-place editing? Not that hard.

The ratings stars? Banshee has it. So does Rhythmbox.

Native look-and-feel is a valid complaint. If GTK+ used the native file dialogs in Windows and OSX, that would help a lot. Adding default themes for those platforms that better mimic native controls (and such themes exist) would also help.

Granted, that says nothing about the community, but from a technical perspective, that talk was worthless.

The Subsurface developers failed to accomplish things that are common in many GTK+ applications.

If some of the people that wrote the kernel you are running on are unable to figure out how to do common tasks, then that says a lot about the APIs and documentation of a tool kit.

In-place editing? Not that hard.

The ratings stars? Banshee has it. So does Rhythmbox.

Are those apps using something from GTK or are they having custom code for this?

Note that Linus said at the end of the presentation that inplace editing was possible but totally messed up the focus handling due to bugs in the code (if I did not mishear that, Linus did not have a mic).

Native look-and-feel is a valid complaint. If GTK+ used the native file dialogs in Windows and OSX, that would help a lot. Adding default themes for those platforms that better mimic native controls (and such themes exist) would also help.

That is a valid concern for years now. That the (apparently already existing) themes are not packaged into gtk says something about how low a priority this must be and pretty much confirms the presenter's statement that gtk does not care at all about non-gnome platforms.

[...] from a technical perspective, that talk was worthless.

I don't think so: If those guys can not figure gtk out, then I do not even need to bother trying and should head for Qt right away. That is valuable technical information to me.

Re:Failure on Subsurface devs' part

[Sri Ramkrishna]

Writing a UI is not the same as a kernel. It is a different mind space.

Re:Failure on Subsurface devs' part

[keneng]

I don't want to judge Subsurface as the be-all end-all conclusion as to which toolkit(kde or gtk or qt)/which gui language(c++ vs qml/declarative vs java vs javascript) is best. That's not my point. My point is we shouldn't trash gtk/gtkmm. Gtk/gtkmm have their strengths and the subsurface team failed to discover gtks strengths given their limited effort/time unfortunately.

My main concern is for the subsurface team to be seen as simply plugging QT as the ONE AND ONLY GUI tookit all developers should be imposed to use. I am also concerned about the subsurface team plugging the QML/declaratives(javascript-like) as the ONLY language to use for building GUI's.

It is important for developers to have options by supporting the variety of languages/toolsets in the developer ecosystem not only on Linux Desktops, but also on all mobile devices be it Android, Ubuntu Touch, Jolla , MozillaOS or others.

I believe gtk is a valid alternative to qt and I wish it to remain so. I also believe golang like other newer languages will be easier to use complementary alternatives to c++ and deserve more love and attention also since their bindings with qt as well as gtk are getting more maturity. I didn't realize Unity uses gtk apis. Ubuntu continues to ship gnome-ubuntu based on gtk apis. I recently heard phablet-flash was re-written using the golang. There is a reason for that. golang compiles/links faster than c++ without compromising runtime performance. I'm not saying golang is the only tool to use. On the contrary, it solidifies my position that qt/qml shouldn't be the only alternatives to consider for building apps/guis if you're going to consider a code rewrite. golang is hugely interesting because of the way it more easily creates bindings for existing c/c++ libs than perl, python and JAVA/JNI.

Re:Failure on Subsurface devs' part

[Anonymous Coward]

I don't want to judge Subsurface as the be-all end-all conclusion as to which toolkit(kde or gtk or qt)/which gui language(c++ vs qml/declarative vs java vs javascript) is best.

No, it is one data point. Wireshark and LXDE are two more... they announced to be heading from GTK2 to Qt, too. This seems to be becoming a trend, which is worrysome, especially since I do not see any reaction in the Gnome camp to counter that trend. But then I am not deeply involved in that area, so I might just be missing something.

That's not my point. My point is we shouldn't trash gtk/gtkmm. Gtk/gtkmm have their strengths and the subsurface team failed to discover gtks strengths given their limited effort/time unfortunately.

What are those strengths? The main strength I can find here in the comments seems to be that C is the language of choice and that sounds like a dubious argument to me. Admittedly slashdot comments are not the best place to look for the strengths of anything...

My main concern is for the subsurface team to be seen as simply plugging QT as the ONE AND ONLY GUI tookit all developers should be imposed to use. I am also concerned about the subsurface team plugging the QML/declaratives(javascript-like) as the ONLY language to use for building GUI's.

Did you watch the actual presentation? I do not see that happening.

About QML/javascript: That is an additional option that is available to Qt developers. You seem to be in favor of having many options, so why does that bother you?

It is important for developers to have options by supporting the variety of languages/toolsets in the developer ecosystem not only on Linux Desktops, but also on all mobile devices be it Android, Ubuntu Touch, Jolla , MozillaOS or others.

I agree.

I believe gtk is a valid alternative to qt and I wish it to remain so.

It is? Does it even run on Jolla, MozillaOS, Ubuntu touch, Android? Well, they are all unix-oid, so maybe it can be ported, but is there serious support for those platfroms available in GTK? What about iOS? Qt is the environment of choice on Jolla, Blackberry and Ubuntu Touch, that is well supported on those platforms. Qt also runs on iOS, the big mobile OS which is mysteriously missing in your list.

I also believe golang like other newer languages will be easier to use complementary alternatives to c++ and deserve more love and attention also since their bindings with qt as well as gtk are getting more maturity. I didn't realize Unity uses gtk apis. Ubuntu continues to ship gnome-ubuntu based on gtk apis. I recently heard phablet-flash was re-written using the golang. There is a reason for that. golang compiles/links faster than c++ without compromising runtime performance. I'm not saying golang is the only tool to use. On the contrary, it solidifies my position that qt/qml shouldn't be the only alternatives to consider for building apps/guis if you're going to consider a code rewrite. golang is hugely interesting because of the way it more easily creates bindings for existing c/c++ libs than perl, python and JAVA/JNI.

Are there Qt bindings for golang yet?

Qt and QML are actually two different options. Qt(Widgets) are what subsurface and most other existing desktop Qt applications use. QML/Qt Quick is more suitable for highly customized UIs at this time... but it is moving into the desktop space now that something like widgets comes out of the box.

Re:Failure on Subsurface devs' part

[Anonymous Coward]

Yes, that is right. But please do not claim that writing a simple UI for an application is rocket science either.

If two core kernel devs (one of them hacking on the underlying X-windows for literally decades) can not figure that out makes me doubt the quality of the UI toolkit they were using. Dirk repeatedly said they could not make something work that the documentation said should work and then were told they are idiots for failing. I fully understand how he arrived at the conclusion that the toolkit is buggy, the documentation lacking and the community unfriendly from there!

What I would like to read about is how gtk/gnome wants to counter that impression. Subsurface is not the only project that jumped ship recently and went from gtk2 straight to Qt.

Mozilla Servo

[Flammon]

While the old GTK vs QT and C vs C++ debate continues, the interesting stuff is really happening in the Web space with projects like Mozilla Servo where the UI is parallelised as much as possible. Servo might be rendering HTML at first but it could just as easily render another XML dialect designed for apps like XUL. Actually, it would be nice if they could move away from XML and move to JSON but I digress.

Re:Mozilla Servo

[Anonymous Coward]

Count me unimpressed: That is pretty much vapor-ware at this time.

Take a look at Qt Quick and QML if you want UIs running on GPUs now.

Re:It's true!

[Mister Liberty]

Well, Dirk Hohndel, nice diversion, but what about this: Intel is a shill for the NSA.
How do you respond?

Re:It's true!

[Anonymous Coward]

GTK is horrible. I found it impossible to edit the NATION files in Freeciv and getting them to work without hanging the application. Note that Freeciv uses GTK - even the Windows version of it does.

Re:It's true!

[Anonymous Coward]

Shhhh, don't mess up what sounds good with facts.

Re: It's true!

[Anonymous Coward]

Put it another way. When Linus Torvalds and 3 of the core GNOME maintainers *CANNOT* figure out how to do something, and Linus asks for help from the GTK community and got a "meh", your community sucks.

If indeed 3 core gnome maintainers can not figure out how to get a application with a pretty simple UI working, then it is not just your community that sucks! Either your product or your core maintainers suck, too.

Re:It's true!

[Darinbob]

Qt is also partially commercial while still being open source. This means that there's a financial incentive to treat users with respect; ie, they're customers instead of lusers.

Re:It's true!

[mugurel]

Informative as this is, GP was not saying they were *old* linux users, just they were old-*style* linux users.

Re:It's true!

[Zero__Kelvin]

"Simply folks who REALIZE they lend a helping hand when they send you a friendly "RTFM" or multiple links instead of simply helping out even is they could help out and solve the problem in a few sentences. "

FTFY. As an added bonus in this post I am going to help you in a way that nobody has (apparently) ever helped you before. I mean this with 100% sincerity. Before you ever stop to think if you might be more qualified than those of us with more than 30 years experience, Read This.

If you can show me a case where the aforelinked content was clearly understood, and the advice followed, where the person didn't provide the kind of help you want then we can talk. Right now, I guarantee you are grousing about them, when it is you that is woefully in err, and you and your "brethren" still just don't get it..

Re: It's true!

[Zero__Kelvin]

" I myself have stopped releasing any more projects due to the arrogant and unappreciative behavior of my users."

Ironically, they are both much less angry now than they used to be.

Found it.

[Lendrick]

http://stackoverflow.com/questions/1051333/combing-an-external-event-loop-with-qts