-
Notifications
You must be signed in to change notification settings - Fork 36
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update app-model documentation #325
Conversation
ping @DragaDoncila @jni who may be interested |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucyleeow thanks for getting started on this - so much useful information in here. I know it's still in draft but I've done a first pass and left mostly grammar/spelling fixes as well as a couple of other suggestions. Feel free to ignore if you have a different workflow!
@@ -2,66 +2,195 @@ | |||
|
|||
# napari's application model | |||
|
|||
```{important} | |||
**This is not a part of the public napari interface!** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucyleeow I think it's probably still good to keep this notice here? Afaik there's no public interface for the app?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but it is now inside the 'architecture' section which only includes docs aimed at devs, so we can infer that it is not part of the interface. I guess it's good to spell it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But as I understand, there is intention to make it public:
napari/napari#6054
Without making get_app public, the actions cannot be simply called from plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do make it public we can amend this message.
I think the intention is more to allow users to register actions at runtime. Depending on the contribution type, the user may already have a public API func to access plugin actions- e.g., there is the open_sample
func for sample contributions, and I think there may be a way for the user to get reader/writers too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that option to call actions is as important, as runtime registration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You think users should call a command in app
via the command ID string instead of using existing public API like open_sample
? Why?
Or do you just mean you want users to have the option of calling a command via string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we provide public API only for opening sample and adding plugin widget. And plugins could provide many more contributions.
And there is an area for people who would like to provide custom controllers (either widget or hardware)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure but these are not the current comtribution types? We could create public API for new contribution types. Have we already decided how these new contributions would look?
I'm not opposed to execute via app model but there's probably a few decisions to be made here and this way may not be the best?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I don't think this is going to get hashed out in this PR lol.
Let's update the message to: This is not currently a part of the public napari API, but we are considering ways to expose action execution directly.
Once we actually decide what the interface for that is, we will amend.
Okay I think this is ready for review now. Thanks @DragaDoncila for the thorough review already! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this fell through the cracks!
It's really good and useful, I did catch a few broken links, so requesting changes, but otherwise it's good to go IMO.
## app-model vs action manager implementation differences | ||
|
||
App-model and action manager differ in when actions are executed. | ||
In app-model, actions are defined executed when they |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actions are defined executed when
This is confusing to me, either one of those should be dropped (executed?) or there is an "and" missing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah I mucked that up. I think I mean 'executed'? (because define just means which file they are written in right??). When a function is connected to an event or registered to the app
, the function itself is 'run' right? I mean we import the e.g., view menu actions and that import runs the functions inside the file where the view menu actions are defined?!
What is the best phrasing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not use executed
in this context. I would say "defined" when referring to the file they are literally written in, and registered
when they are added to the app-model/action_manager registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good point. I've remembered what I was thinking about when I wrote this -> plugins menu actions used to be registered later when we create the plugins menu (when we know we have Qt). Now we register plugin actions much earlier, when we don't know if we have Qt. (Thus we've had to do 'safe register')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done @DragaDoncila, let me know what you think, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, I'll let @DragaDoncila & @Czaki make the final call on the two open questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a few comments to unresolved conversations. @lucyleeow ping me once these are done and I'll approve!
@@ -2,66 +2,195 @@ | |||
|
|||
# napari's application model | |||
|
|||
```{important} | |||
**This is not a part of the public napari interface!** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I don't think this is going to get hashed out in this PR lol.
Let's update the message to: This is not currently a part of the public napari API, but we are considering ways to expose action execution directly.
Once we actually decide what the interface for that is, we will amend.
## app-model vs action manager implementation differences | ||
|
||
App-model and action manager differ in when actions are executed. | ||
In app-model, actions are defined executed when they |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would not use executed
in this context. I would say "defined" when referring to the file they are literally written in, and registered
when they are added to the app-model/action_manager registry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Let's get this in and we can always improve in future PRs. Thanks @lucyleeow 🙏
@psobolewskiPhD could this go in? 🙏 I've got a new PR that depends on it 😬 |
Description
Updates the app-model documentation:
This depends on napari 4991 as I link to a file in the repo that is created in that PR.