Announcement

Collapse
No announcement yet.

KDE Frameworks 6 Progresses By Porting Code Away From Deprecated Functions

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

  • #11
    Originally posted by tildearrow View Post

    ...I thought Deepin used HTML5?
    It had in the past. Now it's using Qt since Deepin 15.

    Comment


    • #12
      You have to wonder why Qt needs to keep on changing existing parts of the API, since it kind of suggests that they were not designed well enough to begin with to need constant revision. Qt is a fantastic API, very well designed, don't get me wrong. There must be very good reasons for the revisions however. Removing backwards compatibility however, can create lost productivity however in having to go back and fix code that working fine before, so it should not be done lightly. I always prefer keeping backward compatibility to ensure that applications continue to work right as breaking a lot of applications creates a reputation of unreliability.

      Comment


      • #13
        Originally posted by Nth_man View Post
        If anyone is wondering why those KDE news can be read peacefully, it's because 144Hz / GhostOfFunkS / Funkstar / Griffin / Honton was banned:

        https://www.phoronix.com/forums/foru...72#post1147372
        Maybe Michael should keep lists of users that troll KDE/Gnome/Nvidia/whatever news pieces and script an automatic temporary ban when he publishes anything on the subject?

        Originally posted by Neraxa View Post
        You have to wonder why Qt needs to keep on changing existing parts of the API, since it kind of suggests that they were not designed well enough to begin with to need constant revision. Qt is a fantastic API, very well designed, don't get me wrong. There must be very good reasons for the revisions however. Removing backwards compatibility however, can create lost productivity however in having to go back and fix code that working fine before, so it should not be done lightly. I always prefer keeping backward compatibility to ensure that applications continue to work right as breaking a lot of applications creates a reputation of unreliability.
        Qt is used a lot on embedded stuff, I'm guessing part of the reason they have to keep their stuff clean/cruft free is they need it to be light on resources.

        Comment


        • #14
          Originally posted by Nth_man View Post
          If anyone is wondering why those KDE news can be read peacefully, it's because 144Hz / GhostOfFunkS / Funkstar / Griffin / Honton was banned:
          Actually I miss them a little, maybe they should be allowed to troll 1 news per month, just for the lulz hahaha

          Comment


          • #15
            Originally posted by tildearrow View Post

            ...I thought Deepin used HTML5?
            No, they're using Qt since v15.

            Comment


            • #16
              Originally posted by andrei_me View Post

              Actually I miss them a little, maybe they should be allowed to troll 1 news per month, just for the lulz hahaha
              Agreed lol. And while we're at it, let's make the same exception for Debianxfce

              Comment


              • #17
                Originally posted by timofonic View Post
                What about moving more KDE Frameworks cruft into Qt itself in a same, intelligent and elegant way?
                Actually, they've done that for at least the Qt4 and Qt5 releases and I assume more of that for Qt6.
                The reason a lot of KDE APIs become deprecated is because they got features upstreamed.

                Comment

                Working...
                X