-
-
Notifications
You must be signed in to change notification settings - Fork 410
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
TODO list for integration of app-model #4860
Comments
@tlambert03 Thanks for putting this together! do you mind if I convert this issue to a project board so we can track and collaborate? |
the |
Small addition: Update (I am assuming that after full transition to app-model we won't be using the old system at all anymore?) Edit: I see all the |
@lucyleeow I think #6643 should also be listed somewhere in here, probably in the lower priority tasks, since we have a workaround for now. Thank you for the exceptional recordkeeping 馃檹 馃帀 |
Done and added some more! |
# References and relevant issues Towards #4860 # Description Migrates debug menu to app-model --------- Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
# Description Now that all menus have migrated to app-model (see #4860) `NapariMenu` and `populate_menu` are redundant and no longer used in the code base. This PR removes the `napari/_qt/menus/` folder.
馃О Task
list of todos after #4784
continue replacing procedural QtMenus with app-model registered ones (note PR use app-model for view menu聽#4826 provides the base changes and tests required for the menu migration to app-model and all other PRs are based off of this original PR. It should thus be merged first)
allow registration of app keybindings that aren't attached to a specific python object (like viewer or layers). I think this could be done gradually. to start, we could by put a object that implements the
KeymapProvider
interface at the beginning or end of theChainMap
used to lookup keybindings. In the longer run, the app-model keybindings registry would be the source of keybindings, andkey_bindings.KeymapHandler
would be retired.extract keypress control from the vispy canvas (Reclaim keypress events from vispy, and clarify what actually handles keypresses.聽#3087)
add documentation to
napari.org/plugins
that explains how to add menu items, including a list of "contributable" menu ids, (similar to this)add documentation to
napari.org/plugins
explaining exactly what names they can use in theirwhen
context clauses in their manifests (like this page for vscode). Related issue: DocumentContextKeys
聽docs#146, also for reference Talley has mentioned wanting to (auto)generate docs using the descriptions in the ContextKeys: Update layer list context keys聽#4499 (comment)add documentation explaining how to use
superqt.fonticons
to declare icons (and figure out the best way for those icons to change color with the theme)decide on and add documentation to explain exactly what types may be used as type hints for dependency injection in a plugin command function. (these are the names that are declared in the the
app.injection_store.namespace
)replace action manager with commands registry, determine if any deprecation is needed
consider putting the notification system in the app-model (perhaps upstream)
create 3 tiers of keybinding scope: default (napari), plugins, and user keybindings (in order of increasing priority)
rename
_qt.get_app
toget_qapp
... however that's publicly exported, and that needs to be consideredconsider using Actions for layer mode buttons
move to expressing keybindings using app-models keycodes instead of vispy's (the app-model tests and demos have a lot of examples of how to express keypresses using the
KeyMod
andKeyCode
enums)suggestion: context object for layerlist and viewer to be moved to app model聽#4919
Task: add tests for all app-model registered action callbacks聽#4979
The text was updated successfully, but these errors were encountered: