nmearl
commented
8 years ago Ginga -- Provides backend agnostic toolkit and callbacks.
I don't see this as being practical. Ginga, while a cool idea, is definitely not robust enough (last I checked), and covers up a lot of the advanced functionality of the libraries it attempts to abstract (requiring the user to explicitly use their preferred toolkit, negating the benefit of having an agnostic toolkit). It also makes way too many assumptions about the reasons you're using the toolkit (e.g. as a fits viewer). Last I was aware, it made arbitrary divisions (e.g. global vs local plugins) which cordon functionality and, while a great helper feature for scientists who don't want to learn a gui library, restricts communication to a basic callback system. I am also not a fan of the strict adherence to the MVC style (it inherently sandboxes functionality for the sake of ease of use). I guess my biggest argument against Ginga is that it would require an entire re-write, much in the same vein as having used Glue as our base framework, which for our current usage, is much more reasonable (albeit still quite impractical) than using Ginga.
Eliminate the need for Qt Designer and enable others to easily contribute to GUI changes
Qt Designer isn't necessary, we could just as easy cut it out and code directly (e.g. like we did in the original remake of SpecView). It's just a matter of time and preference.
(Below, I paraphrase my responses to Adam Ginsburg from an email exchange).
specutils -- Uniform spectrum I/O across the community.
Specutils has some really nice functions that allow for good, robust parsing of fits files and is definitely something we’ll want to incorporate in the future. We had tried to focus, foremost, on the ability to extend the io structure via user-definable loader files and thus shied away from making too many assumptions about the state of the data. This obviously means we’ve left gaps for when data is not exactly formatted as expected. This is where, I think, the power of specutils will lie.
pyspeckit -- Might have useful things that goes beyond spec I/O that we can use.
The pyspeckit framework is a very nice option, however, we had decided early on to adopt the astropy NDData object as the base class for our data objects. With it, we also grabbed the arithmetic mixin to handle math operations being that it handles things such as uncertainty propagation (with a nice way of defining different uncertainty types) and our units reasonably well. So far, it seems to work well, but we will definitely be looking into some functionality that pyspeckit implements.
SpectralCube? -- Useful if we want to extend viewer to cubes.
From a cursory glance, it seems like this tool could help with preserving WCS information through axis transformations, which would be very useful for exporting data after some manipulation.
I think all of this is a great discussion to have. Thanks for bringing this up, @pllim!
pllim
astrofrog
Some Astropy-affiliated packages that might be useful:
The initial switch is going to be a learning curve and will take time. But I think doing this make specviz more maintainable in the long run. So, something we want to think about if specviz is going to stay permanently beyond the sprint and going to be used by many people within and outside STScI.