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

[phoronix]

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

[Ancurio]

*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.

[BlaXpirit]

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?).

[Ericg]

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

[eydee]

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.

[oleid]

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.

[zxy_thf]

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

[oleid]

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?

[the303]

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.

[cs-barbara]

*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.