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

[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

[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

[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

[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

[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

[hubie]

inherited from old-timer UNIX neckbeards.

Old-school UNIX guys had full beards.

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]

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

[cheesybagel]

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

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

[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

[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

[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

[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

[marcosdumay]

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

It's different from QT.

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

[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

[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

[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

[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

[Dahamma]

Can't resist.

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

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.

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:It's exactly why GTK was born!

[MickyTheIdiot]

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

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

[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

[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

[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

[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

[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

[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: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.

"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

[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

[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? :-)

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?

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.

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

[jbolden]

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

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

[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.

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.

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:It's true!

[t_hunger]

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

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.

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.

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: 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.

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'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]

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.