Difference between revisions of "Installers"

From HaskellWiki
Jump to navigation Jump to search
Line 1: Line 1:
There are quite a few Haskell compilers/interpreters, and on Windows they all want to be the default handler for .hs and .lhs files. This document prescribes how all the installers should work with regards to file paths. Hopefully this document can reach a concensus.
+
There are quite a few Haskell compilers/interpreters, and on Windows they all want to be the default handler for .hs and .lhs files. Some Haskell tools might provide several handlers for Haskell source files, many Haskellers might want to use several Haskell tools side by side. Oh, and then there is the question of editing source files - to each their own.. This document aims to be the basis for a consensus, which all installers of Haskell tools on Windows should try to adhere to, so that all Haskell users and tools may work in harmony (amen;-).
   
The compilers which are committed to implementing this standard are: [[Yhc]], [[Hugs]]
+
The compilers which are committed to implementing this standard ''(note that this document is still in the discussion phase)'' are: [[Yhc]], [[Hugs]]
   
 
== User configuration ==
 
== User configuration ==
   
During install the user will be asked whether they want to register .hs/.lhs files to open with the compiler being installed. Yes will be the default. If the user picks no, then no changes will be made to the .lhs/.hs association settings.
+
This document is concerned with two configurable aspects of installation: associating file name extensions with file types and associating file types with the handlers provided by the Haskell tools being installed. During install the user will be asked whether they want to register .hs/.lhs files to open with the tool being installed. Yes will be the default, meaning that the installer will ensure that the common file types for .lhs/.hs files will be known, and that the Haskell tool's handlers ("Open in Tool", "Edit with Tool", ..) will be available via the right-click menu for files of these types. If the user picks no, then no changes will be made to the .lhs/.hs association settings.
  +
  +
Installers may also offer to register one of their handlers as a default handler for these file types, but is important to realise that there are two kinds of users: first-time Haskellers just want to say yes to everything the installer offers and have it do "the right thing", whereas more experienced Haskellers will have widely different opinions about what "the right thing" is. So when you write your installer, you will have to curb your enthusiasm and, instead of just putting your own tool first, think of it as adding functionality to a whole box of Haskell tools.
   
 
== File types ==
 
== File types ==
   
