# Workflow that brings together a few modules as tabs in a unifying parent module.

**URL:** <https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314>\
**Category:** Development\
**Created:** [January 8, 2019, 8:54pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314 "2019-01-08T20:54:48Z")\
**Posts on this page:** 9\
**Page:** 2

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 13, 2019, 8:21pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/21 "2019-01-13T20:21:13Z")

</div>

Agreed. The next set of commits should enable that.

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 13, 2019, 10:07pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/22 "2019-01-13T22:07:23Z")

</div>

In addition of supporting `Slicer --designer` where the Slicer launcher is available, the cross-platform approach to start Qt designer is to run `SlicerDesigner` executable found in the `bin` directory.

It was needed to configure a launcher because on macOS it is not possible to run `./Slicer --designer` from an install tree.

Based on tomorrow nightly build, we may have to tweak the packaging of designer on Windows and macOS. After this is tested, we will initiate the 4.10.1 release process.

---

<div class="post-metadata">

**Author:** ![adamrankin](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/adamrankin/32/155_2.png) [@adamrankin](https://discourse.slicer.org/u/adamrankin)\
**Post date:** [January 16, 2019, 7:48pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/23 "2019-01-16T19:48:23Z")

</div>

Just an FYI to all, I have recently stumbled upon [this](https://issues.slicer.org/view.php?id=4670) issue.

I will work on a fix, but until then, the `slicer.util.loadUI()` approach can’t load re-usable widgets from extensions.

---

<div class="post-metadata">

**Author:** ![NormandRobert](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/normandrobert/32/4818_2.png) [@NormandRobert](https://discourse.slicer.org/u/NormandRobert)\
**Post date:** [January 16, 2019, 10:20pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/24 "2019-01-16T22:20:54Z")

</div>

Looking at someone else’s code and noticed that they use ScriptedLoadableModuleWidget.setup(self). If one starts from the python generated module template this function is not called and the template instead has code to produce a reload button reload and test button and connections and a method to reload modules.

---

<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:** [January 16, 2019, 11:03pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/25 "2019-01-16T23:03:31Z")

</div>

The older templates included the developer section, but now they use the superclass:

> <https://github.com/Slicer/Slicer/blob/4b38acadf6878ef37092443b63ab4f5b12f37c8d/Utilities/Templates/Modules/Scripted/TemplateKey.py#L42>

Is that not working?

---

<div class="post-metadata">

**Author:** ![NormandRbert](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/normandrbert/32/2975_2.png) [@NormandRbert](https://discourse.slicer.org/u/NormandRbert)\
**Post date:** [January 17, 2019, 12:36am UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/26 "2019-01-17T00:36:33Z")

</div>

I ran the script more than a year ago. Could be my fault. Will check.

---

<div class="post-metadata">

**Author:** ![NormandRobert](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/normandrobert/32/4818_2.png) [@NormandRobert](https://discourse.slicer.org/u/NormandRobert)\
**Post date:** [January 18, 2019, 11:17pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/27 "2019-01-18T23:17:22Z")

</div>

Yep I was using a template I generated too long ago…

---

<div class="post-metadata">

**Author:** ![NormandRbert](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/normandrbert/32/2975_2.png) [@NormandRbert](https://discourse.slicer.org/u/NormandRbert)\
**Post date:** [January 28, 2019, 10:24pm UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/28 "2019-01-28T22:24:37Z")

</div>

I have thinking about UI reuse a bit more (as opposed to logic reuse). Do you all agree that it is just a case of putting all the UI stuff in a new class… let’s call it ModuleNameWidgetUI with some constructor expecting a layout whereby said class is also designed so that MRML node(s) can be “passed in” and for each MRML “passed in” the node selection widget is not created and the “passed in” value is used 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:** [January 29, 2019, 12:58am UTC](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314/29 "2019-01-29T00:58:20Z")

</div>

The current design is that each module offers a number of reusable widgets. The module widget is built up a couple of these widgets. This results in much simpler design and more clean interfaces than trying to make a large monolithic module widget highly configurable with lots of options.

Some module widgets may contain sections that are not available directly as reusable widgets (we did not have the extra time to do that or did not think that there would be a strong need for it). If you want to reuse such sections in your module then the solution is to factor out those parts as a separate widget - as it has been done several times in the past.

[Previous page](https://discourse.slicer.org/t/workflow-that-brings-together-a-few-modules-as-tabs-in-a-unifying-parent-module/5314.md?page=1)