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

  • #61
    Originally posted by cl333r View Post
    Just like with games, C++ is the preferred language when it comes to desktop apps or AAA games, it just has the best trade-offs.
    So GTK being a C solution is enough not to like it. Its C++ backed (gtkmm) doesn't feel like C++
    I don't know, I think the API of gtkmm is much cleaner and nicer than Qt. And it integrates nicely with STL.

    Originally posted by cl333r View Post
    In the past GTK was a Linux only solution, the windows port was a crappy joke, don't know about now.
    Fast forward to today: GTK4 is very easy to build on windows, is fully hardware accelerated.

    Originally posted by cl333r View Post
    And as an API GTK isn't as professional as Qt.
    How do you measure that?
    I recall trying to use Qt to create PDF files from a batch process. Using the QConsoleApplication. Turned out you need a QApplication to create PDF files. For some reason, PDF files were handled using some printing context.

    In the end, I created the PDF files with cairo. Cairo doesn't care what device you are writing to, everything is nicely abstracted away.


    Comment


    • #62
      Originally posted by MadCatX View Post
      But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely, C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this. If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole. This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles.
      And you work better with coherent code that follows norms and styles, source code that does not look like a Frankenstein monster (a part from that library, a part from another one...).

      The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.

      And you prefer well done documentation. Obviously a nicely designed API makes it easier and less expensive to document.

      Comment


      • #63
        Originally posted by MadCatX View Post
        But this is exactly the problem. Sure, you can use TinyXML and jsoncpp to parse internet resources and stuff, GnuTLS to fetech them securely,
        You would use libsoup in the gnome universe.

        C++20 coroutines to do it asynchronously, GStreamer to play multimedia, GIO or std::filesystem to access files, etc. It will probably work just fine but it will much more of a pain to maintain code written like this.
        Is it?

        Originally posted by MadCatX View Post
        If you write code against Qt and use as much of Qt functionality as possible, you are targeting a single framework that is developed, tested and deployed as a whole.
        Ack.


        Originally posted by MadCatX View Post
        This is a lot better than having to target fifteen independent libraries with their own APIs, datatypes and release cycles
        It depends on the length of the release cycles.

        C++ stl is *INSANELY* stable.
        gstreamer is *VERY* stable since its 1.0. No breaking changes for years.
        libsoup is stable for years.

        Actually, you have more breakage with Qt.

        EDIT:

        I wonder why the same people which argue pro UNIX philosophy prefer huge frameworks over libraries.
        Last edited by oleid; 06 April 2021, 07:17 PM.

        Comment


        • #64
          Originally posted by Nth_man View Post
          The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.
          There is little need to use C apis here. This isn't C vs C++. Most C APIs have nice C++ wrappers, e.g. GTKmm, gstreamermm, cURLpp, the list goes on.

          Comment


          • #65
            Originally posted by Alexmitter View Post

            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.
            Even with Breeze-gtk gnome stuff looks weird and out of place on my desktop.

            Also GTK filepicker sucks and continues to suck. Even Windows 98 has a better filepicker.

            Comment


            • #66
              Originally posted by Alexmitter View Post
              Fanboyism.
              Yes, you are. FWIW, I liked xfce 4.14.x, and I still don't feel completely comfortable with KDE 5. Whatever, but please continue with your stupid narrative that people who don't like GNOME Shell are Win95 Luddites.

              Comment


              • #67
                Originally posted by oleid View Post

                > The API is much cleaner - a lot of that is because it's based around an object-oriented C++ base rather than C.

                There is little need to use C apis here. This isn't C vs C++. Most C APIs have nice C++ wrappers, e.g. GTKmm, gstreamermm, cURLpp, the list goes on.
                An object-oriented C++ base is better and cleaner than a C++ wrapper around a not-object-oriented base...

                Comment


                • #68
                  Originally posted by Alexmitter View Post

                  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.
                  I tried every desktop session under the sun when I first came to Linux (KDE 3.x, GNOME 2.x, Xfce whatever, Enlightenment E16, Fluxbox, Openbox, etc. etc. etc.) and settled on KDE 3.x because GNOME 2.x felt like a more feature poor, more visually bloated version of it.

                  When GNOME 3.x came out, I gave it a shot... it just doesn't fit with my workflow... and you're talking to someone who now uses KDE 5.x, not because it works like Windows 95, but because it's the easiest to reprogram to my preconceptions of how I want my desktop to behave.

                  You're talking to the maintainer of QuickTile, a guy with three monitors who makes heavy use of global hotkeys and drop-down terminals to interact with his desktop, and who has been meaning to find time to hack together an AwesomeWM config to achieve the blend of tiling and floating he wants.

                  It has nothing to do with behaving like Windows 95 and everything to do with just plain not liking the direction the GNOME HIG is going.

                  Comment


                  • #69
                    Originally posted by cynical View Post

                    In what sense? Let's say for the sake of argument that you are right, wouldn't it be simpler to add whatever features you are missing to GTK and then use that instead of be beholden to some company that clearly doesn't care about you at all? Personally I'd love to see Qt abandoned so that there is only one major display toolkit on Linux. It would simplify things for app developers and fix all the theme issues. The only problem is that KDE would have to be completely rewritten.

                    It won't happen, but I can dream.
                    Let's see.:
                    1. Qt's documentation is far superior to GTK's. (IIRC, this was listed as the big reason Subsurface moved from GTK to Qt.)
                    2. Last I checked, while Qt's MVC framework for data widgets is often considered its worst part, GTK's MVC framework was still a nightmarish mess by comparison.
                    3. GTK requires you to reinvent customizable toolbars or pull into GNOME componentry. It's built-in as part of Qt, and it's six lines of code to automatically persist both window geometry and toolbar/panel configs.
                    4. When I left PyGTK for PyQt4, you still had to use this hack to get multi-selection and drag-and-drop in the same TreeView widget.
                    5. GTK just deprecated Glade in favour of recommending that people write the GTK Builder XML by hand. Sorry, but I like working with Qt Designer.
                    6. GTK developers consider it to be as-intended that you can't rename or delete things inside the file picker but, instead, have to open up the file browser and navigate to it the long way. As soon as I upgrade my Kubuntu LTS, I'm planning to set USE_PORTAL globally to see how many GTK apps I can rid of it.
                    7. I'm sorry, but I don't want to work with a desktop that's so focused on cargo-culting what they like about Apple that they don't understand first-year HCI concepts, such as "stick with the floppy disk icon, because affordances are only valuable for learning the iconography, after which consistency reigns, and your user base already knows the 'save icon', which has other technical advantages too" or "Dialogs should read like printed pages, which means you put the action buttons in the bottom-right in LTR languages like English, not in the titlebar." (See, for example, this blog post, for some guidance on the kinds of things it's important to be thinking about.)

                    The list goes on and on.

                    Originally posted by cynical View Post
                    Compromise accepted. I think Gnome is slowly going that way no matter what. On the other hand, what are the odds KDE or its applications will ever be written in Rust? I'd say near zero.
                    While it's more intended for incorporating Rust into a project that uses CMake and C++ at the top of the stack, the rust_qt_binding_generator crate is a KDE project. (It's a pragmatic approach that gets something usable now while Ritual and its rust-qt bindings churn away at implementing machine-generated bindings for things like subclassing-based APIs, overloaded methods, and all the other C++ OOP "goodness" that Qt APIs like QWidget picked up when they were laid down in the 90s.)
                    Last edited by ssokolow; 06 April 2021, 09:03 PM.

                    Comment


                    • #70
                      Why every, but every thread on news about Qt, KDE, GNOME, or GTK, has to escalate into a fight between the 2 ecosystems? In the end, just use what you like. I use GNOME because i like it more. As for the article itself, KDE has always been a tech demo of Qt, and always will be. If you expect KDE to ever drop Qt, you just don't understand the situation... KDE will NEVER drop Qt, and if for some reason Qt ceases to exist, KDE will cease to exist as well.

                      Comment

                      Working...
                      X