I tried to fix this problem myself in the last days. It's really strange!
The normal behavior is

QmitkRenderWindow::mouseMoveEvent()
  QmitkRenderWindow::AdjustRenderWindowMenuVisibility()
    QmitkRenderWindowMenu::ShowMenu()
      QmitkRenderWindowMenu::DeferredShowMenu()

Once the bug starts, mouseMoveEvent() is no longer called.
I was wondering why. Either:

• there's an invisible widget in front of the QmitkRenderWindow, so I'm not hovering on it for real. I added a QTimer that tells me on which QObject I'm hovering. It's always the right object pointer and the right objec type. This seems fine.
• something else is filtering the events, so I'm not receiving them. I added my own event filter in QmitkRenderWindow (with installEventFilter) and made sure setMouseTracking is set to true. It works perfectly before the bug. After, it's never called. Knowing this, of course mouseMoveEvent won't be called. The problem is that I can't find why there's no more event. Afaik, nothing is deactivating the filter or the mouse tracking.
• something else I'm missing :( Can't say I know much about OS X.

I found what's causing the problem: the QSplitter.
I did a quick test, commenting some of the splitter code, and it was fine.
I'll try to compile master on OS X to see if it's still a problem. I'll try pushing a patch in the next days if it is.

In fact, the QSplitter are also broken on Windows (and probably on Linux) in 2016.03; it's just harder to see.

1. Make on the the view fullscreen.
2. Find one of the insivible splitter on the top or on the left by moving your mouse in the gray area.
3. Move it. A part of the view will be painted white.

I can't reproduce this problem on master though.

PR https://github.com/MITK/MITK/pull/168

It's hard to understand what you actually did to fix the issue as you touched large portions of the code. It also seems like you changed the public interface? Please describe the bug precisely and why the QSplitter is causing the trouble and what's needed to fix the issue. Also, please simplify your commit to the bare minimum necessary to fix the issue, as otherwise it is too confusing to review, thank you. :-)

Yes, I changed the public interface. I understand that you don't want to change it because some people might be using it, but all changes are related to the RenderWindowMenu. I doubt anyone outside of MITK is using this class.

As for your other requests, I can't say much right now because I don't remember the reasons of my coding decisions 3 months after. I'll look into it when I can.

The thing is, if you change public interface, you must go through the deprecation process. And you don't want to do this. 😄 Especially if it is simply a cosmetic change. Thanks for looking into it again.

Haha, ok, you're right, I don't want to do that. I don't know much about the deprecation process, so here's one question. Lets say my code is ok, the bug is fixed, but I deleted one public method somewhere because it made no sense anymore and it's incompatible with what I did. Are you telling me I must keep the old implementation along my new implementation for the next version(s)? The old implementation is buggy; it would make no sense to keep it.

Well it depends on the details but it is possible that if a public method doesn't make no sense anymore, a strategy could be to mark that method as deprecated in the class declaration and making a no-op out of it in the class definition. The more interesting question is if code from other clients would still work as they expect or if they would need to follow a migration guide.

It took me a while but I tested a little more and:

• Forget my PR, it's not good enough. It was a wonderful fix for OS X (the menus are unusable without my fix) but it doesn't fix the next point
• There are visual glitches on Windows too. (Probably linux too), let me explain.

Here are 3 images. I simply colored the QSplitter in red, the widgetContainer in blue and the parent (QmitkStdMultiWidgetEditor) in green.
For example, m_MainSplit->setStyleSheet("background-color:red;");

http://i.imgur.com/ebOzLEW.png
We can see here that everything is as it should. We only see the red of the QSplitters.

http://i.imgur.com/sU6WYfs.png
I clicked on Fullsreen axial. We suddenly see the widgetContainer (blue) and the QSplitters (red). Yes, you can move the QSplitters but it does nothing. Also, there's now a little less space for the 4views, you can see it if you open both images.

http://i.imgur.com/Y08KLvj.png
I clicked on the 4views button. Now this is strange. Some QSplitters are now empty and glued on the top. I'm not sure if there's more and more if we repeat the process. Yes, you can move them but it does nothing. Also, eveyrhing turns green (so, children of QmitkStdMultiWidgetEditor?)

That's about it. There's no need to concentrate of the OS X bug. I'm pretty sure it will disappear when this bug is fixed. The bad news is, I haven't put any time on it so I don't know how to fix it. I just wanted to help the later-me or anyone who wants to fix this.

Finally, a new, improved and shinny PR: https://github.com/MITK/MITK/pull/196

Tested on MITK2016.11 on Windows, Linux and OS X. Tested on master only on Windows.

I pushed 2 new commits because I received a bug report from one of my user who told me he sometimes had strange result in fullscreen. Since then, no problem on any OS so I think it's safe to look at this PR.

Cool. The menus were impossible to use on OS X. However, I suggest that you reopen this issue. I tested master to check if the other problem that was explained in my 3-05-2017 post was solved. It affects all OSes. From my tests, it's still a problem. It might be considered minor but:

• it's still a bug
• I already posted a solution 4 months ago, it might be useful to use it

T23990: Changing render window layout mess up Qt layout