Why is Qt better than GTK?

[schmalzler]

For Qt, the moc output is C++ standard, you can pass it to any compiler, but the moc input (with the Qt specific additions) is not, quite simply.

moc creates definitions. If you don't run moc the files still compile cleanly, you only will get link failure due to missing definitions. So even the moc input is standard compliant, as it get's compiled cleanly. Because all the additions are implemented as macros on the "input side", and as long as macros will remain standard compliant the "moc input" will also be standard copmliant.
Quite simple, isn't it?

[AnonymousCoward]

well "qt keywords" like signals, slots, emit are replaced to empty string with #define. the Qt headers are standart C++ code.

[FLHerne]

So any project using yacc, lex, google protocol buffer, gsoap, or any code generation tool is by definition "non-standard" ?

A "standard" project is allow only to use a compiler and linker and it becomes non-standard if it uses the same compiler/linker to generate intermediate development tools (like the moc) to simplify or add feature to the final product?

Or are some tools allowed, but not the moc? In that case who gets to decide which tools are "standard" and which aren't ?

The ones you mention (or at least those that I recognise from them) are fairly general-purpose code-generators used by multiple projects to generate a wide variety of code.
I don't know if moc could be used more generally, but in practice it's only used by Qt to implement a very small collection of specific extra features.

[erendorn]

moc creates definitions. If you don't run moc the files still compile cleanly, you only will get link failure due to missing definitions. So even the moc input is standard compliant, as it get's compiled cleanly. Because all the additions are implemented as macros on the "input side", and as long as macros will remain standard compliant the "moc input" will also be standard copmliant.
Quite simple, isn't it?

Wow, that's neat, I stand partially corrected.
Partially, because linkage is covered by the standard

3.2.3 Every program shall contain exactly one definition of every non-inline function or object that is used in that
program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the
standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8).
An inline function shall be defined in every translation unit in which it is used.

[schmalzler]

Wow, that's neat, I stand partially corrected.
Partially, because linkage is covered by the standard

Doesn't make any sense... First you said moc is OK, the input is the issue, now it's the missing implementation.
That's what moc is used for. You always can write all the code moc creates on your own. Good luck But why do an error-prone job on your own when you can rely on a tool? It's as simple as integrate some program calls (moc) into the build system (if you don't rely on qmake/cmake/...)

@FLHerne: The "very small collection" is introspection (which C++ does not offer btw.) and the whole SIGNAL/SLOT mechanism (though Qt5 changed in tat regard), so hte core of Qt.
I never worked with gobject-introspection, but I am sure you have to rely on generated code, too.

[justmy2cents]

well, as developer who used gtk and switched to qt i can name few reasons why qt beats gtk
- api stability, while gtk2 was rocking here, 3 is disaster
- not being taken over by DE. CLA is a small price to pay for that and doesn't even touch you if you write qt it self
- true cross platform api. apps really look/work as native everywhere

Gtk# is a Graphical User Interface Toolkit for mono and .Net. The project binds the ... Want to know how Gtk# is being used in the real world? Check out some ...

yea, if we wouldn't still be waiting for gtk#3. api instability is really hard on bindings and i kinda understand devs working on it

[sandy.martel]

Doesn't make any sense... First you said moc is OK, the input is the issue, now it's the missing implementation.

Yeah, interresting, isn't it? Like I said in my first post and someone else reiterate, everything that goes around (in/out the moc or the implementation files) is standard c++. And yet, someone some day planted the idea that it wasn't and it stuck, first with Qt haters, then as a general misinformed idea of how Qt works.

[FLHerne]

@FLHerne: The "very small collection" is introspection (which C++ does not offer btw.) and the whole SIGNAL/SLOT mechanism (though Qt5 changed in tat regard), so hte core of Qt.
I never worked with gobject-introspection, but I am sure you have to rely on generated code, too.

I didn't say it wasn't useful, or important to Qt - I have written some code with Qt, and think it's rather nicer than GTK+.

I was specifically addressing sandy.martel's suggestion that since lex and yacc aren't considered 'non-standard' moc shouldn't be either. moc is neat, but it's not 'standard' because it's useful (or at least used) only for Qt and a fairly small fixed set of generated code, and that's where I think the boundary is that sandy.martel denies the existence of.

[liam]

well, as developer who used gtk and switched to qt i can name few reasons why qt beats gtk - api stability, while gtk2 was rocking here, 3 is disaster - not being taken over by DE. CLA is a small price to pay for that and doesn't even touch you if you write qt it self - true cross platform api. apps really look/work as native everywhere yea, if we wouldn't still be waiting for gtk#3. api instability is really hard on bindings and i kinda understand devs working on it

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

[sandy.martel]

... and that's where I think the boundary is that sandy.martel denies the existence of.

I see, yes, I do deny this boundary. I deny it because it troubles me in defining what is "standard c++". moc is a C++ tool build in C++ for a C++ framework, but it's only useful to the few hundreds (or thousands?) projects using Qt. Trying to define that boundary will always be a subjective process.