Goal of “SlicerVerse” (“Slicer universe”) is to offer custom Slicer distributions built on the same Slicer core but pre-configuret for specific applications (Communities / “SlicerVerse”).
It is important to decide how much these custom distributions should be separated from the vanilla Slicer distribution.
Should the application name be still “Slicer”?
It has many implications.
Application name is used in the install package name, start menu shortcut, title bar of the application. It is easier to find/distinguish a custom distribution if it has a custom name.
Application name is also used for storing application settings (.ini files). If the application name is not “Slicer” then all user and version-specific settings are separate from the vanilla Slicer distribution settings. This can be useful, as you can set up custom startup module and other application settings separately for each distribution.
Only one application of a specific name and version may be installed at a time.
Should custom distributions be able to download additional extensions from the Slicer appstore?
If yes, then these custom distributions should be built on official factory machines so that ABI compatibility can be guaranteed.
Theoretically it could be possible to set up identical build environments, but it would be hard to ensure they are kept in sync (OS, compiler updates, environment variables, etc. may all affect the binaries). Also, application signing would be easier to set up at one place (we still have not managed to set it up for current Slicer).
@jcfr Do you think Kitware build machines could cope with a couple of more Slicer core nightly builds? Dependencies (VTK, ITK, CTK, DCMTK, …) could be built once and used for building all custom distributions. Extensions would be probably also shared between all.
My $.02 is that it would be ideal to package these distributions from a single official nightly. Even ignoring build machine load, multiple separate builds could add a lot of confusion, maintenance overhead, etc.
If we wanted to keep it really simple and don’t mind trading some package size, we could even bundle everything (the extensions aren’t that big, are they?), and do something clever with the installer to make it activate only some bundles by default, perhaps based on the download name or a prompt (the others would still be available from the extension manager).
Now that docker is natively available on all platforms, we might be able to have standardized build images for all platforms, which would also (somewhat) resolve the long-standing SDK request. (modulo license restrictions for MSVC, not sure how that works, but I have seen docker-windows build images…)
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.
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.
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:
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).
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.
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.
User downloads standard Slicer installer and installs extensions manually.
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.
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.
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?
One is the question about what to call the thing at the top of the landing page, for linking/advertising “topical groupsCommunities 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 teamCommunity 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
@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?