Custom Slicer distributions

If we customize the application name then it has to be a rebuild (at least of the application components) not just a repackaging, but we can reuse all the pre-built dependencies, so it wouldn’t be a big burden.

Total size of all zipped nightly extension packages on Windows is 217MB.

Current Slicer installer is 188MB, and when EMSegmenter will be spun out to a separate extension then Slicer core installer will be only about 120MB. Bundling all the extensions would increase the package size to about 400MB, so bundling all extensions would result in a 3x larger install package.

Overall, bundling all extension is an interesting idea but I’m not sure if it is the best solution and it would not scale very well as more extensions are added.

Good point. I don’t know how easy it is to have Windows docker images. Docker for Windows runs Linux images, but maybe some recent Windows server versions can now run Windows images, too? Visual Studio Community license is free, but Windows OS license is not - I don’t know how that is handled.

I was basically envisioning a customized launcher name only (maybe icon too), possibly at install time. But maybe I’m underestimating the work/complication there, or overestimating feasibility with CMake and CPack.

Yes, exactly.

You can change the application name and settings without recompiling. I added that for the CustomSlicerGenerator. I don’t think we change the app icon right now, but that’s also possible to do without recompiling.

OTOH I do like the idea of using containers to build extensions on-the-fly for all the different platforms. This would allow anyone to build a ‘mini factory’ to update extensions against particular slicer builds.

1 Like

Currently we have an extension and that works well. I’m not sure why all SlicerVerse packages need a custom full Slicer installation (distribution). If the name becomes distribution, this is implied, but I don’t think it has to be a requirement for everything. It seems like more to maintain. Thoughts?

I’ve checked the code and indeed application name is not hardcoded anywhere but it is determined from the application executable name at startup. So, you can get quite close to a usable solution using CustomSlicerGenerator. However, there are two limitations:

  1. CustomSlicerGenerator does not give you an installer package. We cannot just dump a zip file on the user (at least on Windows it doesn’t work).
  2. Another issue is replacing resources. CTKResEdit can replace standard windows resources (such as the application icon). However, Qt resources (referenced by the qrc file) are compressed, converted to C++ code, and compiled into the Qt C++ program. These cannot be changed after the application is built.

Agree. I’m happy with SlicerDMRI as an extension for now too.

I agree with Lauren. We should not force our users to create custom distributions of Slicer. Extensions are fine.
However, all extensions cant be considered Slicer Distributions. This falls along a definition of what constitutes a SlicerDistribution.

We talked about the fact it needs to be customized to the needs of a certain biomedical community and be self-sufficient by itself (no matter if it is an extension or a Slicer package)

The reason why I decided going through the hassle of creating SlicerCMF and Salt as their own packages is because our specific communities struggled installing extensions (they did). Also, because you can create a snapshot of your program/extension in time to avoid having to keep the extension current with Slicer.

Nothing that anybody with an extension cant do with the SlicerCustomGenerator.

What do you mean by a “SlicerVerse package”?

Options existing today:

  1. User downloads standard Slicer installer and installs extensions manually.
  2. Custom installers (have custom application name, some additional extensions are bundled, some modules are excluded) - this can be built without modifying anything in Slicer source code, just by tuning CMake options (except resources, which currently cannot be customized through CMake). No extension manager access.
  3. CustomSlicerGenerator: It kind of works but currently has two serious limitations (no installer; resources are not customizable).

We are happy with Option 1 for most cases. For some use cases (commercial applications, clinical installations) we use Option 2.

What is a SlicerCMF and Salt package? A custom installer? Does it use a custom application name (custom settings, etc)?
How you distribute it? How do you update it?
Does it have access to the extension manager?

What do you mean we cant dump a zip file on the user? We have done that in the past, and people has had no problem using the unzipped package. SlicerCustomGenerator fixes the paths during the first time you run the program.

What is a SlicerCMF and Salt package? A custom installer? Does it use a custom application name (custom settings, etc)?

They are generated differently. SlicerCMF uses SlicerCustomGenerator, with the idiosyncrasie that we are discussing. SlicerSALT uses a different library that does create installers and allows customizing the application name, the colors etc.

How you distribute it?

Distribution is where I see the biggest problem. You have to use your own resources, hosting, etc.

How do you update it?

SlicerCMF - download a new Slicer package for the customization
SlicerSALT - update Slicer git tag as part of the build

Does it have access to the extension manager?

It can, it is configurable. I have decided to hide the extension manager in both packages, just because I am trying to remove cluter from the packages. Both SlicerCMF and SlicerSALT modules are distributed initially as part of the Slicer proper extension mechanism (in that way we give back to the community). So if a user wants to use any of the CMF or SALT extensions in conjunction with other tools, that can be done through Slicer proper.

For this reason I disagree with the name “Distribution.” Our original idea was to advertise the communities and dedicated application-specific software packages that have grown up with Slicer. I prefer the name Communities to Distributions, for example, though I don’t know what is the perfect name.

1 Like

Yes, there are communities who use/develop different distributions. I would use the “distribution” word instead of “package”. Now we just have to figure out what a “package” should mean.

I think we should agree in one method that is acceptable for all needs. It is enough work to specify, implement, and maintain one new mechanism.

SlicerCMF = Option 3: I don’t think SlicerCustomGenerator’s lack of installer and resource customization are acceptable and the main problem is that I don’t know about any possible fix (that would work without rebuilding the application).

SlicerSALT = Option 2: I think this could be usable. We just have to make sure that no Slicer core source code has to be modified (for maintainability, binary compatibility, etc). As far as I know, all necessary parameters can be customized via CMake variables. The only current limitation is that changing resources requires changing Slicer core files - but this should be fixable.

In SlicerSALT repository do you change anything else than resource files to customize your application?

3 posts were split to a new topic: Customized application launchers

There are at least three conversations here.

One is the question about what to call the thing at the top of the landing page, for linking/advertising “topical groups Communities with a website and funding” -> I suggest taking this conversation back to the other thread: Communities / “SlicerVerse”

Then there is a technical, logistical, and maintenance question of:

  • improving capabilities to create customized bundles
  • creating such bundles on a regular basis (perhaps on behalf of a team Community as defined above – but by no means are they required to do so)

-> this thread!?!

And the related question of: including custom launchers in a bundle, installer, and/or extension. -> I suggest moving to a new thread: Customized application launchers

1 Like

@ihnorton now I am double lost, since I get an impression individual messages are being moved across the threads that are being split and merged again …

I have to say that I really don’t like the feature of Discourse of moving messages around. It is super confusing to me, and in fact discourages to contribute to the discussion.

I love the possibility to have clear discussion threads, but the discussion was so complex already that I agree that splitting just made it much harder to follow. We can still merge it back to one thread again - but I’m not sure if it would help or make things even worse.

Anyway, I think we are talking about several things and we don’t even have a common agreement about what we are talking about.

Should we try to keep discussing this in writing or set up a teleconference instead?

Ok, sorry. I can see how splitting made it even more confusing. The feature is very nice when there is a more clear break to follow.

Having learned from my own mistakes, I made a new thread to discuss the topic of splitting threads Splitting of the discussions

I don’t have a good idea how to salvage this one though!