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

  • #51
    Originally posted by lumks View Post
    I'm sad about this whole situation. KDE is kind of a small team. A team of people who show of whats possible with Qt and doing so for years and years. Yet they have to do even more work because of this situation. From the users point of view - is there anything we can actually do?


    https://relate.kde.org
    http://www.kde.com/donations
    If KDE is the best you can do with Qt, it would be a massive embarrassment.

    The people who actually show what is possible are the people who use it in embedded scenarios, who actually write pretty good software.

    Comment


    • #52
      Originally posted by Yeayo guy View Post
      All the discussions in this thread are nonsense, a waste of time and to spread hatred to Qt.
      Poor Qt, it must really suffer from all that hatred.

      Originally posted by Yeayo guy View Post
      First, Qt is GPL and LGPL licensed.
      Sure, but the Qt company and only them decide if a certain release is GPL/LGPL or if it stays fully proprietary as they wish. That is nothing but a loose promise of the Qt

      Originally posted by Yeayo guy View Post
      Second, if you contribute Qt you allow them to make a dual license in GPL/LGPL and proprietary, yes, but your code will still be GPL.
      That is technically incorrect.
      The moment you commit to the Qt repos, you have to give away all rights to your code, it is not anymore GPL/LGPL licensed and you do not hold any rights on it, you could not even have it removed later. That is a workaround around the net of ownership that normally protects a GPL/LGPL project from ever ending up proprietary.
      Right in this moment, a technician at the Qt Company could extend code that was committed by a KDE person in the 5.x stack and the KDE community will never see that improved code.

      Originally posted by Yeayo guy View Post
      Third, in a year KDE will be transitioned to Qt6.
      More like 3 years for the core projects and another 2 for the surrounding projects.

      Comment


      • #53
        Originally posted by Alexmitter View Post
        Qt serves everyone and everything and that equally bad.
        I disagree. For at least 90 % of cases, functionality provided by Qt is good enough. Need to load a PDF and paint in on the screen? Or do text encoding conversions? Or fetch a JSON from a server over TLS, parse it and display the content? Or maybe you have some data in a SQLite database? Perhaps now you want to visualize that data in a 3D chart? Not a problem, Qt has your back. Unless you have some very specific needs, I really don't see what is Qt doing badly.

        Comment


        • #54
          I hope the people who suggest that KDE move away from Qt to some other framework are just trolling. Anyone who's done any GUI programming knows that switching to another framework amounts to pretty much rewriting the whole thing.

          So, KDE is sticking to Qt. But this proprietary move is obviously a problem for them, because whenever the Qt people decide, KDE will be left without upstream support until they manage to bring all their code to the new version of Qt. This is the first time it's happening. We'll see how long it takes KDE to transition to Qt6. But I sort of suspect it's going to take so long and so much effort that KDE will have no choice but to strike some kind of special deal with Qt, because both forking it and updating to higher versions all the time will prove to be a death sentence.

          Comment


          • #55
            Originally posted by cl333r View Post
            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.
            Yeah that's a fair criticism. I have my own language preferences, and I can understand people not liking C or the C++ bindings. Personally I don't like either of them myself and would prefer Rust. It's not even that I like Rust itself, it's just the most tolerable of the manual memory management languages, and I favor functional programming over OO.

            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.
            Well you have GIO and other libraries for things like file system access. Of course all of those libraries are dependent upon C. Part of the reason that KDE's fate is tied to Qt is that everything is handled there. I'm starting to be convinced that the reason people favor one over the other comes from the difference between C and C++. I think it's pretty clear that C++ provides a nicer API in general for something like UI or networking programming because it is OO, and Gnome ends up having to simulate that in C to make a poor man's C++.

            I wonder if Rust can fix that in the future. I firmly believe that functional programming has the better UI model. There are no good short term answers though.

            Originally posted by eltomito View Post
            I hope the people who suggest that KDE move away from Qt to some other framework are just trolling. Anyone who's done any GUI programming knows that switching to another framework amounts to pretty much rewriting the whole thing.
            That's why I said it was a dream. I'm well aware they would have to rewrite everything, and so it won't happen. They will always have a precarious relationship with that company though. It will no doubt become worse over time as their financial pie shrinks. Qt Company is betting the farm on IoT/embedded use cases, which is sensible, but why would you choose to use Qt over something like Flutter, which will have much better support on mobile?
            Last edited by cynical; 06 April 2021, 04:49 PM.

            Comment


            • #56
              Originally posted by Alexmitter View Post
              Poor Qt, it must really suffer from all that hatred.


              Sure, but the Qt company and only them decide if a certain release is GPL/LGPL or if it stays fully proprietary as they wish. That is nothing but a loose promise of the Qt


              That is technically incorrect.
              The moment you commit to the Qt repos, you have to give away all rights to your code, it is not anymore GPL/LGPL licensed and you do not hold any rights on it, you could not even have it removed later. That is a workaround around the net of ownership that normally protects a GPL/LGPL project from ever ending up proprietary.
              Right in this moment, a technician at the Qt Company could extend code that was committed by a KDE person in the 5.x stack and the KDE community will never see that improved code.



              More like 3 years for the core projects and another 2 for the surrounding projects.
              That's not true, I think you should read again the Qt's Contribution Agreement.

              Comment


              • #57
                Originally posted by cynical View Post
                Well you have GIO and other libraries for things like file system access.
                But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely, C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this. If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole. This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles.

                Comment


                • #58
                  Originally posted by MadCatX View Post
                  I disagree. For at least 90 % of cases, functionality provided by Qt is good enough. Need to load a PDF and paint in on the screen? Or do text encoding conversions? Or fetch a JSON from a server over TLS, parse it and display the content? Or maybe you have some data in a SQLite database? Perhaps now you want to visualize that data in a 3D chart? Not a problem, Qt has your back. Unless you have some very specific needs, I really don't see what is Qt doing badly.
                  And unlike Qt, GTK is basically a non-entity outside the Linux/FOSS bubble.

                  Comment


                  • #59
                    Originally posted by Raka555 View Post
                    Here is something worthwhile for the rust people to rewrite ...
                    There are a few rust based toolkits, check out https://github.com/hecrj/iced and https://github.com/linebender/druid - they are the most popular ones.

                    Comment


                    • #60
                      Originally posted by cl333r View Post

                      Rust is not fit this kind of stuff, it's much worse than C++, it shines in the realm of little tools and random small libs.
                      Well, there are rust-native toolkits. They have a different design than your usual off-the-self C++ GUI toolkit, but guess what: what you get is thread-safe

                      Comment

                      Working...
                      X