Canonical has seemingly also decided the same thing when they cancelled Unity. And I do not blame them. Has anyone you know actually paid for a Linux desktop, outside of buying some really basic and general enterprise…
>Thinking "for a fact" that users will do something is a perfect way to make several of them unhappy when they want to do something else :-P. My point is those users will be unhappy anyway, they choose to break their…
That article is pretty rambling and the conclusion does not make a lot of sense. GNOME also does not really support custom panels on X11 either (unless you use an extension). If they do not want to support custom panels…
I only mention WPF because you brought up Win32. If you can acknowledge it is not completely the same then maybe do not bring that up at all. The drawing part of the Win32 API is actually probably closer to Xlib and Xaw…
>Only when someone deals with pixels directly (e.g. drawing shapes on a canvas manually) has to update the application. Pretty much every custom widget with custom drawing does this, so that excludes most non-trivial…
That does not follow. WPF is also not backwards compatible and you have no issue with that, because Win32 is still being maintained so that makes you feel you can ignore WPF. Am I wrong here?
>At the end of the day it is up to users to decide what they want to do with their computers - and deal with pros and cons of their choices The issue with this thinking is that those cons eventually cascade back to the…
>after all my point was about being possible on X11 Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance. WM hints only work correctly if the…
>they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features. This is already how it is. If you want those features, then port to newer versions. If you do…
This is a nonsensical comparison though. New versions of GTK are actually new APIs. So what you are saying is more like "WPF programs do not work if you delete WPF and try to compile it against only the Win32 API" which…
Not all features of Windows 11 can be bolted on to legacy Win32 APIs. Some features can but others cannot. GTK is not different in this regard. Some features have stayed the same but others have changed and require…
>not dbus In practice D-Bus is functionally similar to many other IDL schemes and can be trivially tunneled over SSH. But yes, it has mostly become used for local applications to communicate with system daemons, and the…
The only reasons anything has compatibility breakage is because things have not been back ported, or because no one has built a compatibility layer. GTK1, and most other programs using Xlib, are able to work because…
The parent comment was asking for "bug-fixes and nothing else" so I have no idea why you are talking about new features. If they wanted new features then it was not a waste of time. There are plenty of new features in…
If they are getting something out it then it is not a waste of time. Those applications are free to stay on GTK1 or GTK2 or whatever they want. Those APIs were never broken. But I bet even you would admit that is a…
GTK was not rewritten from scratch. Each major release has been an incremental improvement.
>I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else. This is how it already is for MATE as long as they intend to keep it that way. It uses GTK3, which is currently in…
Making a command line interface that outputs binary is even worse than a text stream, because then it cannot be used interactively at all, and that defeats the whole purpose of a command line user interface. At that…
Sure, you may not have heard of it. But it is a thing that can happen and is not possible to fix without changing (i.e. breaking) the API. X11 does not have a mechanism to fix it, that was never added.
I mentioned three solutions. In general you can make a lot of things "just work" with SSH, by using port forwarding.
No, you can just install it if you need it. It is just another package, there is no special reason it needs to be default.
That is how all other remoting solutions work. X11 forwarding just happens to be the worst one.
>The ability to automate and integrate with a huge ecosystem of compatible tools What you are thinking of is an API, not a command line interface. That still exists, and it can be used to build a command line interface.…
>how do we design both a secure system and one that allows screenshots and screen sharing? That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston…
But you can still fiddle. Unless I missed something, the only complaint here is that the method of fiddling has changed. And somehow, I doubt that even the most fervent of fiddlers really enjoy typing obscure command…
Canonical has seemingly also decided the same thing when they cancelled Unity. And I do not blame them. Has anyone you know actually paid for a Linux desktop, outside of buying some really basic and general enterprise…
>Thinking "for a fact" that users will do something is a perfect way to make several of them unhappy when they want to do something else :-P. My point is those users will be unhappy anyway, they choose to break their…
That article is pretty rambling and the conclusion does not make a lot of sense. GNOME also does not really support custom panels on X11 either (unless you use an extension). If they do not want to support custom panels…
I only mention WPF because you brought up Win32. If you can acknowledge it is not completely the same then maybe do not bring that up at all. The drawing part of the Win32 API is actually probably closer to Xlib and Xaw…
>Only when someone deals with pixels directly (e.g. drawing shapes on a canvas manually) has to update the application. Pretty much every custom widget with custom drawing does this, so that excludes most non-trivial…
That does not follow. WPF is also not backwards compatible and you have no issue with that, because Win32 is still being maintained so that makes you feel you can ignore WPF. Am I wrong here?
>At the end of the day it is up to users to decide what they want to do with their computers - and deal with pros and cons of their choices The issue with this thinking is that those cons eventually cascade back to the…
>after all my point was about being possible on X11 Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance. WM hints only work correctly if the…
>they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features. This is already how it is. If you want those features, then port to newer versions. If you do…
This is a nonsensical comparison though. New versions of GTK are actually new APIs. So what you are saying is more like "WPF programs do not work if you delete WPF and try to compile it against only the Win32 API" which…
Not all features of Windows 11 can be bolted on to legacy Win32 APIs. Some features can but others cannot. GTK is not different in this regard. Some features have stayed the same but others have changed and require…
>not dbus In practice D-Bus is functionally similar to many other IDL schemes and can be trivially tunneled over SSH. But yes, it has mostly become used for local applications to communicate with system daemons, and the…
The only reasons anything has compatibility breakage is because things have not been back ported, or because no one has built a compatibility layer. GTK1, and most other programs using Xlib, are able to work because…
The parent comment was asking for "bug-fixes and nothing else" so I have no idea why you are talking about new features. If they wanted new features then it was not a waste of time. There are plenty of new features in…
If they are getting something out it then it is not a waste of time. Those applications are free to stay on GTK1 or GTK2 or whatever they want. Those APIs were never broken. But I bet even you would admit that is a…
GTK was not rewritten from scratch. Each major release has been an incremental improvement.
>I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else. This is how it already is for MATE as long as they intend to keep it that way. It uses GTK3, which is currently in…
Making a command line interface that outputs binary is even worse than a text stream, because then it cannot be used interactively at all, and that defeats the whole purpose of a command line user interface. At that…
Sure, you may not have heard of it. But it is a thing that can happen and is not possible to fix without changing (i.e. breaking) the API. X11 does not have a mechanism to fix it, that was never added.
I mentioned three solutions. In general you can make a lot of things "just work" with SSH, by using port forwarding.
No, you can just install it if you need it. It is just another package, there is no special reason it needs to be default.
That is how all other remoting solutions work. X11 forwarding just happens to be the worst one.
>The ability to automate and integrate with a huge ecosystem of compatible tools What you are thinking of is an API, not a command line interface. That still exists, and it can be used to build a command line interface.…
>how do we design both a secure system and one that allows screenshots and screen sharing? That did already happen, Weston had a built in screenshot tool. Pipewire was adopted because it was an improvement on the Weston…
But you can still fiddle. Unless I missed something, the only complaint here is that the method of fiddling has changed. And somehow, I doubt that even the most fervent of fiddlers really enjoy typing obscure command…