Announcement

Collapse
No announcement yet.

Qt 6.0 Might Be Coming After Qt 5.14, Could Depend Upon C++17

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Qt 6.0 Might Be Coming After Qt 5.14, Could Depend Upon C++17

    Phoronix: Qt 6.0 Might Be Coming After Qt 5.14, Could Depend Upon C++17

    Since last year there has been more talk and early planning around the eventual Qt 6.0 milestone. It's looking now like Qt 6.0 might happen after Qt 5.14, or likely in 2020...

    http://www.phoronix.com/scan.php?pag...-After-Qt-5.14

  • caligula
    replied
    Originally posted by Calinou View Post

    Out of curiosity, which applications are those? I don't think I'm currently using any Qt 4 applications, although that was the case for me back in 2015-2016.
    I made some upgrades while investigating this. My keepass manager was using qt4, but I switced to keepassxc now. I had few small Python program depend on kde / qt4 libs. x2goclient was depending on qt4. I had somehow compiled few programs with qt4 even though they supported qt5 (e.g. LyX).

    Leave a comment:


  • carewolf
    replied
    Originally posted by carewolf View Post

    The example in that blog was using simple things, Qt always strives to make the 90% simple and the rest possible. One big problem with the Qt3 to Qt4 upgrade was the redesign of model-control-view, where it was heavily integrated in monolithic classes in Qt 3, but was split apart in more flexible classes in Qt 4. This splitting apart meant that applictations using the model-view Qt3 classes had to do some refactoring. Other classes went into Qt3Support like containers with auto-delete of containted pointers, which you had to port away from if you wanted to avoid libqt3support, or at the latest when upgrading to qt 5. For most applications this was not a problem, but for a few it was either tough, or just non-trivial in semi-dead project, which made it tough for the Qt project as some Qt-using applications lacked for a long time.

    Btw. For KDE4 specfically. The biggest problem was not the changes in Qt. The biggest problem was that the build system was changed at the same time as Qt, which meant that many modules needed both changes to combile with new Qt, and have a new build system written, and fixing just one wouldn't build (couldn't upgrade to Qt4 because there was no build system, writing the build system was hard because it wouldn't compile anyway), making development blind and untestable. The lesson was that you shouldn't upgrade two key things at once. Which of course KDE then did again with KDE5
    Last edited by carewolf; 06-15-2018, 05:53 AM.

    Leave a comment:


  • carewolf
    replied
    Originally posted by Vistaus View Post

    But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/
    The example in that blog was using simple things, Qt always strives to make the 90% simple and the rest possible. One big problem with the Qt3 to Qt4 upgrade was the redesign of model-control-view, where it was heavily integrated in monolithic classes in Qt 3, but was split apart in more flexible classes in Qt 4. This splitting apart meant that applictations using the model-view Qt3 classes had to do some refactoring. Other classes went into Qt3Support like containers with auto-delete of containted pointers, which you had to port away from if you wanted to avoid libqt3support, or at the latest when upgrading to qt 5. For most applications this was not a problem, but for a few it was either tough, or just non-trivial in semi-dead project, which made it tough for the Qt project as some Qt-using applications lacked for a long time.

    Leave a comment:


  • Luke_Wolf
    replied
    Originally posted by Vistaus View Post
    But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/
    It's because when they say "Qt 3 -> Qt 4" was tough what they really mean is Qt 3 -> Qt 4 + KDElibs3 -> KDElibs4 + Refactoring and General Rearchitecting + that whole shift to the Plasma Architecture... in a massive codebase. Which means the whole process was fairly involved and therefore "tough"

    Same goes for Qt4 -> Qt 5. because KDE decided it was time to decouple the project and replace KDELib with KDE Frameworks and upstream a lot of it into Qt, among other things

    Qt5 -> Qt6 shouldn't be particularly disruptive. There's no flashy new tech in Qt like there was with the Qt 4-> Qt 5 transition with Qt Quick, and the KDE side should be fairly stable unless there's news I've been missing.

    Leave a comment:


  • cochise
    replied
    Originally posted by ssokolow View Post

    I'm still running TDE's Qt 3 version of BasKet Note Pads because, when I tried to load my data into the KDE 4 version, it froze up.
    Try the 2.49a version with Qt 5 and Frameworks 5.

    I don't have any Qt 4 program, but many programs still using deprecated KDE 4 classes (ported to Qt 5) from kdelibs4support.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by carewolf View Post
    Particular Qt3->Qt4 was tough.
    But everyone keeps touting that Qt has a very easy upgrade path, so how can it be "tough"? And aside from the community, even the Qt team themselves tout that it's very easy to upgrade: https://blog.qt.io/blog/2018/05/24/porting-from-qt-1-0/

    Leave a comment:


  • Vistaus
    replied
    Originally posted by caligula View Post
    Apparently we will need three versions of Qt simultaneously. I still have apps that depend on Qt 4.
    Meanwhile, people are complaining about the "GTK 3 mess" while Qt apps still aren't even fully ported to Qt 5...

    Leave a comment:


  • Vistaus
    replied
    Originally posted by TheBlackCat View Post
    Source compatible means a program written to be compiled on X [...]
    But we're trying to get rid of X. Sorry, I couldn't help myself :P

    Leave a comment:


  • t.s.
    replied
    Originally posted by carewolf View Post

    Yeah, the last one I had was clementine, and it has had a qt5 version for years, and last time I used the qt4 version was a few years back.

    Anyway. That whole situation with getting projects to upgrade is why source compatibility is so strongly pursued by Qt, without too may projects do not upgrade. Particular Qt3->Qt4 was tough.
    My Arch still have quite plenty qt4 related packages: attica-qt4, libdbusmenu-qt4 phonon-qt4, polkit-qt4, qca-qt4, kdelibs, kdebase-runtime, breeze-qt4, oxygen-qt4, etc.. Maybe I'll try to remove those package and see if it will break my plasma desktop or not.

    Leave a comment:

Working...
X