Why is Qt better than GTK?

[erendorn]

Yes, they need to be part of the standard, because macros, templates etc. are part of the language specification, there needs to be a definition how they need to be handled so that compiler writers konw how they need to implement them. But gcc- and binutils-developers do not care where the input for their tools comes from.
Again: The C++ standard does not name any tools that are needed or allowed! So "external tools" are completely out of scope! The standard just defines the bare minimum that is needed to correctly transform the source code and for runtime behaviour (which is unimportant for moc...).

Well, Qt code uses more than this bare minimum. Qt code requires C++ AND the moc. This, by any definition, is a strict superset of C++.
Out of scope requirement = non standard.

[FLHerne]

Again: The C++ standard does not name any tools that are needed or allowed! So "external tools" are completely out of scope!

That's sort of the point. With a toolchain that complies exactly with the C++ standard (providing no additional processing/features) it's impossible to compile code that relies on the moc. You can compile and link code that uses standard preprocessor directives, or templates, or anything else that's defined by the standard - but not moc-input code, because the standard doesn't specify the moc's existence or behaviour.

Of course, that makes all the other code-generators 'non-standard' in the language-specific sense, but they're 'normal' (or 'standard' colloquially) because they're used by multiple projects, usually with more flexibility in the code they generate than the moc has, and in some cases have multiple (near-)compatible implementations.

[justmy2cents]

One of the gtk developers said during, i think it was last year's guadec, that gtk3 isn' intended to be used for either "large projects". He said that he expects gtk4 will be far more stable. IOW, gtk3 is a rather extended experiemental period That's just a great way to lose developer support. Your second point is, I think, actually a strength. It is both simpler and more efficient to target a toolkit to a single platform. So, although they take patches for other platforms they seem to target only linux. There is a cost to abstraction, whether it be memory, complexity, or efficiency. Gtk+ doesn't have the manpower to develop something to compete with qt, so it makes sense for them to make their work as easy as possible while still meeting their needs. The separate question is whether or not they've done a good job. Certainly clutter is a bit crap, hence why they're dumping it and plan on giving putting a scene graph into gtk itself. A bigger problem, though, would seem to be the difficulty with creating custom widgets. I've no idea why this is, but you can see things like the new anaconda installer's design was compromised b/c of limitations with gtk (see Mo's blog posts and compare her mockups to the final version).

1st one would be nice as gtk is really neat api to use and instability is major break. as far as 2nd one, there is a difference between being tied to one platform and being tied to one platform if it deviates from how other software works. qt is and always was tied to kde, but not once did it shown as a failure. main problem with gtk project being almost unportable in 3 era does not derive from lack of manpower, but from deviation from other OS-s in basics. beside unstable api, that would be 2nd detriment. how do you expect people to use desktop if less and less developers are writing for it since it is not portable? this seems that gnome developers would like to fart and smell the roses at the same time without realizing they are too small for people to smell their farts just to smell their roses

also, just as joke if lack of manpower is the problem then it has to be really severe. gtk.org doesn't agree with you in one single word. all, nice and shiny there when you read it not to mention it works everywhere

[schmalzler]

Yes, they need to be part of the standard, because macros, templates etc. are part of the language specification, there needs to be a definition how they need to be handled so that compiler writers konw how they need to implement them. But gcc- and binutils-developers do not care where the input for their tools comes from.
Again: The C++ standard does not name any tools that are needed or allowed! So "external tools" are completely out of scope! The standard just defines the bare minimum that is needed to correctly transform the source code and for runtime behaviour (which is unimportant for moc...).

[erendorn]

You have to understand that "the c++ standard" is a manual for people "implementing C++"

But I think that's the core issue. For "implementing C++" there is a definite list of things that one must support, the things that are explicitly written in the standard. If you use any "C++ implementation", the things from this list will be implemented (or listed as missing from the implementation). If a feature is not on the list, you cannot expect it. That's the difference between standard and not standard. It does not have to be against it. It just have to be "not in it". Code generation using the preprocessor is described in the standard, and available in all compliant implementations. Same for templates. If you use those, you are clear with any "C++ implementation". But code generation by any other mean is not.

[schmalzler]

You have to understand that "the c++ standard" is a manual for people "implementing C++" - Those freaks writing GCC/binutils/LLVM/CLANG. The definition of the language is more or less a by-product. The standard itself is very permissive, it nearly never disallows the implementer to do things in one or the other way. That's why you can't find anything about a "tool chain" that HAS to be implemented/used. An implementer might do extreme optimizations which require one or mote additional tools to preprocess the sources (think of limited platforms where you can't keep all needed declarations in memory during the process of tranlation - you will store certain informations in files).

But that is the point, isn't it? HipHop output is standard c++, but php isn't, and, more importantly, conversion from php to c++ isn't either.

The CONVERSION isn't covered by the standard, hence it's not really relevant. But the OUTPUT of the conversion is. But in my OPINION it would not qualify as a project _written_ in C++. You have to do the whole development in PHP, people knowing only C++ won't be able to contribute code. Qt programs are written in C++. A C++ developer will immediately be able to start contributing. The project ships with a build system that makes use of all tools needed to translate "the sources" into "the program".
And of course the last sentence is true for HipHop/PHP/...-transformed projects: You deliver the sources together with a build system, so you make sure everything related to C++ goes the right way. Then everything related to translation of C++ code into "the program" complies with the standard.

The discussion in your link says the same, by the way. Dyn libraries do not violate the standard. They are simply out of scope, and as such not standard(ized).

Dynamic loaded libraries (libraries loaded during runtime; shared libraries can also be loaded during startup time which makes them part of the program) are not covered by the standard and so they can't violate the standard.
moc is not covered by the standard and so it can't violate the standard - yes that's right

[erendorn]

Well HipHop certainly produces standard c++.

But that is the point, isn't it? HipHop output is standard c++, but php isn't, and, more importantly, conversion from php to c++ isn't either.

The discussion in you link says the same, by the way. Dyn libraries do not violate the standard. They are simply out of scope, and as such not standard(ized).

[erendorn]

Not forbidden by the standard = left to implementers The C++ ISO/IEC standard does not know anything like a "default tool chain", that was my point. It knows/defines "translation unit", "linkage" and NOT compiler and linker!
And it does not forbid code generators, because it does not matter.

A less drastic example than HPHPc:
Do you consider the #import directive to be standard C++?

[doom_Oo7]

So HPHPc is standard c++?

Well HipHop certainly produces standard c++.

It's like if you said RAD tools like WinDev weren't compliant to the c++ standard. It doesn't matter because they are not covered by the standard.
A good discussion about what is and is not a standard is here (about the shared libs that were talked earlier) :

http://stackoverflow.com/questions/8002678/do-dynamic-libraries-break-c-standard

[erendorn]

Not forbidden by the standard = left to implementers The C++ ISO/IEC standard does not know anything like a "default tool chain", that was my point. It knows/defines "translation unit", "linkage" and NOT compiler and linker!
And it does not forbid code generators, because it does not matter.

So HPHPc is standard c++? It's not forbidden by the standard, and you can pass the output to a standard tool chain. It's only a code generator after all.

It doesn't matter what's in the tool chain, or what is the tool chain. What matters is what you can put in it and expect to work. You cannot put qt code in it and expect it to work.