Page MenuHomePhabricator

QmitkRenderWindowMenu disappears or flickers on OS X
Closed, ResolvedPublic

Description

The 3 buttons in the 4 views have a strange behavior. Only on OS X of course. There's no problem when the application boots. All buttons are visible when and where they should be.

When one of the views is set to fullscreen, so by:

  • The normal m_FullScreenButton button on all views
  • "Big 3D", "Axial plane", "Sagittal plane" or "Coronal plane" actions in m_SettingsButton.

we can't see the button anymore. Or they flicker. Or they are always visible. Or a random happy mix.
There seems to be some safe hover zones where the buttons appear.
They appear when I click and drag the mouse the the buttons, so I can release the click and use the buttons.

OS X only. It works perfectly on Windows and Linux.
I tested on OS X 10.11.6 (El Capitan) on an Mac Mini and a Mac Book Pro.

Event Timeline

goyette created this task.Nov 8 2016, 8:05 PM
gaehlert edited subscribers, added: wasserth; removed: gaehlert.Nov 9 2016, 9:32 AM

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.

goyette claimed this task.Nov 24 2016, 6:19 PM
kislinsk triaged this task as Normal priority.Dec 14 2016, 2:28 PM
kislinsk edited projects, added MITK (2016-11), Pull Request; removed MITK.
kislinsk moved this task from Backlog to OS X on the MITK (2016-11) board.Dec 19 2016, 1:41 PM
kislinsk edited projects, added MITK; removed MITK (2016-11).Feb 6 2017, 11:23 AM

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.

kislinsk closed this task as Resolved.Dec 21 2017, 2:36 PM

Most probably resolved by the overall fixing of the MITK rendering on macOS.

goyette added a comment.EditedDec 22 2017, 2:21 PM

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