The Haskell file types are given as .hs and .lhs. They icon used shall be the top line of [http://www-users.cs.york.ac.uk/~ndm/projects/winhugs/winhugs-icons.png this image]. These icons are available in the Hugs CVS repository in Windows .ico format (where?).
+
The Haskell file types are given as .hs and .lhs. The icon used shall be the top line of [http://www-users.cs.york.ac.uk/~ndm/projects/winhugs/winhugs-icons.png this image]. These icons are available in the Hugs CVS repository in Windows .ico format (where?).
   
  +
The file type description for each file shall be "Haskell Source" for .hs and "Literate Haskell Source" for .lhs. It is important that installers agree on these file types. On a related note, MIME types for Haskell files have also been discussed in the past (see [http://www.mail-archive.com/haskell@haskell.org/msg10716.html this 2002 thread] and the 1999 thread it points to).
The file type description for each file shall be "Haskell Document" and have a given MIME type.
 
   
 
== Actions available ==
 
== Actions available ==
Line 21: Line 23:
 
Where interpreter is an interactive environment, in the style of Hugs/GHCi/Yhe.
 
Where interpreter is an interactive environment, in the style of Hugs/GHCi/Yhe.
   
  +
'''''question: should version numbers be included (probably yes)?'''''
If the interpretter can offer a sensible Edit action (i.e. WinHugs, but not GHCi) then there will be an additional command:
 
  +
 
If the interpreter can offer a sensible Edit action (i.e. WinHugs, but not GHCi) then there will be an additional command:
  +
 
* Edit using <interpreter>
  +
  +
It is probably not useful to flood the right-click menu with Edit actions where each interactive Haskell system just calls out to an editor, but some Haskell tools (e.g., WinHugs) have invested some effort in finding sensible default Edit actions, so users can save time by letting the Haskell tool open the Haskell file with the editors configured (and configurable) there. Also, IDEs (e.g., Visual Haskell or Eclipse FP) might offer combined interaction and editing functionality.
  +
  +
* Edit with <editor>
   
  +
Though not usually provided by Haskell tool installers, it is good to keep in mind that there are various programmers' editors out there, so installers should never lose existing actions associated with Haskell files, just add their own handlers.
* Edit using <interpretter>
 
   
 
== Default Action ==
 
== Default Action ==
   
 
If there is a preexisting default handler, then that must not be changed without the users consent (a checkbox during install). It doesn't matter whether that default is an older version of the tool you are installing or another tool you consider inferior to the one you provide: the user is always right!
The default action (double clicking) is ranked with the following priority:
 
   
  +
It does make sense to offer making one of your tool's handlers the default during install, it does make sense to suggest uninstalling that old version before proceeding with the new install (after copying the user preferences), and you might be forgiven for pointing out that one of your tool's handlers would make a much more sensible default for Haskell files than the existing ones. But users need a chance to say no, and if they do, that's it.
* If prior to installing the compiler there is a default document handler for .hs/.lhs files, which is not one of the compilers adhereing to this standard, then this has highest priority.
 
* Any Edit action.
 
* Any Open action.
 
   
  +
If the user does agree to make one of your tool's handlers the default, you still need to take care that the old default handler remains available in the right-click menu (i.e. you add your tool's handlers, then switch defaults - never mess up what is already there!).
If there is a preexisting default handler, then that must not be changed without the users consent (a checkbox during install). If the preexisting action is a higher priority than the new one, then this defaults to no, otherwise defaults to yes.
 
   
 
== New Document Creation ==
 
== New Document Creation ==
   
An entry should be added to the Explorer's New menu, giving Haskell Document as an option, which will create a .hs file.
+
An entry should be added to the Explorer's New menu, giving Haskell Source as an option, which will create a .hs file.
   
 
== Technical Implementation ==
 
== Technical Implementation ==

Revision as of 22:34, 29 September 2006

There are quite a few Haskell compilers/interpreters, and on Windows they all want to be the default handler for .hs and .lhs files. Some Haskell tools might provide several handlers for Haskell source files, many Haskellers might want to use several Haskell tools side by side. Oh, and then there is the question of editing source files - to each their own.. This document aims to be the basis for a consensus, which all installers of Haskell tools on Windows should try to adhere to, so that all Haskell users and tools may work in harmony (amen;-).

The compilers which are committed to implementing this standard (note that this document is still in the discussion phase) are: Yhc, Hugs

User configuration

This document is concerned with two configurable aspects of installation: associating file name extensions with file types and associating file types with the handlers provided by the Haskell tools being installed. During install the user will be asked whether they want to register .hs/.lhs files to open with the tool being installed. Yes will be the default, meaning that the installer will ensure that the common file types for .lhs/.hs files will be known, and that the Haskell tool's handlers ("Open in Tool", "Edit with Tool", ..) will be available via the right-click menu for files of these types. If the user picks no, then no changes will be made to the .lhs/.hs association settings.

Installers may also offer to register one of their handlers as a default handler for these file types, but is important to realise that there are two kinds of users: first-time Haskellers just want to say yes to everything the installer offers and have it do "the right thing", whereas more experienced Haskellers will have widely different opinions about what "the right thing" is. So when you write your installer, you will have to curb your enthusiasm and, instead of just putting your own tool first, think of it as adding functionality to a whole box of Haskell tools.

File types

The Haskell file types are given as .hs and .lhs. The icon used shall be the top line of this image. These icons are available in the Hugs CVS repository in Windows .ico format (where?).

The file type description for each file shall be "Haskell Source" for .hs and "Literate Haskell Source" for .lhs. It is important that installers agree on these file types. On a related note, MIME types for Haskell files have also been discussed in the past (see this 2002 thread and the 1999 thread it points to).

Actions available

The actions available for each compiler shall be:

  • Open in <interpreter>

Where interpreter is an interactive environment, in the style of Hugs/GHCi/Yhe.

question: should version numbers be included (probably yes)?

If the interpreter can offer a sensible Edit action (i.e. WinHugs, but not GHCi) then there will be an additional command:

  • Edit using <interpreter>

It is probably not useful to flood the right-click menu with Edit actions where each interactive Haskell system just calls out to an editor, but some Haskell tools (e.g., WinHugs) have invested some effort in finding sensible default Edit actions, so users can save time by letting the Haskell tool open the Haskell file with the editors configured (and configurable) there. Also, IDEs (e.g., Visual Haskell or Eclipse FP) might offer combined interaction and editing functionality.

  • Edit with <editor>

Though not usually provided by Haskell tool installers, it is good to keep in mind that there are various programmers' editors out there, so installers should never lose existing actions associated with Haskell files, just add their own handlers.

Default Action

If there is a preexisting default handler, then that must not be changed without the users consent (a checkbox during install). It doesn't matter whether that default is an older version of the tool you are installing or another tool you consider inferior to the one you provide: the user is always right!

It does make sense to offer making one of your tool's handlers the default during install, it does make sense to suggest uninstalling that old version before proceeding with the new install (after copying the user preferences), and you might be forgiven for pointing out that one of your tool's handlers would make a much more sensible default for Haskell files than the existing ones. But users need a chance to say no, and if they do, that's it.

If the user does agree to make one of your tool's handlers the default, you still need to take care that the old default handler remains available in the right-click menu (i.e. you add your tool's handlers, then switch defaults - never mess up what is already there!).

New Document Creation

An entry should be added to the Explorer's New menu, giving Haskell Source as an option, which will create a .hs file.

Technical Implementation

Not much point in doing this section until everyone agrees on the end user behaviour!