4 ms·

This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on a

This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.

Analemma_ 3y ago
It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead. There's no silver bullet here.
- jwells89 3y ago
  Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code. For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set. Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing. In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX. [0]: https://mauikit.org https://mauikit.org
  - rubymamis 3y ago
    You can use Rust with QML[1]. QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you. I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer. [1] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [2] https://www.get-plume.com/ https://www.get-plume.com/ [3] https://www.appflowy.io/ https://www.appflowy.io/ [4] https://github.com/stdware/qwindowkit https://github.com/stdware/qwindowkit
    - airstrike 3y ago
      You have no idea how valuable and helpful this comment was to me. Thank you very much!
      - rubymamis 3y ago
        I'm glad!
  - ogoffart 3y ago
    I'd like to take the opportunity to mention Slint: a new toolkit in the scene, is inspired by the spirit of Qt while aiming to address its shortcomings https://slint.dev https://slint.dev
epcoa 3y ago
“ feature gaps between platforms, making their feature set a union of features” This fundamentally doesn’t work for UI/UX. You have to pick a paradigm and implementation details at some point and the high level UX design of Windows UI dejure and Mac are just different, in ways that cannot be factored out of a framework without leaky abstractions. Your choices are: the Qt/Tk/Swing approach write once, a solid if dated UX that is themeable but not truly native anywhere, the web app (or its QML/Flutter/FX equiv), wxwidgets etal which sort of tried to be native everywhere last century and looks and works that way, or at least two parallel independent native UI implementations which is a gargantuan more effort. Or go whole hog with FLTK or your own custom thing. a11y? WTF is that? “ Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.” I wouldn’t call wxwidgets basic, but it is a mess. It can’t be any other way. If it could someone would have made it in the last 30 years. Just because you use Cocoa/AppKit rather than drawing on a canvas does not magically make your app feel like a Mac app. Literally 100s of side projects have started down this path. People eventually learn you can’t abstract everything away, at least not the labor intensive part.

Analemma_ 3y ago

It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work. And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead. There's no silver bullet here.

jwells89 3y ago
Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment. The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code. For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set. Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing. In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX. [0]: https://mauikit.org https://mauikit.org
- rubymamis 3y ago
  You can use Rust with QML[1]. QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you. I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer. [1] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [2] https://www.get-plume.com/ https://www.get-plume.com/ [3] https://www.appflowy.io/ https://www.appflowy.io/ [4] https://github.com/stdware/qwindowkit https://github.com/stdware/qwindowkit
  - airstrike 3y ago
    You have no idea how valuable and helpful this comment was to me. Thank you very much!
    - rubymamis 3y ago
      I'm glad!
- ogoffart 3y ago
  I'd like to take the opportunity to mention Slint: a new toolkit in the scene, is inspired by the spirit of Qt while aiming to address its shortcomings https://slint.dev https://slint.dev

epcoa 3y ago

“ feature gaps between platforms, making their feature set a union of features” This fundamentally doesn’t work for UI/UX. You have to pick a paradigm and implementation details at some point and the high level UX design of Windows UI dejure and Mac are just different, in ways that cannot be factored out of a framework without leaky abstractions. Your choices are: the Qt/Tk/Swing approach write once, a solid if dated UX that is themeable but not truly native anywhere, the web app (or its QML/Flutter/FX equiv), wxwidgets etal which sort of tried to be native everywhere last century and looks and works that way, or at least two parallel independent native UI implementations which is a gargantuan more effort. Or go whole hog with FLTK or your own custom thing. a11y? WTF is that? “ Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.” I wouldn’t call wxwidgets basic, but it is a mess. It can’t be any other way. If it could someone would have made it in the last 30 years. Just because you use Cocoa/AppKit rather than drawing on a canvas does not magically make your app feel like a Mac app. Literally 100s of side projects have started down this path. People eventually learn you can’t abstract everything away, at least not the labor intensive part.