6 ms·

What were the problems with this transition?

by nfoz 6y ago

madboston 6y ago
There are not enough words I can write for this.
RedShift1 6y ago
API changes every minor release.
- vetinari 6y ago
  Any specific examples? According to https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to-y.html https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to..., the changes were pretty minor.
  - ohazi 6y ago
    They broke enough of the theming API on every minor release that for a few years it was essentially impossible to run any GTK theme other than the GNOME sanctioned default theme (Adwaita). Adwaita was updated in lock step with GTK minor releases (by the same developers), and unaffiliated theme builders were left with periodic drops of subtly different behavior and no notes or tools on how to update their themes. It drove many of them away. This was apparently a part of a deliberate strategy around GNOME branding. The GNOME developers wanted all GTK apps to have one consistent look-and-feel, they wanted people to associate this look with GNOME, and they wanted people to start thinking of GTK apps as "GNOME Apps." More recently, they crippled existing functionality for server side-window decorations in Wayland (which literally every other toolkit supports), because GNOME decided to use exclusively client-side decorations. They vetoed all of the reasonable seeming workaround proposals, essentially telling developers to either use GNOME's decorations or to manually draw the close/maximize/minimize buttons. Honestly, all of the crap that systemd gets should be redirected towards GTK/GNOME. I've never seen a group of developers act in such bad faith.
    - saagarjha 6y ago
      Looks like they got the worst of both worlds, with no Cocoa arising from it and a bunch of pissed off developers and users…
    - baybal2 6y ago
      I myself was turned off from working on GTK+ when it became clear that GTK is turning from "The Gimp Toolkit" to "The GNOME Toolkit"
    - nyanpasu64 6y ago
      One time GTK3 altered the CSS formatting, causing Java Swing delegating theming to GTK3 to have invisible checkboxes and other widgets.
    - p_l 6y ago
      The GNOME/GTK devs and systemd devs are pretty tightly coupled... Recall the infamous config defaults change that killed sessions impacting things like tmux/screen? Pretty sure it was done because of gnome-session...
    - vetinari 6y ago
      Theming is internal, not public API though. It is fine to break internal APIs, that's why they are internal. Themers were warned, that the styling engine was under heavy rework. Gtk people could either wait few years until it's done and be stuck with Gtk2 meanwhile, or go out with Gtk3, which has relatively stable public API and internal API under rework. It's no brainer to take the same way they took. They also communicated this, so anyone who ignored their advice has no basis to complain. They were told exactly what is going to happen, and that they will either have to keep up, or not do it yet. Switch to client-side decorations was also done for a very good reason. There's a post by Rasterman (author of the Enlightenment WM) on reddit, where he details it why - and he is not even associated with Gnome. Windows and Mac also do client-side decorations, you just cannot see it, because clients cannot connect directly to the compositors, they have to use the client side libraries that handle that. Which is exactly what Gtk does.
  - wolfgke 6y ago
    RedShift1: > API changes every minor release. vetinari: > the changes were pretty minor. Was this pun intended? ;-)
rleigh 6y ago
There are so many that I could spend several hours ranting about them. If you invested time and effort in writing GTK+ 2.x applications, the GTK+ developers spent zero time caring about API compatibility even for cases where it would have cost them nothing to maintain. They just had to rip it all out just for the sake of it, even when single line compatibility forwarding functions would have been entirely sufficient to avoid breakage. This is the fundamental dichotomy with GTK+. Its developers want to hack on the toolkit itself for their own amusement and occasionally for GNOME features. They don't care about the needs of the application developers who would use their toolkit to write actual applications. God forbid it's used for its intended purpose. If you invested thousands of hours into using it, they will not bear that in mind as they rip out stuff people used for over two bloody decades in the name of "progress". Like GtkHBox. Gone. There since 1997 and used by every GTK+ application on the planet, but that's no reason to keep "old code"! That's their choice. But other libraries like Qt do take better care of the interests of their customers and end users, and don't gratuitously break core functionality on a whim while chasing shiny new things. In the above example, the GtkHBox class is replaced by GtkBox with an "orientation" property. Now, any sane developer would retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. New way works. Old way works. No breakage. Everyone is happy. But they just had to rip it all out in the name of "progress". Consider how many instances of this there are in a large codebase. Hundreds to thousands in a big UI. The breakage was entirely avoidable and quite unnecessary. Maintaining the compatibility code would have been a tiny effort with a few one-liner compat functions, but ripping it out imposed huge problems upon every user of the library. "Cleanliness" needs to be traded off against "breaking end users", but they have the scale dialled all the way to one side, which is spectacularly unhelpful and inconsiderate. That's just one class and one example. You could write a book enumerating all of the other instances. It's that bad. No one who looks at this rationally in 2020 should be choosing GTK+ for a new project. You know in advance it will end in tears and frustration, as all of the value you created will be destroyed on a whim by developers who should know better, but go ahead and break everything anyway just because they can. That's their choice. But it's our choice to not get sucked into the bizarre world where this kind of software maintenance is considered in any way acceptable or justifiable. Seriously. These people are on another planet. What project intentionally gives the finger to all of their developer base? A really messed up one with nonsensical priorities. Sorry if this comes over badly. If you can't tell, I've got a bit of pent-up frustration after spending far too many hours of my life trying to work around GTK+, submit patches which are ignored, and try to develop applications in spite of GTK+, not because of it. I should have just used Qt from the start.
deleted 6y ago
[deleted]

What were the problems with this transition?

by nfoz 6y ago

What were the problems with this transition?

