1. 44
  1. 6

    I think it’s safe to say that most of us don’t exactly have fond memories about the early days of the 3.x series.

    Hopefully this will be nothing like that!

    1. 3

      They’ve guaranteed API stability this time, so fingered crossed, no churn. Porting also looks a lot simpler than 2->3 was.

      1. 3

        “Stability” was guaranteed at various points during the 3.x series, too, and it didn’t count for much. Remember, for example, that time (around 3.12 or 3.14?) when we all breathed a sigh of relief that support for theme engines was just being “deprecated” and would remain in until GTK 4, and that turned out to mean the methods won’t be removed, so that the code will still compile, they just won’t do anything anymore?

        1. 1

          There is no API stability. See my other comment. They have removed major GTK components.

          1. 4

            I don’t think anyone was expecting API stability between 3 and 4 though? That’s kind of the whole thing of major versions.

            1. 1

              Yeah, what they’re not doing is changing the core APIs in 4.x.

              1. 1

                What do they mean by Core APIs then? If GTK.container is not one, then what is? I know the input manager APIs are vastly different as well?

                1. 4

                  I should have been clear: in 4.x minor versions. The churn in early 3.x minor versions was… not exactly SemVer.

      2. 5

        Given that I couldn’t even get a basic gtk app to start on GTK4.0 not that long ago, I am not holding out hope. Having read over a good bunch of some of the code, I have high hopes that it’ll be better, but porting to it is going to be mega-painful, and cause a bunch more people to move to something like QT. Personally they are deprecating one of the foundational classes (Gtk.Container) and this will mean re-writing a huge chunk of Terminator.

        1. 5

          Time to find new maintainers for GTK2…

          1. 1

            Which relevant GTK2 applications are left? I believe most have switched to GTK3 by now?

            1. 7
              $ xbps-remove gtk+
              gtk+-2.24.32_3 in transaction breaks installed pkg `firefox-83.0_2'
              gtk+-2.24.32_3 in transaction breaks installed pkg `gimp-2.10.20_1'
              gtk+-2.24.32_3 in transaction breaks installed pkg `graphviz-2.44.0_1'
              gtk+-2.24.32_3 in transaction breaks installed pkg `libgimp-2.10.20_1'

              Firefox also depends on gtk3; dunno why it also needs gtk2, this may be an error as it doesn’t seem to link against it. But GIMP only has had gtk3 support in the development version (and only since last month). Graphviz also doesn’t seem to have gtk3 (based on this issue).

              1. 5

                But GIMP only has had gtk3 support in the development version (and only since last month)

                Wow that’s ironic, considering GTK originally stood for “Gimp Tool Kit”

                1. 1

                  The development version of GIMP and the release version of Xfce4 now supports GTK3.

                  1. 1

                    dunno why it also needs gtk2

                    Some remnants of NPAPI/Flash support :D It shouldn’t be a dependency in the package anymore, of course.

                    1. 0

                      Ah, GIMP.

                      On my current Arch installation, mostly packages related to Xfce4 or Erlang would be removed if I uninstalled gtk2.

                      Xfce4 on gtk4 would be nice. I wonder if Erlang really needs gtk2.

                    2. 3

                      There are plenty of old apps that are nowadays unmaintained that may be or historical or research interest for decades to come. For this reason IMHO some libraries, including toolkits, need to live essentially forever.

                      1. 7

                        Let’s say you wanted to research a GTK2 application in 2030, or just look at it out of historical interest.

                        Why would it need to be maintained? Could you not just install an old release of a Linux distro in a virtual machine and give it a go?

                        1. 2

                          For historical interest, sure. For actual use, probably not. I’m writing this while using xmms as my media player; xmms was removed from Slackware when it purged gtk1, then put back, because…it’s actually pretty good.

                          Software has become a strange ecosystem where people work on things and then lose interest. In some cases, the software gets really good before that happens. But that leaves us with a big ecosystem of great things that aren’t going to keep up with framework fashion. Some people would say we just need to change our media players every other year to keep up with the frameworks. But do frameworks exist to enable applications, or limit our choice in applications?

                          For the most part, that doesn’t mean things need to be “maintained” in a strong sense. Neither xmms nor gtk1 should really need many changes. They do need occasional patches to keep up with compiler changes though.

                          1. 1

                            If you want an XMMS lookalike, there’s Promoe, an XMMS2 client.

                            However, I think you’re in the minority for needing something like XMMS in the first place, in the age of Spotify and other streaming services. If you insist on having your own media collection, there are CLI and web-based interfaces available. Or XMMS2 clients, various media players that comes with GNOME or KDE etc.

                            There is an inflation of open source desktop applications that can provide roughly the same functionality as XMMS1. Is this really an argument for keeping GTK1 in the package repositories of modern Linux distros?

                            Even if GTK1 and XMMS don’t require much maintenance, the potential for security issues in GTK1, or compilation issues in future releases of GCC or Clang has the potential to be time consuming. The only argument I can see in favor of keeping GTK1 and XMMS around in new releases of Linux distros, is pure nostalgia.

                  2. 2

                    I wonder whether GTK+ finally supports fractional scaling. Last time I used GTK+ on a Hi-DPI screen I could choose between “everything is incredibly tiny” and “everything is way too large, also no screen estate at all”.

                    1. 1

                      Yep, it does. The last couple versions if Gnome even provide an option on the settings dialog for it. Honestly the bigger issue for me had been dealing with mixed-dpi monitors (which I solved by buying a 4k monitor)