Announcement

Collapse
No announcement yet.

KWinFT Projects Hit Beta Ahead Of Stable Releases Aligned With KDE Plasma 5.20

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

  • #11
    I don't think KWin as a compositor has to rely on Qt. It's just wrong design, so I totally support Roman's goal here. Qt should be limited to UI use cases, not used as a replacement for C++ standard libraries which Qt tries to do in quite a number of areas.

    Comment


    • #12
      Originally posted by 144Hz View Post
      Go go go go!
      144Hz cheering KDE? That's a rare treat...

      Comment


      • #13
        Originally posted by shmerl View Post
        I don't think KWin as a compositor has to rely on Qt. It's just wrong design, so I totally support Roman's goal here. Qt should be limited to UI use cases, not used as a replacement for C++ standard libraries which Qt tries to do in quite a number of areas.
        Qt is not just an UI toolkit...
        Using Qt for C++ development is so much easier, than standard C++. You have signal/slots, JSON-, XML-support, HTTP(S) support etc.
        Compare also QVector with std::vector. QVector has a contains-method, while for std::vector you have to use std::find() which produces unreadable code.

        Comment


        • #14
          Originally posted by Steffo View Post

          Qt is not just an UI toolkit....
          I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.

          Either way, for high level language I'd go with Rust over C++ if there is a choice and I'd go for libstdc++ over Qt analogs otherwise.
          shmerl
          Senior Member
          Last edited by shmerl; 27 September 2020, 03:44 PM.

          Comment


          • #15
            Originally posted by aufkrawall View Post
            What is the status on merging/replacing upstream?
            I see this offered sooner as a plain kwin replacement package.
            With any luck, some distros will pick it up once it goes stable. I see Manjaro already does that and there's an AUR for Arch as well. I'm going to give it a try once I get 5.20.

            Comment


            • #16
              Originally posted by shmerl View Post

              I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.

              Either way, for high level language I'd go with Rust over C++ if there is a choice and I'd go for libstdc++ over Qt analogs otherwise.
              I agree that reimplementing libstdc++ is not the best of ideas, but Qt is old and when it came out C++ was way different.
              I mean, Qt is older than boost and just 1 year younger than STL.
              Qt 6 will be based on C++17, so hopefully much stuff will use more modern C++.

              I don't know KWin's code, so I can't say if it would be better off in pure C++. I think it really depends on the specific case

              Comment


              • #17
                Impressed by romang's drive to tackle this. Curious to try it out sometime!

                Comment


                • #18
                  Originally posted by shmerl View Post

                  I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.
                  Branched out? It is where it started! It is older than C++98, back then there was no reliable standard library, they were different between every platforms, so a cross platform toolkit's job was to offer a consistent alternative. As time goes by more and and more can be let go, though there are still key difference that still make some Qt classes very useful even with standard alternatives. Especially QString is not an std::string replacement and can't be replaced by it, QByteArray is the std::string equivalent. The container classes are mostly just copy-on-write versions of the standard library classes these days, I think in Qt6 QMap just wraps an std::map with CoW semantics and superior Qt syntax.

                  Besides the standard library is way too primitive for a GUI toolkit. The majority of Qt has no standard library equivalents.

                  Comment


                  • #19
                    Originally posted by 144Hz View Post
                    tildearrow
                    Senior Member
                    tildearrow I’m cheering any de-cute effort.
                    De-cute-ing should be the main focus for KDE in their next version. The more they depend on Qt, the easier is it for the greedy Qt company to pressurize them into making changes to this already very weak contract that are purely in the favour of the Qt company.


                    But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.

                    It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.

                    Comment


                    • #20
                      Originally posted by Alexmitter View Post

                      De-cute-ing should be the main focus for KDE in their next version. The more they depend on Qt, the easier is it for the greedy Qt company to pressurize them into making changes to this already very weak contract that are purely in the favour of the Qt company.


                      But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.

                      It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.
                      Yeah, sure, that makes perfect sense.
                      But why stopping at Kde? There are many other projects that need True Freedom™!
                      Let's rewrite everything written in Qt with a better and truly free toolkit!
                      Do you have any suggestions?

                      Comment

                      Working...
                      X