Ultimate question

[scunz]

When should we stop supporting Qt4? @antis81

Let me try to summarize some points here:

Pro Qt5-Only:

• We get the QFusionStyle, which is what I actually want to base BlueSky upon.
• We can store meta data in the module that is accessible before loading the module (This is a feature that I will need soon. If we're still supporting Qt4, I have to write and read an external xml file with that information)
• We could get rid of all the Qt related CMake magic that we are using.
• We can rely on a stable json API, which we need to integrate Github / Gerrit / Whatever Web APIs.
• We could also move all of the BlueSky config from xml to easier to use json structures.
• We get a way more modern WebKit 1.

Contra Qt5-Only:

• Linux doesn't integrate Qt5 natively (nor does any other OS, but it's a bit painful on KDE, since it integrates Qt4 with everything). Will solve it self some years ahead of now.
• Qt5 is way harder to build on Windows than Qt4 is. Probably will not change.
• Qt5 has a big overhead when it comes to distribution (25MB alone icu) This won't change anytime in the future.
• No support for getting Windows native data types into QPixmap and co. Will be solved with the upcomming Qt5.2.
• Need to create more CMake magic to get the modules.json files to show up in QtCreator.
• We still use some qmake invocation to determine correct Qt5 modules paths. The proposed way of initializing a CMake cache is just too hard IMHO.
• We will probably be forced to switch to Blink or at least WebKit2 (Both are out-of-process things). Actually, I don't want that at all - and I am not really looking forward to that.

[scunz]

@antis81 Any opinion on that? I'm just about to compile Qt5.2 and see what happens :)

[antis81]

@scunz Tried to compile Qt5.2 on OSX 10.6.8 - with no luck so far :(. The GCC version compiles (~3h) but doesn't want to install. The clang version breaks early (<1 min.) with some error on an assembler call. I'll send you the logs. Maybe you have an idea what to do about it ^^.

Other than that, I think switching to the 5.2 version is the right direction and we should do it as soon everything's setup alright.

[scunz]

@antis81 @fibrethil
My general impression of Qt 5.2 is that it is a very unfinished and premature release, actually.

As for Mac OS X 10.6, they actually say that they don't "officially" support it. Hoever, I am at least expecting it to run on Mac OS X 10.6.

First of all, I am disappointed by the fact that -debug-and-release is now only supported on Mac OS X. They suggest to use a release build and provide additional configure options to a) create debugging symbols and b) force the Q_ASSERTs to be compiled in anyway. Well. -force-asserts doesn't compile QML. I digged into the V4 code, just to find that the compile problem was already fixed in stable. So, the first usable version of Qt 5.2 will probably be 5.2.1.

Yet - that's not all...
On my Linux, I had to change some system headers to be able to compile Qt 5.2. But after all, it did not help. Actually, I had to pass compiler definitions to WebKit to be able to compile, finally.

Btw - at the same time, I was unable to compile a debug build of Qt 4.8.5. Again, had to change some really internal things in Qt and gstreamer's system headers...

Qt Creator 3 on Qt 5.2 now runs somewhat smooth (contrary to the QTC3/QT52 compiled by Digia on my Mac at work).

Did not test Windows, yet. But I am not really looking forward to do that, actually :-)

[antis81]

@scunz With your tips via mail I managed to build the Qt 5.2 Version of MGV 👍 ❤️

Everything runs out of box (well, after some headaches on building qt5 itself). One thing I noticed is: The main menu is missing. Maybe HIC is not called correctly?

I use the following line for cmake in QtCreator:
-DCMAKE_BUILD_TYPE=Debug -DQt5=On -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

I installed via Homebrew brew install qt5. They add some missing library dependencies in the formula script. Thus a plain build from sources will fail on OSX 10.6.8!

In addition, I added /usr/local/Cellar/qt5/5.2.0/bin to PATH like you wrote in the mail and Qt4 / Qt5 builds are both running well now. I'm looking forward to when this is not needed anymore 😄.

@claus007 FYI 😄

[scunz]

One thing I noticed is: The main menu is missing. Maybe HIC is not called correctly?

What you are seeing, is actually macgitver/libHeaven#20 So, we know now that it is not only related to Mac OS X 10.8. If 10.6 got the bug, 10.7 will probably, too.

i've just finished the freaking 2,1GB X-Code download for 10.9. The "Smarter but still stupid" Qt5 configure tries to invoke xcodebuild, which on 10.9 just errors out saying that it needs XCode installed in order to work... Well. If i'd speak out what I think about that, I'd probably violate some christian rules...

I did not manage to get Qt 4.8.5 to compile WebKit on Mac OS X 10.9. It still needs all of the patches from macports.

Let's see how the situation with Qt 5.2 is.

[scunz]

I'm looking forward to when this is not needed anymore.

