Weired bugs need weired solutions to unwire them!!!

This obviously fixes the not-appearing menu on Mac OS X. Well, it's at least obvious if you read the documentation carefully and manage to connect all the tiny little concepts in libHeaven. Damn, I've been thinking every now and then about this issue for about half a year!
Yet, the solution is so plain simple and stupid. So, let's have a look at what the foo was happening here:

We create a MgvPrimaryWindow, which sets its menu bar to a menu bar obtained from the hic file associated. This menu bar is associated with a NULL-parent (actually _all_ menu bars from heaven have that property on Mac OS X). Then it shows itself.

In order to avoid endless loops and wasted cpu cycles, heaven caches requests to fill the real QMenu, QMenuBar and QToolBar through Qt's event loop. Any menu changes are accumulated and run in the next loop. Though, the object itself exists, but initially is totally empty.

He, who know the Qt source by heart, will realise that this empty-ness is not different from the menu bar that you get, if you just call a QMainWindow::menuBar() and then bluntly ignore that bar. So, an all-empty menubar imposes something special, qt internally on Mac OS X.

Now, the qt documentation states, that the _first_ menu bar created with a NULL-parent will become the so called _default_ menu bar. If one doesn't create such a default bar, Qt has its very own one (which actually just contains the "Quit" item on Mac OS X and is empty everywhere else).

So far for the docs. But since an all-empty menu bar can not be distinguished from no menu bar at all, Qt might actually exchange the default menu bar not before it has any content...

Farther down the line, the docs also explain how a window's menu bar is found: The focused widget is checked for a menu bar, if it has one this will be used. If it has no parent, the _default_ bar is used. If it has no menu bar but a parent, the logic goes up the parent hierarchy. This will eventually land at the window-widget and use either that one's or the default.

What the documentation does not say, is: _when_ this logic will be applied. But honestly, it's pretty obvious that it can only be done while the focus changes. So, we realise that at the moment we _show_ the MgvPrimaryWindow, this logic will be executed.

Finally, at the moment we show the MgvPrimaryWindow, it (of course) has no parent and a menu bar that looks like it is empty. Qt has not yet set the default menu bar to our heaven created one. The code to trigger that is still in the queue in the main event loop.

This at least explains all the strange behaviour we were seeing with opening a dialog and closing it again. At the time the dialog is opened, the boot up queue of heaven's internal setup has been run. So, now the default menu bar is _the right one_. And the menu-bar-finding-logic will actually find the right one.

After all, what can we do to prove that and to avoid the issue? Simple: Let's defer the showing of our MgvPrimaryWindow until the method MenuBarPrivate::reemergeGuiElement() has actually been executed...

And pooof. It works :)

cf.: http://qt-project.org/doc/qt-5.0/qtdoc/mac-differences.html

@antis81 can you verify this really is a :rocket: and merge? :8ball: