Hi all. I’d like to see an option to sync settings across multiple Joplin clients, if sync is enabled. This would allow faster setup time on a new client, and a consistent experience across platforms.
2 Likes
Ha, this is an interesting idea and I actually have thought about this myself.
However, there are a few caveats, which have to be considered.
- fonts might not be available
- paths could be different on different clients (not to mention the directory separators
\and/) - options are not available on all clients
The best way to handle this would be a feature to export all settings (which should only be allowed to be restored on the same type of client).
1 Like
Yes, exporting the settings is what I was also thinking of. I’m not sure of this, but if the clients are aware of the platform they’re running on, then we might export the settings in a common format(json, maybe), and add some logic to read it appropriately for the platform.
Another thing I noticed was that some settings on the desktop client are missing on the mobile client(probably because of different editor). This would also have to be handled.
Yeah, this is a really good idea. It will really save a lot of time for users. What if we export values of all settings in some file and in all platforms take those values in some format and with some modifications. We can check the platform and can make necessary changes according to that. And also if we are exporting from phone to desktop if there are settings that are there in desktop but in mobiles, we will use default values for them.
2 Likes
@anihm136 and @ishantgupta777 as you are here for GSoC, we are open for suggestion 
2 Likes
I was going through the existing synchronizer model, and it seems possible to convert the settings to a javascript object and serialize it, same way notes and their related configs are. Is this feasible?
It may be feasible but as talked about by @PackElend and I with another student, it may be a good idea to make a system that follows Joplin’s current implementations that can be used in the main app to show you have an understanding of how Joplin handles it and then, once you grasp that, have at it with a different implementation. Your project isn’t necessarily going to be used by the main Joplin dev team for the app but instead a proof of concept that shows that you have what it takes to work on a project of this scope. PRs are almost exclusively used to show understanding of Joplin’s code and flow.
1 Like
This topic is the idea for my GSoC proposal. For the PR, I’m working on a couple of other issues. I was clarifying an idea for my proposal itself.
2 Likes
Is there any update on this feature? I use Joplin on my Macbook for work and POP_OS (Ubuntu based) Linux machine for home and I'm having more and more difficulty keeping the features and configurations in synch.
Alternatively, is it possible to manually export the Joplin configuration?
Hey, I was thinking about working on this. Is anyone already working on this...