Difference between revisions of "Documentation/Labs/CustomSlicerGenerator"

From Slicer Wiki
Jump to: navigation, search
Line 51: Line 51:
  
 
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.
 
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.

Revision as of 01:15, 23 February 2015

Home < Documentation < Labs < CustomSlicerGenerator

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

  1. Create Prototype ProfileWizard as scripted module in a custom Extension
    1. Offer a list of modules with checkboxes
    2. Create a new output application directory containing only selected modules
  2. Test this on the TMJ-OA craniofacial use cases
  3. Review how to map to batch mode
    1. Define configuration format
    2. 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.