1. 25
  1. 6

    I’m glad they’re going with the GTK ecosystem and contributing to it, I’d love to see more people building GTK apps.

    (I keep a list of GTK apps, btw. Most new apps seem to be built by elementary OS users, with Vala+Granite as the elementary “SDK” instructs them to do.)

    1. 3

      While I prefer Gnome, it seems foolish to me Purism is inventing a mobile stack from essentially whole cloth instead of trying to adopt Plasma Active, which while extremely rough, has had a head start by actually existing.

      1. 3

        While there’s nothing wrong with GTK as such, Qt has always looked nicer, had a nicer API, better designer tool, better Python bindings, better documentation… and for all the issues with C++, it’s a first-class programming language with a tool/library ecosystem that Vala can never hope to match. Given that the licensing issues have been resolved years or decades ago, I do think the best thing for the community would be to get behind Qt.

        1. 7

          I never liked Qt. It has some advantages (native look on Windows, various options for running without any window system), but it feels very much like a “jack of all trades” thing, and it feels like a Heavy Framework.

          The C++ thing makes it hard to use from other languages. While GObject has been designed for auto-generating language bindings. You can write GTK apps in Haskell, Rust, Nim, D…

          Documentation… honestly, no UI toolkits has great docs.

          Also, GTK 4 is bringing GPU rendering to the existing regular desktop widget system, instead of creating a new separate thing (QML/QtQuick) that’s rarely going to be used, especially on desktop apps :P

          1. 2

            it feels very much like a “jack of all trades” thing, and it feels like a Heavy Framework.

            Given the limited state of package management in the C/C++ world I think monolithic frameworks are an advantage. Slackware gave up on packaging Gnome because the build dependencies were too complex to keep track of, whereas Qt’s qtcore/qtnet/qtui/… model is straightforward enough to make up for using bigger libraries than strictly necessary, IMO.

            The C++ thing makes it hard to use from other languages. While GObject has been designed for auto-generating language bindings. You can write GTK apps in Haskell, Rust, Nim, D…

            Not convinced that that’s worked out in practice. Certainly when working in Python, the Qt bindings were much nicer to use than the GTK ones. “It’s harder to bind to C++ than C” is true as far as it goes, but binding to GObject doesn’t really mean binding to C, it means binding to either a pile of preprocessor macros or to Vala, both of which seem harder than binding vanilla C++.

            Documentation… honestly, no UI toolkits has great docs.

            True as far as it goes, but there are definitely some with better docs than others.

            Also, GTK 4 is bringing GPU rendering to the existing regular desktop widget system, instead of creating a new separate thing (QML/QtQuick) that’s rarely going to be used, especially on desktop apps

            We’ll see how that works out for them. Back when I worked on a game in ~2010 I found the Qt approach to this very easy and common-sense: set the flag to enable OpenGL on the part for which it made sense (my game scene), don’t try to use it on the vanilla widgets (because why would I want to?)

      2. 3

        It’s great to see regular progress where some of the other libre phone projects seem dead. If this ends up being usable I will probably get one.