57 ms·

Nice to hear, congratulations and thanks for your hard work. Now time for gtk4 :( There was a time, when I was young, backwards compatibility was a big part o

by jmclnx 4y ago

Nice to hear, congratulations and thanks for your hard work. Now time for gtk4 :( There was a time, when I was young, backwards compatibility was a big part of our job. To me, it seems every other day QT and GTK makes a point of ignoring backwards compatibility with their releases, making Application Development hard. I admit, I do *not* understand GTK/QT development model at all. But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not break user space".

deleted 4y ago
[deleted]
mhd 4y ago
> Now time for gtk4 Port it back to its original toolkit, Motif, now that that's open. Won't be needing an update after that ;)
- orangesite 4y ago
  Given how many look&feel trends we've seen over the last few decades it would even look kinda cool&trendy in a postmodern-ish kinda way!
  - 2b3a51 4y ago
    Motif Window Manager (mwm) is very like twm but with nice regular sized colour icons and Alt-Tab already defined in the system .mwmrc. Very Windows 3 with iconised windows on the desktop. https://en.wikipedia.org/wiki/Motif_Window_Manager https://en.wikipedia.org/wiki/Motif_Window_Manager
orra 4y ago
> Now time for gtk4 :( Hopefully easier? Unsure however. > But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not break user space". Quite. Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine).
- pjmlp 4y ago
  Depends if they use Glade, or any of the removed APIs.
  - orra 4y ago
    I don't understand the Glade problem. I thought both GTK+ 3 and GTK+ 4 had a GtkBuilder class which loads .ui files? And as for creating .ui files, Cambalache is a replacement for Glade?
    - pjmlp 4y ago
      Sure if you like to write XML by hand. Cambalache is years away to reach feature parity with Glade. Then there is the whole of using Web to render the designer.
      - stuaxo 4y ago
        This sort of long slog work is where proper funding is needed. I'm sure all the distros are busy, but it sure would be nice if one of them would fund get a developer they pay to do this.
      - llothar 4y ago
        Their idea of GUI building is just too bad and backward. You define the GUI by dragging things on a Canvas and some things that are specified in text. What you never want is going through thousands of widgets in a sidebar and a bit here and a bit there. It suffers from we don't think about UI but only about technology. GUI Builder the old way stink (only XCode stinks like a perfume). There is also a reason why Microsoft does not offer a GUI Builder for their new WinUI 3
    - zorr 4y ago
      From what I've seen the .ui format for Gtk3 and Gtk4 are different and Glade does not support Gtk4 Widgets or its additional libraries like libadwaita. Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again. The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.
laweijfmvo 4y ago
A good example of why backwards compatibility is important! I've been using GIMP for years with no clue that it was using a 10-year old version of GTK. And that's great.
- awill 4y ago
  What does that have to do with backwards compatibility? Gnome hasn’t received a major update in ages because it required so much work to support gtk4. Of course gimp would keep working if you keep it on gtk3.
  - laweijfmvo 4y ago
    I guess I was imagining a scenario where Gnome 55 on Gtk 7 completely breaks compatibility with older Gtk apps and all the distros stopped providing Gtk 2/3 in their repositories and there were conflicts/headaches trying to get it all working. As long as Gtk continues to have backwards compat, old/unmaintained apps should never just 'stop working'.
    - int_19h 4y ago
      But your Gtk2 apps will not work on later versions of Gtk, and most distros are on the track to remove Gtk2 from the repos. So this isn't a hypothetical. And it will be the same once Gtk3 is phased out: https://docs.gtk.org/gtk4/migrating-3to4.html https://docs.gtk.org/gtk4/migrating-3to4.html
  - robertlagrant 4y ago
    Why are you agreeing so adversarially?
    - awill 4y ago
      Not trying to be adversarial. But I’m not agreeing. Obviously gimp will keep working if they don’t upgrade the dependencies. I don’t understand how that is impressive.
kitsunesoba 4y ago
Perhaps that kind of backwards compatibility requires a level of completeness or maturity that despite their age, GTK and Qt have yet to achieve (or are just now achieving). It's not too hard to get an AppKit/Cocoa project from the early 2000s compiling on modern macOS, but Cocoa had already accrued 20 years of age by 2005, which no doubt has reduced the degree of changes that've been necessary in the 18 years since. GTK only hit that 20 year mark a few years ago and hasn't enjoyed the same level of corporate firepower to develop it.
- jerf 4y ago
  There is a widespread lack of understanding of just how staggeringly large a high-quality GUI toolkit is. Across a number of minority language communities I participate in, there's a constant stream of "Why isn't there a good native GUI toolkit in $MY_FAVORITE_LANGUAGE yet? All the ones I can find suck." questions, to which the answer is, you're asking for a project that can easily be on the order of magnitude of all the other Open Source projects in the language combined, if not greater. What you get with less than effort than that are the aforementioned "suck"y GUI toolkits. Which I celebrate and praise, but realistically, just getting a production-grade "rich text widget" is alone a staggering undertaking, let alone everything else that goes into a GUI toolkit. Just a project to bind an existing GUI toolkit into your favorite language can easily overwhelm a dedicated team of multiple people, and as annoyingly complicated as that can be, it's wildly easier than building the entire toolkit. Getting to "maturity" is a really, really hard problem.
  - bfrog 4y ago
    A big part of that historically was a GUI toolkit might need to build up a whole object model, render model, various container types, event loop, timer queue, networking, IPC, file system abstractions, internationalization and tools to deal with that, debugging and visualization tools, etc, etc, etc. For cross platform toolkits a whole OS and build system layer to deal with that as well. At least the ones people ended up using widely (gtk, qt, win32, cocoa, etc). That's to say that a useful GUI toolkit has typically been a whole lot more than simply "draw me some widgets and let me poll on input events" I wonder if that's really still as true though in newer (not C/C++) languages like Rust for example, where you can reuse a lot more of what the ecosystem and language already provide.
hgs3 4y ago
> There was a time, when I was young, backwards compatibility was a big part of our job. To me, it seems every other day QT and GTK makes a point of ignoring backwards compatibility with their releases, making Application Development hard. Which is odd because desktop user interfaces haven't fundamentally changed in the past two decades. Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format.
- robertlagrant 4y ago
  RIP XUL[0]. [0] https://en.m.wikipedia.org/wiki/XUL https://en.m.wikipedia.org/wiki/XUL
- chungy 4y ago
  > Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format. Lazarus's LCL components pretty much do that. One source, can target Win32, Qt, GTK, and Cocoa.
- kitsunesoba 4y ago
  > Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format. In theory yes, but the attempts I've seen at this run into issues with things like widgets present on one platform not being present on others (e.g. Win32 has no miller column widget like Cocoa's NSBrowser) and the UI toolkit chasing identical behavior between platforms. For this sort of idea to work, I think an approach that fills gaps (following previous example, providing a Windows implementation of a miller column widget to mirror NSBrowser) and doesn't try to fight the behaviors of the UI toolkits it's built upon is what's ultimately required. Without that, an approach that reimplements everything from scratch is probably better.
  - ptx 4y ago
    wxWidgets [1] and SWT [2] are probably the most successful attempts at striking this balance (using native widgets). But usually the apps look slightly off on every platform. [1] https://www.wxwidgets.org/about/screenshots/ https://www.wxwidgets.org/about/screenshots/ [2] https://www.eclipse.org/swt/ https://www.eclipse.org/swt/
samsquire 4y ago
It is interesting that I read your comment today, I recently had an idea about enabling seamless binary compatibility and binary polymorphism without having to change and recompile sum types. Widget frameworks are very complicated and have intricate APIs. With present day computer technologies it is difficult to mutate an API or interface that others are implementing or using. I think people also rely on side effects that aren't promised by APIs, which makes it harder to change things. I want to be capable of refactoring my logic and code without breaking my data structure and I want to change my data structure without breaking my logic. These are at odds. How many times has a library upgrade caused a compiler error for you? When someone implements my Java API, it is difficult for me to change it. Breaking software upgrades is my common experience upgrading software libraries. My idea is that we should trace the method names, field/properties names and parameters used of methods in an Abstract Syntax Tree of code and then turn it into a structure and hash the symbols in the structure to correspond to in-memory layout index offset. (We put the data for the member symbol for example "children" in the same memory position every time) We can use heuristics with this AST that from any given symbol name, there is a traversal from one symbol to another. My idea is to handle the seamless migration of types - such as replacing one type for another, new type, merging types, splitting up types into members, changing the associations of a type, changing the plurality of the type (is it a 1-to-1 or 1-to-many mapping or many-to-many mapping?) The idea is to create a struct data layout from an AST symbol trace and turn it into deterministic arrangement of data at the machine code layer. When I refer to a symbol on a computer, it is at a numerical position in memory, relative to other symbols, such as relative to a symbol with RIP relative addressing in assembly. If the same symbol corresponds to the same numerical position every time regardless of the AST, we get binary compatibility regardless of the AST that created that symbol traversal. If I change the AST, but the data has the same underlying associations, the data structure can be inferred. For example, git detects file moves based on file hashes. We could define a list of keywords and hash them into buckets and then people use these symbol names and they get binary compatibility for free. For example, if a library upgrade changes the object hierarchy and splits something off into a new object, or introduces a plurality (one to many) where there was none before? Such as having multiple addresses for a customer, or multiple email addresses and contact numbers for an account where previously there was only one. The hash of the relationship diagram can map to a struct layout deterministically. For example, take the following data associational hierarchy: bussiness_unit-> department-> product -> manager and managers now need to be responsible for departments, the associational diagram changes to business_unit -> manager -> department -> product can we sort and hash the fields of these relationship diagrams so that they always place fields at the same index offsets in memory? hash "bussiness_unit-> department-> product -> manager" hash "business_unit -> manager -> department -> product" so business_unit_manager manager_department all produce the same indexes there are fields on business_unit to manager and children of manager object for department and children on department for products, or something like this. or similar. This kind of schema changes should be programmatically deterministic, because these kinds of migrations are so common. This idea could also solve database migrations too.
lifewallet_dev 4y ago
If you really didn't work with GTK2 then there's no way you can understand the problem, thus your comment.
jcelerier 4y ago
> To me, it seems every other day QT and GTK makes a point of ignoring backwards compatibility with their releases, making Application Development hard. can't talk about GTK but Qt broke C++ API compatibility once between 2012 and 2023 for Qt 5 -> Qt 6 (and really porting from 4 to 5 and 5 to 6 is not particularly complicated), I wouldn't say that it's fair to call this "makes a point of ignoring backwards compatibility with their releases"
- vetinari 4y ago
  There are still some people salty, that Gtk3 was breaking themes (not API or ABI, but themes). It was communicated explicitly that themes are going to break, the theme engine implementation was not fully ready when Gtk3 was originally released and that themes are not considered part of the public API. Yet, some people didn't take that warning seriously, and eventually found out the hard way that it was meant seriously.
- TingPing 4y ago
  GTK broke C api in 2011 and 2020. Not bad IMO.
  - llothar 4y ago
    10 years is the timespan for one technology transformation (yes, using Javascript Framework of the Day is not new technology). So it's not bad but also far from good or anything special to realize.
- Karellen 4y ago
  Is it really "breaking" the API when moving from v5 to v6 (or v2 to v3, or v3 to v4), when the old and new versions are co-installable, especially if they're all still at least receiving security support? GTK2 will continue to be included with Debian 12 ("Bookworm") when it's released later this year (knock on wood). Any apps written for GTK2 20 years ago will still work against it as the GTK2 API (and ABI) has remained backwards compatible all that time. (OK, GTK2 is EOL and not receiving any more updates since Dec 2020. So that's not great. But it does still work, and so will the apps that use it.)
sprash 4y ago
> I admit, I do not understand GTK/QT development model at all. It's very easy to understand. QT is a commercial and de-facto proprietary product and the development model is: do what the paying customer wants. GTK has no customers and after it was taken over by the GNOME crowd the development model is to deliberately sabotage the FOSS ecosystem. Small long tail projects can not afford to follow the relentless stream of backwards incompatible changes produced by upstream and die off. Even big projects like GIMP struggle with this. The result is a broken ecosystem which serves certain market participants (e.g. that offer desktop operating systems) very well.
- JellyBeanThief 4y ago
  On what basis are we claiming malicious intent by GNOME?
- TingPing 4y ago
  GNOME has developed it for decades. They broke API twice. Fewer times than Qt.
  - sprash 4y ago
    This is of course a lie. They declare widely used APIs as "internal interface" and break backwards compatibility on a regular basis even on sub minor version updates.
    - llothar 4y ago
      I think you are talking about the styling API during the 3.10 - 3.16 years. Yes they did but the styling was never an official API. If you can't find the documentation in Devhelp, then it's nothing you should use. For people who thought they are smart its of course a fuckery. The most painfull came from breaking the drawing code: Gtk2 moved to Pango/Cairo, Gtk4 moved to GPU Textures. Gtk5 will now break ageing view models. And i hope Gtk6 will break the single threading of the whole Gui.
phone8675309 4y ago
CADT
LeFantome 4y ago
You are not wrong that compatibility is a factor in the success of the Linux kernel and a huge reason that desktop Linux has never really hit the mainstream. Flatpak looks like it may partially fix that problem for desktop apps. Certainly, Flatpak makes it more realistic to support a commercial app on Linux. For gaming, somewhat ironically, the Windows APIs are serving to provide that compatibility role. If I wanted to reach Linux gamers, I think I would write a Windows game that was properly tested for good compatibility and performance on Proton. Not only can I probably effectively reach more Linux desktops that way today but my game will probably still run well a couple of years from now whereas a “native” Linux binary will probably have broken by then.

by jmclnx 4y ago

deleted 4y ago

[deleted]

mhd 4y ago

> Now time for gtk4 Port it back to its original toolkit, Motif, now that that's open. Won't be needing an update after that ;)

orangesite 4y ago
Given how many look&feel trends we've seen over the last few decades it would even look kinda cool&trendy in a postmodern-ish kinda way!
- 2b3a51 4y ago
  Motif Window Manager (mwm) is very like twm but with nice regular sized colour icons and Alt-Tab already defined in the system .mwmrc. Very Windows 3 with iconised windows on the desktop. https://en.wikipedia.org/wiki/Motif_Window_Manager https://en.wikipedia.org/wiki/Motif_Window_Manager

orra 4y ago

> Now time for gtk4 :( Hopefully easier? Unsure however. > But I think having that compatibility is one of the reasons of Linux's success, the rule of "Do not break user space". Quite. Of course, it's a sometimes repeated joke that the Linux GUI toolkit with the most binary compatibility is the Win32 API (via Wine).

pjmlp 4y ago
Depends if they use Glade, or any of the removed APIs.
- orra 4y ago
  I don't understand the Glade problem. I thought both GTK+ 3 and GTK+ 4 had a GtkBuilder class which loads .ui files? And as for creating .ui files, Cambalache is a replacement for Glade?
  - pjmlp 4y ago
    Sure if you like to write XML by hand. Cambalache is years away to reach feature parity with Glade. Then there is the whole of using Web to render the designer.
    - stuaxo 4y ago
      This sort of long slog work is where proper funding is needed. I'm sure all the distros are busy, but it sure would be nice if one of them would fund get a developer they pay to do this.
    - llothar 4y ago
      Their idea of GUI building is just too bad and backward. You define the GUI by dragging things on a Canvas and some things that are specified in text. What you never want is going through thousands of widgets in a sidebar and a bit here and a bit there. It suffers from we don't think about UI but only about technology. GUI Builder the old way stink (only XCode stinks like a perfume). There is also a reason why Microsoft does not offer a GUI Builder for their new WinUI 3
  - zorr 4y ago
    From what I've seen the .ui format for Gtk3 and Gtk4 are different and Glade does not support Gtk4 Widgets or its additional libraries like libadwaita. Cambalache is a successor for Glade but it also has issues. It uses its own storage format and you have to export to a .ui file for use in your Gtk4 project, and if you make changes to the UI file it's very difficult or even impossible to use those changes in Cambalache again. The general consensus on a few of the GNOME-related Matrix channels seems to be writing .ui files by hand.

laweijfmvo 4y ago

A good example of why backwards compatibility is important! I've been using GIMP for years with no clue that it was using a 10-year old version of GTK. And that's great.

awill 4y ago
What does that have to do with backwards compatibility? Gnome hasn’t received a major update in ages because it required so much work to support gtk4. Of course gimp would keep working if you keep it on gtk3.
- laweijfmvo 4y ago
  I guess I was imagining a scenario where Gnome 55 on Gtk 7 completely breaks compatibility with older Gtk apps and all the distros stopped providing Gtk 2/3 in their repositories and there were conflicts/headaches trying to get it all working. As long as Gtk continues to have backwards compat, old/unmaintained apps should never just 'stop working'.
  - int_19h 4y ago
    But your Gtk2 apps will not work on later versions of Gtk, and most distros are on the track to remove Gtk2 from the repos. So this isn't a hypothetical. And it will be the same once Gtk3 is phased out: https://docs.gtk.org/gtk4/migrating-3to4.html https://docs.gtk.org/gtk4/migrating-3to4.html
- robertlagrant 4y ago
  Why are you agreeing so adversarially?
  - awill 4y ago
    Not trying to be adversarial. But I’m not agreeing. Obviously gimp will keep working if they don’t upgrade the dependencies. I don’t understand how that is impressive.

kitsunesoba 4y ago

Perhaps that kind of backwards compatibility requires a level of completeness or maturity that despite their age, GTK and Qt have yet to achieve (or are just now achieving). It's not too hard to get an AppKit/Cocoa project from the early 2000s compiling on modern macOS, but Cocoa had already accrued 20 years of age by 2005, which no doubt has reduced the degree of changes that've been necessary in the 18 years since. GTK only hit that 20 year mark a few years ago and hasn't enjoyed the same level of corporate firepower to develop it.

jerf 4y ago
There is a widespread lack of understanding of just how staggeringly large a high-quality GUI toolkit is. Across a number of minority language communities I participate in, there's a constant stream of "Why isn't there a good native GUI toolkit in $MY_FAVORITE_LANGUAGE yet? All the ones I can find suck." questions, to which the answer is, you're asking for a project that can easily be on the order of magnitude of all the other Open Source projects in the language combined, if not greater. What you get with less than effort than that are the aforementioned "suck"y GUI toolkits. Which I celebrate and praise, but realistically, just getting a production-grade "rich text widget" is alone a staggering undertaking, let alone everything else that goes into a GUI toolkit. Just a project to bind an existing GUI toolkit into your favorite language can easily overwhelm a dedicated team of multiple people, and as annoyingly complicated as that can be, it's wildly easier than building the entire toolkit. Getting to "maturity" is a really, really hard problem.
- bfrog 4y ago
  A big part of that historically was a GUI toolkit might need to build up a whole object model, render model, various container types, event loop, timer queue, networking, IPC, file system abstractions, internationalization and tools to deal with that, debugging and visualization tools, etc, etc, etc. For cross platform toolkits a whole OS and build system layer to deal with that as well. At least the ones people ended up using widely (gtk, qt, win32, cocoa, etc). That's to say that a useful GUI toolkit has typically been a whole lot more than simply "draw me some widgets and let me poll on input events" I wonder if that's really still as true though in newer (not C/C++) languages like Rust for example, where you can reuse a lot more of what the ecosystem and language already provide.

hgs3 4y ago

> There was a time, when I was young, backwards compatibility was a big part of our job. To me, it seems every other day QT and GTK makes a point of ignoring backwards compatibility with their releases, making Application Development hard. Which is odd because desktop user interfaces haven't fundamentally changed in the past two decades. Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format.

robertlagrant 4y ago
RIP XUL[0]. [0] https://en.m.wikipedia.org/wiki/XUL https://en.m.wikipedia.org/wiki/XUL
chungy 4y ago
> Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format. Lazarus's LCL components pretty much do that. One source, can target Win32, Qt, GTK, and Cocoa.
kitsunesoba 4y ago
> Theoretically you could generate UI code for Win32, Qt, GTK, and others from a common markup format. In theory yes, but the attempts I've seen at this run into issues with things like widgets present on one platform not being present on others (e.g. Win32 has no miller column widget like Cocoa's NSBrowser) and the UI toolkit chasing identical behavior between platforms. For this sort of idea to work, I think an approach that fills gaps (following previous example, providing a Windows implementation of a miller column widget to mirror NSBrowser) and doesn't try to fight the behaviors of the UI toolkits it's built upon is what's ultimately required. Without that, an approach that reimplements everything from scratch is probably better.
- ptx 4y ago
  wxWidgets [1] and SWT [2] are probably the most successful attempts at striking this balance (using native widgets). But usually the apps look slightly off on every platform. [1] https://www.wxwidgets.org/about/screenshots/ https://www.wxwidgets.org/about/screenshots/ [2] https://www.eclipse.org/swt/ https://www.eclipse.org/swt/

samsquire 4y ago

It is interesting that I read your comment today, I recently had an idea about enabling seamless binary compatibility and binary polymorphism without having to change and recompile sum types. Widget frameworks are very complicated and have intricate APIs. With present day computer technologies it is difficult to mutate an API or interface that others are implementing or using. I think people also rely on side effects that aren't promised by APIs, which makes it harder to change things. I want to be capable of refactoring my logic and code without breaking my data structure and I want to change my data structure without breaking my logic. These are at odds. How many times has a library upgrade caused a compiler error for you? When someone implements my Java API, it is difficult for me to change it. Breaking software upgrades is my common experience upgrading software libraries. My idea is that we should trace the method names, field/properties names and parameters used of methods in an Abstract Syntax Tree of code and then turn it into a structure and hash the symbols in the structure to correspond to in-memory layout index offset. (We put the data for the member symbol for example "children" in the same memory position every time) We can use heuristics with this AST that from any given symbol name, there is a traversal from one symbol to another. My idea is to handle the seamless migration of types - such as replacing one type for another, new type, merging types, splitting up types into members, changing the associations of a type, changing the plurality of the type (is it a 1-to-1 or 1-to-many mapping or many-to-many mapping?) The idea is to create a struct data layout from an AST symbol trace and turn it into deterministic arrangement of data at the machine code layer. When I refer to a symbol on a computer, it is at a numerical position in memory, relative to other symbols, such as relative to a symbol with RIP relative addressing in assembly. If the same symbol corresponds to the same numerical position every time regardless of the AST, we get binary compatibility regardless of the AST that created that symbol traversal. If I change the AST, but the data has the same underlying associations, the data structure can be inferred. For example, git detects file moves based on file hashes. We could define a list of keywords and hash them into buckets and then people use these symbol names and they get binary compatibility for free. For example, if a library upgrade changes the object hierarchy and splits something off into a new object, or introduces a plurality (one to many) where there was none before? Such as having multiple addresses for a customer, or multiple email addresses and contact numbers for an account where previously there was only one. The hash of the relationship diagram can map to a struct layout deterministically. For example, take the following data associational hierarchy: bussiness_unit-> department-> product -> manager and managers now need to be responsible for departments, the associational diagram changes to business_unit -> manager -> department -> product can we sort and hash the fields of these relationship diagrams so that they always place fields at the same index offsets in memory? hash "bussiness_unit-> department-> product -> manager" hash "business_unit -> manager -> department -> product" so business_unit_manager manager_department all produce the same indexes there are fields on business_unit to manager and children of manager object for department and children on department for products, or something like this. or similar. This kind of schema changes should be programmatically deterministic, because these kinds of migrations are so common. This idea could also solve database migrations too.

lifewallet_dev 4y ago

If you really didn't work with GTK2 then there's no way you can understand the problem, thus your comment.

jcelerier 4y ago

> To me, it seems every other day QT and GTK makes a point of ignoring backwards compatibility with their releases, making Application Development hard. can't talk about GTK but Qt broke C++ API compatibility once between 2012 and 2023 for Qt 5 -> Qt 6 (and really porting from 4 to 5 and 5 to 6 is not particularly complicated), I wouldn't say that it's fair to call this "makes a point of ignoring backwards compatibility with their releases"

vetinari 4y ago
There are still some people salty, that Gtk3 was breaking themes (not API or ABI, but themes). It was communicated explicitly that themes are going to break, the theme engine implementation was not fully ready when Gtk3 was originally released and that themes are not considered part of the public API. Yet, some people didn't take that warning seriously, and eventually found out the hard way that it was meant seriously.
TingPing 4y ago
GTK broke C api in 2011 and 2020. Not bad IMO.
- llothar 4y ago
  10 years is the timespan for one technology transformation (yes, using Javascript Framework of the Day is not new technology). So it's not bad but also far from good or anything special to realize.
Karellen 4y ago
Is it really "breaking" the API when moving from v5 to v6 (or v2 to v3, or v3 to v4), when the old and new versions are co-installable, especially if they're all still at least receiving security support? GTK2 will continue to be included with Debian 12 ("Bookworm") when it's released later this year (knock on wood). Any apps written for GTK2 20 years ago will still work against it as the GTK2 API (and ABI) has remained backwards compatible all that time. (OK, GTK2 is EOL and not receiving any more updates since Dec 2020. So that's not great. But it does still work, and so will the apps that use it.)

sprash 4y ago

> I admit, I do not understand GTK/QT development model at all. It's very easy to understand. QT is a commercial and de-facto proprietary product and the development model is: do what the paying customer wants. GTK has no customers and after it was taken over by the GNOME crowd the development model is to deliberately sabotage the FOSS ecosystem. Small long tail projects can not afford to follow the relentless stream of backwards incompatible changes produced by upstream and die off. Even big projects like GIMP struggle with this. The result is a broken ecosystem which serves certain market participants (e.g. that offer desktop operating systems) very well.

JellyBeanThief 4y ago
On what basis are we claiming malicious intent by GNOME?
TingPing 4y ago
GNOME has developed it for decades. They broke API twice. Fewer times than Qt.
- sprash 4y ago
  This is of course a lie. They declare widely used APIs as "internal interface" and break backwards compatibility on a regular basis even on sub minor version updates.
  - llothar 4y ago
    I think you are talking about the styling API during the 3.10 - 3.16 years. Yes they did but the styling was never an official API. If you can't find the documentation in Devhelp, then it's nothing you should use. For people who thought they are smart its of course a fuckery. The most painfull came from breaking the drawing code: Gtk2 moved to Pango/Cairo, Gtk4 moved to GPU Textures. Gtk5 will now break ageing view models. And i hope Gtk6 will break the single threading of the whole Gui.

phone8675309 4y ago

CADT

LeFantome 4y ago

You are not wrong that compatibility is a factor in the success of the Linux kernel and a huge reason that desktop Linux has never really hit the mainstream. Flatpak looks like it may partially fix that problem for desktop apps. Certainly, Flatpak makes it more realistic to support a commercial app on Linux. For gaming, somewhat ironically, the Windows APIs are serving to provide that compatibility role. If I wanted to reach Linux gamers, I think I would write a Windows game that was properly tested for good compatibility and performance on Proton. Not only can I probably effectively reach more Linux desktops that way today but my game will probably still run well a couple of years from now whereas a “native” Linux binary will probably have broken by then.