consider passing the model directly to gui view objects

[tlambert03]

currently, GUI views don't touch the model... they just notify the controller of a change, and then the controller requests the changed value from the view before passing it to the model:

class SomeView:
    currentIndexChanged = Signal()
    def __init__(self):
        self.dims_sliders = ...
        self.dims_sliders.currentIndexChanged.connect(self.currentIndexChanged.emit)
    def current_index(self): ...

class Controller:
    def __init__(self):
        self.model = ...
        self.view = ...
        self.view.currentIndexChanged.connect(self._on_view_current_index_changed)

    def _on_view_current_index_changed(self) -> None:
        self.model.current_index.update(self.view.current_index())

That works fine, but it requires a lot of signal machinery to be on the View objects, and adds some indirection. We could alternatively just pass the model to the frontend widget:

class SomeView:
    def __init__(self, model):
        self.model = model
        self.dims_sliders = ...
        self.dims_sliders.currentIndexChanged.connect(self._on_view_current_index_changed)

    def _on_view_current_index_changed(self, value) -> None:
        self.model.current_index.update(value)

class Controller:
    def __init__(self):
        self.model = ...
        self.view = ...

having the view control the model is not necessarily an unusual pattern. Most of Qt view widgets have direct access to and mutate their models (it's mostly a model-view only pattern).

not sure yet whether this would make it harder to keep the different views behaving similarly

[tlambert03]

on a quick stab at implementing it, I ran into one other issue that would likely need addressing: the view has the ability to reset the range of the canvas. Ideally this would actually correspond to a change on the model, but we don't yet model the camera in the display model. That's a big ball of wax that was a real sticking point in microvis ... but we'll need to tackle it someday