6 ms·

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

by jp2022 4y ago

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

badsectoracula 4y ago
> 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.
- Crysstalis 4y ago
  GTK was not rewritten from scratch. Each major release has been an incremental improvement.
  - badsectoracula 4y ago
    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/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
    - Crysstalis 4y ago
      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.
Crysstalis 4y ago
>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.
- badsectoracula 4y ago
  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.
  - Crysstalis 4y ago
    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.
    - badsectoracula 4y ago
      > 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. 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.

by jp2022 4y ago

badsectoracula 4y ago

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

Crysstalis 4y ago
GTK was not rewritten from scratch. Each major release has been an incremental improvement.
- badsectoracula 4y ago
  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/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
  - Crysstalis 4y ago
    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.

Crysstalis 4y ago

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

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