-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial implementation of abstract class #126
Conversation
Separated out the Ginga implementation. Re-organized and updated tests.
cb4e10e
to
9800195
Compare
TST: Update test matrix and added a test. DOC: Re-organized doc and notebooks. DOC: Update example notebooks
This comment has been minimized.
This comment has been minimized.
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. |
@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 |
Ah, thanks, @ejeschke ! It is fixed now. |
pycairo will give you the most capability... |
1f3baf9
to
debe04e
Compare
Hoping to take a look at this later today...if not, then first thing wednesday. |
a9a7c2d
to
a62d31f
Compare
DOC: Cannot use automodapi for Ginga API because we need to inherit docstring. DOC: Do not display inherited members because too confusing. [ci skip]
4d6579e
to
678a2e4
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
|
||
.. code-block:: python | ||
|
||
from astrowidgets.somebackend import ImageWidget |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptually I wonder if this is better presented as
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?
In some out-of-band discussion, @mwcraig, @pllim, and I concluded we want to try the |
Superseded by #162 |
Fix #93
Pre-requisite for #122
Bonus:
TODO
docs
example_notebooks
ImageWidget
to inherit docstring fromBaseImageWidget
?