Hey @CalebJohn, @JackGruber, I would really appreciate any suggestions of yours on the above approach as you will be mentoring this project.
Update: The issue with this approach is we would need to restart the app in order to install the plugins. To solve this, I think I will also need to figure out a way to install the plugins without restarting the app. I didn't find any discussion on this topic on the forum, but if there has been, please let me know.
There are different methods how the default plugins can be distributed:
Bundle the Plugins directly into the distributed Joplin files
Modify the installer and install the plugins during the installation
Install the Plugins during the first app start
The problem with the app restart only occurs when the default plugins are downloaded and then installed the first time Joplin is started.
The question is is this really a problem? I don't think so, since this is relatively quick since there is no data in Joplin yet.
An update for default plugins should not be handled differently than for all others, so nothing needs to be considered here.
Also a change of the default plugins should not install/uninstall plugins on already installed joplin clients.
All the plugin jpl files are present in the joplin plugin repro, you do not have to build them.
Thanks for the reply, JackGruber and CalebJohn, Happy to know that I am on somewhat right track.
I was thinking bundling plugins(.jpl files) directly into distributed Joplin files and then installing them on the first app start. So we don't have to download them.
Ok. I thought this because on idea list it said "Some process needs to be implemented so that they are bundled and updated automatically."
I like this approach as we don't have to do things very differently on different platforms. For example, with modifying-the-installer approach, we might have to do something different for AppImages for Linux.
But I will look into different options given by JackGruber in more depth to see what's best for Joplin.
I don't have clear idea about this but from the above page I think they will be Backup or Rich Markdown plugin etc. Basically plugins which provides/enhances core functionality like backup. But Joplin team will be responsible for deciding these, I think.
Of course, you can disable/uninstall them at any time, but this raises a good question, i.e. how about we have some pop-up that asks if user wants to install all the default plugins or not?
So IMO, before installing the plugins, the pop-up should mention
how to manage these plugins after installation,
ideally, should show a list of the plugins that will be installed, with a brief description,
ideally, each plugin should have a checkbox to accept or not its installation (in my opinion the user should not have to go to the plugins section in "Options" to disable or remove after the first install)
I think the idea is that these are specific plugins that are so necessary that they should probably just be core features, but for some reason they aren't/can't be.
So I think that a new user would have no basis upon which to make the decision as to whether they should be installed or not. It's not like these plugins contain advertising.
However I do think it's a good idea during the installation process to have some kind of mention that there are things called "plugins" (which non techy users might not understand) and that some really useful ones have been installed already. Or something like that.
I had some questions about the approach we will be using for this project. I thought maybe we can discuss and finalize it.
So there are 2 main parts for this project. They are as follows
Installing plugins on app's first start
By the current approach, we will be packaging the .jpl files for the default plugins with the app itself, so users don't have to wait for them to be downloaded. These should be installed on app's first start up.
As pointed out by Laurent in forum, we may install default plugins before loading the plugins as to avoid restarting. But after doing a quick test of this approach I was getting 'There is already a plugin with this ID' but I believe after some debugging I should be able to fix this.
My approach for this was to run CI script in joplin/plugins repo. It will compare the versions present in main Joplin repo and if a newer version is available in plugins repo it will make PR for .jpl file to be included in main Joplin repo.
When discussing this idea in the draft proposal, Laurent suggested that the approach for CI script should be a bit different. Are you suggesting that the script should run on the main Joplin repo?
Yes, I would put this as a hard requirement for the default plugin project. The default plugins must be available on the first start. If you are having difficulties troubleshooting, we can take a look at alternative options for making it happen.
I'm not familiar with the discussion you had. But it seems to me that the process should take place in the main Joplin repo, when Joplin desktop is being built. The build script would grab the latest jpl files for each default plugin and include them in the build.
Yes I agree that would be the better approach. We could bundle the plugins when the app is built, and that way we don't need to deal with CI and can more easily test locally.
We should also consider whether it should fetch the latest versions, or if we should pin them (one is more convenient, the other more secure). This issue is less important though as that can tweaked later on.