Page 15 of 21 FirstFirst ... 51314151617 ... LastLast
Results 141 to 150 of 210

Thread: GNOME & Intel Developers Plan The Wayland Future

  1. #141
    Join Date
    Feb 2013
    Posts
    82

    Default

    Quote Originally Posted by kigurai View Post
    And why are you surprised that two major versions of a library are incompatible? Isn't that exactly how it always works?
    Yet no one pointed out that same thing happened with Qt3->Qt4->Qt5 (those who are defending it). And no one is complaining because there isn't anything to complain about that. GStreamer 0.10 has been arround for 8 years or so (and I am not sure if ABI/API changed - but I doubt it), it's time for a new design :P

  2. #142
    Join Date
    Nov 2012
    Posts
    199

    Default

    Quote Originally Posted by Krejzi View Post
    Yet no one pointed out that same thing happened with Qt3->Qt4->Qt5 (those who are defending it). And no one is complaining because there isn't anything to complain about that. GStreamer 0.10 has been arround for 8 years or so (and I am not sure if ABI/API changed - but I doubt it), it's time for a new design :P
    Yeah, I have two versions of Qt installed, just like I have two versions of gstreamer and two versions of Gtk. And libusb, and ... so I have no idea what the problem is.

  3. #143
    Join Date
    Dec 2010
    Posts
    1,117

    Default

    Quote Originally Posted by kigurai View Post
    Can you point out specific breakages? As a user I have not noticed anything.
    “The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series.”
    http://gstreamer.freedesktop.org/new...9-24T18:00:00Z

    Quote Originally Posted by kigurai View Post
    And why are you surprised that two major versions of a library are incompatible? Isn't that exactly how it always works?
    Gnome fanboys just defended to use GStreamer directly. Because of that, every single GStreamer-using Gnome app has to be ported manually.
    With Phonon no application does even have to be touched. Just select another Phonon back-end and be done.

  4. #144
    Join Date
    Nov 2012
    Posts
    199

    Default

    Quote Originally Posted by Awesomeness View Post
    “The 1.x series is a stable series targeted at end users. It is not API or ABI compatible with the 0.10.x series.”
    http://gstreamer.freedesktop.org/new...9-24T18:00:00Z

    Gnome fanboys just defended to use GStreamer directly. Because of that, every single GStreamer-using Gnome app has to be ported manually.
    With Phonon no application does even have to be touched. Just select another Phonon back-end and be done.
    And how is this different from every other major version change of other libraries, for example: Qt3->Qt4->Qt5, Python2 -> Python3, ...?

  5. #145
    Join Date
    Feb 2011
    Posts
    1,086

    Default

    Quote Originally Posted by kigurai View Post
    And how is this different from every other major version change of other libraries, for example: Qt3->Qt4->Qt5, Python2 -> Python3, ...?
    This has already been explained several times.

    KDE has a binary compatibility guarantee over the course of a major version (i.e. KDE SC 4.x). Yes, Qt3->Qt4 is a binary-incompatible release, but KDE 3 only support Qt 3, and KDE SC 4 only supports Qt 4. You will never see a KDE SC 4 release that can run on Qt 5 because it wouldn't be binary compatible. Similarly, KDE cannot abandon support for Python 2 bindings over the course of KDE SC 4.x, because again that would not be binary compatible.

    Gstreamer, on the other hand, had no such binary compatibility guarantees. Quite the contrary, it was guaranteed to have binary compatibility breaks, although at the time of planning KDE 4 when and how gstreamer was going to break binary compatibility was unknown. Therefore, even if gstreamer's future was guaranteed, which it wasn't at that point, KDE could not, as a matter of long-standing policy, rely on it directly, since it would break their binary compatibility guarantee.

  6. #146
    Join Date
    Nov 2012
    Posts
    199

    Default

    Quote Originally Posted by TheBlackCat View Post
    This has already been explained several times.

    KDE has a binary compatibility guarantee over the course of a major version (i.e. KDE SC 4.x). Yes, Qt3->Qt4 is a binary-incompatible release, but KDE 3 only support Qt 3, and KDE SC 4 only supports Qt 4. You will never see a KDE SC 4 release that can run on Qt 5 because it wouldn't be binary compatible. Similarly, KDE cannot abandon support for Python 2 bindings over the course of KDE SC 4.x, because again that would not be binary compatible.

    Gstreamer, on the other hand, had no such binary compatibility guarantees. Quite the contrary, it was guaranteed to have binary compatibility breaks, although at the time of planning KDE 4 when and how gstreamer was going to break binary compatibility was unknown. Therefore, even if gstreamer's future was guaranteed, which it wasn't at that point, KDE could not, as a matter of long-standing policy, rely on it directly, since it would break their binary compatibility guarantee.
    As far as I can tell the 0.10 series was stable, but not compatible with the earlier 0.8 series. And the same goes for 1.0. If you have other information I'd be happy to see it though.
    If you don't, then sorry, I still don't understand why gstreamer is different from say the Qt3->Qt4 shift. Older applications can still use the older version of the library, and everyone is happy (?).

  7. #147
    Join Date
    Dec 2010
    Posts
    1,117

    Default

    Quote Originally Posted by kigurai View Post
    I still don't understand why gstreamer is different from say the Qt3->Qt4 shift.
    Yes, it's very evident that you are clueless about that matter and resistant to learn things.

  8. #148
    Join Date
    Nov 2012
    Posts
    199

    Default

    Quote Originally Posted by Awesomeness View Post
    Yes, it's very evident that you are clueless about that matter and resistant to learn things.
    Since I am obviously slow, then perhaps you could share some of your wisdom?

  9. #149
    Join Date
    Feb 2011
    Posts
    1,086

    Default

    Quote Originally Posted by kigurai View Post
    As far as I can tell the 0.10 series was stable, but not compatible with the earlier 0.8 series. And the same goes for 1.0. If you have other information I'd be happy to see it though.
    If you don't, then sorry, I still don't understand why gstreamer is different from say the Qt3->Qt4 shift. Older applications can still use the older version of the library, and everyone is happy (?).
    Several reasons:

    1. As I explained, the schedule of future ABI breaks was unknown when KDE SC 4 was released. There was no guarantee the 0.10 series would still be readily available over the lifetime of KDE SC 4, nor could KDE developers force Gstreamer developers to keep binary compatibility if they decided to break it multiple times over the course of KDE SC 4.

    2. When KDE 4 and phonon were being planned, Gstreamer 0.10 wasn't even out yet.

    3. Qt is a core part of a huge number of applications. Continued packaging of it by distros is guaranteed. A multimedia framework like Gstreamer, on the other hand, is much less important so is much less likely to be maintained for a long time. Add to that the fact that Gstreamer wasn't all that popular or well-supported at the time of the KDE 4.0 release (not to mention several years before when it was being planned), assuming that distros would want to continue packaging an unknown number (at the time) of incompatible versions of gstreamer for an unknown (at the time) amount of time. I hopefully don't need to remind you that unlike Qt 3, Gstreamer 0.8 is no longer being packaged by most (if any) distros. If Gstreamer devs had decided to do a 0.12 early in the KDE SC 4 life cycle then 0.10 would probably not be packaged, either.

    4. Even if Gstreamer 0.10 continued to be packaged, the libraries it relies on are changing rapidly and breaking binary compatibility much more often than Gstreamer itself is. So without continued maintenance, something like Gstreamer rapidly becomes useless. There are already incompatible releases of Gstreamer dependencies that will never work with Gstreamer 0.10.

    5. Gstreamer devs agreed with this approach and promised to write their own Phonon backend. However, around the time KDE 4.0 was released, they changed their minds, said they were completely opposed to Phonon, and never wrote the backend they promised. By then it was way, way, way too late for KDE devs to change their plans.

    So yes, by shear coincidence it turned out that the only binary incompatible release of gstreamer happened close to the release of the next binary incompatible release of KDE, and Gstreamer is popular enough that the 0.10 series will likely still be packaged by that point. But there was no reason to think that was the case 5 years ago when KDE 4.0 was released, not to mention 8 or 9 years ago when it was being planned.
    Last edited by TheBlackCat; 08-03-2013 at 08:47 AM.

  10. #150
    Join Date
    Nov 2012
    Posts
    199

    Default

    Quote Originally Posted by TheBlackCat View Post
    Several reasons:

    1. As I explained, the schedule of future ABI breaks was unknown when KDE SC 4 was released. There was no guarantee the 0.10 series would still be readily available over the lifetime of KDE SC 4, nor could KDE developers force Gstreamer developers to keep binary compatibility if they decided to break it multiple times over the course of KDE SC 4.

    2. When KDE 4 and phonon were being planned, Gstreamer 0.10 wasn't even out yet.

    3. Qt is a core part of a huge number of applications. Continued packaging of it by distros is guaranteed. A multimedia framework like Gstreamer, on the other hand, is much less important so is much less likely to be maintained for a long time. Add to that the fact that Gstreamer wasn't all that popular or well-supported at the time of the KDE 4.0 release (not to mention several years before when it was being planned), assuming that distros would want to continue packaging an unknown number (at the time) of incompatible versions of gstreamer for an unknown (at the time) amount of time. I hopefully don't need to remind you that unlike Qt 3, Gstreamer 0.8 is no longer being packaged by most (if any) distros. If Gstreamer devs had decided to do a 0.12 early in the KDE SC 4 life cycle then 0.10 would probably not be packaged, either.

    4. Even if Gstreamer 0.10 continued to be packaged, the libraries it relies on are changing rapidly and breaking binary compatibility much more often than Gstreamer itself is. So without continued maintenance, something like Gstreamer rapidly becomes useless. There are already incompatible releases of Gstreamer dependencies that will never work with Gstreamer 0.10.

    5. Gstreamer devs agreed with this approach and promised to write their own Phonon backend. However, around the time KDE 4.0 was released, they changed their minds, said they were completely opposed to Phonon, and never wrote the backend they promised. By then it was way, way, way too late for KDE devs to change their plans.

    So yes, by shear coincidence it turned out that the only binary incompatible release of gstreamer happened close to the release of the next binary incompatible release of KDE, and Gstreamer is popular enough that the 0.10 series will likely still be packaged by that point. But there was no reason to think that was the case 5 years ago when KDE 4.0 was released, not to mention 8 or 9 years ago when it was being planned.
    Thank you for the explanation.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •