# DICOM browser is stuck behind main window after DICOM import

**URL:** <https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826>\
**Category:** Support\
**Tags:** dicombrowser, dicom\
**Created:** [November 20, 2018, 9:49pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826 "2018-11-20T21:49:06Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![mag](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@mag](https://discourse.slicer.org/u/mag)\
**Post date:** [November 20, 2018, 9:49pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/1 "2018-11-20T21:49:06Z")

</div>

I think the DICOM browser in the new stable release for Mac has a very little issue. When I import a DICOM, after it finishes it closes automatically (before it would stay open and let me load the series). After the browser closes, the DICOM module keeps working but not the browser button: if I click on it to reopen the browser, nothing happens. However if I go to another module and then come back to DICOM module, the browser button works alright. Is anybody having the same funny behaviour? The nightly built from the 01/11/18 also does the same thing but the previous stable release doesn’t.

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 20, 2018, 10:21pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/2 "2018-11-20T22:21:21Z")

</div>

It does not close, it is just “hiding” behind the main window. Try to move around your Slicer main window, then you should be able to find the DICOM Browser window. It is quite annoying and counter-intuitive.

---

<div class="post-metadata">

**Author:** ![mag](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@mag](https://discourse.slicer.org/u/mag)\
**Post date:** [November 20, 2018, 10:33pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/3 "2018-11-20T22:33:37Z")

</div>

Oh wow that’s funny, I would never have noticed, cause it doesn’t even show in the dock 😅  
Indeed, it’s very annoying…I think I’ll just revert to the old version. Thank you!

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 20, 2018, 10:34pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/4 "2018-11-20T22:34:57Z")

</div>

> [@mag](#):
>
> I think I’ll just revert to the old version.

Wow! I would never think it is that bad for a user … I don’t know how difficult/feasible it would be to fix this. I thought I raised this issue a while ago, but I cannot find the thread.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 20, 2018, 10:39pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/5 "2018-11-20T22:39:52Z")

</div>

If you only have a single monitor then it is better to automatically hide the DICOM browser window after loading by unchecking “Browser persistent” checkbox. Do you mean that the DICOM browser window is not hidden after loading even if “Browser persistent” is unchecked?

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [November 20, 2018, 10:41pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/6 "2018-11-20T22:41:50Z")

</div>

@lassoan on mac the DICOM Browser window is hiding behind the main application window _after the Import_ operation. This is not about hiding it after load.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [November 20, 2018, 11:20pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/7 "2018-11-20T23:20:38Z")

</div>

Yes, I saw this today with Sonia too - it seems to be an issue with Qt5 on mac.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 20, 2018, 11:21pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/8 "2018-11-20T23:21:38Z")

</div>

I see, thanks for the clarification. I cannot fix this, as I cannot reproduce this on Windows, but probably the DICOM browser window just need to raised to the top by calling `widget.raise_()` or something similar.

---

<div class="post-metadata">

