4 ms·

If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply

If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply integrated with specific DE. Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used.

rvz 7y ago
> If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply integrated with specific DE. I see. So you're saying it's the "app developers" fault when a Linux user changes any system component of the Linux desktop stack i.e. display manager or desktop environment and the app fails to start or crashes because it only runs on GNOME, KDE or its X11 or Wayland-specific. It is actually an entire distro problem. When someone decides to make the switch to full blown Wayland or some other configuration, all bets and guarantees are off on stability and they start finding alternatives for other apps because the apps they tried don't work on their setup. [0] There's a reason why they say "UNSUPPORTED". For example, Firefox couldn't start on SwayWM and the number of issues and combinations of people not running it on their distro setup was mounting. [1]. Such issues are easy to test on Windows and macOS but very difficult in Linux distros, resorting to trail through the whole desktop stack to find the issue as demonstrated in this ticket [2]. Such issues like this still exist in many Linux apps not just Firefox. > Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used. Like I said, no guarantees are made if the user ends up changing system components or old frameworks and the app crashes on their setup when it is specifically made to work on a default install of XYZ distro. The point is that the freedom to mix and match subsystem components makes it complicated to test your app or trace a bug which could at worst be a regression in one part of a Linux subsystem component, which is why some see it as a blessing and a curse here. [0] https://www.swalladge.net/archives/2019/10/14/are-we-wayland-yet/ https://www.swalladge.net/archives/2019/10/14/are-we-wayland... [1] https://github.com/swaywm/sway/issues/3115 https://github.com/swaywm/sway/issues/3115 [2] https://bugs.kde.org/show_bug.cgi?id=397834#c1 https://bugs.kde.org/show_bug.cgi?id=397834#c1
- Spivak 7y ago
  I mean you're free to release an app and say it's only supported in GNOME or KDE on $distros. What the parent is getting at is that in most cases when developing with GTK or QT you have to make an effort to tie yourself to a specific DE. And as long as you don't do that the crashing is a bug in the DE/WM/User Error, not your app. Basically if you don't try to be super fancy you make it other people's problem if your app crashes.
- vetinari 7y ago
  Apples and oranges, in two aspects: 1. You compare dev version of linux compositor to stable versions of the other OSes If the app fails to start or crashes when it runs under one WM or another, then following happens: - app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app - the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor. The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces. Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do. Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates. 2. You compare different layers in the stacks In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it. In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you. By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain. --- I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that: 1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either. 2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.

rvz 7y ago

> If you have a problem that manifests itself under one DE but not under another, you are doing something very wrong - unless you are doing something very deeply integrated with specific DE. I see. So you're saying it's the "app developers" fault when a Linux user changes any system component of the Linux desktop stack i.e. display manager or desktop environment and the app fails to start or crashes because it only runs on GNOME, KDE or its X11 or Wayland-specific. It is actually an entire distro problem. When someone decides to make the switch to full blown Wayland or some other configuration, all bets and guarantees are off on stability and they start finding alternatives for other apps because the apps they tried don't work on their setup. [0] There's a reason why they say "UNSUPPORTED". For example, Firefox couldn't start on SwayWM and the number of issues and combinations of people not running it on their distro setup was mounting. [1]. Such issues are easy to test on Windows and macOS but very difficult in Linux distros, resorting to trail through the whole desktop stack to find the issue as demonstrated in this ticket [2]. Such issues like this still exist in many Linux apps not just Firefox. > Seriously, for a normal, user-facing app, all you should care about is at the level of the framework you used. Like I said, no guarantees are made if the user ends up changing system components or old frameworks and the app crashes on their setup when it is specifically made to work on a default install of XYZ distro. The point is that the freedom to mix and match subsystem components makes it complicated to test your app or trace a bug which could at worst be a regression in one part of a Linux subsystem component, which is why some see it as a blessing and a curse here. [0] https://www.swalladge.net/archives/2019/10/14/are-we-wayland-yet/ https://www.swalladge.net/archives/2019/10/14/are-we-wayland... [1] https://github.com/swaywm/sway/issues/3115 https://github.com/swaywm/sway/issues/3115 [2] https://bugs.kde.org/show_bug.cgi?id=397834#c1 https://bugs.kde.org/show_bug.cgi?id=397834#c1

Spivak 7y ago
I mean you're free to release an app and say it's only supported in GNOME or KDE on $distros. What the parent is getting at is that in most cases when developing with GTK or QT you have to make an effort to tie yourself to a specific DE. And as long as you don't do that the crashing is a bug in the DE/WM/User Error, not your app. Basically if you don't try to be super fancy you make it other people's problem if your app crashes.
vetinari 7y ago
Apples and oranges, in two aspects: 1. You compare dev version of linux compositor to stable versions of the other OSes If the app fails to start or crashes when it runs under one WM or another, then following happens: - app is using something/talking to something/assumes something in a way it is not supposed to -> bug in the app - the WM or compositor doesn't take some message or poking in a way it is supposed to take -> bug in the WM or compositor. The example you posted is sway, during the time it was in development. I stress again, it was in development, it was not supposed to be bug-free, and no distro shipped it. Applications do crash under dev version of macOS and Windows too; you just don't see that because the respective bug trackers are not public, and the respective dev builds of the os are not very public either. In Linux, you have access, but then you have to break something, with the implicit understanding that when that happens, you get to keep the broken pieces. Nobody sane would consider that supporting development versions of any package on any OS is something you are supposed to do. Related: Switching to Wayland is mostly non-issue. If your app previously used X11, it will continue run using X11 under Xwayland. If anything, the Wayland developers made it too seamless. Unlike Apple, which made XDarwin eye-sore, so the users would be aware and demand updates. 2. You compare different layers in the stacks In Windows, you have to use MS provided UI toolkit (whether Win32 or UWP, doesn't matter). In macOS, you have to use Cocoa. Neither of these vendors would allow you to talk directly to their respective compositor, no way around it. In Linux, just because you can - everything is transparent - doesn't mean you should. If you want to play at the same level as you do on Windows/macOS, use it at the same level: use a toolkit, that will abstract the same things for you, as the vendor supplied frameworks on the other OSes do. Gtk, Qt, Electron, doesn't matter, they do the heavy lifting for you. Do not talk to compositor directly - then you do not even have to care, whether it is X11 or Wayland, the toolkit will arrange it for you. By inserting yourself on the different level in the stack, you assume on yourself solving all the problems that are being solved there. If you want add your workload, you are welcome, but then be honest at least to yourself and admit, that it is easily avoidable self-inflicted pain. --- I understand, that there is no system-wide SDK with a given ABI, and that can be frustrating sometimes. I understand, that ABIs that distributions provide are semi-stable. There are solutions for that: 1. Pick a distribution you will support. Blackmagic supports RHEL/CentOS, nothing else. GoG supports Ubuntu. If it runs anywhere else, cool, but you are on your own. Similarly, you can even support several of them, but when someone decides to do X, where X breaks other apps, he is on his own. When the user is competent of breaking something on his own, surely he is competent of fixing it too. You don't support users who hex-edited their system libraries in Windows either. 2. Use flatpak. You choose the runtime, you choose when your app switches to newer runtime. Most runtimes have defined support periods and document, what can change during that support period (i.e. freedesktop one allows for security updates and updated OpenGL drivers). This has the advantage, that nobody is going to try using their self-compiled libraries as a replacement for the runtime-supplied ones.