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

  • Originally posted by MadCatX View Post
    Well, this code is:

    - Difficult to read
    - Error prone
    - Probably slow (depends on your STL implementation)
    - Less flexible (What if you want to match against a string passed in runtime instead of "foobar" for instance?)
    - Problematic with Unicode
    - Strictly speaking wrong (your trimming "functions" are not sufficient)
    - A complete departure from a well established and perfectly functional QString API

    You can write your own string manipulation library with plain STL but if you are using Qt, why would you do that when Qt already provides one?
    So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?

    At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.

    Comment


    • Originally posted by wertigon View Post
      So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?
      I'm afraid you're thinking about this all wrong. There are numerous huge software projects that use Qt - a lot of them commercial. Imagine the sheer amount of work that'd have to go into moving away from QString to std::string API. How would you explain to your customers that they have to rewrite all of their container code if they want to upgrade to Qt6? Why would anybody do that?

      Qt containers are fine. They have a STL-like and Java-like convenient APIs. They do copy-on-write (STL doesn't). They use signed integers for indices (I think it was Scott Meyers who said that using unsigned ints for indexing is one of STL's biggest mistakes). They are guaranteed to work exactly the same on all platforms. They are used consistently across the entire Qt. What exactly do you gain by switching over?

      Originally posted by wertigon View Post
      At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.
      Qt does adopt things from STL. Qt5 relies on STL. QString has fromStdString() and toStdString() methods since Qt5. You can use std::thread with Qt slots for example. At one point they did consider adopting some STL containers but eventually decided against it.

      Comment


      • Originally posted by zerothruster View Post

        From falkon-3.1.0/CMakeLists.txt

        Code:
        # Project name and version
        project(Falkon VERSION 3.1.0)
        
        # Find ECM, with nice error handling in case of failure
        include(FeatureSummary)
        find_package(ECM 5.27.0 CONFIG)
        set_package_properties(ECM PROPERTIES TYPE REQUIRED DESCRIPTION "Extra CMake Modules." URL "https://projects.kde.org/projects/frameworks/extra-cmake-modules")
        feature_summary(WHAT REQUIRED_PACKAGES_NOT_FOUND FATAL_ON_MISSING_REQUIRED_PACKAGES)
        set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)
        
        # Many includes from ECM, to get all the nice cmake functions and settings
        include(KDEInstallDirs)
        include(KDECMakeSettings)
        include(KDECompilerSettings NO_POLICY_SCOPE)
        include(ECMInstallIcons)
        include(ECMSetupVersion)
        include(ECMAddAppIcon)
        include(ECMQtDeclareLoggingCategory)
        include(ECMPoQmTools)
        However, it compiles just fine without ECM on at least Deepin and Haiku, so I repeat: ECM is *not* needed.

        Comment


        • Originally posted by wertigon View Post
          So your criticism is basically "Well, this is not what I'm used to, so..." naturally this code is not the easiest to read for an untrained eye, and sure you can find places where one approach or the other is preferable. Is it "Add-15-MB-of-extra-dependencies" preferable though? What about 300 MB?
          Well, your few lines of code are hard to read even for the somewhat trained eye.
          I'd trade a few tens of mbs of precompiled dependencies and some performance for more readable code. (within reason, of course)
          Because things will be easier for me and my users will never notice the difference

          Originally posted by wertigon View Post
          At this rate I see Qt eventually becoming another jQuery. You know that JavaScript augmented library that allowed you to do cool stuff with even old IE6 back in the day. Then it got obsolete as ECMAScript evolved, and these days people mostly just drop it over standard JS and CSS. I would suggest very careful trimming of the Qt fluff going forward, start deprecating things that are now part of the standard C++17 like regexps, et cetera.
          I think that Qt devs would be happy to wrap Qt classes around standard libraries if it makes sense.
          By the way, do you have any idea of just how many sites still rely on jQuery?
          A little context: https://trends.builtwith.com/javascript/jQuery

          Comment


          • Originally posted by MadCatX View Post
            I'm afraid you're thinking about this all wrong. There are numerous huge software projects that use Qt - a lot of them commercial. Imagine the sheer amount of work that'd have to go into moving away from QString to std::string API. How would you explain to your customers that they have to rewrite all of their container code if they want to upgrade to Qt6? Why would anybody do that?
            This is why the keyword "Deprecated" exists. It is not unreasonable to ask your customers to recode to a different container while maintaining the old API one last generation.

            Originally posted by MadCatX View Post
            Qt containers are fine. They have a STL-like and Java-like convenient APIs. They do copy-on-write (STL doesn't). They use signed integers for indices (I think it was Scott Meyers who said that using unsigned ints for indexing is one of STL's biggest mistakes). They are guaranteed to work exactly the same on all platforms. They are used consistently across the entire Qt. What exactly do you gain by switching over?
            Just because they work fine, does not mean they are fine. The trouble comes when you need to launch beyond Qt, at which point these containers incur technical debt. For instance, the entire programming community has settled on UTF-8 as the standard Unicode codepoint. Except Qt, Win32 and Java, whom are being stubborn about this. Meanwhile the WWW has pretty much settled the issue and most if not all documents authored nowadays are UTF-8 on the web.

            What do you gain by switching over? Interoperability and less need for hacky workarounds. Not saying all of it is bad, but quite a few things are and should be switched over for the sake of making Qt more useful.

            Originally posted by MadCatX View Post
            Qt does adopt things from STL. Qt5 relies on STL. QString has fromStdString() and toStdString() methods since Qt5. You can use std::thread with Qt slots for example. At one point they did consider adopting some STL containers but eventually decided against it.
            Yes. Qt depends on STL; but it does not allow for this very much when interfacing the Qt libraries. This becomes apparent when you want to, say, pair a more capable network library with Qt than exist in the Qt platform.

            Bottom line, there really is no reason to cling to old and outdated containers, even if replacing them is a massive undertaking. Keeping said containers will only hurt more and more for each passing year, just like jQuery did for browsers.

            Comment


            • Originally posted by wertigon View Post

              In my humble opinion, qt should strive towards the std:: libs as they improve and rely less on their own, incompatible stuff where possible.
              In my humble opinion, rolling their own string type is fine for Qt. GTKmm doesn't use std::string as well. In contrast to Qt, however, their string type is utf8. And from my point of view, that is the most sane thing. Now if there only was a utf8 string type in the standard...
              Last edited by oleid; 08 April 2021, 05:13 PM.

              Comment


              • Originally posted by wertigon View Post
                This is why the keyword "Deprecated" exists. It is not unreasonable to ask your customers to recode to a different container while maintaining the old API one last generation.
                Instead, think about how reasonable it is for your customers not to have to fix things that weren't broken.
                Especially considering that they can already choose the containers that suit their project best.

                If you're curious about why they're still using QString instead of std::string or std::wstring, you can read this thread
                https://interest.qt-project.narkive....not-std-string
                It's a bit long, but I think it's interesting.
                That said, I don't think it's that big of a deal to call toStdString() when you need std::string or to work with std::string and call fromStdString()

                Comment


                • Originally posted by JackLilhammers View Post
                  Instead, think about how reasonable it is for your customers not to have to fix things that weren't broken.
                  Especially considering that they can already choose the containers that suit their project best.
                  I do not see it as unreasonable to consolidate on the same library over time. If this were to be deprecated in Qt 6 and removed in Qt 8, that would be 10-15 years for customers to change. While things are not broken as of now, using a 3D-printed plastic cog instead of a solid, molded titanium one isn't exactly a recipe for a lasting machine, either. So, the 3D printed cog has 16 teeth instead of 14; This creates some repercussions like the axis the cog is on is not turning at the correct velocity. Redesigning the machine to then use more standard parts over time is a good idea, ya?

                  Originally posted by JackLilhammers View Post
                  If you're curious about why they're still using QString instead of std::string or std::wstring, you can read this thread
                  https://interest.qt-project.narkive....not-std-string
                  It's a bit long, but I think it's interesting.
                  That said, I don't think it's that big of a deal to call toStdString() when you need std::string or to work with std::string and call fromStdString()
                  Thread is from 2012; surely, by now most points made are no longer valid? I could be wrong of course.

                  To be clear here, I do not know enough details about any single Qt component, nor do I know if this has been discussed over at Trolltech, and this is just one of many non-standard parts. All I know is, Qt is designed by people, at this stage being very conservative, and most engineers I've talked to tend to do a thing a certain way because they've always done it that way. It is good for every new iteration of a framework, to challenge each component. This does not mean the custom component is automatically bad; but I do not see a good reason to use Qstrings for instance. I also see no good reason to stick to UTF-16, other than backwards compatibility; that alone would solve a lot of headaches.

                  But I'll agree to disagree, it's clearly not my product.

                  Comment


                  • Originally posted by wertigon View Post
                    Thread is from 2012; surely, by now most points made are no longer valid? I could be wrong of course.
                    I know it's an old thread, but explains why Qt 5 used QString instead of standard strings.
                    I could be wrong too, but I don't think the standard library has changed so much as to make QString obsolete.

                    Originally posted by wertigon View Post
                    It is good for every new iteration of a framework, to challenge each component.
                    Actually, they do challenge every component.
                    If you look at the changelog in Qt 6 you'll see that QVector and QList implementation has been merged and QLinkedList has been deprecated and they're recommending using std::list while keeping the old class for backwards compatibility.

                    Comment


                    • Originally posted by wertigon View Post
                      What I cannot understand, is why the heck Qt 6, released in 2021, must insist on spending resources and burning goodwill with their own incompatible qt::QString instead of deprecating it completely and simply do:

                      Code:
                      typedef qt::QString std::wstring;
                      The main difference between QString and std::wstring is that QString is implicitly shared.

                      Comment

                      Working...
                      X