10 ms·

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

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.

badsectoracula 4y ago
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.
- Crysstalis 4y ago
  >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.
  - badsectoracula 4y ago
    > 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.
    - Crysstalis 4y ago
      >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.

badsectoracula 4y ago

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.

Crysstalis 4y ago
>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.
- badsectoracula 4y ago
  > 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.
  - Crysstalis 4y ago
    >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.