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 support?
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 then that is their decision, it should not have any influence on what other desktops decide to do.
In my personal opinion, all those panel and decoration protocols are broken and are needlessly recreating many of the same problems as were present in X11.
Thanks for the fact check. The article was labelled as opinion, and itsfoss.com can be a little rambling at its best, so it's good to hear a more informed counter-point.
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 networked case is not particularly relevant.
The modern replacement for networked objects is to write a web server and communicate using XMLHttpRequest/fetch/websockets, which is outside the scope of a desktop environment.
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 XWayland was built as a compatibility layer. If there are other areas where things have broken, then I suggest you try to build additional compatibility layers.
As i already wrote twice in other replies, Gtk breaking backwards compatibility is not due to a force of nature, but due to the Gtk developers deciding to break it.
The backwards compatibility i refer here is having libraries, binaries and code work with the very latest version of Gtk (not Gtk1, Gtk2, Gtk3 or Gtk4, but *Gtk*, no numbers or anything) always work, just like a Win32 binary made in Windows 95 using the Win32 API can work in Windows 11 and even get new functionality introduced in the same APIs since then or just like an ELF binary compiled in a 1997 Linux i386 distribution can work on a modern x86_64 Linux distribution (assuming no dependencies to broken userland libraries, of course) and use new functionality introduced to the same APIs in kernel since then.
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 porting.
If the suggestion is that GTK should somehow get the same budget that Microsoft has to put towards backwards compatibility, you know very well this is not possible. It would probably not even be wanted, GTK is a lot less popular than Windows.
Win32 programs from 2000 work on the latest Win32 and get new functionality that is exposed through the APIs they used at the time, where that applies.
Gtk programs from 2000 do not work on the latest Gtk, regardless of if the functionality they used from the APIs they relied on would be found in the latest Gtk. Instead they have to be "ported" to the new Gtk, assuming the source code is available, the developers are available and someone is willing to waste effort and time to do the porting.
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 is also correct. GTK1 programs will continue to work on GTK1, it has not changed.
> This is a nonsensical comparison though. New versions of GTK are actually new APIs.
Which has been my entire criticism! Gtk major versions being "new APIs" is what breaks backwards compatibility and causes existing applications, libraries to waste time keeping up.
It actually worse than Win32 vs WPF because the latter is something you can ignore as Win32 is still receiving improvements with bug fixes and new functionality, but Gtk development for any previous major version eventually stops all development. Not only that but even with new APIs, under Windows there is always some official way to use the previous APIs together with the new (e.g. mix Win32 with WPF) but there isn't anything like that for GtkN-1-with-GtkN (and even if there was it'd be pointless in long term as GtkN-1 would eventually stop working, unlike Win32).
>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 whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.
No, my actual criticism is that backwards compatibility was broken, not that previous versions stopped development - such a concern about stopping development only exists because the newer versions were not backwards compatible.
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?
I have issues with WPF too since i think Microsoft should have focused on improving Win32 instead of wasting their resources (and, most importantly, the time of everyone who felt at the time they had to keep up - see the Joel article i linked elsewhere), but bringing up WPF doesn't serve anything aside from muddling the discussion.
The only areas where i see WPF doing better is that at least it allows merging Win32 and WPF code, so an application can improve partially if they see WPF as a valid path forward - and it doesn't present itself as Win32 v2 so that Win32 development can continue independently (remember that i wrote that WPF is something you can at least ignore). None of these are the case with Gtk though.
But again, mentioning WPF here serves no purpose, what i wrote so far should be clear enough by itself.
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 than it is to GTK. And those libraries have not really changed in 30 years or so. With some hacking I bet you could get Xaw widgets to display in a GTK4 window.
That Joel article is more of a rant than a coherent statement, it is not reasonable to ask developers to stop working on new APIs and libraries.
>None of these are the case with Gtk though.
But this is incorrect, development can continue independently on old versions of GTK.
> I only mention WPF because you brought up Win32.
I brought up Win32 because it retains backwards compatibility for decades and still gets bug fixes and new features, WPF is as relevant to the discussion as Qt would be.
> The drawing part of the Win32 API is actually probably closer to Xlib and Xaw than it is to GTK.
The Win32 API provides way more functionality than Xlib (Xaw is a separate toolkit and unrelated to Gtk) and is closer to a toolkit like Gtk.
> That Joel article is more of a rant than a coherent statement, it is not reasonable to ask developers to stop working on new APIs and libraries.
What Joel asked (well, he didn't ask, jut put forward) was about wasting developers' time chasing new APIs that do the same things like the old APIs because they are afraid they're going to remain behind and the old APIs will stop getting any form of support or development.
Like what Gtk does to older major versions, basically.
> But this is incorrect, development can continue independently on old versions of GTK.
The entire idea of having an "old version of Gtk" that some 3rd party developer(s) continue on to keep backwards compatibility could only be a possibility because the actual Gtk developers do not care about keeping backwards compatibility.
>Ideally I would use an embedded Wayland compositor widget instead of a webview and broadway, but unfortunately there is only an old non working prototype called Wakefield and finishing it is a project on its own. In any case replacing the webview with a wayland compositor widget would be trivial.
>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 experience, this method would only work correctly with composited X or with XWayland.
>For example i prefer to have tearing on my desktop... In all cases, tearing is controllable through the vblank_mode setting via the .drirc file in your home directory
>Well, yes, it is your problem
This is also doing the same thing that the parent post is asking you not to do. It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
> Adding this to X window managers would be a flawed and inferior experience, this method would only work correctly with composited X or with XWayland.
You'll need to explain why and how it is "flawed and inferior", because the way i see it a Window Manager is responsible for managing windows and has an overview of all (toplevel) windows on the system (as a result of being responsible for them) and its placement and setup (e.g. in which monitor it is, what state -minimized, rolled up, maximized, etc- it is, etc). As such, like how it moves windows around, updates its state (minized, rolled, etc) it can also update the window's scale factor.
The main difference here is that the window needs to know how to scale itself, but this isn't that different from knowing how to handle arbitrary sizes when getting resized.
The idea isn't that weird (and honestly Windows does something similar so toolkits that work on Windows would need little change to support the same functionality on X):
1. Applications/toolkits that do not support the protocol will be scaled by the window manager, if possible (via, e.g, composition, note that a window can be composed without composing the full desktop - though there might be some corner cases here that need tweaks on the X server - a full desktop compositor will have no issues here however)
2. Applications/toolkits that do support the protocol but are running under a window manager that doesn't support it will do their scaling themselves by using the appropriate X APIs (RandR provides per-output DPI info that can be scaled, though a toolkit can also have user-wide settings for providing DPI-independent scaling settings per monitor) and geometry notifications
3. Applications/toolkits that do support the protocol and are running under a window manager that does support it (which can be known by a root window attribute and the application can also use a window attribute to specify that the window "speaks" the protocol) will receive scaling events from the window manager. The logic for these scaling values would be up to the window manager (e.g. per-output, per-monitor, per-application scaling but also could be some option in a context menu in the titlebar that provides scaling values and/or have some shortcut keys to scale up/down).
For #3 there could also be a message for the window manager to request scaling for a window so that, e.g. something like xdotool could provide such requests via the command like.
> It is not moving the discussion forward. The rest of your comment has very little in the way of meaningful suggestions that I can parse, you could have edited it down to maybe 4 or 5 sentences and gotten your point across.
Then i suggest making better effort towards understanding what others write or at least ask clarifications (like i did at my first response in this comment) because making the assumption that it doesn't move a discussion forward.
>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 X11 and it will break when someone wants to disable compositing or use another old window manager. As for the other parts, those would technically work, and it already does work like that for the most part. Most programs that can do DPI scaling do already have a way to scale themselves. But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
>Then i suggest making better effort towards understanding what others write or at least ask clarifications
There are no clarifications to ask, you are repeating the same comments that get posted all the time. Keep in mind these are the type of comments that you can see repeated very often:
"I have no problem, it works on my hardware"
"It is not a problem because I personally prefer it this way"
"Just try to fix the problem yourself by tweaking these developer settings (config files, environment variables, etc) and hoping it works"
If your comment follows this pattern then I would say just avoid making that comment, it is not moving the discussion forward. I think you can agree, when building these systems the goal is to get something that is usable out of the box for everyone. So these comments do not "move the needle" towards that, these are just reinforcing the current status quo.
> 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 X11 and it will break when someone wants to disable compositing or use another old window manager.
But it also does not rely on Wayland and all the flaws it has - after all my point was about being possible on X11, not about Wayland. Wayland had nothing to do with the post i wrote.
> But that is not a good experience for users, the point of it working seamlessly is to have support for it built into the window manager.
Yes, which is exactly what i wrote in my original message: "Window manager support for some common messages/hints (ala EWMH) so that the window manager is responsible for telling applications how to scale would improve things".
> There are no clarifications to ask, you are repeating the same comments that get posted all the time [...] If your comment follows this pattern then I would say just avoid making that comment
I suggest try to actual read what people are writing instead of trying to pattern match answers to whatever you think the poster is writing. This may also help understand what i write in my other replies about backwards compatibility.
>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 window manager is compositing which many window managers are not, or do not want to add, and some X11 users still seem to insist on not using them... Any attempts to add this to X11 are fighting an uphill battle.
>I suggest try to actual read what people are writing
I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
> Well my point was that it will always be an inferior experience on X11 even though it technically is possible in some circumstance.
Regardless of what you consider "inferior" (again, i do not see anything inferior assuming it is done as i described), the point was that it was possible.
> WM hints only work correctly if the window manager is compositing which many window managers are not, or do not want to add
Compositing is only needed for applications that do not support scaling themselves. There is no compositing necessary for applications that do support scaling, aside from the (literal) edge case of having an application cross two (or more) different monitors of different scale values and wanting to have the same visible area in all of them.
> and some X11 users still seem to insist on not using them...
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 best developers can do is try to provide options.
If something isn't possible in whatever "perfect" sense one might have, it can still be worth implemented in "good enough" ways. For example i use Window Maker, a window manager without desktop compositing support (aside from a minor use for window thumbnails) the UX of which i like in general despite its flaws in some cases. If i had multiple monitors with mixed DPI, i'd rather stick with WM even if i had to deal with the "window looks too big/small while dragging it between monitors" flaw since i consider the latter a minor issue while switching to a different environment (and all the consequences it may have) a much bigger one.
> I did and I believe those replies are following those patterns. Those comments seem unrelated to the other things about backwards compatibility. It is an entirely separate concern.
Your responses indicate that your beliefs are wrong then. The comment about backwards compatibility are relevant if you are also trying to do that pattern matching against what i write there.
>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 developer, if you know for a fact users will use an option that is going to break the intended use case. Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method. Old legacy applications with no scaling support will still need support from the window manager. So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
>Your responses indicate that your beliefs are wrong then
I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
> The issue with this thinking is that those pros and cons eventually cascade back to the developer, if you know for a fact users will use an option that is going to break the intended use case.
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.
> Window Maker is going to be broken or have a sub par experience with the situation you describe, because that only works with applications that support this method.
Maybe, but as i wrote, the alternative is either not using Window Maker or not having any scaling support, both of which would be way more undesirable for me.
> Old legacy applications with no scaling support will still need support from the window manager.
Sure, like any application with no scaling support in any platform that provides it, will need to support them somehow - this isn't limited to X11.
> So that is a perfect illustration of why that solution is inferior and can never work correctly if you want to take this angle of "I can make whatever choice I want, including the broken ones".
As far as i am concerned, the solution i describe is both superior and works perfectly fine when the alternative is introducing worse issues.
And this is the important bit: what i consider better and superior and what you consider better and superior are not the same thing, hence being able to have the option to set up things in the way each one likes (which of course relies on underlying systems that are modular enough to allow that).
> I do not think so, your additional writings have drifted further from that subject. I should remind you, this thread is a discussion of GNOME, not Window Maker.
I brought up Window Maker as an example that i have personal experience with, it could have also been IceWM or any other window manager without support for desktop composition.
Also FWIW my original reply in this thread wasn't about GNOME specifically either, it was a reply on some issues the original poster had with the Linux desktop environment in general (itself a post not specifically about GNOME too).
>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 own system. There is little reason to try to accommodate them further. The alternative is always going to be don't use that WM or don't have scaling support. It is not superior as you are always faced with this choice. That is the choice you get when you want to use legacy apps and WMs which is the only real reason to still be using X11.
> My point is those users will be unhappy anyway, they choose to break their own system.
That is a very "i know what is good for the users better than them" stance.
> The alternative is always going to be don't use that WM or don't have scaling support. It is not superior as you are always faced with this choice.
It is (or can be) superior when taking the entirety of the environment into account, not just the particular "scaling vs not scaling" support. It shouldn't really be that hard to understand that someone might prefer to stick with a window manager (or other program) because they like its overall UX despite not having a perfect solution for some particular problem, right?
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 called superior or even a solution at all. It just is something that does not affect you. Taking the entirety of the environment would consider all apps and all options that could possibly be used, I bet you can see how that would quickly become a bad situation that the users almost certainly do not know better than the developers how to handle. By definition, if a user is only focusing on their specific apps in a very strict and controlled situation, they actually cannot know what is the best overall choice.
Gtk in its entirety was never written from scratch but Gtk is big and individual components and parts of it have been written from scratch and has broken backwards compatibility in major ways, requiring from applications and libraries that depend on it to waste time keeping up with those changes (see XFCE or even GIMP as examples that took literally years to update to a new major version, only for Gtk developers to break their APIs again).
It reminds me of that old "Fire and Motion" article by Joel[0], especially these last bits:
> Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? [..] The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. [..] People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t, because this is how the game is played, Bubby.
Except of course, unlike Microsoft, GNOME and Gtk have nothing to gain by shooting the developers that depend on their APIs :-P
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 horrible idea because those toolkits are woefully outdated.
As i wrote in the other comment you replied (copy pasting here again since you basically repeated the exact same comment) it was a waste of time because 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.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
> But I bet even you would admit that is a horrible idea because those toolkits are woefully outdated.
The only reason these are seen as "woefully outdated" is because Gtk2 was incompatible with Gtk1, Gtk3 incompatible with Gtk2 and Gtk4 incompatible with Gtk3. If, however, they were backwards compatible then there wouldn't even be possible for a situation where remaining with a "woefully outdated" version to be a consideration - people would just upgrade to whatever is the latest version and things would keep working.
Again, Gtk breaking itself with major versions isn't due forces of nature, so you don't have to act as if that would be the only possibility.
>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 DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits. It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes. The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment. The rest of the comment stems from this incorrect assumption so I have not much else to say.
> This is incorrect, things like the DPI scaling, or the CSS changes, or the new rendering model in GTK4 could not be added in a backwards compatible way. They require porting to gain any of the benefits.
Then, assuming these specific features cannot be added in a backwards compatible way for existing applications (i have my doubts for DPI scaling since, e.g. Lazarus / LCL did exactly that, though in source code compatibility form only but that is due to a language limitation around shared libraries), they can be exposed in ways that do not break backwards compatibility and instead applications can opt-in to those features.
> It is simply not possible to design an API in such a way that you can perfectly anticipate all future changes.
Nobody ever mentioned that, what i refer to is not breaking existing applications, libraries and -of course- code that works, not to design APIs that are perfect from the get go.
> The "force of nature" here is not the GTK developers, it is the surrounding environment changing in ways that require the API to change to keep up, and it is in fact unavoidable for any developers trying to support that environment.
If there is actual interest in not breaking backwards compatibility, these features and any other features, could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
If i have, e.g., a program that has an input field with two buttons, one that shows a file picker dialog to fill the field with the path to the selected file and another that performs some (non-GUI) operation on the picked file, then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
>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 not want them, then do not port.
>could have been implemented and designed in such a way as to avoid breaking existing applications but also making porting the applications easy.
This is simply not possible. Many older APIs are just not designed to support this.
>then there is absolutely nothing that is affected in that application by improvement to scaling support, CSS support, rendering models or anything else.
Indeed, such a program would probably be trivial to port.
>With what i describe if Gtk4 was backwards compatible with Gtk1, a binary of that application compiled against Gtk1 would run under Gtk4 and get the new file picker dialog instead of the weird one used in Gtk1, would get antialiased font rendering, would get the themes used by Gtk4, etc.
If you want binary compatibility, that is a different story. It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4. But only the most trivial ones like a form with a couple of buttons. Anything with custom widgets (which is all non-trivial applications) would probably break or would lose most/all of the benefits, the GTK1 API simply was not designed in that way.
> This is already how it is. If you want those features, then port to newer versions. If you do not want them, then do not port.
Sorry but this shows you refuse to understand what i write in my responses.
> This is simply not possible. Many older APIs are just not designed to support this.
Then make new APIs alongside the old APIs.
> Indeed, such a program would probably be trivial to port.
And my point is that it shouldn't need to be ported.
> If you want binary compatibility, that is a different story.
It is not a different story, it is part of the entire backwards compatibility story. I refer to not only binary compatibility but also source compatibility. What i refer to is being able to:
1. Run old binaries in new systems while receiving any new functionality that may apply
2. Compile old programs against the latest version of the library without issues (at least not issues due to the library) and get pretty much the same functionality you'd get if you ran the old binary against the latest version of the library
3. Being able to upgrade the program, in parts or in whole (where that'd make sense - a new approach might be "better" in some ways but not be worth the effort for a particular program so using the old approach should still work)
> It might be possible to get some very trivial GTK1 programs to work with a compatibility layer on top of GTK4.
Such a compatibility is only needed because Gtk4 itself isn't backwards compatible with Gtk1.
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 many GTK1 applications do) then you cannot do anything about that with any "backwards compatibility". The application will just not work with DPI scaling until it is ported to work with a variable scale instead of a hard coded DPI. You cannot upgrade the program in parts either, or add a new API alongside it. The whole thing must be changed to support DPI scaling or some of it will be in the incorrect scale and the effects will cascade to other widgets that expect the scale to be passed to them from the parent widget. Because remember everything in a GTK program is in a widget tree that depends on passing down state.
Part of the reason that the themes changed and the CSS implementation got changes was because of these issues, i.e. pretty much all GTK1 and GTK2 applications and themes had no concept of device-independence, most drawing was done hard coding a DPI against raw device pixels. The few applications that implement it themselves would not benefit from any backwards compatibility layer.
You can also apply the same logic to many of the other changes in GTK. Your suggestions just cannot be done by swapping out the library, they are either impossible or are even more impractical than the current situation. If it were as easy as you seem to think it is then the GTK developers would have done it by now.
> 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 many GTK1 applications do) then you cannot do anything about that with any "backwards compatibility".
There are multiple ways to deal with that, for example Lazarus / LCL scales all automatic values by the scale factor. Only when someone deals with pixels directly (e.g. drawing shapes on a canvas manually) has to update the application.
Yes, in that case it wont work automatically, but it can still be good enough for most applications and the changes to make it work "properly" can still be much simpler than doing a massive API upgrade. In a desktop-based bugtracking program i wrote in Lazarus, pretty much all of the UI worked "out of the box" on a GPD Win 1 running KDE/Xorg with scaling set to 150% - except a single widget where i drew things manually. Fixing that was a matter of a few lines of code. Much preferable to having to port to some different toolkit.
Also fallbacks can still be implemented, like using shadow drawing and scaling. These can even be exposed as controls to the user via binary parameters or environment variables, thus allowing users who are not in a position to modify the program (e.g. using some old binary or found some source code that they can compile but do not really have the knowledge to fix themselves) to find a "good enough" scenario. This is why, e.g. Windows have that "Compatibility" tab in there, even if they cannot always get a 100% perfect fix.
The point is at least making an effort.
> they are impossible.
They are not impossible, most of the time when a programmer claims something is "impossible" they haven't tried or thought enough or tried to think enough out of the box: you have to take that into account from the point where you design the new features, not try to backport them after the fact.
A bunch of Gtk4 features as it exists and was designed right now with the current mindset will certainly feel hard / impossible to backport to something like Gtk1. The point is not have that mindset in the first place and treat backwards compatibility as a feature as important as anything else at all points during the development of the library.
>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 applications from using this method.
>Much preferable to having to port to some different toolkit.
Again, for applications with no custom widgets or without any use of the complex features, the porting effort to newer versions of GTK is also just a few lines of code, if even that. The simple things like buttons and inputs have barely changed.
>The point is at least making an effort.
Well, GNOME will probably not make this effort, as they dropped GTK1 around twenty years ago. It is not used anywhere in their stack. It was much easier and more beneficial for them to port or rewrite every application, multiple times actually. So I cannot really buy this complaint that porting is so difficult yet adding this compatibility to GTK1 is supposedly easy. If the method in Lazarus works so well then maybe an interested party should look at implementing it into GTK1 proper, because no one else seems to have any interest in maintaining GTK1.
>you have to take that into account from the point where you design the new features, not try to backport them after the fact.
Again there is nothing to take into account here. The issue is that the app developers also have hard coded these bad assumptions into their apps. If the app has to be changed to change the assumption then you might as well just port the app, because the only way to deal with it is to do that or backport it after the fact.
> Pretty much every custom widget with custom drawing does this, so that excludes most non-trivial applications from using this method.
A large part of even non-trivial applications do not do custom drawing - and many do not do any custom drawing at all. In the cases where this is needed, you only need to fix the particular drawing code and nothing else.
> the porting effort to newer versions of GTK is also just a few lines of code, if even that
Even if that is the case, it still has all the other backwards compatibility issues i mentioned.
> Well, GNOME will probably not make this effort, as they dropped GTK1 around twenty years ago.
The effort i mentioned here was on designing backwards compatible APIs and libraries, not about supporting something specific to Gtk1. I do not expect GNOME / Gtk developers to support Gtk3 for long, let alone Gtk1.
> Again there is nothing to take into account here.
The "that" in "have to take that into account" was backwards compatibility, not DPI scaling.
Look, we're going in circles and i do not feel like having to explain things that i believe should be self-explanatory all the time. So there is no really any point continuing that discussion, it is not like i expect any Gtk developer to suddenly come across my posts and somehow get enlightened or something and Gtk stops breaking itself (and well, even if one does, they'd have a hard time convincing the other developers, so it is probably better for their psyche if they do not understand what i write :-P).
>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 backwards compatibility when more benefits can be gained by porting. This is why most GNOME applications have ported.
>Even if that is the case, it still has all the other backwards compatibility issues i mentioned.
Those issues would be even worse by trying to hack various things into GTK1.
>The effort i mentioned here was on designing backwards compatible APIs and libraries
My point was that some things are impossible to design in a backwards compatible way. For example, anything that leads to certain assumptions getting hard coded in the app. You cannot API design your way out of those type of problems. The app has to be rewritten or ported.
>it is not like i expect any Gtk developer to suddenly come across my posts and somehow get enlightened or something
Keep in mind that GTK developers have very likely already weighed the benefits of what you are suggesting and have decided that it is not worth it, for various reasons.
>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 maintenance mode, and will only receive bug-fixes and nothing else.
It also means it wont receive any new features though and if the MATE developers want those features they'd have to waste time upgrading their -non-trivial- codebase from Gtk3 to Gtk4, just like they had to waste time (which took years, IIRC) to to upgrade the GNOME 2 (early MATE) codebase from Gtk2 to Gtk3.
Time that could have been spent improving MATE instead.
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 GTK3 and GTK4, those are the main reason to port.
> The parent comment was asking for "bug-fixes and nothing else" so I have no idea why you are talking about new features.
Because "bug-fixes and nothing else" isn't enough as i described in the comment you replied to right now as well as in a more detailed comment i replied to the parent post.
> If they wanted new features then it was not a waste of time. There are plenty of new features in GTK3 and GTK4, those are the main reason to port.
It was a waste of time because 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.
Gtk4 breaking backwards compatibility with Gtk3 wasn't an unavoidable act of nature, it was a decision made by the Gtk developers, my comments are a criticism of this decision and its consequences for the developers that rely on Gtk.
I am sure you can understand how that is a contrived situation if you are trying to test and deploy a general-purpose network application. In every other case with lower speeds it is a horrible option, the bandwidth usage is unacceptable.
There is nothing contrived about it. This is my daily reality. I have more than a hundred sites, each with hundreds to thousands of Linux servers, none of which are connected to the Internet.
I've also seen it work fine with 100mbit speeds. But again, I'm not going to make the claim that X-forwarding is the be-all and end-all of remote display solutions; I use mostly RDP and VNC when I'm on the Internet. I never said that X-forwarding is the best remoting solution in all scenarios. You're the one making the argument that everyone who doesn't do things your way is doing it wrong, because you don't seem to understand that other people have radically different use cases than what you're used to. And the flexibility of X11 means that it supports those use cases and others out of the box...and Wayland does not.
In fact, the only thing I've seen going for it is that a) people don't want to maintain X11 and b) it addresses vague security issues like applications resetting your display settings that almost no-one ever had a problem with. It's not a mystery to me why people complain. You're telling people that they're wrong for using their computers the way they've been using them for decades, and if they only change their workflow and environment (which they may have no control over) then they will be compliant with what's new and happening. I'm not here to defend X11, I have no great love for it, but it's bizarre to be told not wanting major feature regressions is wrong.
That unfortunately is a Qt bug, not specifically a Wayland bug. An issue should be filed there if it is not already. But, it is not likely you will be able to correct it for every app, because Qt apps can technically do whatever they want with their own theme and override the system theme.
GNOME's regards towards theming is precisely because of things like Qt themes being broken all the time.
