5 ms·

Free-for-all in terms of toolkit and application mix, yes, but that's actually the "lesser" problem of the Linux desktop. Ideally we would have all-native appli

Free-for-all in terms of toolkit and application mix, yes, but that's actually the "lesser" problem of the Linux desktop. Ideally we would have all-native applications, but not even macOS can really manage that. The X11 and Wayland compatibility layers are very different than XQuartz macOS or the Wayland-based WSL GUI are, they are much more tightly integrated into Haiku. While you are still going to notice some seams here and there, overall the experience is much more like a "full port" than most other OSes have on this point. More to the point, all ported applications are still running on top of Haiku's kernel, Haiku's window manager / display server, Haiku's media services, Haiku's init system, Haiku's package manager, etc. On Linux, all those things come from separate projects, and some of them can even be swapped out within a Linux distribution, never mind between distributions. Not so on Haiku.

rayiner 4y ago
That’s a good observation. In many ways your approach is like Carbon on MacOS, or the bajillion UI toolkits that exist on top of the same display driver, clipboard, etc., infrastructure in Windows.
sho_hn 4y ago
Many of the apps are designed to the conventions of the various desktop environments on Linux (or Windows, in case of Wine), and feel most at home in one of them. Without additional effort to e.g. implement D-Bus and XDG portals, having a Qt or GTK app run will mean those apps open File Open/Save dialogs that are not the native Haiku ones. In the end it will be a fractured feel as well. I hear what you're saying and I do understand the point you're trying to make. However, I think it's interesting to point out just how app-centric systems have become, with many apps even shipping essentially their own unique HIG and look and feel. If you look at Haiku's competitors, 10 years ago they were all much more editorialized with a strong sense of what a proper, native app for them should look like. And despite all having more such native apps than Haiku has now, the trends have - at least for the time being - pulled away from that. If Haiku gets more popular it'll similarly become subject to simply running the most popular software.
- Ygg2 4y ago
  That's the issue with specific GUI toolkit. Haiku has its own set of tools. As long as it's integrated it might avoid Lisp Curse of Linux. It's too easy to fork and too hard to reintegrate.

rayiner 4y ago

That’s a good observation. In many ways your approach is like Carbon on MacOS, or the bajillion UI toolkits that exist on top of the same display driver, clipboard, etc., infrastructure in Windows.

sho_hn 4y ago

Many of the apps are designed to the conventions of the various desktop environments on Linux (or Windows, in case of Wine), and feel most at home in one of them. Without additional effort to e.g. implement D-Bus and XDG portals, having a Qt or GTK app run will mean those apps open File Open/Save dialogs that are not the native Haiku ones. In the end it will be a fractured feel as well. I hear what you're saying and I do understand the point you're trying to make. However, I think it's interesting to point out just how app-centric systems have become, with many apps even shipping essentially their own unique HIG and look and feel. If you look at Haiku's competitors, 10 years ago they were all much more editorialized with a strong sense of what a proper, native app for them should look like. And despite all having more such native apps than Haiku has now, the trends have - at least for the time being - pulled away from that. If Haiku gets more popular it'll similarly become subject to simply running the most popular software.

Ygg2 4y ago
That's the issue with specific GUI toolkit. Haiku has its own set of tools. As long as it's integrated it might avoid Lisp Curse of Linux. It's too easy to fork and too hard to reintegrate.