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 JackLilhammers View Post
    Following that thought, C is syntactic sugar over machine code...
    It is

    Comment


    • Originally posted by lowflyer View Post

      Every time there's a Qt thread there's also someone praising Qt high above the sky while denying any shortcomings (and there are many of course) ...

      You accuse me of ignoring the "bigger picture". Well, I'm working daily on a >1MLOC project with some modules using Qt and some not being able to use Qt. Well, you can call that an "ecosystem", and you're correct it's the ecosystem that matters. On a daily basis I'm confronted with the "bigger picture" question: shall we keep the Qt application framework as part of our ecosystem?

      Over time we have found more an more areas where Qt actually sucks, including licensing and support. This made us look around for alternatives. It's almost always better to use the STL. While I don't deny that Qt provides its users "a lot of stuff", the "cohesive way" is provided by other libraries as well. No distinct advantage of Qt. The only "advantage" is that you get "everything out of a single hand". But that depends heavily on the platform. (library dependency handling is different windows than on Linux. On some platforms you do not care...)

      A serious software engineer always keeps an eye on alternatives. We have recently managed to get away from qmake. Our next step is to get away from Qt Creator. Don't get me wrong, Qt is probably really the best user interface toolkit. But the trolls just tried to dance on too many weddings simultaneously. To get rid of the rest of the Qt libraries is already a discussion point on our table. Whether we are able to pull that off is another question.
      I'd say that these are different pictures and different ecosystems.
      Qt must be considered as a whole, but each project (even big ones) is a "pocket universe".

      Of course I'm always looking around for better alternatives, but I still haven't found one.

      I'm not saying you're wrong, but your argument is not about Qt, but about frameworks.
      Whenever there are lots of parts moving together (and this is especially true for big projects like yours) frameworks become harder to use.
      I'd say that the more the moving parts, the more the constraints imposed by each framework you're using.

      With that in mind, IMHO, Qt is still pretty awesome because while being a big application framework, it's very modular and you in most cases you can shred the things you don't need and replace them with whatever works best for your project

      Comment


      • As a low-end programmer with just enough knowledge about GUI programming to become dangerous; I can understand why Qt once, historically, did things a certain way. I can understand the argument that it did not start with, say, std::string since the type sucked in the early days.

        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;
        In my humble opinion, qt should strive towards the std:: libs as they improve and rely less on their own, incompatible stuff where possible. The advantages of rolling their own is decreasing more and more every year, while the disadvantages pile up. How long before the pain is bigger than the benefits?
        Last edited by wertigon; 08 April 2021, 07:41 AM.

        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. The advantages of rolling their own is decreasing more and more every year, while the disadvantages pile up. How long before the pain is bigger than the benefits?
          It would be absolutely terrible.
          Like, with QString I can just do stuff like

          if(string.startsWith("foobar"))
          string.trimmed();
          string.matches(QRegularExpression("[Ss]ome regexp?");
          string.splitRef(",");

          etc etc... all of those are a pain to write with std::wstring ; also with QString I can just do QString::{from,to}Utf8() and things JustWork, just like writing to the console JustWorks. Try writing unicode characters to the console in a cross-platform win / mac / linux with just std::.

          Comment


          • Originally posted by lowflyer View Post
            I don't deny that. When did Qt become standardized?
            What do you consider standardized and how is it relevant for the discussion?

            Originally posted by lowflyer View Post
            Well, you're wrong. The range of a codepoint in std::string is [1;255]. The biggest difference between std::string and QString is not the character handling, it's the memory handling. QString does "implicit sharing". That's why QString copies are fast - but they are actually not copies.

            Regarding character handling, the Trolls at Qt made the same mistake that Microsoft did and used UCS-2 (not to confuse with UTF-16). This is the same that you get with std::wstring. QString is just a container for 16-bit codepoints. When you are working with any of the UTF-* encodings you'll run into exactly the same problems on both. Perhaps a little bit later than with std::string.
            Neither std::string, std:wstring nor QString store code points. std::string stores an array of bytes. std::wstring stores an array of wchar_ts, wchar_t is an implementation-defined integral type that may be as small as 8 bits (yes, really). QString stores an array of UTF-16 code units. std::string and std::wstring make no assumptions about the data they store. Since QString assumes its content to be a UTF-16 code unit sequence, it can implement Unicode-aware text handling consistently across multiple platforms. You still need to exercise caution when dealing with surrogate pairs in QString. However, AFAIK there is no string manipulation library that is considerably better in this regard.

            Originally posted by lowflyer View Post
            Well, that is different. In your original post you were talking about local socket.
            When people talk about a local socket, I imagine that most people think of AF_UNIX kind of socket. Most APIs and SDKs use the name local socket to describe this device.

            Comment


            • Originally posted by tildearrow View Post

              I would like to complain.

              The KDE file picker is extremely slow on directories with a lot of files. For some reason it fills the list with file updates as it reads more files, which might give the user the illusion that the files are loading, but it blocks (even delays!) user input, making it hard to type the filename if the user already knows it in the "file" text input field (even worse, if you press Enter before the file picker has finished loading the directory, it QUEUES your input until all the files have loaded for some dumb reason, forcing you to wait 30 seconds for the list to finish loading).
              On the other hand, the GTK file picker doesn't do this, which allows you to type the file name and press Enter even before the directory is loaded (of course, the file list doesn't update to give you an illusion of "loading" but at least it doesn't block like crazy)......

              Furthermore, when using portal, the KDE file picker takes up to 10 seconds to appear (the GTK picker takes one second).
              Maybe I just haven't used my KDE applications in folders with enough files, but I haven't noticed that myself. If it's true, it needs to be fixed.

              Funny enough, years ago (5? I can't remember), I loathed the GTK picker because it far outstripped the KDE pickers I was using it alongside in exactly that problem. (Useless until all the files have loaded in a big directory.)

              In fact, I think my solution at the time was using that LD_PRELOAD-based hack to get KDE file dialogs in GTK applications because, otherwise, they were practically useless.

              Comment


              • Originally posted by doom_Oo7 View Post

                It would be absolutely terrible.
                Like, with QString I can just do stuff like

                if(string.startsWith("foobar"))
                string.trimmed();
                string.matches(QRegularExpression("[Ss]ome regexp?");
                string.splitRef(",");

                etc etc... all of those are a pain to write with std::wstring ; also with QString I can just do QString::{from,to}Utf8() and things JustWork, just like writing to the console JustWorks. Try writing unicode characters to the console in a cross-platform win / mac / linux with just std::.
                Well... Not to pop your bubble, but with std::string and pals you can just do:

                Code:
                #include <regex>
                #include <string>
                
                if std::regex_match(string, std::regex("^foobar"))
                string = std::regex_replace(string, std::regex("^[ \t]+"), "")
                string = std::regex_replace(string, std::regex("[ \t]+$"), "")
                std::regex_match(string, std::regex("[Ss]ome regexp?"))
                string | view::split(',') | ranges::to<std::vector<std::wstring>>();
                Which all does precisely what you want them to, with little to no extra code. As the C++ STL evolves, the need to keep a separate library is drastically reduced. Of course, the examples you cite all have easy boost counter parts as well, but if you do not wish to use that library you are free not to use it.

                Not to mention a future C++ developer would be more likely familiar with the standard code than QT code.

                Comment


                • Originally posted by zerothruster View Post

                  I thought I said it was nominally within kde. It wants extra-cmake-modules from kde. That is the only kde package I install in my normal builds.
                  In that case you might want to contact your distro maintainers as I don't need extra-cmake-modules for Falkon on my distro, nor on Haiku.

                  Comment


                  • Originally posted by wertigon View Post

                    Well... Not to pop your bubble, but with std::string and pals you can just do:

                    Code:
                    #include <regex>
                    #include <string>
                    
                    if std::regex_match(string, std::regex("^foobar"))
                    string = std::regex_replace(string, std::regex("^[ \t]+"), "")
                    string = std::regex_replace(string, std::regex("[ \t]+$"), "")
                    std::regex_match(string, std::regex("[Ss]ome regexp?"))
                    string | view::split(',') | ranges::to<std::vector<std::wstring>>();
                    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?

                    Comment


                    • Originally posted by Vistaus View Post

                      In that case you might want to contact your distro maintainers as I don't need extra-cmake-modules for Falkon on my distro, nor on Haiku.
                      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)

                      Comment

                      Working...
                      X