madboston 6y ago

There are not enough words I can write for this.

RedShift1 6y ago

API changes every minor release.

vetinari 6y ago
Any specific examples? According to https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to-y.html https://developer.gnome.org/gtk3/stable/gtk-migrating-3-x-to..., the changes were pretty minor.
- ohazi 6y ago
  They broke enough of the theming API on every minor release that for a few years it was essentially impossible to run any GTK theme other than the GNOME sanctioned default theme (Adwaita). Adwaita was updated in lock step with GTK minor releases (by the same developers), and unaffiliated theme builders were left with periodic drops of subtly different behavior and no notes or tools on how to update their themes. It drove many of them away. This was apparently a part of a deliberate strategy around GNOME branding. The GNOME developers wanted all GTK apps to have one consistent look-and-feel, they wanted people to associate this look with GNOME, and they wanted people to start thinking of GTK apps as "GNOME Apps." More recently, they crippled existing functionality for server side-window decorations in Wayland (which literally every other toolkit supports), because GNOME decided to use exclusively client-side decorations. They vetoed all of the reasonable seeming workaround proposals, essentially telling developers to either use GNOME's decorations or to manually draw the close/maximize/minimize buttons. Honestly, all of the crap that systemd gets should be redirected towards GTK/GNOME. I've never seen a group of developers act in such bad faith.
  - saagarjha 6y ago
    Looks like they got the worst of both worlds, with no Cocoa arising from it and a bunch of pissed off developers and users…
  - baybal2 6y ago
    I myself was turned off from working on GTK+ when it became clear that GTK is turning from "The Gimp Toolkit" to "The GNOME Toolkit"
  - nyanpasu64 6y ago
    One time GTK3 altered the CSS formatting, causing Java Swing delegating theming to GTK3 to have invisible checkboxes and other widgets.
  - p_l 6y ago
    The GNOME/GTK devs and systemd devs are pretty tightly coupled... Recall the infamous config defaults change that killed sessions impacting things like tmux/screen? Pretty sure it was done because of gnome-session...
  - vetinari 6y ago
    Theming is internal, not public API though. It is fine to break internal APIs, that's why they are internal. Themers were warned, that the styling engine was under heavy rework. Gtk people could either wait few years until it's done and be stuck with Gtk2 meanwhile, or go out with Gtk3, which has relatively stable public API and internal API under rework. It's no brainer to take the same way they took. They also communicated this, so anyone who ignored their advice has no basis to complain. They were told exactly what is going to happen, and that they will either have to keep up, or not do it yet. Switch to client-side decorations was also done for a very good reason. There's a post by Rasterman (author of the Enlightenment WM) on reddit, where he details it why - and he is not even associated with Gnome. Windows and Mac also do client-side decorations, you just cannot see it, because clients cannot connect directly to the compositors, they have to use the client side libraries that handle that. Which is exactly what Gtk does.
- wolfgke 6y ago
  RedShift1: > API changes every minor release. vetinari: > the changes were pretty minor. Was this pun intended? ;-)

rleigh 6y ago

There are so many that I could spend several hours ranting about them. If you invested time and effort in writing GTK+ 2.x applications, the GTK+ developers spent zero time caring about API compatibility even for cases where it would have cost them nothing to maintain. They just had to rip it all out just for the sake of it, even when single line compatibility forwarding functions would have been entirely sufficient to avoid breakage. This is the fundamental dichotomy with GTK+. Its developers want to hack on the toolkit itself for their own amusement and occasionally for GNOME features. They don't care about the needs of the application developers who would use their toolkit to write actual applications. God forbid it's used for its intended purpose. If you invested thousands of hours into using it, they will not bear that in mind as they rip out stuff people used for over two bloody decades in the name of "progress". Like GtkHBox. Gone. There since 1997 and used by every GTK+ application on the planet, but that's no reason to keep "old code"! That's their choice. But other libraries like Qt do take better care of the interests of their customers and end users, and don't gratuitously break core functionality on a whim while chasing shiny new things. In the above example, the GtkHBox class is replaced by GtkBox with an "orientation" property. Now, any sane developer would retain GtkHBox and simply implement it in terms of GtkBox with a defaulted "orientation" to horizontal. New way works. Old way works. No breakage. Everyone is happy. But they just had to rip it all out in the name of "progress". Consider how many instances of this there are in a large codebase. Hundreds to thousands in a big UI. The breakage was entirely avoidable and quite unnecessary. Maintaining the compatibility code would have been a tiny effort with a few one-liner compat functions, but ripping it out imposed huge problems upon every user of the library. "Cleanliness" needs to be traded off against "breaking end users", but they have the scale dialled all the way to one side, which is spectacularly unhelpful and inconsiderate. That's just one class and one example. You could write a book enumerating all of the other instances. It's that bad. No one who looks at this rationally in 2020 should be choosing GTK+ for a new project. You know in advance it will end in tears and frustration, as all of the value you created will be destroyed on a whim by developers who should know better, but go ahead and break everything anyway just because they can. That's their choice. But it's our choice to not get sucked into the bizarre world where this kind of software maintenance is considered in any way acceptable or justifiable. Seriously. These people are on another planet. What project intentionally gives the finger to all of their developer base? A really messed up one with nonsensical priorities. Sorry if this comes over badly. If you can't tell, I've got a bit of pent-up frustration after spending far too many hours of my life trying to work around GTK+, submit patches which are ignored, and try to develop applications in spite of GTK+, not because of it. I should have just used Qt from the start.

deleted 6y ago

[deleted]