Hey,
I was thinking about how default plugins project can be implemented and wanted to discuss that. But before that, here are some links to my PRs and other work:
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.
You're off to a really good start. What you show above is quite high level, so I can't say too much about it.
Specifically about plugins needing the app to restart issue. I can see two options:
The Joplin app is updated to no longer need a restart when installing plugins (I really have no idea how much work this would be). This would be great to have regardless of default plugins.
The first-launch-plugin-install happens in a sort of pre-launch install phase. This is where I would be leaning (partly because it also helps with other issues).
Deciding between these will take more investigation to see which is a more natural fit for Joplin.
note: I just noticed that JackGruber replied as well just before me I'll post this anyways
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.
Sorry if I missed something in the discussion, but being an average user, I don't understand what "default plugins" are.
Which ones are we talking about?
If it's a first installation of Joplin, how can a user know if he needs these plugins or not? And which ones?
Can he refuse them?
Can he install only some of them?
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?
This means that always the newest one is used for bundling. An automatic update of already installed is bad, for example, there may be a reason why someone does not want to update a particular plugin.
Can you please explain what do you mean by 'merging'? Do you mean in the sense that we don't have to install them, and we won't see them in the plugins section?
Also, we can consider this as a part of this project, right?
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.
Hi CalebJohn and Laurent,
I was thinking if we should discuss and finalize the overall approach for the project. Should I create a separate post for this project under 'GSOC Projects'?
Sorry for not reaching out earlier, this is a holiday weekend in Canada. I'll be reaching out to you privately to discuss communication details and next steps.
Hey,
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.
CI Script
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.
I'll post this anyways