Announcement

Collapse
No announcement yet.

Qt 4.8 Forked Into New "CopperSpice" C++11 GUI Library

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

  • Qt 4.8 Forked Into New "CopperSpice" C++11 GUI Library

    Phoronix: Qt 4.8 Forked Into New "CopperSpice" C++11 GUI Library

    Making some rounds on the Internet today is CopperSpice, a fork of Qt 4.8 from two years ago that's starting to take shape as a nice C++ GUI library for developers...

    http://www.phoronix.com/scan.php?pag...rk-CopperSpice

  • #2
    *sigh* ..... why would you do that.. Is it really worth it, just to remove moc and use more C++11 features? I feel like a fork should have a lot more crucial reasons for being done.

    Comment


    • #3
      Many of these aspects resonate with me.

      I haven't seen a single change in Qt 5 that is relevant to me, just because almost all of them are somehow related to JavaScript.
      And it seems like they did away with those flashy new modules for toy applications.

      Getting rid of MOC is a huge step towards simplifying Qt bindings to other languages (although using C++11 features is a step backwards?).

      Comment


      • #4
        Originally posted by BlaXpirit View Post
        Getting rid of MOC is a huge step towards simplifying Qt bindings to other languages (although using C++11 features is a step backwards?).
        I agree that removing MOC is fine, but is C++11 really a step backwards? Its Qt, its C++ anyway and C++11 isn't really a 'bleeding edge' update anymore
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          It's a step towards fragmenting the linux desktop even more. Many people already have to keep Qt4 and Qt5 installed at the same time, now if a popular program starts using this, people will have to keep all 3. If you add the numerous versions of GTK to the list, a generic linux desktop can have 6-8 frameworks installed for different GUIs.

          Comment


          • #6
            A step backwards when it comes to binding to other languages, but that's all. A step backwards in general is using autotools *shrug*.

            Actually, many languages as Haskell or Rust, which don't play well with c++ libraries, use qt5 features (namingly QML) to be able to use Qt.

            Comment


            • #7
              Removing moc implies trimming reflection support from Qt, which is a major step back unless c++ has compile-time reflection support.

              Comment


              • #8
                Originally posted by eydee View Post
                It's a step towards fragmenting the linux desktop even more. Many people already have to keep Qt4 and Qt5 installed at the same time, now if a popular program starts using this, people will have to keep all 3. If you add the numerous versions of GTK to the list, a generic linux desktop can have 6-8 frameworks installed for different GUIs.
                It's still hard to get rid of gtk2. But a modern distribution as ArchLinux doesn't use Qt4 anymore, does it?

                Comment


                • #9
                  Originally posted by oleid View Post

                  It's still hard to get rid of gtk2. But a modern distribution as ArchLinux doesn't use Qt4 anymore, does it?
                  pacman -Qii qt4
                  Name : qt4
                  Required By : heimdall qbittorrent qjson vlc wireshark-qt
                  I have programmed a moderate project using Qt5 and it also does not use MOC. You can simply use the new C++11 style `connect` when binding signals and that was the only place that I needed MOC, so that fork of Qt4 seems useless to me. I don't know about the `reflection` thing mentioned above though.
                  Last edited by the303; 09 June 2015, 08:01 PM.

                  Comment


                  • #10
                    Originally posted by Ancurio View Post
                    *sigh* ..... why would you do that.. Is it really worth it, just to remove moc and use more C++11 features? I feel like a fork should have a lot more crucial reasons for being done.
                    We developed CopperSpice for many reasons, one of theme was to remove moc. There were many other limiting issues we found with Qt and strongly believe CopperSpice offers a better approach as a C++ GUI library. One of our goals is to change the contain classes Qt used to leverage the STL.

                    Comment

                    Working...
                    X