3 ms·

In my opinion, what desktop Linux needs to attract the the sort of developers that create the high-polish third party software that macOS is known is a combinat

In my opinion, what desktop Linux needs to attract the the sort of developers that create the high-polish third party software that macOS is known is a combination DE and UI toolkit that provides the same breadth and depth that's found in AppKit. With AppKit, one can build just about any kind of app imaginable by importing a handful of stock frameworks. The need to use third party libraries is the lowest I've seen on any platform, with many apps not needing any at all. That's huge for lowering the amount of activation energy and friction involved in building things, as well as for reducing ongoing maintenance burden (no fear of the developer of libfoo suddenly disappearing, requiring you to chase down the next best fork or to fork it yourself). The other thing is not being afraid of opinionated design choices, which is also a quality of AppKit. This is going to chafe some developers, but I see it as a necessary evil because it's what allows frameworks to have "happy paths" for any given task that are well-supported, thoroughly tested, and most importantly work as expected. GTK and Qt are probably the closest to this ideal but aren't quite there.

MrDrMcCoy 2y ago
I've been meaning to get into Qt dev for a while now, as it seems to be a pretty big, portable framework with batteries included, which would be a big step up from the little headless Python tools I've been writing. What would you say is missing from Qt and the related KDE frameworks compared with AppKit?
- jwells89 2y ago
  With a disclaimer that I'm not an expert on Qt: - Qt Widgets has a selection of controls that falls a bit short of that of AppKit and doesn't receive much attention any more - Qt Quick/QML seems more mobile-oriented and web-styled, being barebones if you don't pull in a library of third party widgets (e.g. Kirigami) - Neither go as deep as AppKit with functionality and require more third party library usage - Practically speaking, developers are limited to C++ or Python for Widgets and JavaScript for QML - Distribution of Qt apps is messy and error-prone These aren't really dealbreakers on their own but pile up to pull the overall experience down.
  - MrDrMcCoy 2y ago
    Do you think there are any better frameworks for open source development of cross-platform GUI apps? I keep seeing mutterings that Godot or some other game engine could become that, but have yet to see anything materialize in that space.
    - jwells89 2y ago
      At the moment, no not really. Some of the other options improve on Qt’s weaknesses, but only at the cost of its strengths (for example, if you want a tableview/datagrid with sortable, rearrangable columns like is standard in Qt Widgets and AppKit, more “modern” options Flutter and Jetpack Compose aren’t options because they lack such a widget). The problem with using game engines for UI is that their accessibility (support for screen readers, for example) is bad and they don’t adapt to the user’s desktop settings (e.g. light/dark mode and font size) unless you implement that yourself.
    - consteval 2y ago
      Electron + React is pretty good. In that you get tons of components, accessibility, and tooling. The downside however is that it's incredibly expensive compute and memory wise. Many applications are just too complex to represent as HTML + JS + CSS with a virtual dom in a performant manner. So then to make the performance work you have to write more custom code in JS or use more fringe technologies like WASM and at that point you're losing the usability aspect of Electron. I haven't looked at the source code for VS Code, but I'm pretty confident in saying it's not naive/straight-forward HTML + JS.
      - jwells89 2y ago
        The other big downside is a dependency tree that is better described as a rainforest with all of the third party widgets that you'll likely be importing, each of which comes with is own set of quirks, shortcomings, level of QA and maintenance, preferred development style, etc.

MrDrMcCoy 2y ago

I've been meaning to get into Qt dev for a while now, as it seems to be a pretty big, portable framework with batteries included, which would be a big step up from the little headless Python tools I've been writing. What would you say is missing from Qt and the related KDE frameworks compared with AppKit?

jwells89 2y ago
With a disclaimer that I'm not an expert on Qt: - Qt Widgets has a selection of controls that falls a bit short of that of AppKit and doesn't receive much attention any more - Qt Quick/QML seems more mobile-oriented and web-styled, being barebones if you don't pull in a library of third party widgets (e.g. Kirigami) - Neither go as deep as AppKit with functionality and require more third party library usage - Practically speaking, developers are limited to C++ or Python for Widgets and JavaScript for QML - Distribution of Qt apps is messy and error-prone These aren't really dealbreakers on their own but pile up to pull the overall experience down.
- MrDrMcCoy 2y ago
  Do you think there are any better frameworks for open source development of cross-platform GUI apps? I keep seeing mutterings that Godot or some other game engine could become that, but have yet to see anything materialize in that space.
  - jwells89 2y ago
    At the moment, no not really. Some of the other options improve on Qt’s weaknesses, but only at the cost of its strengths (for example, if you want a tableview/datagrid with sortable, rearrangable columns like is standard in Qt Widgets and AppKit, more “modern” options Flutter and Jetpack Compose aren’t options because they lack such a widget). The problem with using game engines for UI is that their accessibility (support for screen readers, for example) is bad and they don’t adapt to the user’s desktop settings (e.g. light/dark mode and font size) unless you implement that yourself.
  - consteval 2y ago
    Electron + React is pretty good. In that you get tons of components, accessibility, and tooling. The downside however is that it's incredibly expensive compute and memory wise. Many applications are just too complex to represent as HTML + JS + CSS with a virtual dom in a performant manner. So then to make the performance work you have to write more custom code in JS or use more fringe technologies like WASM and at that point you're losing the usability aspect of Electron. I haven't looked at the source code for VS Code, but I'm pretty confident in saying it's not naive/straight-forward HTML + JS.
    - jwells89 2y ago
      The other big downside is a dependency tree that is better described as a rainforest with all of the third party widgets that you'll likely be importing, each of which comes with is own set of quirks, shortcomings, level of QA and maintenance, preferred development style, etc.