Keep "implementation details" out of the top-level API

[eteq]

I know this is currently at hack-level so all is forgiven, but at some point if this design has legs we want to keep the top-level API (import astrowidgets limited to the API specific to here. That is, right now some ginga stuff (AstroImage, most notably) is in the top-level, which I think would confuse users.

Similarly (but more controversially): perhaps the core widget shouldn't be a subclass of a widget at all, but rather contain the widget? (but override _repr_html_ and so on to behave correctly). That way the tab-completion method of learning a tool isn't overwhelmed by all the widet details.

Not urgent, but just putting it here to keep track/discuss.

[pllim]

@eteq , it does not subclass anymore. I did subclass for like 2 days, but then I replaced that implementation.

As for where to import what... That certainly can use improvement.

[mwcraig]

Oops, just saw this, the ImageWidget is back to subclassing from ipywidgets.Box. I think we want to continue to subclass from that; it is what makes this a widget, i.e. allows it to tie into the communication and event interface that comes along with widgets.

That does add some overhead when you tab complete, of course, but a tidy and well documented API should help some with that.

Agreed the top level import needs to be clean.

My main concern at the moment is that the internals of the current implementation are tied pretty strongly to ginga. On the other hand there really are not any other contenders for the drawing side of things I've seen yet. There are some on the horizon, maybe, but they are not there yet.

[pllim]

This is naturally superseded by #162 .