3 ms·

Those are annoyances one can work around. They are not APIs anyway (which is what the debate is all about), they are UI design decisions. Plus "Save As" kinda c

by batista 14y ago

Those are annoyances one can work around. They are not APIs anyway (which is what the debate is all about), they are UI design decisions. Plus "Save As" kinda came back (hold Option while browsing the file menu), and Spaces are still here inside Mission Control. Changing APIs like Gnome/KDE did frequently is something else altogether, especially when you don't have the luxury of a huge user base to force commercial companies to rewrite their code. As for open source application developers, they often just flee and abandon their apps than rewrite them for the third time around some new API.

pcwalton 14y ago
Carbon -> Cocoa was a massive change. So was PPC -> x86. There are also massive API compatibility issues even between those two enormous shifts -- witness the sudden breakage of all SDL games due to raw surface access in CoreGraphics moving to IOSurface, just to name one. The difference is, I think, that Apple has conditioned developers to expect massive breakage, and the OS X app industry has structural differences from the Linux desktop app community that make it more likely for apps to get fixed quickly.
- yarrel 14y ago
  Yes the facts really aren't with Miguel on the API breakage claim.
- batista 14y ago
  >Carbon -> Cocoa was a massive change. So was PPC -> x86. 1) Both were necessary. Carbon was a stop-gap port of the old Mac way and incompatible with the OS X design, and the x86 transition had to be made because the PPC mobile roadmap was late (and bad). It was not a "let's break API compatibility because we came with a cool new idea" or "because the old maintainer got bored and the new one has different ideas", which often happens in Gnome/Linux land. 2) Not to mention that the Carbon->Cocoa took like 7+ years to be made full (Carbon apps actually still run on modern OS X), and Apple went to the effort to provide a full bundled compatibility layer for PPC for many years (Rosetta), plus "fat binaries" to make the switch easier. I.e nothing like the "let's break stuff to make them better and let them deal with it" attitude in the Gnome world. 3) Also: Apple remade the old stuff ITSELF each time, with paid developers working on the OS X, bundled userland and Apple pro apps to port them, whereas Gnome changes made lots of developers walk away from the free, OS, Gnome apps. 4) Plus: Apple had a lot of market share (compared to Linux) to force companies like Adobe, Microsoft et al, to port their stuff along eventually. Gnome did not have that benefit. So, not at all the same, and no, it's far more than "Apple conditioning developers to expect change".
mpyne 14y ago
I'd just like to point out as a KDE developer that we don't go changing our APIs all willy-nilly. Every major release I can remember (since KDE 2.0) has kept binary compatibility for the libraries (see http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B http://techbase.kde.org/Policies/Binary_Compatibility_Issues...). There have been exceptions for Plasma libraries, but those were announced beforehand. Many current KDE libraries are evolutions of technology going back to KDE 2 (for better or worse). Perhaps the biggest change over the whole lifetime has been the shell (going from kdesktop+kicker in KDE 2+3 to Plasma in KDE 4) and going from aRts in KDE 2+3 to Phonon in KDE 4. Btw, we were highly encouraged to adopt the popular multimedia framework at the time (gstreamer 0.10) instead of writing Phonon. gstreamer will soon be releasing an incompatible 1.0, while in the interim Phonon gained native support for the sound server that become highly popular in the meantime, PulseAudio. KDE has been doing its part to insulate developers as much as possible from mandatory API changes. It's not as good as the kernel or Microsoft has been able to do, but it's certainly not as bad as GNOME IMHO. I can say this as an app maintainer too. Going onto the KDE 4.10 development cycle, JuK still has code that uses the "kde3support" library. :(
- batista 14y ago
  I've stopped following KDE like 5 years ago, but I remember constant changes to the multimedia APIs. Also each new QT version (2->3->4, now 5) brings incompatibilities, no?
  - mpyne 14y ago
    The multimedia API changed from KDE 2 and 3's aRts to KDE 4's Phonon. The API is still Phonon, and this will be true in KDE 5 as well. There were other application-specific APIs that were used for things that were beyond the capability of aRts and Phonon (e.g. Juk could use gstreamer directly in KDE 3) but the KDE APIs themselves were pretty stable. It's true that a Qt change in binary incompatible and involves at least some source porting effort, but honestly those have been fairly infrequent, and only one of those transitions (3->4) involved more than minor source changes. Qt 4 was released at the end of 2005 (around the time of Linux 2.6.15) and is still the "current" version, though the Qt 5 release is around the corner. In just the KDE 3 timeframe to now, on the other hand, there has been gstreamer 0.6, 0.8, 0.10, soon 1.0, PulseAudio, ConsoleKit, HAL, HAL's replacement (DeviceKit), DeviceKit's replacement (udev and friends, upower, udisks, etc.), PolicyKit, PolicyKit's replacement ("polkit"), NetworkManager 0.8, NetworkManager 0.9. Needless to say, trying to keep in sync with all of that has not been fun. :-/

by batista 14y ago

pcwalton 14y ago

Carbon -> Cocoa was a massive change. So was PPC -> x86. There are also massive API compatibility issues even between those two enormous shifts -- witness the sudden breakage of all SDL games due to raw surface access in CoreGraphics moving to IOSurface, just to name one. The difference is, I think, that Apple has conditioned developers to expect massive breakage, and the OS X app industry has structural differences from the Linux desktop app community that make it more likely for apps to get fixed quickly.

yarrel 14y ago
Yes the facts really aren't with Miguel on the API breakage claim.
batista 14y ago
>Carbon -> Cocoa was a massive change. So was PPC -> x86. 1) Both were necessary. Carbon was a stop-gap port of the old Mac way and incompatible with the OS X design, and the x86 transition had to be made because the PPC mobile roadmap was late (and bad). It was not a "let's break API compatibility because we came with a cool new idea" or "because the old maintainer got bored and the new one has different ideas", which often happens in Gnome/Linux land. 2) Not to mention that the Carbon->Cocoa took like 7+ years to be made full (Carbon apps actually still run on modern OS X), and Apple went to the effort to provide a full bundled compatibility layer for PPC for many years (Rosetta), plus "fat binaries" to make the switch easier. I.e nothing like the "let's break stuff to make them better and let them deal with it" attitude in the Gnome world. 3) Also: Apple remade the old stuff ITSELF each time, with paid developers working on the OS X, bundled userland and Apple pro apps to port them, whereas Gnome changes made lots of developers walk away from the free, OS, Gnome apps. 4) Plus: Apple had a lot of market share (compared to Linux) to force companies like Adobe, Microsoft et al, to port their stuff along eventually. Gnome did not have that benefit. So, not at all the same, and no, it's far more than "Apple conditioning developers to expect change".

