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.
badsectoracula|3 years ago
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.
Crysstalis|3 years ago
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.