**Author:** ![jdx-john](https://avatars.discourse-cdn.com/v4/letter/j/a6a055/32.png) [@jdx-john](https://discourse.slicer.org/u/jdx-john)\
**Post date:** [November 21, 2018, 1:55pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/9 "2018-11-21T13:55:59Z")

</div>

I think this sounds the same issue we’ve seen in our Slicer application @lassoan. If so, it was a problem since a year ago for us which pre-dates Qt5?

@Sunderlandkyl you looked on our side, did you raise a bug or anything?

---

<div class="post-metadata">

**Author:** ![mag](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@mag](https://discourse.slicer.org/u/mag)\
**Post date:** [November 21, 2018, 6:09pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/10 "2018-11-21T18:09:23Z")

</div>

It’s not bad but the old version has everything I need and does not have this bug so I’d rather use that until I’ve finished importing all my dataset 🙂

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [November 21, 2018, 7:24pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/11 "2018-11-21T19:24:16Z")

</div>

It’s funny I cannot reproduce this with my local build or Slicer 4.10 on my desktop or 4.10 on my laptop mac (running 10.13.6 High Sierra and 10.14 Mojave respectively).

In non-persistent mode the DICOM browser closes after loading. In persistent mode it stays on top of the slicer app window.

---

<div class="post-metadata">

**Author:** ![mag](https://avatars.discourse-cdn.com/v4/letter/m/58f4c7/32.png) [@mag](https://discourse.slicer.org/u/mag)\
**Post date:** [November 21, 2018, 8:12pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/12 "2018-11-21T20:12:09Z")

</div>

I’ve just tried again on my work desktop (running 10.13.6 High Sierra) and after importing a new DICOM series the browser hides behind the main window independently on whether persistent mode is selected or not. This happens with Slicer 4.11.0-2018-11-0, Slicer 4.10.0 and Slicer 4.9.0-2018-10-16 but not in Slicer 4.8.1-stable. I don’t know about the latest nightly because I would need admin approval to install it and can not do it right now.

But that’s ok, when I raised the issue I thought the browser button was stuck, I hadn’t realized the browser was just hidden (sorry for that, I could have looked better). That’s not a big issue, I’ll just do all the imports at once or use the old version to avoid playing hide and seek with the DICOM browser.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [November 21, 2018, 11:09pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/13 "2018-11-21T23:09:43Z")

</div>

I see - yes, this happens when the directory import is complete, not on loading the data (sorry, read the issue wrong). It’s probably because the confirm dialog is parented to the main app window so main window is raised when the dialog is closed. Probably the directory selector and the confirm dialog should be parented to the dicom browser window instead.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 23, 2018, 4:01am UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/14 "2018-11-23T04:01:08Z")

</div>

We’ve been testing this @Sunderlandkyl and found that the problem may be the use of modal popups. These popups are quite annoying anyway, so we are thinking about replacing them by widgets in the DICOM browser window.

We could move the progress bar from a popup to the bottom of the DICOM browser window and disable the rest of the window. We could probably even run indexing in a background thread (SQLite allows concurrent database access from multiple threads) and so indexing would not block the GUI. The result popup could be replaced by a textbox/button showing summary and by clicking on it we could show more detailed information.

---

<div class="post-metadata">

**Author:** ![Sunderlandkyl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sunderlandkyl/32/79987_2.png) [@Sunderlandkyl](https://discourse.slicer.org/u/Sunderlandkyl)\
**Post date:** [November 23, 2018, 5:34am UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/15 "2018-11-23T05:34:51Z")

</div>

Here is a quick mockup of the proposed layout:

 ![DicomProgressBarv01](https://us1.discourse-cdn.com/flex002/uploads/slicer/original/3X/b/0/b06d1a8fae74929b1b31d37518e66be48d9dd878.png)

The label beside the progress bar would provide a broad indication of the current operation/status (import in progress, import completed, etc.). Clicking the details button would provide the user with additional info (Number of patients imported, verbose error messages, etc.)

Any feedback or thoughts?

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 23, 2018, 12:14pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/16 "2018-11-23T12:14:33Z")

</div>

Thank you, this looks good to me!

We also need a Cancel button. It could be next to the progress bar or in the details window (that is shown when Details button is clicked). Probably the details window would be a better place because in the future we could add a cancel button for each task (and tasks could include network tasks, such as push/pull images to/from a server).

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [November 23, 2018, 12:50pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/17 "2018-11-23T12:50:29Z")

</div>

Note that we tried threading the indexing in the past and had some mystery crashes.

I’m sure it’s solvable, but probably best to fix the model dialog issue first and then do threading as a separate experiment.

As the [SQLite FAQ says](http://www.sqlite.org/faq.html#q6):

> “Threads are evil. Avoid them.”

See this issue for more background:

> <https://github.com/commontk/CTK/issues/292>
>
> In the summer of 2012 we started using the QtConcurrent \[1\] approach in the inde…xer for multithreading \[2\]. While this seems to work fine in the ctkDICOM test application, when importing large data in slicer we get random crashes like \[3\] and \[4\].
> 
> It seems that Qt does not support accessing one database connection from multiple threads \[5\] which is what we do when each functor is using the same ctkDICOMDatabase instance. The Qt documentation suggests looking at the particular db interface for further guidance.
> 
> The sqlite faq is unambiguous about their opinion of threads \[6\]. ;) Although they do say that threading could work in some situations \[7\].
> 
> It seems the safest thing is to remove the thread code and go back to something in the main event loop, perhaps with a timer so that the GUI remains responsive.
> 
> \[1\] http://doc.qt.digia.com/qt/qtconcurrentfilter.html
> 
> \[2\] https://github.com/commontk/CTK/commit/8daad7583115e59df90e43cd77fb0a9d665f657e
> 
> \[3\] http://na-mic.org/Bug/view.php?id=2839
> 
> \[4\] http://na-mic.org/Bug/view.php?id=2871
> 
> \[5\] http://qt-project.org/doc/qt-4.8/threads-modules.html#threads-and-the-sql-module
> 
> \[6\] http://www.sqlite.org/faq.html#q6
> 
> \[7\] http://www.sqlite.org/threadsafe.html

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 23, 2018, 4:39pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/18 "2018-11-23T16:39:59Z")

</div>

Background indexing will be done in a separate development step for sure.

If threading is not stable then we may do it in a separate process, in a CLI module. We already have all the necessary asynchronous execution features in place for CLIs (progress reporting, canceling, job queuing, etc.), so we would not need to develop new infrastructure.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 23, 2018, 4:43pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/19 "2018-11-23T16:43:28Z")

</div>

By the way, it seems that you’ve tried to use the same database connection in multiple threads, which I think is not allowed by default.

We could also change the indexer to collect all data in memory in a worker thread, and after every 50-100 files update the database from the main thread.

---

<div class="post-metadata">

**Author:** ![Sunderlandkyl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/sunderlandkyl/32/79987_2.png) [@Sunderlandkyl](https://discourse.slicer.org/u/Sunderlandkyl)\
**Post date:** [November 23, 2018, 8:08pm UTC](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826/20 "2018-11-23T20:08:38Z")

</div>

I’ve actually discovered something interesting.

- If you create a ctkDICOMBrowser from the python interactor, then import **will not** cause the issue
- If you create a DICOM browser through DICOMWidget.py, then the browser **will** have the issue

In that case, it seems to me that it might not be caused by the modal popups, but is instead caused by the rewiring of the browser widget that takes place in DICOMWidget.py.

To get a better idea of what’s going on, can someone explain to me why this widget reorganization is neccesary in DICOMDetailsBase.setup(): [https://github.com/Slicer/Slicer/blob/8d765eab6445c277346f4c7248d9441dca4559dc/Modules/Scripted/DICOMLib/DICOMWidgets.py#L127-L343](https://github.com/Slicer/Slicer/blob/8d765eab6445c277346f4c7248d9441dca4559dc/Modules/Scripted/DICOMLib/DICOMWidgets.py#L127-L343)

[Next page](https://discourse.slicer.org/t/dicom-browser-is-stuck-behind-main-window-after-dicom-import/4826.md?page=2)