Announcement

Collapse
No announcement yet.

Qt 5.9 To Be An LTS Release, Qt 6 Planning On Radar

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

  • #21
    Originally posted by bobwya View Post
    Oh great - so Plasma 5 is almost stable and the Qt folks are already talking about Qt 6.
    The problems with early Plasma 5 were because of the decision to modularize and frequently rewrite large chunks of code on the KDE side, not so much because of the Qt update.
    Taking KDE4 and porting it to Qt5 without any other modifications would have been possible and would have resulted in a usable KDE5 very quickly.
    The KDE guys decided to do a major cleanup instead (which is, for the most part, good) - that doesn't have to be done again for Qt 6.

    I expect Plasma 5 -> Plasma 6 to be more like KDE 2 -> KDE 3 -- not all that problematic.

    I do hope that the time between the release of Qt 6 and the release of Plasma 6.0 will be a lot shorter than the time between Qt 5 and Plasma 5.0 -- the long time KDE was on 4.x while 5.x was available already is what makes Plasma 5 seem a little short-lived.

    Comment


    • #22
      Originally posted by hussam View Post
      I can almost hear KDE users yelling "not again ".
      I totally understand you. Only in the last couple of years or so the linux desktop in general gave some predictability to users. Users. Not coders. It is impossible not to rant....

      Originally posted by berolinux View Post

      Umm, no thanks. Try actually writing an identical application in Qt and GTK, and then see which took you longer, which is more readable, and which is more superfluous lines of code - and you'll see why Qt is a far better choice.

      GTK's API is horrible (in parts because it has to invent its own object model in a language not really meant for object oriented programming). To the GTK guys' credits, they have realized their API is impossible to work with, so they're coming up with new "solutions" all the time, then deciding those don't work either, throwing them away, and starting over. Use Gtkmm! No, use Inti (does anyone even remember that one?)! Actually, no, use PyGTK, it solves all the world's problems! Then again, no, we've just decided Vala is the best way to go. Except now we aren't maintaining that anymore, so go with Mono!

      Qt on the other hand started out with a nice API and keeps (mostly) improving on it.
      Although this discussion has lots of grounds, it completely misses the point. What should we expect of "the linux desktop" wider adoption if the biggest selling point is that _the code is leaner and easier to read_? What. The linux desktop is coded for coders, so that the user is welcome to take his/her part on this big sandbox forever?

      This "please help us get desktop calculator give us a 5 when asked for 2+3 instead of giving us some 30 segfaults" argument will not help and the linux desktop will remain just a promise for another 15 years. Thank you developers but this way users will leave. And all you'll have is your desktop bug-hunting-fest forever, just for you.

      Users expect stability. Boredom. Predictability. It's not hard. It's mainly a matter of decision-making and Q/A philosophy. Users do not care if the code is complex or beautiful, all users care is that the code works as intended. Period. I wonder where it all got lost. We are in 2017 and some things are unacceptable. Like fighting a misbehaving file manager. Really. If the linux kernel folks behaved like that we would've all be playing whatever other kernel today. Or still fighting 3 hours a day to get our wireless network cards working. Just like 2003.

      Desktop developers have forgotten that the desktop is _not_ supposed to be theirs exclusively. Taking me as an example, I write scientific code and the last thing I ever want is to get through 3-4 annoying usability/stability regressions a day, for the sake of the code, because someone decided that it doesn't matter to break stability if we should all work hard to get buggy code to do whatever we've already had 3 years ago working nicely.

      Comment


      • #23
        Originally posted by hussam View Post
        I can almost hear KDE users yelling "not again ".
        Well, just for you
        "Argh! Not again!" (for my main box)
        "Argh! Not again!!" (for my laptop, two exclamation marks cause this thing takes longer with compiling, or need to take the SSD to the bigger box for chroot compiling)
        "Argh! Not again!!!" (for the KDE components I love to use among XFCE on my little thin client)
        "Argh! Not again!!" (for the next one)
        "Argh! Not again... oh, wait, there's even still KDE 4 on it, OMG" (for the HTPC)

        I just hope they'll use the opportunity to fix things and make the running code slender and nice. And unless KDE will have a huge major overhaul that tumbles everything over a pure Qt update/upgrade might be okay. (I understand that they had to do a lot of this for "KDE" 5 but unlike the KDE 3 -> KDE 4 transition it was upstream that forced a half-baked "KDE" 5 upon us and had already abandoned KDE 4 for good.)

        Still, just in case a late LTS for Qt 5.xx would be nice in case Qt 6 doesn't work out as expected in the beginning. (And usually things are bumpy on an X.0 release nowadays.)
        Stop TCPA, stupid software patents and corrupt politicians!

        Comment


        • #24
          Originally posted by berolinux View Post

          Umm, no thanks. Try actually writing an identical application in Qt and GTK, and then see which took you longer, which is more readable, and which is more superfluous lines of code - and you'll see why Qt is a far better choice.

          GTK's API is horrible (in parts because it has to invent its own object model in a language not really meant for object oriented programming). To the GTK guys' credits, they have realized their API is impossible to work with, so they're coming up with new "solutions" all the time, then deciding those don't work either, throwing them away, and starting over. Use Gtkmm! No, use Inti (does anyone even remember that one?)! Actually, no, use PyGTK, it solves all the world's problems! Then again, no, we've just decided Vala is the best way to go. Except now we aren't maintaining that anymore, so go with Mono!

          Qt on the other hand started out with a nice API and keeps (mostly) improving on it.
          You are talking to a gnome troll so you are wasting your time talking sense

          Comment


          • #25
            I've been through this since I maintain KStars. So the switch from Qt3 to Qt4 was quite substantial and took a LOT of time and effort. But Qt4 to Qt5 did not introduce significant changes compared to the Qt3 to Qt4 switch, and I suspect the Qt5 to Qt6 will be even less of a headache.

            Comment


            • #26
              shame they didn't pick 5.10, would have been nice to have the vulkan stuff picked up by an LTS release, and then be part of the 2018 distro LTS releases for the following three/five years (Ubuntu 18.04 / SLES 15 / etc).
              Last edited by Jedibeeftrix; 10 May 2017, 06:22 AM.

              Comment


              • #27
                Originally posted by Jedibeeftrix View Post
                shame they didn't pick 5.10, would have been nice to have the vulkan stuff picked up by an LTS release, and then be part of the 2018 distro LTS releases for the following three/five years (Ubuntu 18.04 / SLES 15 / etc).
                If we ignore wishful thinking for a moment, the first release with support for something, isn't a good candidate for LTS.
                Look at RedHat: features are introduced in Fedora, left to bake for a while and only after that they get into RHEL.

                Comment


                • #28
                  Originally posted by Griffin View Post
                  Bug77. SLES will not include KDE. Unaudited code like KDE is not allowed in Enterprise systems.
                  the sles comment was mine.
                  i don't disagree with anything you say, but the reason why i mentioned it is because it affects the lifecycle of Suse Leap.
                  Leap 42.x is sticking with 5.6LTS, Leap 15 will likely stick with 5.9LTS, which means a whole three year cycle of Leap up to late 2021 will be absent Vulkan support on the KDE desktop.

                  Which is a shame. Same applies to Ubuntu 18.04.

                  Comment


                  • #29
                    Originally posted by Caveira View Post
                    Although this discussion has lots of grounds, it completely misses the point. What should we expect of "the linux desktop" wider adoption if the biggest selling point is that _the code is leaner and easier to read_?
                    Of course you're right about that - it can't be the selling point to a larger audience. But code being leaner and easier to read is a prerequisite to getting anything else done.
                    What good is an "almost there" desktop if the code is so messed up that nobody can figure out how to get the remaining 1% done?

                    Of course my neighbors or anyone won't notice how nice the code of their desktop is. They will notice, however, how quickly bugs get fixed and new features get added (and neither of those is going to go too well on a broken code base.

                    KDE did its job on fixing the code base (both by picking a sane toolkit and language and by modularizing) and can now build on top of it. LXQt and Lumina are also showing some promise there. Now they're in a position to do the things that matter to non-technical users while some others still have to figure out what language/wrapper library/codegenerator-of-the-day to use for any new widget they want to add.

                    Comment


                    • #30
                      Originally posted by Griffin View Post
                      It is fact not troll. Think about it, Ubuntu will default to Wayland before KDE. Qt is not the silver bullet to Linux desktop. The latest Qt release even made Wayland support WORSE!
                      The fact is Gnome is not usable for many people and I'm not just talking about usability problems. It suffers from huge memory leaks which are present since years. I'd like to have some alternative to KDE, but I won't use something as unstable as Gnome. Such flaws are unacceptable. The very first full of memory leaks 'enterprise desktop' (tm).





                      Few (at this moment 11) hours after starting gnome-shell, it uses about 67% of 2GB system memory (the ram), and maybe few hundred MB-s of the swap, too. I know it is not Ubuntu only, it appears in Fedora, Arch and more. lsb_release -rd Description: Ubuntu 11.10 Release: 11.10 apt-cache policy gnome-shell gnome-shell: Telepítve: 3.2.0-0ubuntu1 Jelölt: 3.2.0-0ubuntu1 Verziótáblázat: *** 3.2.0-0ubuntu1 0 500 http://archive.ubuntu.com/ubuntu/ oneiric/universe i386 Packages ...


                      Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.




                      I noticed that Gnome Shell's (3.8) System Monitor-reported memory consumption remained more or less constant in RHEL7/CentOS7. My experience elsewhere had been different. So, I did clean, new, installs of F20 and, then, Ubuntu Gnome, both with Gnome 3.10. In both, the Shell's memory allocation grew steadly and was only reduced by a Shell restart. E.g., opening a window increased the allocation in the range of 0.5-3 megs. The allocation shown in System Monitor did not decrease when it was


                      Comment

                      Working...
                      X