| >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. |
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).