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

  • #11
    Originally posted by 144Hz View Post
    Alexmitter Sorry but this is the anti-fork. KDE pulls from upstream Qt so patches effectively needs to be CLAed. In other words KDE just validated Qt’s current actions and future actions. KDE also invalidated true Free forks and claims like “Qt doesn’t require maintenance” and “The KDE Free foundation prevents any malicious actions from Qt”.

    Qt won again.
    Of course Qt Company won, for now. But the KDE Community gets more open to a fork over time now. It will still take years before the KDE community is truly liberated from that abusive company. Those are just first and very small steps.

    But the later one is incorrect. Qt wont release its patches to Qt5 in code form as GPL from now on, so the KDE people have to write those themself. They can maybe use some parts of the Qt6 patches and updates, maybe backport some stuff but not everything.
    Last edited by Alexmitter; 06 April 2021, 08:48 AM.

    Comment


    • #12
      So there are already halfway towards doing their own https://www.copperspice.com/, why not just move over?

      Comment


      • #13
        Originally posted by Charlie68 View Post
        As I said in several discussions .... this was to be expected. Once you have switched to Qt6 there will be no more problem. This problem exists only in the transition period to a higher version.
        I don't think this is a big deal, it's just about patching any security issues or bug fixes.
        Usually the latest version of a cliclo (4,5,6 etc.) is always in good condition, so there won't be much to do.
        It will take the KDE Community about 5 years from now to port the at least still frequently used projects.

        Comment


        • #14
          Alexmitter Read the FAQ. They are going to backport from CLAed Qt6. KDE also announced they are moving to Q6. No forks are planned.

          Comment


          • #15
            To all those fretting "omg, fork!", KDE already routinely contributes patches to Qt. It's just that for this particular branch (5.15 LTS), contributions won't make it back to a public release, so KDE has to maintain the patches themselves for a while.
            Like I've said before, I don't have a problem with the new Qt policy, but around 5.15 is probably the worst time to implement it. This being one of the side effects.

            Comment


            • #16
              Originally posted by bug77 View Post
              I don't have a problem with the new Qt policy, but
              Don't use "but" if you have trust in your words. But is always the end of a lie, followed by the truth.
              Back to the topic

              around 5.15 is probably the worst time to implement it. This being one of the side effects.
              I actually do think this is intentional. That way people don't have anything to switch to. There is no next-compatible release and everything that was before is in a worse state. KDE might be Qts collateral damage in this "Framework war", so I actually think KDE should act in some way. Not with a fork, because that would be just an "keeping alive an outdated Qt version". It would be possible to extend framework 5/6 into an growing base-framework and grow this one over time into some KDE own framework. So there wouldn't be a hard cut, instead it would be a slow move-away to something own.

              Or, you know. join GTK to create a GTK(mm)5 that also works for KDE to switch to, BUT that might be me trolling.



              Comment


              • #17
                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

                Comment


                • #18
                  Originally posted by lumks View Post
                  Or, you know. join GTK to create a GTK(mm)5 that also works for KDE to switch to, BUT that might be me trolling.
                  As someone who's coded against both (albeit in Python), I have to say that GTK is so feature-poor compared to Qt that doing that just isn't viable in any near-term case.

                  I switched to Qt before GNOME 3.x-isms started to pollute the LXDE components I was mixing into my KDE and you'd have to pay me to go back to reinventing those wheels. Now, I imagine KDE would have to maintain something like the gtk3-classic patch set on top of that because of all the unwanted GNOME-isms that are getting forced onto non-GNOME desktops built on GTK.

                  Comment


                  • #19
                    Originally posted by 144Hz View Post
                    Alexmitter Read the FAQ. They are going to backport from CLAed Qt6. KDE also announced they are moving to Q6. No forks are planned.
                    I am aware of that, and I am aware that this is what they would like to do. But it wont work, at least not for everything. They will have to fix issues themself that do not exist in Qt6 anymore due to completely different code base that they can not simply pull into their qt5.

                    Comment


                    • #20
                      Originally posted by ssokolow View Post
                      I switched to Qt before GNOME 3.x-isms started to pollute the LXDE components I was mixing into my KDE and you'd have to pay me to go back to reinventing those wheels. Now, I imagine KDE would have to maintain something like the gtk3-classic patch set on top of that because of all the unwanted GNOME-isms that are getting forced onto non-GNOME desktops built on GTK.
                      Looks like someone is afraid of everything that does not look and work like windows 95. Real spooky.

                      In fact KDE maintains a breeze theme for GTK3 and it looks quite nice, better then their own breeze qt theme I would say. But that is mostly due to GTKs extremely flexible css based theming.

                      Comment

                      Working...
                      X