Design CLI for plotting

[Owen Arnold]

Output will be a design document approved by scientists and developers from both facilities. This will be the default flavour of plotting interface (not Horace).

Estimate 1-2 weeks

[Nick Draper]

Bulk move of tickets out of triage (new) to assigned at the introduction of the triage state

[Owen Arnold]

The basic agreement is to make the plotting as matplotlib like as possible.

[Owen Arnold]

The basic design document has been read and agreed to by the member of the technical steering committee at bot the SNS and ISIS. ​https://github.com/mantidproject/documents/blob/master/Design/Plotting/plotting_cli.md

[Owen Arnold]

Federico and I are now working on implementing this.

[Federico M Pouzols]

I've had a look at the relevant docs, and the other day Owen explained to me what's the aim and approach here. So I think I can make a neutral evaluation, as I haven't been involved in this so far. On the other hand I'm not very experienced with Mantid, so take these comments with tons of salt. To sum up in a couple of points:

• The detailed objectives seem sensible and clearly defined to me. I just note a possible question mark, when they say "Additional top-level plot command that will inspect the data and plot it in the most sensible form", the "most sensible form" for so many different kinds of things may have different meanings for different users. This may require careful thinking/feedback/testing.
• Longer term, we'll need to explore how much of Matplotlib we can/want to support. And in the opposite direction, we'll need to explore how to wrap the tools and plotting functionality of Mantid that are definitely not Matplotlib-like to make them look as Matplotlib-like as possible.

Good points to note:

• There are a few examples in the design document and even some code in the mantid repository which give a good idea of what would be the concrete direction to take.

• The approach taken maintains full backwards compatibility, which would be my main concern, by providing the new functionality in a 'future' package. This is also great for testing/getting feedback.

[Owen Arnold]

Very good questions!

Please remind me about this at some point soon, as we should expand this document to include answers to your questions.

Replying to Federico M Pouzols:

I've had a look at the relevant docs, and the other day Owen explained to me what's the aim and approach here. So I think I can make a neutral evaluation, as I haven't been involved in this so far. On the other hand I'm not very experienced with Mantid, so take these comments with tons of salt. To sum up in a couple of points:

• The detailed objectives seem sensible and clearly defined to me. I just note a possible question mark, when they say "Additional top-level plot command that will inspect the data and plot it in the most sensible form", the "most sensible form" for so many different kinds of things may have different meanings for different users. This may require careful thinking/feedback/testing.
• Longer term, we'll need to explore how much of Matplotlib we can/want to support. And in the opposite direction, we'll need to explore how to wrap the tools and plotting functionality of Mantid that are definitely not Matplotlib-like to make them look as Matplotlib-like as possible.

Good points to note:

• There are a few examples in the design document and even some code in the mantid repository which give a good idea of what would be the concrete direction to take.

• The approach taken maintains full backwards compatibility, which would be my main concern, by providing the new functionality in a 'future' package. This is also great for testing/getting feedback.

[Stuart Campbell]

This ticket has been transferred to github issue ​9780