Open tlambert03 opened 1 year ago
@tlambert03 Thanks for putting this together! do you mind if I convert this issue to a project board so we can track and collaborate?
- [ ] rename
_qt.get_app
toget_qapp
... however that's publicly exported, and that needs to be considered
the napari.qt
could still export get_app
with a deprecation warning.
Small addition:
Update docs/guides/contexts_expressions
to explain their use in context of app-model.
(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 Expr
stuff has been moved to app-model so contexts and expressions in napari is definitely out of date.
Documenting some planning/tasks related to app-model integration.
Tasks post #4991 :
_rebuild_npe1_samples_menu
partial
in _rebuild_npe1_samples_menu
Window._add_menus
(see: https://github.com/napari/napari/pull/4991#discussion_r1429848050 for details)Other related tasks, where I am not sure of priority/order to be worked on:
Tasks once npe1 deprecated (only listing items relevant/related to this body of work):
_run
and deprecate _add_plugin_function_widget
and add_plugin_dock_widget
(no function/dock widget distinction in npe2Lower priority (?) related tasks:
when
and enablement
conditionals to plugins):
string_list.json
post the app-model changescc @Czaki @DragaDoncila in case I missed something.
@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 :pray: :tada:
Done and added some more!
🧰 Task
list of todos after #4784
[ ] continue replacing procedural QtMenus with app-model registered ones (note PR #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)
[x] 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 (https://github.com/napari/napari/issues/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: https://github.com/napari/docs/issues/146, also for reference Talley has mentioned wanting to (auto)generate docs using the descriptions in the ContextKeys: https://github.com/napari/napari/pull/4499#issuecomment-1129426998[ ] 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 considered[ ] consider 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)[ ] #4919
[ ] https://github.com/napari/napari/issues/4979