Skip to content

Programmatically control zooming & panning#2

Open
burhankhanzada wants to merge 3 commits into
hlvs-apps:mainfrom
burhankhanzada:programatically_controll
Open

Programmatically control zooming & panning#2
burhankhanzada wants to merge 3 commits into
hlvs-apps:mainfrom
burhankhanzada:programatically_controll

Conversation

@burhankhanzada
Copy link
Copy Markdown

Added feature to programmatically control zoom and panning which is helpful when need shortcuts but have to create new custom controller and move some methods to that. Please review it.

@hlvs-apps
Copy link
Copy Markdown
Owner

Hi, thanks for the effort. It looks like a good idea; however I have some concerns with your current implementation, mainly regarding the duplicate code within the update methods and the state tracking in general.

The common approach imo would be a bigger refactor, moving the state tracking to a single source of truth and the respective update methods to the new controller class, so they can be removed from/reduced to one liners in the BetterInteractiveViewerBaseState class, although that would mean removing these settings from the widget and moving them to the controller, which is a no-go for me because it would make using the widget much harder.

I think a better approach would be something like keeping all the state in the abstract BetterInteractiveViewerBaseState, and providing the pan and zoom methods there (making it available via a global key) and possibly providing a shrinked version of your InteractiveViewer2Controller that the BetterInteractiveViewerBaseState attaches automatically to, giving the controller a way to forward the method calls to the base class.

Also, I would like to keep some compatibility to the current interactive viewer transformattion controller, so the new controller should at least offer a factory like InteractiveViewer2Controller.wrapTransformationController(TransformationController controller)

@burhankhanzada
Copy link
Copy Markdown
Author

burhankhanzada commented Sep 5, 2025

Yeah i totally agree with you my solution have divided state but that was my poor man solution to able to work with this package as default implementation lack some functionality.

I think your approach would be better and backward compatible also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants