Difference between revisions of "Documentation/Labs/CustomSlicerGenerator"
(4 intermediate revisions by the same user not shown) | |||
Line 43: | Line 43: | ||
A new extension has been created: https://github.com/pieper/CustomSlicerGenerator | A new extension has been created: https://github.com/pieper/CustomSlicerGenerator | ||
− | As of late February 2015 | + | ===As of late February 2015=== |
+ | It mostly works and creates a custom application with the modules specified by a configuration script. The resulting custom application runs, but it uses the settings from Slicer because the application name is [https://github.com/Slicer/Slicer/blob/9ab851e646f7eb755d27e0fb9d367d97ee55ad08/Applications/SlicerApp/Main.cxx#L108 hard-coded in Slicer's Main.cxx]. | ||
Line 49: | Line 50: | ||
Since we are using the [http://www.commontk.org/index.php/Tools:_Application_launcher ctkApplicationLauncher], we will need to change the settings to point to SlicerCustomApp-real{.exe} and when processing argv0 we'll need to strip that off. | Since we are using the [http://www.commontk.org/index.php/Tools:_Application_launcher ctkApplicationLauncher], we will need to change the settings to point to SlicerCustomApp-real{.exe} and when processing argv0 we'll need to strip that off. | ||
+ | |||
+ | We also need to update the Info.plist for mac and the app launcher settings for windows and linux to point to the newly custom-named App-real executable. | ||
+ | |||
+ | It will also be important to save provenance about the custom slicer version to help with support and debugging. Basically the custom app will be a whole new application so it needs it's own versioning. Probably the config.json should come from a git repository (something like a .s4ext) so that the version can be generated from that. Then in the future this process can be automated and the git repository info about the config file will uniquely define the custom slicer that was generated and therefor all the dependencies can be traced back as well. | ||
+ | |||
+ | === As of March 6, 2015=== | ||
+ | |||
+ | * Slicer trunk has been patched to allow a custom application name based on argv0. This allows the custom app to have independent settings from the original Slicer. | ||
+ | |||
+ | * CustomSlicerGenerator module has fixed most issues: | ||
+ | ** Settings files (ini on linux and windows; and plist on mac) now contain the correct info about the application to launch. | ||
+ | ** Launcher is customized based on new app name | ||
+ | ** there is now a customizer module installed on the new app that can perform any app-specific initializations | ||
+ | *** show an app-specific dialog or splash screen | ||
+ | *** set module paths | ||
+ | *** create a custom layout or other interface | ||
+ | *** configure the logos | ||
+ | *** figures out how to set Extension paths correctly and prompts for restart | ||
+ | |||
+ | Example packages: | ||
+ | * [http://joe.bwh.harvard.edu/slicer/SlicerCMF.app-2015-03-06-macosx.zip SlicerCMF.app-2015-03-06-macosx.zip] | ||
+ | |||
+ | * TODO items | ||
+ | ** add automatic zip file creation with date and platform information | ||
+ | ** maybe uploading zip to a server | ||
+ | ** see if Customizer can auto-load extension modules without requring a reboot | ||
+ | ** testing on all platforms | ||
+ | ** fetching the config.json file from a url rather than on-disk (so it can come from a controlled repository) | ||
+ | ** Communicating with other project for other requirements (SlicerRT, SlicerIGT, SlicerRadiomics, SlicerProstate...) |
Latest revision as of 19:08, 6 March 2015
Home < Documentation < Labs < CustomSlicerGeneratorContents
Goals
In many use cases it is desirable to provide customized versions of Slicer that remove clutter from the user interface and only expose the set of functionality that is needed.
Ideas
Based on original design ideas from Bea, at the 2015 Winter Project Week Steve, Francois, and Jc brainstormed about what is needed and how we might accomplish it.
Some goals were:
- Single click download for end users, customized logo and application name
- Cross-platform support
- Ability to configure:
- Included extensions
- Excluded modules
- Application settings (layout, toolbar, home module...)
- Easy to generate and update and create new versions
- Interactively
- Batch
Planned Steps
- Create Prototype ProfileWizard as scripted module in a custom Extension
- Offer a list of modules with checkboxes
- Create a new output application directory containing only selected modules
- Test this on the TMJ-OA craniofacial use cases
- Review how to map to batch mode
- Define configuration format
- Determine how to access all directories and other info in order to automate download and packaging cross-platform
Issues to sort out
- How to make a custom application icon (currently app icons are stored as read-only resources inside the application executable).
- How to tell slicer to use the extensions.
- Could copy all extension executables and shared libraries into lib/Slicer-4.4/cli-modules, but on Mac the paths are 'fixed up' meaning they are hard coded to be in extension subdirectories. They do not work if copied into the core.
- Could find a way to customize the settings file to set module path and mimic the behavior of the extension manager.
- Could provide a scripted module that finishes the installation of the Custom Slicer application the first time it is run on a client machine (this might be the best option).
- How to remove module menu groups like "Diffusion" when they are empty.
Implementation Progress
A new extension has been created: https://github.com/pieper/CustomSlicerGenerator
As of late February 2015
It mostly works and creates a custom application with the modules specified by a configuration script. The resulting custom application runs, but it uses the settings from Slicer because the application name is hard-coded in Slicer's Main.cxx.
If the applicationName is not set, newer Qt will use either argv or a mac-specific method to guess a name. But this isn't really what we want since we use the launcher on linux and windows and we don't want to mess around modifying with the mac-specific stuff if it can be avoided. Note that the application name needs to be pretty much right away during the startup process. So we'll need to have a custom solution for this rather than porting over the new Qt code.
Since we are using the ctkApplicationLauncher, we will need to change the settings to point to SlicerCustomApp-real{.exe} and when processing argv0 we'll need to strip that off.
We also need to update the Info.plist for mac and the app launcher settings for windows and linux to point to the newly custom-named App-real executable.
It will also be important to save provenance about the custom slicer version to help with support and debugging. Basically the custom app will be a whole new application so it needs it's own versioning. Probably the config.json should come from a git repository (something like a .s4ext) so that the version can be generated from that. Then in the future this process can be automated and the git repository info about the config file will uniquely define the custom slicer that was generated and therefor all the dependencies can be traced back as well.
As of March 6, 2015
- Slicer trunk has been patched to allow a custom application name based on argv0. This allows the custom app to have independent settings from the original Slicer.
- CustomSlicerGenerator module has fixed most issues:
- Settings files (ini on linux and windows; and plist on mac) now contain the correct info about the application to launch.
- Launcher is customized based on new app name
- there is now a customizer module installed on the new app that can perform any app-specific initializations
- show an app-specific dialog or splash screen
- set module paths
- create a custom layout or other interface
- configure the logos
- figures out how to set Extension paths correctly and prompts for restart
Example packages:
- TODO items
- add automatic zip file creation with date and platform information
- maybe uploading zip to a server
- see if Customizer can auto-load extension modules without requring a reboot
- testing on all platforms
- fetching the config.json file from a url rather than on-disk (so it can come from a controlled repository)
- Communicating with other project for other requirements (SlicerRT, SlicerIGT, SlicerRadiomics, SlicerProstate...)