GHOST Target-Specific Configuration
swalker2m opened this issue · comments
The GHOST IFU(s) can be independently configured and I believe the most convenient place to do so is in the target component, along with the target definition itself. Selecting a target in the target table already shows its coordinate, proper motion, magnitude and ITC "source" editors. This task adds another editor for GHOST targets.
The editor needs to contain
- Binning setting which is a choice between 1, 2, 4, or 8.
- Whether to explicitly override the guide fiber on/off state. (I believe though that we have decided to defer the guide fiber state to the future so we shouldn't include it for the June release.)
The challenge of this task is defining where to put more target-specific configuration in an already crowded screen.
One idea is to halve the space for Magnitudes and add another section below for GHOST targets. Another is to relegate the sections to tabs like "Coordinates", "Magnitudes", "Source", and "GHOST". Another would be to just add a new section below the existing ones.
The GHOST-specific information would only appear for GHOST science targets, the IFU1 and IFU2 targets. Just as for guide stars and ITC "Source" information, it should disappear for any other target.
As per our discussion, the other option was to place this information in the GHOST editor, which is less than ideal since this would introduce a strong dependency on the data in the two UI nodes, which would be confusing and probably more time consuming.
I believe we also talked about placing this information in a tab akin to the problems tab. I also think that this is confusing as it acts quite differently to how this tab is typically used, and no other information is configured in this way, IIRC.
I'd like to know how often the information in this section of the target environment editor is either changed or referenced, as I don't know offhand. If there are sections that are seldom changed and referenced, I like the idea of breaking this into tabs: this is probably the option that will give us the most flexibility moving forward and clean up how cluttered the UI is here. The division you propose is the one that makes sense to me (unless for some reason, the contents of two tabs are coupled to the point where one would have to page-flip back and forth, in which case, we could have fewer tabs.)
If, on the other hand, this information is frequently referenced / changed, I think we may need to incorporate it into the existing UI. I think this is the inferior option, though, as I think it will add more clutter than we already have, and introduce a dependency on the Magnitude display region for GHOST, which I don't like. (Adding an independent tab for GHOST target configurations seems much simpler than trying to throw another panel in there if GHOST is the instrument.)
So, the short version: I definitely prefer tabs, provided they aren't inconvenient to the users.
and introduce a dependency on the Magnitude display region for GHOST
Seems like we might be able to generalize it to a panel for whatever asterism/instrument-specific editor is required, which would be none for everything but GHOST.
Tabs are usually annoying and clicky but I don't really have a great answer here. I might be inclined to halve the magnitude editor if there is an instrument-specific config panel but I agree it really is starting to get too busy and that only works if the panel is tiny (as it would be in this case).
I think that this is going to take some experimentation to find the best UI layout that works, even though performing the actual configurations themselves won't be extremely hard. I'd like to say 2-3 days?
With regards to our meeting this morning, it looks like very little configuration is going to be needed for targets. Steve said that he needs to figure out what GHOST expects in terms of information regarding targets, but it looks like much of the work for this is not necessary for July (e.g. creating "sky" targets instead of just "object" targets). Much of what was listed here is either not needed for July or will be accomplished for 1442, so I will include the estimates for this task in that one.
Correct, binning has been moved out altogether and guide fiber state can be defaulted for now if I understand it correctly. Nothing to do here for now.
There may be some work left to do for this task, so I'll leave it for now. I suspect binning will be in the instrument component, but guide fibre state will - if I understand correctly - need to be in the target component?