Hacker News Reader

Comment by jp2022 | Hacker News Reader

jp2022

>Happy Birthday, MATE

Too bad that GTK is more or less controlled by the GNOME people which means that useful features are getting deprecated left and right. For this reason I sadly had to leave MATE and everything else GTK related behind since you never know how much will be deprecated in the next big GTK release. I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else. GNOME2 (and also GNOME 1.4) was good as is for me. I never needed more and don't want my user interface to change at all. It would be perfect if one could just compile GNOME 1.4 or GNOME 2.x without having to worry about some changes in a dependency of the DE making it unusable.

View on HN

> I just wish we would have a stable DE and Toolkit that only receives bug-fixes and nothing else.

That is not a good idea because new computers and hardware have new features that you'd want to use from your existing programs. For example you'd certainly want touch support for the laptops that have it, scaling support for high DPI screens, hardware acceleration support for having fast and smooth graphics on slower machines that still have hardware accelerated graphics (e.g. Raspberry Pi), etc.

The thing isn't to only get bug fixes and nothing else, but to get bug fixes and new features - but done in a completely backwards compatible way (even if that means new features have to be done by explicitly opting in to them).

This is harder and not as interesting as rewriting things from scratch though.

GTK was not rewritten from scratch. Each major release has been an incremental improvement.

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

[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

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.

Reply on news.ycombinator.com