Initial implementation of abstract class

[pllim]

Fix #93

Pre-requisite for #122

Bonus:

• Fix What is select_points xfailed in test #127
• Fix TST: Un-ignore empty marker warning #128

TODO

• Rebase after TST: Stop ignoring warnings #125 is merged
• Update docs
• Update example_notebooks
• How to get Ginga ImageWidget to inherit docstring from BaseImageWidget?
• See if we can get inheritance diagram to show something saner. If not, just do not show.
• Get feedback from stakeholders
• After merge, update all my unmerged PRs here

[pllim]

Note to reviewers: I don't expect you to go through all that diffs. This is probably the page you want to focus on: https://astrowidgets--126.org.readthedocs.build/en/126/abstract.html

@mwcraig , also note the API changes reflected in the example notebooks diff.

[ejeschke]

@pllim, are any of 'pycairo', 'pillow', 'opencv' or 'aggdraw' installed in the test environment? One of them is needed for the web backend to function, but I don't think any of them are in install_requires. Probably we should add pillow to the requirements because it is used in a lot of places (although technically not required if you are just using, say Qt, with just the ginga widget in a desktop app...)

[pllim]

Ah, thanks, @ejeschke ! It is fixed now.

[ejeschke]

pycairo will give you the most capability...

[pllim]

Re: pycairo -- @ejeschke , for the purpose of CI, that isn't important, but maybe we can discuss this as a separate issue (#130).

[mwcraig]

Hoping to take a look at this later today...if not, then first thing wednesday.

[pllim]

Thanks, @mwcraig ! Your feedback would be very valuable. I was just playing with finalizing the rendered API appearance and I think I finally got it working.

[eteq]

Have not managed a proper review of this, but given #142 I figure I should hold off anyway.

Conceptually I like this on its own, but with the caveat of all the points @mwcraig makes in #142. That is, using subclasses like this might turn off downstream users who want their astrowidgets backend to be the "real" viewer objects. It's easy to imagine a lot of dragons in managing the __init__, possible metaclasses, etc.

That said, I think basically everything in the "Understanding BaseImageWidget" section basically is still good even in the #142-style approach! That is, this captures what the user wants to see regardless of whether the backends are implemented as subclasses vs interfaces.

[eteq]

Conceptually I wonder if this is better presented as

Suggested change

	from astrowidgets.somebackend import ImageWidget
	from somevizpackage.astrowidget_backend import ImageWidget

? That is, make it clear that external packages can and should write their own backends, rather than it being an import from astrowidgets?

[eteq]

In some out-of-band discussion, @mwcraig, @pllim, and I concluded we want to try the Protocol approach at least to start with over the abstract/subclass approach implemented here. But the machinery from here for the documentation (i.e. https://astrowidgets--126.org.readthedocs.build/en/126/abstract.html ) and the testing machinery from here should definitely be ported to #142.

[pllim]

Superseded by #162