Announcement

Collapse
No announcement yet.

Why is Qt better than GTK?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • sarmad
    started a topic Why is Qt better than GTK?

    Why is Qt better than GTK?

    I've heard so many people saying Qt is better than GTK, but I'm yet to see one giving a proper technical explanation of this. I want to know which one is ARCHITECTURALLY better. Qt seem to be more complete and comprehensive, but I hate the following:
    * Qt doesn't use standard C++, instead it uses a layer on top of C++. It just doesn't sound right.
    * Qt reinvents the wheel with QML, compared to GTK which depends on Clutter, JSON, CSS for example.

    So, what am I missing? Why do people seem to favor Qt? Is it only because Qt has some corporate support behind it making it more mature, or there are architectural reasons behind that?

    Please no trolling and flame wars, I want technical answers. And "theme A looks better" doesn't count as technical.

  • carewolf
    replied
    Originally posted by mhogomchungu View Post
    That is just not true.

    If you have a malformed C++ source file,the C++ compiler will refuse to compile it,it is just that simple.

    The fact that any C++ compiler can parse a Qt based C++ source file and generate object code for the source file should be proof enough that the Qt based source file is "C++ standard compliant".If it wasnt standard,the C++ parser would complain about it,its just that simple.

    Qt's extensions are just macros that hides the ugly details of how it stretches C++,but those macros live within the rules of the language.

    What moc does is generating addition "standard C++" code that glue together the expanded macros.Remove moc and all Qt based code will compile just fine,things will just fail to link because the expected glue will be missing.If you write Qt code,you can write the expected glue yourself,skip moc and things will build and link just fine.Why couldnt they come up with another macro that provided the glue?Who knows,maybe they reached the limit of their collective imaginations.
    Because C++ is not quite there. Almost but not quite, even C++14 will be missing a few things if feature parety is to be maintained. See http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by FLHerne View Post
    This is pretty much true - projects that use code that isn't in the C++ standard are rather common. As I said earlier though, most of these use general-purpose, multi-project code generators that are at least 'standard' in the colloquial sense (not the C++ one) rather than a project-specific one.
    To bring this full circle, though, how does this effect Qt vs GTK+? GTK has Vala, which is an entirely separate programming language that has to go through a pre-processor to get C. It isn't required, but then again neither is moc. On the other hand, moc is more central to Qt than Vala is to GTK+.

    On the other hand, it sounds like gobject requires quite a bit of boilerplate to manually code introspection, which Vala handles for you. How does that compare to the amount of boilerplate needed to do the same thing manually with Qt?

    Then there is these perl libraries used in installation. What do they do?

    Leave a comment:


  • FLHerne
    replied
    Originally posted by saulo View Post
    EFL is better than Qt and GTK
    Are you going to provide any supporting arguments for that?

    Leave a comment:


  • saulo
    replied
    EFL is better than Qt and GTK

    Leave a comment:


  • FLHerne
    replied
    Originally posted by AnonymousCoward View Post
    I'm not sure anyone here is arguing that the moc is unnecessary or a bad thing, just that it clearly isn't standard...

    Originally posted by Ancurio
    8) Any serious project in existence uses code generation (config.h)
    => barely any standard C++ using projects exist
    This is pretty much true - projects that use code that isn't in the C++ standard are rather common. As I said earlier though, most of these use general-purpose, multi-project code generators that are at least 'standard' in the colloquial sense (not the C++ one) rather than a project-specific one.

    Leave a comment:


  • AnonymousCoward
    replied
    why Qt use moc http://qt-project.org/doc/qt-5.1/qtdoc/why-moc.html

    Leave a comment:


  • Ancurio
    replied
    Originally posted by erendorn View Post
    Let's make a quick recap of those very fruitful last 6 pages.

    1) Qt code + moc output is c++
    => Qt code is the code without moc output, as per Qt documentation

    2) Qt code + manually written definitions is c++
    => Qt code is the code without the additional definitions, as per Qt documentation

    3) Qt code has a valid c++ syntax/compiles correctly
    => c++ code must not lack definitions, as per c++ standard

    4) A strict subset of Qt does not require the moc / is c++
    => Qt is not a subset of Qt, as per definition of "strict subset"

    5) The standard does not explicitly forbid running tools for conversion.
    => see answers 1, 2 and 3.

    6) Qt is useful
    => yes, but irrelevant

    7) Other tools do it
    => yes, but irrelevant

    Did I forget some?
    Yeah, I think

    8) Any serious project in existence uses code generation (config.h)
    => barely any standard C++ using projects exist

    Leave a comment:


  • schmalzler
    replied
    Originally posted by erendorn View Post
    Let's make a quick recap of those very fruitful last 6 pages.

    1) Qt code + moc output is c++
    => Qt code is the code without moc output, as per Qt documentation

    2) Qt code + manually written definitions is c++
    => Qt code is the code without the additional definitions, as per Qt documentation

    3) Qt code has a valid c++ syntax/compiles correctly
    => c++ code must not lack definitions, as per c++ standard

    4) A strict subset of Qt does not require the moc / is c++
    => Qt is not a subset of Qt, as per definition of "strict subset"

    5) The standard does not explicitly forbid running tools for conversion.
    => see answers 1, 2 and 3.

    6) Qt is useful
    => yes, but irrelevant

    7) Other tools do it
    => yes, but irrelevant

    Did I forget some?
    Yes, of course. Reading and trying to understand the C++ standard document needs interpretation. Interpretation makes use of a personal opinion. The more a document lacks concrete advices the more interpretation is needed - and the C++ document makes heavy use of lacking concrete advices in order to leave it to implementers.

    Leave a comment:


  • erendorn
    replied
    Let's make a quick recap of those very fruitful last 6 pages.

    1) Qt code + moc output is c++
    => Qt code is the code without moc output, as per Qt documentation

    2) Qt code + manually written definitions is c++
    => Qt code is the code without the additional definitions, as per Qt documentation

    3) Qt code has a valid c++ syntax/compiles correctly
    => c++ code must not lack definitions, as per c++ standard

    4) A strict subset of Qt does not require the moc / is c++
    => Qt is not a subset of Qt, as per definition of "strict subset"

    5) The standard does not explicitly forbid running tools for conversion.
    => see answers 1, 2 and 3.

    6) Qt is useful
    => yes, but irrelevant

    7) Other tools do it
    => yes, but irrelevant

    Did I forget some?

    Leave a comment:

Working...
X