@Jonas: Is there already a bug report for the black toolbar? I found something:
https://bugreports.qt-project.org/browse/QTBUG-39210

yes it's 18517 and already fixed! Thank you!

As I know that you worked some bug squashing days on this bug, can you please provide some information here what you found out so far so the knowledge is not lost or forgotten in a few weeks?

We attempted to isolate the bug. But no clear issue was found. The combination of Blueberry framework and qt5 leads to the problem (maybe some qt5 related object renamings...). Sorry, but there was no more to get.
I will stay tuned!

I updated the title to better reflect the actual problem.

I suspect a problem in the parent / child relationship of the the view elements and the QMainWindow. There seeme to have been some subtle changes in Qt5 which do not work well with how BlueBerry lays out the Views contents (on MacOS).

After further investigation of this issue, we got a few more insights:

There are several conditions under which this issue occurs:

1. Every view, which is restored after application restart does not react
2. If a view is opened via "show perspective" it does not react

There are also several conditions under which everything seems to work as expected:

1. If you close a non reacting view and open it again via "show view" it reacts
2. If you remove the QmitkRenderWindows from the QmitkStdMultiWidget all views react

Next finding:

If a view does not react, in berryQtGlobalEventFilter the events of the following target objects are filtered:

"ViewFormWindow"
""
""
""
"ViewFormContentFrame"
""
"ViewForm"
""
"ClientComposite"
""
"Page Composite"
""
"Research - MITK Workbench 2015.5.99-1d94c16f (ITK 4.7.1  VTK 6.2.0 Qt 5.4.2 MITK 2015.5.99-1d94c16f) (Not for use in diagnosis or treatment of patients)"
""

In contrast to that, if a view does react, events for these targets are filtered:

"PartPaneControlWindow"
""
"qt_scrollarea_viewport"
""

Narrowed this issue down to the QVTKWidget:

• If you remove the QmitkRenderWindows from the StdMultiWidget, it works

> Having no QVTKWidget-based render window in MITK solves this bug

• Even if we instantiate a QVTKWdiget e.g. in another plugin and set the QVTKWidget's parent to a widget that is part of MITK it doesn't work again

> There must be some weired interacting between the QVTKWidget's and BlueBerry's Qt event processing

In order to get a simplified view on this issue, the BlueBerry example "Qt Selection Service" was used. To reproduce this issue a QmitkRenderWindow was instantiated in the BlueBerry view "ListenerView" in its CreateQtPartControl.

It turned out, that in the case without the QmitkRenderWindow, two top-level windows exist (checked by calling qApp->toplevelWindows). Calling window->objectName revealed "BlueBerryExampleLauncherWindow" and "Qt Selection ServiceWindow"

In the case with the QmitkRenderWindow there is suddenly a third window named "QMenuClass"

After debugging Qt it turned out that if the QmitkRenderWindow is used, almost each widget of the application is handled as a window (entry for almost each widget in QtGuiApplication's windowList).

The BlueBerry Example suddenly had 19 entries in this list, but if the QmitkRenderWindow is commented out there are just 4!

It seems that in the QVTKWidget (from which the QmitkRenderWindow is derived) in the function SetRenderWindow a WindowID is set, which simultaneously calls the QWidget's (from which the QVTKWidget is derived) winId() function. In this function finally the attribute Qt::WA_NativeWindow is set. This attribute is also set for each child which has the effect, that every child-widget is treated as native window. This can be avoided by setting the Qt Application Attribute Qt::AA_DontCreateNativeWidgetSiblings.

This also explains why this bug only appears in certain situations, namely those where the render windows are initialized after the other GUI parts.

Doing this in the mitk::BaseApplication::getQApplication() by adding:

"qCoreApp->setAttribute(Qt::AA_DontCreateNativeWidgetSiblings);"

seems to fix this bug. After a first testing all views / elements seem to react properly.

What still seems to be buggy is BlueBerry's preview where the view will be attached after dragging them to a certain position within the application window.

User fetzer has pushed new remote branch:

bug-18521-mac-osx-qt5

@Jonas: Can you please test the provided fix?

it seems to be working well in MITK. Also the rearrangement of views was no problem in MITK (is this also your observation?). I tested it on osx 10.11 using qt 5.5.1 and osx 10.10 using qt 5.4.2 - both debug debug builds. A big step forward, good work!!

Yes rearrangement did work for me either. Just the preview (the grey area), were the rearranged view will be attached seems to be buggy.

[f95335]: Merge branch 'bug-18521-mac-osx-qt5'

Merged commits:

2016-03-13 22:55:23 Andreas Fetzer [996208]
Added comment

2016-03-13 01:39:23 Andreas Fetzer [80faa2]
Fixed not reacting views on Mac OS X for Qt 5

A detailed description can be found in T18521 at bugs.mitk.org

Cool!!! Thanks!

Good job!

I tried to find a proper Qt bug report for it, and indeed there is this:

https://bugreports.qt.io/browse/QTBUG-28816

Setting this flag on MacOS seems to fix a lot of problems for many people.