4 ms·

Gtk devs could learn much from projects like Linux, Windows, OpenJDK, Clojure, Emacs, or FLTK wrt backward compatibility. When Linus announced Kernel 5.0, it wa

by dig1 3y ago

Gtk devs could learn much from projects like Linux, Windows, OpenJDK, Clojure, Emacs, or FLTK wrt backward compatibility. When Linus announced Kernel 5.0, it was "just another release" [1]. But, unfortunately, I'm getting the impression that Gtk and GNOME are run by teen boys who want to impress girls rather than get the job done. [1] https://itsfoss.com/linux-kernel-5/ https://itsfoss.com/linux-kernel-5/

konart 3y ago
>But, unfortunately, I'm getting the impression that Gtk and GNOME are run by teen boys who want to impress girls rather than get the job done. Why? Because they desided that new features\API\etc are more important (possibly for a good reason) than speding a great amount of time on maintaining compatibility? Sometimes you have to chose. PS: not to mention that number of contributors for Gtk and Linux (not to mention Windows lol) is quite different.
- lallysingh 3y ago
  Desktop widget libraries aren't wide open spaces for innovation. What new features/APIs can they add that's worth porting an app from gtkN to gtk(N+1)?
  - emkoemko 3y ago
    fractional scaling? hidpi ? hdr etc ?
    - lallysingh 3y ago
      Why do any of those break existing code? Didn't win32 add those without breaking existing code?
      - revelio 3y ago
        Not really. Win32 DPI scaling is a mess.
      - TingPing 3y ago
        GTK is maintained by 2-5 people. They cannot maintain every API forever. win32 is also a terrible example of good API, just stable.
        hulitu 3y ago
        > GTK is maintained by 2-5 people. They cannot maintain every API forever. But they like to rewrite it every couple of years. /s
  - TingPing 3y ago
    Touch, animations, styling, portability, rendering performance, cleaner abstractions… GTK4 is very nice.
    - Zuiii 3y ago
      None of which required breaking backwards compatibility as demonstrated by "Linux, Windows, OpenJDK, Clojure, Emacs, or FLTK" (and I'll add Xorg too). You can add new things without breaking old things.
      - TingPing 3y ago
        That just isn’t true, you clearly haven’t used GTK. FLTK has never done core redesigns like GTK.
        lallysingh 3y ago
        Clearly you've never maintained a large codebase with dependencies.
        Zuiii 3y ago
        > That just isn’t true, you clearly haven’t used GTK. FLTK has never done core redesigns like GTK. One, I've wasted 6 years of my life writing GTK 2 and GTK3 apps. Two, What does "core redesigns" have to do with breaking backwards compatibility? Did the redesign necessitate removing GtkStatusIcon for example^1? What about ANY of the breaking changes made? 1: The reasoning given to justify breaking compatibility here paints a more clearer picture of how GTK devs treat breaking backwards compatibility. Remember, this is coming from the developers of what is supposedly a cross-platform toolkit.
        TingPing 3y ago
        A core redesign of GTK2->3->4 was moving from a model built around X11/xlib to one built around Wayland. GtkStatusIcon only functioned correctly on one backend, X11. It was very poorly supported on win32 and macOS. Other clear examples that had to happen was all rendering used to be done on the CPU with Cairo as part of the API. Cairo is very slow on high resolutions, or when doing animations, or just in general. The modern GTK is built around GPUs using OpenGL. There is a backwards compat story, in that you can use Cairo yourself still, but the API is all around modeled with modern hardware in mind. Something FLTK clearly is not and as such it cannot accomplish much of the things GTK4 can in terms of hidpi, animations, shaders, styling, zero-copy rendering, multimedia playback, etc. Yes, if given infinite resources, one could both resdesign a library and not break API, but it is a small group with limited resources. I genuinely think they have done an incredible job and there are many new possibilities with the toolkit now that were not previously. If the argument truely is just "never break API" I fundamentally disagree and think most platforms that follow it are bad platforms full of legacy cruft.
anthk 3y ago
Read CADT model form JWZ.
yjftsjthsd-h 3y ago
> When Linus announced Kernel 5.0, it was "just another release" In fairness, Linux major version numbers are just made up these days, while GTK is actually using the major version number to demarcate meaningful changes.
- Zuiii 3y ago
  GP's point is that those meaningful changes shouldn't also include breaking backwards compatibility because you don't want to support the old stuff.
  - jeroenhd 3y ago
    Half the comments here are "I wish the world hadn't moved beyond GTK2". I don't see the problem myself (GTK3 isn't libadwaita and some of the GTK2 controls like the file picker belong in a museum) but there's clearly a vocal group of people out there who will use GTK2/Gimp 2 for as long as they possibly can. It also saves a lot of problems with stable distributions (Debian, Ubuntu, etc.) because they can't just upgrade dependencies willy-nilly, and nobody wants a custom Debian patched GIMP to port back features from the next minor release. Taking the time to do a rewrite can help to prevent a half-broken intermediate state with wrapper objects and facades everywhere to deal with the version difference.

