Enhance ConvertToMD interface.

[abuts]

This issue was originally TRAC 6958

ConvertTo MD interface become complicated and overloaded.

It should be simplified either according to the agreed suggestions, offered by the letter below , or by the interface improvements, suggested in the ticket http://trac.mantidproject.org/mantid/ticket/6855

[abuts]

@abuts (2013-04-29T20:53:07):
The missing letter suggesting the changes to MD interface:

This letter is inspired by simple ticket to expose lab frame and sample frame on ConvertToMD interface which is relatively simple one.
It was not there in the first place as the ConvertToMD interface is already overcrowded but if somebody really wants something, it still can bear couple of more properties.

The tester made number of comments related to the ConvertToMD interface complexity, which I completely agree with.
Unfortunately, one of the suggestions made to simplify things was

"Orthogonal HKL and Q in lattice units should go away"

I love orthogonal HKL and want to use it even when Mantid supports non-orthogonal system. In addition to that, it would be nice to add to the interface couple of more properties (e.g. the choice of non-default labels or coordinate system shift) but I would agree that adding anything to existing interface make it look even worse. Moreover, one can notice that there are 7 out of 20 properties on this interface which are related to Q3D mode only.

This is why I am suggesting to change the interface as follows:

1. The convertToMD interface would have only the properties, related to the workspace conversion and the plugin selection (input/output workspace, plugin, other dimensions, min/max & splitting parameters -- we will be able to hide/remove half of this in a future).

2. Each plugin (CopyToMD, ModQ, Q3D) would process two properties exposed to ConvertToMD interface -- the name of a table workspace with relevant properties and the string, which would allow to overwrite any property from this table workspace specifying key-value pair.

3. Three separate algorithms will be extracted from the ConverToMD code, which would prepare the table workspace with properties as in 2) from the input parameters. The algorithm for Q3D mode will build transformation matrix and other stuff needed (there are currently 7 parameters to process). All this is already there internally anyway.

There are no time to implement all this now. If I am not having real objections, I would write ticket to do that for the next release. Meanwhile, I would fix some minor things, noted by the tester for this release, but would mainly leave things as it is now.

---

@NickDraper (2013-07-26T13:55:01):
Moved to backlog at the code freeze for R2.6

---

@NickDraper (2014-02-14T11:04:59):
Bulk move to assigned at the introduction of the triage step

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. If you feel this is incorrect please comment to keep it alive, with a reason why.

To prevent closure, e.g. for long-term planning issues, add the "Never Stale" label.

[stale]

This issue has been closed automatically. If this still affects you please re-open this issue with a comment so we can look into resolving it.