Working on new abstractions right now. Got some ideas just 2 days ago; but all the stuff we're doing in mgv's cmake/*.cmake is giving me headaches... :)

[antis81]

The "Smarter but still stupid" Qt5 configure tries to invoke xcodebuild, which on 10.9 just errors out saying that it needs XCode installed in order to work...

Same here just with 10.6.8 😦 - also installed a full Xcode for that reason.

[scunz]

I want the simplicity of Qt4 back and combined with the new features of Qt5. That would be really: 🚀

[scunz]

so....

Mac OS X 10.9 requires some stuff, but generally works. Qt5.2 did compile (almost) smoothly. It uses C++11 - which is natural, since OSX 10.9 demands XCode 5.0 and with it the latest version of clang.

However, this also means that we have to enable C++11, too and link to stdc++ (I didn't find a way to solve this, but didn't look too hard either). As far as I know, -lstdc++ is not supported by apple before OSX 10.7. So, this probably means the binaries that I can build will never work on Mac OS X 10.6. As the qt-project itself is about to drop support for 10.6, I don't really have a problem with that.

Though, I know that the market share of 10.6 is still roughly at 33%. So, @antis81 since I also know that you're one of the users that don't upgrade their OS: I'd really like to have an understanding about why people don't upgrade to 10.7, 10.8 or even 10.9. Are there technical, philosophical, artistic or monetary reasons behind that? Or is it something I'm currently totally unable to think of? :)

[antis81]

I'd really like to have an understanding about why people don't upgrade to 10.7, 10.8 or even 10.9. Are there technical, philosophical, artistic or monetary reasons behind that? Or is it something I'm currently totally unable to think of? :)

As we are using plain old world stuff made by normal people, there's nothing transcendental to think of here 😄. The reasons are a combination of the four you're stating.

• Technical: I have a well running 13" 2007 plastic MacBook -> only possible upgrade is 10.7.5 (also own an old PPC iMac, but that's another story :).
• Monetary: I'm a pretty lazy updater because I am not willing to spend thousands of euros every two years, just being able to run the latest OS.
• Philosophical: For me, a hardware bought today should last easily 10 years without being forced to upgrade. Supporting old hardware to do new stuff is a pretty cool thing and serves the idea of independent development ^^.
  Artistic: Well ... this is more of a reason for an upgrade :).

Besides that, switching to linux as primary OS is also an option for me.

[antis81]

Btw. just enhanced the qt5 package in homebrew being able to build the docs and without qt tests 😄. Currently brew install qt5 --with-docs is running ...

[antis81]

Let's re-animate this one. I think, this is just the right time to do the switch to C++11. We already made the switch to Qt5.

Advantages:

• Code will be even more readable. 😄
• We can make use of all the cool C++11 features.
• Probably a slight performance gain through compiler optimized code.

Disadvantages:

• Compiling MGV & co. in OSX < 10.7 would become "impossible". MGV itself is still likely to run though. For development on my old 2007 MB, I found a solution by simply developing with Linux now. So to me, this is not a real issue anymore.
• I really don't know about Windows.

@scunz Btw. Digia released QtCreator 3.2.2 yesterday, that addresses the issues with Xcode6. Give it a chance.

[scunz]

As long as you use GCC on Windows, it is more or less supported. According to Blogs / News, Microsoft might release a compiler (the one to follow MSVS 2013), that might support half of C++11...

If you want to support old OS X, you have to do compiler detection and use lots of DEFINE and IFDEF in the code. Same applies if you want to support the Microsoft Compiler. Both is in my opinion a REQUIREMENT still. So, I cannot see how the code might get more readable :)

As for cool features of C++11 - can you name one? Just one! :)

To make any use of the speed improvements that can be achieved by a C++11 compiler vs a C++03 compiler, endless kilobytes of boiler plate code are required. The concepts for which have to be understood really good, to get them right. Also, you should really know all the time, if copy or move assignment is appropriate (which again requires deeper knowledge of the language). Otherwise there will be lots of problems...

[antis81]

...So, I cannot see how the code might get more readable :)

Yeah exactly. But I think it is really not worth it. So why should we stick on old compilers? I know I own one of these by myself (OSX 10.6 again). This is why I looked out for alternatives and found a very good one. Isn't this is just about development and not about the final results. I don't know of any projects compiled with C++11 yet, but aren't they still running on old machines as well? It would be crazy if they are not.

As for cool features of C++11 - can you name one? Just one! :)

Depends on what you define as 🆒 😎. For me, the var initialization is an example for a cool feature. On one hand, this is less to write. Plus, it brings c++ syntax more close to c#/java syntax, which - for me - is a good thing. But, when taking this example together to be compatible with old compilers, you'd have to write:

// the defines are just placeholders. don't know the real names
class A {
public:
  A() 
#ifdef CPP03
  : i(0)
#endif
{}

private:
#ifdef CPP11
  int i = 0;
#else
  int i;
#endif
};

// this makes it muuuuch worse than instead of writing just c++11 code
class A
public:
  A()
  {}

private:
  int i = 0;
};

So to me, it is basically just the decision to JUST DO IT! (copyright infringement completely unintended 😄)

It is definitely easier this way.

[antis81]

And ... forget about the speed improvement thing. It is never a real argument - we should more care about the efficiency of the diff viewer (it really sucks on large diffs with >100 files changed) than this one.