Hi, I'm still not sure if I fully understand the point of onUserEnable (ex. what should I keep in onload and what should I move to onUserEnable?) so can I confirm my understanding?
As far as I observed, onUserEnable is not called if my plugin is already enabled in the app's startup, and it is called if I enabld my plugin after the workspace is ready.
I skimmed through some core plugins' usage of onUserEnable and I noticed that each core plugin who has its own view performs its view initialization in onUserEnable . Also, the view init process is not performed anywhere other than onUserEnable.
Is this because in startup, the view initialization task is automatically handled by the workspace based on workspace.json so we don't have to do that job by ourselves?
From Liam:
Yes, that's exactly right. The most common usage would be creating an instance of your custom view. Commonly, plugins would create their custom view inside onload, but this means that if the user wants to close your view, every time they reopen Obsidian, the workspace would get restored, but the view will reappear.
onUserEnable provides a place for plugins to execute initialization code when the user expresses intent.
The 'Saved Queries' pane reappears every Obsidian startup, since Obsidian 1.7.2 (Insider).
A message on Discord - available to Insiders says:
further discussion says:
From: Ryota Ushio
Hi, I'm still not sure if I fully understand the point of
onUserEnable
(ex. what should I keep inonload
and what should I move toonUserEnable
?) so can I confirm my understanding?As far as I observed,
onUserEnable
is not called if my plugin is already enabled in the app's startup, and it is called if I enabld my plugin after the workspace is ready.I skimmed through some core plugins' usage of
onUserEnable
and I noticed that each core plugin who has its own view performs its view initialization inonUserEnable
. Also, the view init process is not performed anywhere other thanonUserEnable
. Is this because in startup, the view initialization task is automatically handled by the workspace based on workspace.json so we don't have to do that job by ourselves?From Liam:
Yes, that's exactly right. The most common usage would be creating an instance of your custom view. Commonly, plugins would create their custom view inside
onload
, but this means that if the user wants to close your view, every time they reopen Obsidian, the workspace would get restored, but the view will reappear.onUserEnable
provides a place for plugins to execute initialization code when the user expresses intent.