Announcement

Collapse
No announcement yet.

KernelShark 1.0 Released After Switching From GTK To Qt

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

  • #11
    Originally posted by oleid View Post
    Gtk is really a nice Toolkit, it's C++bindings are not stuck in C++98,like Qt. From that point of view, Qt really stucks. And Qt is more a framework, which replaces STL instead of using it, like gtk's c++ bindings do.
    About the STL: this is due to history. Qt is old. like 1995 old. At that time, C++ support was flaky across platforms. And the STL was in even worse shape. Which is why Qt rolled its own. You can use STL containers in your Qt program.
    Carefully written code can use Qt and STL containers interchangeably.

    Comment


    • #12

      Originally posted by msotirov View Post
      Qt on the other hand is much more professionally done (from the code itself all the way to documentation and tooling) but it's also an enterprise product by a large corporation selling it to other large corporations.
      The documentation of Qt is quite nice, but still far from perfect. Being an enterprise product is good on the one hand (tooling, documentation, stable code base), but bad in the other (decisions are based on enterprise decisions, not community ; code is stale). Recent development of Qt was mostly QML and Android stuff, the classic widget codebase didn't change much since Qt4. That's why it got forked some two years ago to get rid of MOC and use C++14 throughout the codebase.

      Originally posted by Serafean View Post

      About the STL: this is due to history. Qt is old. like 1995 old. At that time, C++ support was flaky across platforms. And the STL was in even worse shape. Which is why Qt rolled its own. You can use STL containers in your Qt program.
      Carefully written code can use Qt and STL containers interchangeably.
      That's true (if you're writing templaized code, which is not always what you want) , but nevertheless it feels quite archaic and strange, if you're used to modern C++. In the c++ podcasts I listen to, they wondered why there are so little Qt people on c++ conferences and they assumed, that's due to Qt having it's own kind of C++.
      Last edited by oleid; 07-27-2019, 05:17 PM.

      Comment


      • #13
        Please gnome. Make an effort to have proper theming for Qt applications.

        Comment


        • #14
          Michael Kernelshark is that project that was running a poll to choose the new logo?

          Comment


          • #15
            Originally posted by msotirov View Post
            Not saying that there's anything bad being a hobby project, per se, it's just a fact of being a community driven open-source project.

            Qt on the other hand is much more professionally done (from the code itself all the way to documentation and tooling) but it's also an enterprise product by a large corporation selling it to other large corporations.
            Correction: Qt is made by a small company selling it to other companies large and small.

            Comment


            • #16
              Originally posted by oleid View Post
              That's true (if you're writing templaized code, which is not always what you want) , but nevertheless it feels quite archaic and strange, if you're used to modern C++. In the c++ podcasts I listen to, they wondered why there are so little Qt people on c++ conferences and they assumed, that's due to Qt having it's own kind of C++.
              It is not is own kind of C++. But note all the development is in Europe, you won't find many (or any) going to US developer conferences, but Qt people are often at the European C++ conferences, contributes to the new standards and have a member in the top C++ standards comitee.

              Internally Qt will also use the latest C++ features when available, but can rarely change public API to use them since the minimum there is C++11 at the moment, and was C++98 when Qt 5 was first released; and Qt takes source and ABI compatibility VERY serious (even more so than C++ does).

              Note this will change with Qt6, which will up the minimum requirement to at least C++17, though the current consensus is to not change too much to maintain source compability to avoid having customers stuck on Qt5 for a decade like happened with Qt3. Still a handful of Qt classes now completely superceded by C++ looks to be going away.

              Comment


              • #17
                I was a strong supporter of gtk at the 1.x era, when it was the gimp toolkit, because it was opensource and plain C, as opposed to a non-free qt in C++. At the time I was using gnome 1 and it was great, faster than kde, far better than enlightenment I was using previously, that was already a giant leap forward compared to fvwm/olvwm.

                Then something got broken, gnome 2 got slow and heavy like an elephant, so I switched to xfce, but still preferring gtk 2 applications. At the same time I started developing with glib (liked very much) and qt become free.

                Compiz kicked off the compositing mania and the gnome 3 era begun. Xfce started to look like gnome 2, so I abandoned it in favor of lxde, but also many gtk applications disappeared from my desktop: gtk 2 -> 3 porting issues, ABI incompatibility between minor versions of gtk 3 and the usability changed too much for my taste (where is the menu bar?)

                Today gtk 2 applications are hunted for a bounty (last victim: leafpad removed from debian), gtk 3 seems reached a stable point but gtk 4 is coming, lxde is migrating to qt like many applications and my desktop is a plain openbox + fbpanel with an heterogeneous mix of gtk 2/3, qt 5 and plain X11 applications (mpv, mupdf and I still can't find a substitute for xcalc that can start instantaneously under heavy load)

                I think gtk development was driven too much by gnome, thus making non-gnome gtk applications second class citizens and forcing developers to do additional maintenance burden only to keep the application in a working state. On top of that, qt is now a free alternative, with an API even better stable and wider cross-platform compatibility. Anyway I hope gtk could regain its status and join again the competition in the future.

                Comment


                • #18
                  Originally posted by Britoid View Post
                  There's no sinking ship, Qt just serves better for writing cross-platform (GNOME, KDE, etc) applications.
                  qt has nothing to do with being better cross-gnome than gtk is cross-kde. qt is intrinsically better than gtk just because it is (kindof) c++ library and even kernel devs prefer c++ over c (and to do otherwise you have to lack education, though that's not uncommon)
                  Last edited by pal666; 07-29-2019, 01:30 PM.

                  Comment


                  • #19
                    If I were to guess why Qt might want to stick to old C++ language revisions in core libraries, it would be the embedded.
                    Qt is primary toolkit in automotive and some obscure platforms might not even have gcc crosstoolchain available and thus no C++11 even.

                    Comment


                    • #20
                      Originally posted by Serafean View Post
                      About the STL: this is due to history.
                      no, this is due to obsoleteness. of qt. 1995 was in previous millenium

                      Comment

                      Working...
                      X