Announcement

Collapse
No announcement yet.

KDE Now Maintaining Their Own Set of Patches For Qt 5

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

  • #41
    Originally posted by RealNC View Post
    It would most probably be a hell of a lot of work to bring copperspice up to date, since it's a fork of Qt 4.
    If you drop using QTEverything (god awful QString, QXML, QNetwork, etc) then that would actually help in just using state-of-the-art libraries without layers of bugs and lower maintaining costs.

    Comment


    • #42
      Originally posted by angrypie View Post

      You're implying GNOME would accept patches that go against their "vision," which is... not true at all.
      I don't write desktop applications for Linux so I'm not familiar with GTK/QT APIs, though from what I gather, QT takes the kitchen-sink approach. From what I see, Gnome developers were amenable to libhandy for augmenting GTK with new widgets that support mobile form factors, even to the point that there now exists a libadwaita to make that integration more official. What is GTK missing that Qt app developers want? Could anything less interesting to Gnome devs just be made into a library?

      The only major thing I've seen people complain about is that GTK doesn't support other platforms well, but I think that argument is weaker now that mobile platforms are taking over, and afaik, Qt integration on iOS and Android is pretty terrible.

      Comment


      • #43
        Originally posted by cynical View Post
        What is GTK missing that Qt app developers want?
        Just like with games, C++ is the preferred language when it comes to desktop apps or AAA games, it just has the best trade-offs.
        So GTK being a C solution is enough not to like it. Its C++ backed (gtkmm) doesn't feel like C++ more like what it is - a C++ wrapper around C, not to mention the docs aren't fully ported, often have C copy-pasted material.
        In the past GTK was a Linux only solution, the windows port was a crappy joke, don't know about now.
        And as an API GTK isn't as professional as Qt.

        OTOH Qt is too large, buggy and closed source these days.

        Comment


        • #44
          Originally posted by discordian View Post

          If you drop using QTEverything (god awful QString, QXML, QNetwork, etc) then that would actually help in just using state-of-the-art libraries without layers of bugs and lower maintaining costs.
          But what would you replace it with? Arguably one of the best things about Qt is its consistency. Once you've learned some part of Qt, you've basically learned it all. It uses the same basic datatypes, mechanisms and designs pretty much everywhere. Not having to jump back and forth between different ways how to the same things is a huge win.

          Comment


          • #45
            Originally posted by cynical View Post
            What is GTK missing that Qt app developers want?
            Basically everything. Qt knows how to do file system access, networking, image manipulation, audio and video playback, IPC, process management, threading. It also does it equally well on a lot of platforms from Windows to QNX. GTK has always been a Linux-focused GUI toolkit which is today developed mostly to serve the needs of GNOME.

            Comment


            • #46
              Originally posted by 144Hz View Post
              Cmon guys. Any chance of a fork is dead now. KDE chose Qt6. Nothing will change.
              Good. Now go away and quit trolling.

              Comment


              • #47
                Originally posted by bug77 View Post

                This isn't about looks, it's about (missing) functionality/configurability.
                I guess you are unable to differentiate between GTK and Gnome with Gnome not even using GTK for its shell.

                Comment


                • #48
                  Originally posted by MadCatX View Post

                  Basically everything. Qt knows how to do file system access, networking, image manipulation, audio and video playback, IPC, process management, threading. It also does it equally well on a lot of platforms from Windows to QNX. GTK has always been a Linux-focused GUI toolkit which is today developed mostly to serve the needs of GNOME.
                  Yes, that is a good point against the mess that Qt is. Its not just a toolkit, its your network stack, your image manipulation stack, video playback stack and hell it even has a 3D engine included. Qt serves everyone and everything and that equally bad.

                  Comment


                  • #49
                    this is pretty much the reason why i always thought KDE being dependent on QT was a mistake. i understand toolkits can be hard to make, but i never understood why they didn't adopt GTK. either try to work with it or make their own toolkit off of it via a fork. rather than playing with the hand grenade called QT. its like every year or two there's some sort of big controversy with QT that has something to do with licensing.

                    any benefit that QT has i have a very hard time believing its worth this mess.

                    Comment


                    • #50
                      Originally posted by DanL View Post
                      Looks like someone has been drinking almost as much GNOME Kool-Aid as 144.
                      Fanboyism.

                      Comment

                      Working...
                      X