I just discovered that if Slicer is launched for the first time (ie after removing the settings directory), the splash screen does not disappear after startup, and covers the popup window prompting to accept that Slicer is not FDA approved. See demo below. Today’s nightly on Mac.
I can confirm this by running:
$ /Volumes/Slicer-4.9.0-2018-02-21-macosx-amd64/Slicer.app/Contents/MacOS/Slicer --disable-settings
A workaround is to hit the enter key to bypass the hidden dialog.
Here is the error log -
Session start time .......: 2018-02-22 20:44:34
Slicer version ...........: 4.9.0-2018-02-21 (revision 26937) macosx-amd64 - installed
Operating system .........: Mac OS X / 10.13.3 / 17D47 - 64-bit
Memory ...................: 65536 MB physical, 0 MB virtual
CPU ......................: GenuineIntel Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz, 12 cores, 24 logical processors
Developer mode enabled ...: no
Prefer executable CLI ....: yes
Additional module paths ..: (none)
Number of registered modules: 136
Popen(%s, cwd=%s, universal_newlines=%s, shell=%s)
Popen(%s, cwd=%s, universal_newlines=%s, shell=%s)
libpng warning: iCCP: known incorrect sRGB profile
Number of instantiated modules: 136
Scripted subject hierarchy plugin registered: Annotations
[6570:80131:0222/204438.066624:ERROR:gl_context_cgl.cc(137)] Error creating context.
[6570:80131:0222/204438.134244:ERROR:gl_context_cgl.cc(137)] Error creating context.
Scripted subject hierarchy plugin registered: SegmentEditor
Scripted subject hierarchy plugin registered: SegmentStatistics
Number of loaded modules: 136
Switch to module: "Welcome"
Uncaught TypeError: channel.execCallbacks[message.id] is not a function
I guess the issue is due to the recent changes caused by extension update checker, which introduced event processing before application startup is completed. I cannot reproduce the problem on Windows, so I cannot verify this, but probably this line is the culprit:
Instead of relying on timer events processed after startup completed, the application’s startupCompleted() signal should be used instead.
There can be many other places where event processing before application startup may cause problems, so probably it would be better to delay the extension update check (gatherExtensionsHistoryInformationOnStartup): it should be started after application startup is completed.
It is also very odd that extension update check is performed at every startup. If extension update check is successfully completed then it should not be performed again within 10-20 hours.
I also found that (under some conditions that are unclear to me) the DICOM Browser window gets covered by the main app window, and “Show DICOM Browser” button does not bring it back. However, I can’t consistently reproduce this. From @lassoan post it sounds like this may be a related issue.
Ran into this nasty problem again today - this time there was a popup (shown below) that required an answer for the application to start, but it was obscured by the splash screen! (I did not start any DICOM listeners knowingly, not sure where this came from)
Once I noticed that popup (it blinks really quickly before splash screen covers it), I then ran Slicer with --no-splash command line argument.
I think it is somewhat unlikely a beginner or even an average user would be able to identify the issue and find this workaround. I would suggest disabling splash screen until related issues are resolved.
The problem is that DICOM module starts some operations before application startup is completed. Since extension update checker now starts event processing before application startup is completed, this can cause various issues.
DICOM module (DICOM.py) must be fixed to not start doing any processing in module init method (this has been always a bad practice). but perform all operations in a method that is called when slicer.app startupCompleted() signal is emitted. DICOM module already has such a method, so just all initialization steps must be moved there.
@fedorov Can your team give it a try to implement a fix?
I think there are various situations where popups requiring user action can be covered by the splash screen, effectively blocking the application, so it does not resolve the underlying problem with the splash screen issue.
I have not been doing anything at that level in Slicer for quite a while, and I have a lot of things going on right now. I can’t take on this task you mentioned at this time.
At least for the DICOM module, it looks like it’s just a matter of moving this code into this method. so that it happens after the application is started.
But if it’s not just the DICOM module that can lead to this issue, then there should be a timer that turns off the splash screen.
There is a timer already. The problem is that the timer event is not processed until the modal popup is closed.
There were a handful of other modules that used one-shot timers to perform tasks at application startup but they have been all fixed. DICOM module was missed because it did not even use timer but directly performed actions in the module class constructor, which must never happen. We should document somewhere that this must be avoided.
Note: this is a mac-specific bug. On windows and linux the popups appear in front of the splash screen.
I’ve seen a few similar weird issues with modal windows getting stuck behind the main one after startup, and making the main unresponsive. Also on Mac. Perhaps related: slice pop-up widgets floating all alone when using command-tab to select a Slicer instance with the main on a different desktop (“Space”?). I had been blaming a window controller extension I use called Spectacle, but seems like there could be some bug(s) in Qt.
Unfortunately rearranging that code so that the dialog is triggered by startupComplete doesn’t work - the splash screen is still up when the signal is emitted.
Maybe we should hide the splash window explicitly before emitting the application startup signal?
Yes, it seems the core issue is that the finish method of the splash screen waits until the main window is displayed before going away.
I haven’t had a chance to make a fresh mac build to test it, but closing the splash screen directly should work.
Note that this is a mac Qt5 issue only. I’ve tried various changes to the code but haven’t found a workable solution yet.
You mean you cannot force closing of the splash screen (or the splash screen is closed but the popup still does not appear)? Do you still have problems if you create the modal popup after splash screen is closed?
The problem is that the splash screen is closed when the main window appears but the startupComplete signal is emitted before that has happened. I’m committing a fix now that closes the splashscreen before showing the main window, and this resolves the issue.
Fix committed in r27172.
1 Like
Thank you for working on this Steve! I hope this will resolve the issue.