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