Slicer4:DownloadPackage

From Slicer Wiki
Revision as of 12:23, 26 July 2011 by Kikinis (talk | contribs) (→‎Linux)
Jump to: navigation, search
Home < Slicer4:DownloadPackage
Back to Slicer4 Projects

Introduction

This page contains a wishlist, plans, and assignments for the appearance and user experience of the Slicer 4 downloadable executables

Feature requests

User Side

  • Asks if it should be made the default application for .mrml and .nrrd files (ron says yes for mrml).
  • Reduce the size of the download package
  • 64bit versions for all supported platforms (or as close as is reasonable)
  • check for old version of Slicer. If present ask if to adopt the preferences and customizations
  • offer a registration: accept, later or opt out as options, sign up for mailing list: user list checked by default, developer unchecked by default

Server side

  • speed up the download statistics display on the download page
  • add monitoring of svn checkouts as a separately tracked entity (users versus developers)
  • data base to manage registrations
  • registration form schema
  • extensions should be available
  • SVN number should be the same for all the nightlies as the one showing on the dashboard ("XX files changed by 3 authors as of Wednesday, May 25 2011 23:00:00 EDT")

Architecture specific

Windows

  • Window uninstall should allow to clean up everything, including the registry settings. Note: Ini files are used on windows to store the settings.
  • when Slicer is running, the Slicer icon in the Taskbar has a border around the icon. This looks ugly.

Apple Mac OS X

  • Apple install should behave like other apple applications
  • When Slicer is running, then the icon in the dock should be the slicer icon. Right now its not.
  • should we be present on the Apple mac appstore?

Linux

  • The Linux version should make stable releases available through standard linux distribution mechanisms.

Platform specific installer issues 2011

Slicer has three types of storage needs:

  • Parameters for the program (such as what layout to start with, how much memory the graphics board has...)
  • Plug-ins
  • temporary and permanent data (local data base for the dicom widget, results of processing)
  • We should review where these things are stored in each platform and whether they follow best practices for that platform.
  • We should review, what customizations we should offer at install time.
  • We should offer a registration option at install time (register now, later, never).