mpyne 14y ago

I'd just like to point out as a KDE developer that we don't go changing our APIs all willy-nilly. Every major release I can remember (since KDE 2.0) has kept binary compatibility for the libraries (see http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B http://techbase.kde.org/Policies/Binary_Compatibility_Issues...). There have been exceptions for Plasma libraries, but those were announced beforehand. Many current KDE libraries are evolutions of technology going back to KDE 2 (for better or worse). Perhaps the biggest change over the whole lifetime has been the shell (going from kdesktop+kicker in KDE 2+3 to Plasma in KDE 4) and going from aRts in KDE 2+3 to Phonon in KDE 4. Btw, we were highly encouraged to adopt the popular multimedia framework at the time (gstreamer 0.10) instead of writing Phonon. gstreamer will soon be releasing an incompatible 1.0, while in the interim Phonon gained native support for the sound server that become highly popular in the meantime, PulseAudio. KDE has been doing its part to insulate developers as much as possible from mandatory API changes. It's not as good as the kernel or Microsoft has been able to do, but it's certainly not as bad as GNOME IMHO. I can say this as an app maintainer too. Going onto the KDE 4.10 development cycle, JuK still has code that uses the "kde3support" library. :(

batista 14y ago
I've stopped following KDE like 5 years ago, but I remember constant changes to the multimedia APIs. Also each new QT version (2->3->4, now 5) brings incompatibilities, no?
- mpyne 14y ago
  The multimedia API changed from KDE 2 and 3's aRts to KDE 4's Phonon. The API is still Phonon, and this will be true in KDE 5 as well. There were other application-specific APIs that were used for things that were beyond the capability of aRts and Phonon (e.g. Juk could use gstreamer directly in KDE 3) but the KDE APIs themselves were pretty stable. It's true that a Qt change in binary incompatible and involves at least some source porting effort, but honestly those have been fairly infrequent, and only one of those transitions (3->4) involved more than minor source changes. Qt 4 was released at the end of 2005 (around the time of Linux 2.6.15) and is still the "current" version, though the Qt 5 release is around the corner. In just the KDE 3 timeframe to now, on the other hand, there has been gstreamer 0.6, 0.8, 0.10, soon 1.0, PulseAudio, ConsoleKit, HAL, HAL's replacement (DeviceKit), DeviceKit's replacement (udev and friends, upower, udisks, etc.), PolicyKit, PolicyKit's replacement ("polkit"), NetworkManager 0.8, NetworkManager 0.9. Needless to say, trying to keep in sync with all of that has not been fun. :-/