by dig1 3y ago

konart 3y ago

>But, unfortunately, I'm getting the impression that Gtk and GNOME are run by teen boys who want to impress girls rather than get the job done. Why? Because they desided that new features\API\etc are more important (possibly for a good reason) than speding a great amount of time on maintaining compatibility? Sometimes you have to chose. PS: not to mention that number of contributors for Gtk and Linux (not to mention Windows lol) is quite different.

lallysingh 3y ago
Desktop widget libraries aren't wide open spaces for innovation. What new features/APIs can they add that's worth porting an app from gtkN to gtk(N+1)?
- emkoemko 3y ago
  fractional scaling? hidpi ? hdr etc ?
  - lallysingh 3y ago
    Why do any of those break existing code? Didn't win32 add those without breaking existing code?
    - revelio 3y ago
      Not really. Win32 DPI scaling is a mess.
    - TingPing 3y ago
      GTK is maintained by 2-5 people. They cannot maintain every API forever. win32 is also a terrible example of good API, just stable.
      - hulitu 3y ago
        > GTK is maintained by 2-5 people. They cannot maintain every API forever. But they like to rewrite it every couple of years. /s
- TingPing 3y ago
  Touch, animations, styling, portability, rendering performance, cleaner abstractions… GTK4 is very nice.
  - Zuiii 3y ago
    None of which required breaking backwards compatibility as demonstrated by "Linux, Windows, OpenJDK, Clojure, Emacs, or FLTK" (and I'll add Xorg too). You can add new things without breaking old things.
    - TingPing 3y ago
      That just isn’t true, you clearly haven’t used GTK. FLTK has never done core redesigns like GTK.
      - lallysingh 3y ago
        Clearly you've never maintained a large codebase with dependencies.
      - Zuiii 3y ago
        > That just isn’t true, you clearly haven’t used GTK. FLTK has never done core redesigns like GTK. One, I've wasted 6 years of my life writing GTK 2 and GTK3 apps. Two, What does "core redesigns" have to do with breaking backwards compatibility? Did the redesign necessitate removing GtkStatusIcon for example^1? What about ANY of the breaking changes made? 1: The reasoning given to justify breaking compatibility here paints a more clearer picture of how GTK devs treat breaking backwards compatibility. Remember, this is coming from the developers of what is supposedly a cross-platform toolkit.
        TingPing 3y ago
        A core redesign of GTK2->3->4 was moving from a model built around X11/xlib to one built around Wayland. GtkStatusIcon only functioned correctly on one backend, X11. It was very poorly supported on win32 and macOS. Other clear examples that had to happen was all rendering used to be done on the CPU with Cairo as part of the API. Cairo is very slow on high resolutions, or when doing animations, or just in general. The modern GTK is built around GPUs using OpenGL. There is a backwards compat story, in that you can use Cairo yourself still, but the API is all around modeled with modern hardware in mind. Something FLTK clearly is not and as such it cannot accomplish much of the things GTK4 can in terms of hidpi, animations, shaders, styling, zero-copy rendering, multimedia playback, etc. Yes, if given infinite resources, one could both resdesign a library and not break API, but it is a small group with limited resources. I genuinely think they have done an incredible job and there are many new possibilities with the toolkit now that were not previously. If the argument truely is just "never break API" I fundamentally disagree and think most platforms that follow it are bad platforms full of legacy cruft.

anthk 3y ago

Read CADT model form JWZ.

yjftsjthsd-h 3y ago

> When Linus announced Kernel 5.0, it was "just another release" In fairness, Linux major version numbers are just made up these days, while GTK is actually using the major version number to demarcate meaningful changes.

Zuiii 3y ago
GP's point is that those meaningful changes shouldn't also include breaking backwards compatibility because you don't want to support the old stuff.
- jeroenhd 3y ago
  Half the comments here are "I wish the world hadn't moved beyond GTK2". I don't see the problem myself (GTK3 isn't libadwaita and some of the GTK2 controls like the file picker belong in a museum) but there's clearly a vocal group of people out there who will use GTK2/Gimp 2 for as long as they possibly can. It also saves a lot of problems with stable distributions (Debian, Ubuntu, etc.) because they can't just upgrade dependencies willy-nilly, and nobody wants a custom Debian patched GIMP to port back features from the next minor release. Taking the time to do a rewrite can help to prevent a half-broken intermediate state with wrapper objects and facades everywhere to deal with the version difference.