>A large part of even non-trivial applications do not do custom drawing - and many do not do any custom drawing at all. Then those parts will be easier to port as well, so there is not much benefit to having this…
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…
I understand that, but what you are doing by making that choice is actually choosing to make those other problems your problem. Maybe they do not affect you, but they are still there, so the "solution" can hardly be…
>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…
I understand exactly what you are saying but it does not make sense. Think of this on the most basic level like with DPI scaling. If an application has no idea of DPI scaling and has a certain DPI hard coded in (like…
>but Gtk development for any previous major version eventually stops all development. Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. 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…
>new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries. This is incorrect, things like the…
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…
>You'll need to explain why and how it is "flawed and inferior" Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of…
>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…
It is using a webkit view because currently it is the easiest way to display content from an external process in a cross-platform way. It does not have to be that way though:…
>Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale Adding this to X window managers would be a flawed and inferior…
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…
>A large part of even non-trivial applications do not do custom drawing - and many do not do any custom drawing at all. Then those parts will be easier to port as well, so there is not much benefit to having this…
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…
I understand that, but what you are doing by making that choice is actually choosing to make those other problems your problem. Maybe they do not affect you, but they are still there, so the "solution" can hardly be…
>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…
I understand exactly what you are saying but it does not make sense. Think of this on the most basic level like with DPI scaling. If an application has no idea of DPI scaling and has a certain DPI hard coded in (like…
>but Gtk development for any previous major version eventually stops all development. Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. 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…
>new features can be added in backwards compatible and opt-in ways that keep all existing applications and source code working while still using the latest version of the libraries. This is incorrect, things like the…
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…
>You'll need to explain why and how it is "flawed and inferior" Because it needs special support in the window manager. At that point it is the same as what Wayland is doing except it still has all the other flaws of…
>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…
It is using a webkit view because currently it is the easiest way to display content from an external process in a cross-platform way. It does not have to be that way though:…
>Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale Adding this to X window managers would be a flawed and inferior…
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…