What @che85 and I considered in the past (and I think we discussed this with @lassoan) is to include “launchers” (for the lack of a better word) that would provide access to the application/community-specific slicelet.
The user would still install the full Slicer application downloaded from the same central location, but (perhaps as an option at install time) they would get a separate icon for a focused functionality that would launch specific slicelet, which would not expose the full application with all the bells and whistles.
I am still a bit lost about what is SlicerVerse, and what defines “a SlicerDistribution” or “something that is customized enough to meet the needs of a certain biomedical community” - I think the guidelines are fuzzy or non-existing. But what I suggest would provide access to the very focused application UI developed for a specific need, distributed as part of Slicer. I think if the main goal is to hide the complexities of Slicer that are irrelevant to a given task, it might be enough to achieve that goal.
I absolutely agree. There are often situations where users are overwhelmed by the Slicer user interface and developers decide to create their own slicelets.
I think it would be a great feature to have shortcuts within one’s Application directory (regarding MacOS) that allow starting an extension slicelet for hiding the complexity of Slicer.
Another for extensions that provide a slicelet would be to have a checkbox within the ExtensionManager which says “Add slicelet shortcut to my applications” or something similar.
The structure for the ExtensionIndex might need to be extended then I guess.
Good point, this is a nice approach, too. Based on this, I update the list of existing customization options:
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). No extension manager access.
CustomSlicerGenerator: It works but it has two serious limitations (no installer is available, just a zip file; resources, such as any icons and bitmaps shown in the application are not customizable - except application icon and splash screen).
Custom launcher: Shortcut in the Start menu (Windows) or Application directory (MaxOSX) that starts Slicer, jumping right into a slicelet (module with a simplified user interface). It uses standard Slicer installation.
All these options have some merits. I guess we just need to decide if we want to promote one of these methods to be an officially supported, widely advertised solution for distributing customized Slicer versions.
it would be trivial to add a windows installer to the CustomSlicerGenerator. The current cpack method used for Slicer is NSIS and has been unchanged for well over a decade and it basically just starts from a redistributable directory of the app. (Of course, as @bpaniagua has confirmed a zip file containing an executable is completely usable even by clinical users)
I believe all the Slicer resources can be overridden from python; if not that is probably a limitation to be fixed in any case. However I also suspect that any slicelet or other customized app is going to create a whole new interface that remixes the slicer widgets so the application side of that would have its own resources anyway. (@lassoan can you give a specific example you’d like to change but cannot currently?)
I also think we need to weigh these issues against the benefits of the CustomSlicerGenerator:
Custom app maintainers don’t need to have cmake or compilers or even have access to all the build platforms
customized versions can be built using the standard slicer packages and extensions from using any platform (e.g. linux script can generate linux, mac, and windows custom versions)
re-uses the existing factory and extension resources rather than duplicating them
leverages the python customization features of the Slicer core, so any improvements there will have side benefits for other extensions
As @bpaniagua says, specific versions multiple extensions can be pulled together in a bundle version which simplifies support
I can very easily find any number of users who has no clue what to do with a zip file but can easily install using an installation package. You would not have start menu shortcuts, uninstaller, etc. either. So, I would not even consider this as a viable option.
It’s certainly possible to create/edit an NSIS project file (project.nsi) manually but it requires some work. For example, you need to list explicitly list in the .nsi file all files that need to be uninstalled. If you add some files to the distribution you need to edit the .nsi file and add an uninstall command for each.
I don’t think it is possible to override resources that are built into the application. It is possible to dynamically load/unload complete resource files, but then you need to compile a resource file using Qt’s resource compiler for creating a custom package.
If we know in advance what images we allow to replace (for example the large Slicer logo at the top of the module panel) then we can change the implementation to load those from individual external files instead of a resource package.
There a number of other things that can be nicely configured at build time but not dynamically - see the long list of options here. These were all specifically added because customers needed to change it.
I agree that having a way of customizing a Slicer package without setting up a compiler would be really, really good. All benefits that you listed are valid and I could add a few more. The only issue is that it would be so much work to implement (and maintain) all the necessary hooks and additional mechanisms that would make this solution feasible. in contrast, we have an almost complete solution by simply building Slicer core, customized through CMake options.
If we decide to go that way, I would be ready to help with improving the custom slicer generator, but it would require a lot of efforts from others, too.
If these remain customizable and an installer can be generated on all platforms, then using custom slicer generator will be an acceptable option for us.
Yes, for windows users an installer can be helpful so we should add an option to create one. I haven’t looked in a very long time but it should be easy to just recursively list all the files in the custom slicer directory and tell NSIS to install them.
Of course there’s also the issue that some PCs will let you run executables from zip files, but won’t let you install without admin accounts so people may still want the zip option in some cases.
Other than Slicer_USE_PYTHONQT_WITH_OPENSSL (which I doubt you want to change) it looks like those all just turn modules on or off or set things in the Settings file. These are easy to customize already.
The rest of the options you list should be editable with ctkResEdit or an existing platform specific variant.
Of course, people will always have the option of working from the CMake level to create their own amazing project, but as we all know that is not easy at all!
That’s just a simple setting if the installer should ask for elevated access. It is usually set for elevated access so that you can install in Program Files folder. If the installer does not request for elevated access then any user can run it and then typically you set the install folder to be in the user’s profile (this is for example how Plus applications installer is configured).
Not very simple, but it can be certainly implemented in Python (some directory walking and text file generation based on a template). This is already implemented in CMake but if we don’t want to depend on CMake then it has to be reimplemented from scratch.
Default settings are now hardcoded in the application. If a key is missing then the application creates it and initializes it with the default value. Of course the setting can be changed in Python but you don’t know if a particular setting is a default value set by the application (can be updated) or set by the user (must not be changed). If we don’t implement some sophisticated mechanism then some user settings will be lost on application install.
There is also disclaimer text. There are many solutions for this, just have to implement one of them.
Overall, no blocking issues, just many small things and a few larger mechanisms would need to be implemented.
Hello jcfr,
Thank you for your reply,
I still can’t find the configuration when creating the installer package.
I have built already, I added a new module, and then want to create a new installer package containing the new modules.
for extensions that provide a slicelet would be to have a checkbox within the ExtensionManager which says “Add slicelet shortcut to my applications” or something similar.