5 ms·

> The distros keep your software working with newer versions of Gtk or Qt This doesn't help obscure software (like BambooTracker or vgmtrans) which isn't shipp

> The distros keep your software working with newer versions of Gtk or Qt This doesn't help obscure software (like BambooTracker or vgmtrans) which isn't shipped by most distributions. Additionally a distribution isn't going to port a Qt 5 app to Qt 6 for you; if the original developer doesn't, someone else might do it a few years later, or never. Sure, a distribution might ship Qt 5 indefinitely, but it's going to slowly fall behind over the next few years, like what's been happening to Qt 4. Worse yet is software dependent on the KF5 KDE support libraries. Ironically, old creaky-looking software like Strawberry (based off Clementine, based off KDE 3's Amarok) and Qsynth/QjackCtl (dated look and feel) are the first ones to port to Qt 6 (before KDE applications), because they don't depend on KDE libraries which need to be ported first.

kodah 5y ago
The desktop application ecosystem is kind of a mess from what I experienced; it's also possible I have the wrong expectations as I'm not usually building desktop apps. Gnome and QT generally have to be installed in order for apps that use them to work. I found that when I was trying to make an app, this ended up getting in my way far more than anticipated. There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward. This is kinda nice because the framework then deals with environment integration (for instance X11 vs Wayland, or Windows and MacOS) -- but at a minimum it makes it so you can build native feeling apps that are entirely web frontends. The only limitation here is that I've found UI components for OS-native look and feel (as opposed to mobile) to be fairly limited in quantity. At the end of the day, I guess what I'm alluding to is maybe QT and Gnome are great, but I feel like a lot of applications that are outside of serving a particular OS or ecosystem will need to build with UIs meant to run on multiple machines with minimal dependencies.
- nyanpasu64 5y ago
  On Windows, Electron-based apps generally bundle Electron (Chromium and Node.js) with the app, resulting in a large download size. You can do that with Windows Qt apps as well, and it generally works out too (the app is larger than a Win32 app but smaller than an Electron app). I have less experience with GTK but I assume it works the same. Linux distributions expect Qt and GTK apps to use a system toolkit. Some like Arch try to package Electron apps the same way (using a system Electron). However Electron releases incompatible major versions often, and you often have to install multiple Electron versions in parallel for different apps, and which version changes over time, so I have to juggle installing/uninstalling "electron" and "electron12/13/..." based on when apps update. (Admittedly, I also have Qt5/6 installed and GTK3/4 installed, but I expect these version numbers to remain stable for the next 5+ years.)
- PaulDavisThe1st 5y ago
  > There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward. It was already fairly straightforward. Now it's just understandable to people who are mostly familiar with web-centric development, which is a different claim entirely. Qt is not an ecosystem; KDE is (like GNOME). Qt (like GTK, at least historically) cannot be an ecosystem because it has to be cross-platform. You can build GUI apps in Qt or in other GUI toolkits and they will just work. They do not need integration into a desktop environment (though it can help in some cases if they are. "OS-native look and feel" is overrated. There are numerous apps from Apple, particularly in the media creation sector, that do not conform to their own "native look and feel", and several of the most successful apps in this sector from 3rd parties also ignore it. Maybe for "office/productivity" apps it is important...
  - bigpeopleareold 5y ago
    "OS-native look and feel" - +1 on being overrated. In most cases, I use programs, sometimes with diverging methods for doing common things, but it's not a deal-breaker. If you are not familiar with how a complex piece of software works and you need to use it, you have a bigger problem than if the UI seems a little different than other applications on the platform or if a few keybindings are different than expected. We work in the programs that we use primarily. Browsers are one such example. I wonder if they break OS UI guidelines; websites themselves certainly do. The only issue is if the look and feel is good enough on desktop applications. KDE makes things look consistent even with non-KDE/Qt programs, so I am happy enough.
- GoblinSlayer 5y ago
  Meanwhile the UI framework situation on windows became much worse than on linux. Windows 2000 had comctl, but it was consistent with user32, on XP they became different, vista added ribbons, then came WPF, UWP, Xamarin, Electron, Metro, immersive UI, now windows 11 added something new that looks like tenth UI framework.
- harry8 5y ago
  Question: If we want to write an gui app and have the binary continue to work on anything linux just about forever, how far does static linking get you? In most cases disk is not the resources most needed to optimize. Granted you don't get bugfixes in your libraries but you made the call that they were working well enough, and if security is at issue old binaries probably aren't a good answer ever? Statically linked to everything including libc should be forwards compatible with any kernel upgrade - "don't break userspace" Your app isn't the xserver. Do X upgrades break it? I imagine a distro switch to Wayland would? Or do they reverse compatible an X abi? Anything else that could change under you? Other servers than X? Anything else I'm missing? Anyone else remember being told that the answer was Java? What happened to that?
  - kodah 5y ago
    I can't speak to the long-term limitations of static linking. I will say that the JVM is a user-side hurdle which is undesirable. I usually use Rust or Go for cross compilation.

kodah 5y ago

The desktop application ecosystem is kind of a mess from what I experienced; it's also possible I have the wrong expectations as I'm not usually building desktop apps. Gnome and QT generally have to be installed in order for apps that use them to work. I found that when I was trying to make an app, this ended up getting in my way far more than anticipated. There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward. This is kinda nice because the framework then deals with environment integration (for instance X11 vs Wayland, or Windows and MacOS) -- but at a minimum it makes it so you can build native feeling apps that are entirely web frontends. The only limitation here is that I've found UI components for OS-native look and feel (as opposed to mobile) to be fairly limited in quantity. At the end of the day, I guess what I'm alluding to is maybe QT and Gnome are great, but I feel like a lot of applications that are outside of serving a particular OS or ecosystem will need to build with UIs meant to run on multiple machines with minimal dependencies.

nyanpasu64 5y ago
On Windows, Electron-based apps generally bundle Electron (Chromium and Node.js) with the app, resulting in a large download size. You can do that with Windows Qt apps as well, and it generally works out too (the app is larger than a Win32 app but smaller than an Electron app). I have less experience with GTK but I assume it works the same. Linux distributions expect Qt and GTK apps to use a system toolkit. Some like Arch try to package Electron apps the same way (using a system Electron). However Electron releases incompatible major versions often, and you often have to install multiple Electron versions in parallel for different apps, and which version changes over time, so I have to juggle installing/uninstalling "electron" and "electron12/13/..." based on when apps update. (Admittedly, I also have Qt5/6 installed and GTK3/4 installed, but I expect these version numbers to remain stable for the next 5+ years.)
PaulDavisThe1st 5y ago
> There's a whole new class of electron-like (usually WebView oriented) frameworks appearing for languages now that make building desktop apps fairly straightforward. It was already fairly straightforward. Now it's just understandable to people who are mostly familiar with web-centric development, which is a different claim entirely. Qt is not an ecosystem; KDE is (like GNOME). Qt (like GTK, at least historically) cannot be an ecosystem because it has to be cross-platform. You can build GUI apps in Qt or in other GUI toolkits and they will just work. They do not need integration into a desktop environment (though it can help in some cases if they are. "OS-native look and feel" is overrated. There are numerous apps from Apple, particularly in the media creation sector, that do not conform to their own "native look and feel", and several of the most successful apps in this sector from 3rd parties also ignore it. Maybe for "office/productivity" apps it is important...
- bigpeopleareold 5y ago
  "OS-native look and feel" - +1 on being overrated. In most cases, I use programs, sometimes with diverging methods for doing common things, but it's not a deal-breaker. If you are not familiar with how a complex piece of software works and you need to use it, you have a bigger problem than if the UI seems a little different than other applications on the platform or if a few keybindings are different than expected. We work in the programs that we use primarily. Browsers are one such example. I wonder if they break OS UI guidelines; websites themselves certainly do. The only issue is if the look and feel is good enough on desktop applications. KDE makes things look consistent even with non-KDE/Qt programs, so I am happy enough.
GoblinSlayer 5y ago
Meanwhile the UI framework situation on windows became much worse than on linux. Windows 2000 had comctl, but it was consistent with user32, on XP they became different, vista added ribbons, then came WPF, UWP, Xamarin, Electron, Metro, immersive UI, now windows 11 added something new that looks like tenth UI framework.
harry8 5y ago
Question: If we want to write an gui app and have the binary continue to work on anything linux just about forever, how far does static linking get you? In most cases disk is not the resources most needed to optimize. Granted you don't get bugfixes in your libraries but you made the call that they were working well enough, and if security is at issue old binaries probably aren't a good answer ever? Statically linked to everything including libc should be forwards compatible with any kernel upgrade - "don't break userspace" Your app isn't the xserver. Do X upgrades break it? I imagine a distro switch to Wayland would? Or do they reverse compatible an X abi? Anything else that could change under you? Other servers than X? Anything else I'm missing? Anyone else remember being told that the answer was Java? What happened to that?
- kodah 5y ago
  I can't speak to the long-term limitations of static linking. I will say that the JVM is a user-side hurdle which is undesirable. I usually use Rust or Go for cross compilation.