Results 1 to 8 of 8

Thread: With Qt 5 Being Talked About, So Is KDE 5

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    13,399

    Default With Qt 5 Being Talked About, So Is KDE 5

    Phoronix: With Qt 5 Being Talked About, So Is KDE 5

    Yesterday I delivered the live news about Nokia's plans for Qt 5 with its new features and a road-map to deliver this new tool-kit in the 2012 calendar year. With Qt 5 now being talked about, so is KDE 5...

    http://www.phoronix.com/vr.php?view=OTQyOQ

  2. #2
    Join Date
    Jul 2009
    Location
    Torrington, Ct. USA
    Posts
    150

    Default

    In b4 the GNOME/KDE flame war.

    Just so I understand correctly, they're essentially thinking about going with KDE 5.0.x rather than KDE 4.8.x or 4.9.x in an effort to stay consistent with the Qt version numbers even though the changes in KDE will probably be minor enough as to not really warrant a major version number change?

  3. #3
    Join Date
    Jun 2008
    Posts
    158

    Default

    Quote Originally Posted by sirdilznik View Post
    In b4 the GNOME/KDE flame war.

    Just so I understand correctly, they're essentially thinking about going with KDE 5.0.x rather than KDE 4.8.x or 4.9.x in an effort to stay consistent with the Qt version numbers even though the changes in KDE will probably be minor enough as to not really warrant a major version number change?
    No, if Qt breaks API, then KDE should break API too, because it's a superset of Qt. However KDE is not forced to switch to Qt5 until Qt4 is supported so this time they have "plenty of time to switch to a new version of Qt that is not so different from the previous".
    So when they break API (even if it's not a major breakage) they change major number. A minor change happened also between KDE 2 and 3, there's nothing bad.

    However KDE 4.8 will for sure land, KDE 4.7 is planned for July 2011, 4.8 for January 2012; Qt 5 will not be ready then. If they want they can keep going with Qt4 until they're comfortable with the switch.

    The numbering is different to GNOME which tends to deprecate and then break API even among the same major version.

  4. #4
    Join Date
    Jun 2008
    Posts
    158

    Default

    From KDE core devel:
    > > - Can we realistically pull off a minimal migration in time for the
    > > planned
    > > release date?
    >
    > i think it is possible, but we don't need to roll out KDE Platform 5 when Qt
    > 5 is released, either. in fact, it might be wise to lag by a release to
    > allow Qt 5 to settle in a bit and so we aren't chasing Qt's tail during the
    > Qt5 development cycle.

    Suggestion: target release in Jan 2013, which is also 5 years after the
    release of 4.0.

    Provided Qt 5.0 does release mid-2012.
    http://lists.kde.org/?l=kde-core-dev...1650214043&w=2

    So:
    • KDE 4.8 - January 2012
    • KDE 4.9 - July 2012
    • KDE 4.10 = 5.0? - January 2013

  5. #5
    Join Date
    Feb 2011
    Posts
    943

    Default

    Quote Originally Posted by panda84 View Post
    No, if Qt breaks API, then KDE should break API too, because it's a superset of Qt. However KDE is not forced to switch to Qt5 until Qt4 is supported so this time they have "plenty of time to switch to a new version of Qt that is not so different from the previous".
    So when they break API (even if it's not a major breakage) they change major number. A minor change happened also between KDE 2 and 3, there's nothing bad.
    Technically, it isn't breaking API, it is breaking ABI. Programs compiled against an earlier version of KDE 4.x or Qt 4.x should work with later versions. With a binary compatibility break, they may have to be recompiled. API changes happen fairly often in KDE, and do not necessarily imply a break in binary compatibility. Only binary-incompatible changes are forbidden in point releases.

    But if I am reading Aaron's post correctly the Qt 5.x changes will mean that KDE 4.x applications compiled using Qt 4.x will not be binary compatible with KDE 4.x applications compiled using Qt 5.x, even if KDE is otherwise unchanged, so binary compatibility will have to be broken no matter what KDE does. KDE developers may use this opportunity to clean out some cruft and some issues in their API that they can't do without breaking binary compatibility.

  6. #6
    Join Date
    Jan 2009
    Posts
    80

    Default

    Quote Originally Posted by TheBlackCat View Post
    Technically, it isn't breaking API, it is breaking ABI. Programs compiled against an earlier version of KDE 4.x or Qt 4.x should work with later versions. With a binary compatibility break, they may have to be recompiled. API changes happen fairly often in KDE, and do not necessarily imply a break in binary compatibility. Only binary-incompatible changes are forbidden in point releases.
    It IS breaking the API, albeit only a little. From the Qt 5 plans post:

    To be explicit here we believe we can keep source compatibility for the majority of cases, but we believe that breaking binary compatibility is needed.
    I'm thinking "for the majority of cases" implies there is a minority for which source compatibility WILL break.

  7. #7
    Join Date
    Feb 2011
    Posts
    943

    Default

    Quote Originally Posted by loonyphoenix View Post
    It IS breaking the API, albeit only a little.
    Perhaps I wasn't clear. Yes, there will be API changes. But API changes are not the reason for a change from KDE SC 4 to KDE SC 5. In point releases (KDE SC x.x) they are allowed to change the API as long as the ABI does not change. Changing a major release, though (KDE SC x) implies a break in binary compatibility.

    This also implies some changes in the API, usually changes that are not possible while maintaining binary compatibility. However, under KDE SC version number rules the important issue is binary compatibility, not API compatibility.

Tags for this Thread

Posting Permissions

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