I am running two instances of Joplin, one sync'ed on Joplin cloud, another on Dropbox. I would like to start Joplin with one or the other, without needing a painful start then restart every time I want to switch.
I understand this may actually be available with the --profile qualifier, but I can't find details on it.
Idealy I'd prepare two shortcuts to the appimage, each with a different --profile... qualifier.
Sorry if this is already an obvious feature!
TIA!
Hervé
Edit: Disregard this answer — the --profile flag is intended only for debugging (for example, it's used for automated testing in GitHub CI).
According to @laurent, improper usage of --profile flag can lead to data loss (particularly if used to force different versions of the app (e.g. desktop and CLI) to use the same profile).
Original
In `~/.config/joplin-desktop`, there should be a `profiles.json` file.
Observe that each profile has an id. There should be corresponding profile-id folders for each profile in ~/.config/joplin-desktop/. For example, Profile 4 has a profile-g2sj7zuy folder.
@personalizedrefriger Indeed your last correction was sad for me,because I indeed managed to prepare two linux shortcuts, the ordinary one to the Appimage, and an alternative that launches the same Appimage but appending --profile xxxx where xxxx points to the new profile-id folder that my new Joplin Cloud instance just created.
This way, indeed I can select at launch time the right profile, independent from the 'previous state' of Joplin so it does solve my question!
Do you really think this use of --profile is noxious?
Switching profiles quicker sounds to me a significant advantage... Maybe I should propose this in the famous thread about 'improvements that you'd dream for 2024'?
Thanks in any case!
If you're on a Linux distribution that supports snaps, you might consider using @james-carroll's snap distribution of Joplin in addition to the AppImage. @james-carroll has done an excellent job of providing timely updates and keeping it up-to-date with the main Joplin repository.
It should also be possible to safely run the Snap application at the same time as the AppImage, as the two distributions store data in different places.
This still works too; you can install multiple versions of the same snap and each one gets its own profile and is so cut off from the other you can open arbitrary amounts of them at the same time, each of them can technically be on different versions too; though publically I only ever have the latest stable release available and ignore the pre-releases entirely, so all that means really is that people could pause updates for one and not the other, unless they were happy to rebuild an older version themselves.
As i'm definitely not in favor of snaps*, I'll keep on with the Appimage, initiated according to @personalizedrefriger above, and crossing fingers.
Dealing simultaneously with both Dropbox and Joplin Cloud is a must for me, I don't want to take any risk on data loss (in spite of now being aware that that this way introduces app risk on its own!)
Thanks again!
Hervé
(*) nothing related to Joplin, but in my view snaps are Mark Shuttleworks way of getting money out of Ubuntu by removing the normal Debian apt packaging (for 1 year now) and replacing with his own snap market -a closed market where obviously sooner or later you'll have to pay for your app to appear, and freewares deemed unpleasant will simply disappear.
Debian, to me, is the very opposite of that
Snap won't remove Apt. We're dependant on Apt to build snaps! There'll be specific packages that might get replaced by snaps (in Ubuntu exclusively) but the requirements there are particularly high. Firefox was a perfect example because people always look over the part where Canonical was expected to support 5 different LTS' at the same time across 5 different processor architectures. Not even Mozilla had 25+ active releases for a single version, and especially with OS libraries going back 10 years (and soon to be 12!).
Snaps do make profit in commercial cases (IoT primarily); but I think it's important to remember that development at commercial scale isn't free. Canonical hasn't made a profit for the first 15 years of it's inception, becoming only profitable as recently as ~2018ish. Meanwhile Canonical is an active Debian contributor; there's no need to make downstream changes if they can be pushed upstream first. The Gnome DE packaging in Debian has a lot of the Ubuntu Devs working on it.
I can understand the general concern, but Mark himself has paid off 15 years of peoples salaries to work on open source; whilst the entire world has benefited from it. At some point, the bank of Mark will run out and the company needs to be capable of standing on its own two legs; snaps are a part of that, but I'd not expect it to interfere with the general community/desktop side of things, I'm convinced most Linux devs are aware that home users will actively avoid trying to pay for anything, so why bother trying. Giving the average home user every incentive to go elsewhere, when there's already lots of good choices, isn't how Ubuntu reinforces itself as a convenient platform worth investing in.
@james-carroll Thank you for your detailed comment above!
I contact you out of the thread as the snap destiny is seriously off-topic here
Being myself very afraid of conspiracy theories I do understand I'm probably oversensitive. But well no snaps for me...
Putting this thread a bit back on the topic of multiple profiles specifically, the Flatpak also stores its data elsewhere and should be enable you to have at least the one AppImage version and Flatpak instance side by side. Unfortunately I'm unsure if the same Flatpak can be installed multiple times though.
What you might find interesting is how the snap actually relocates those folders. The Flatpak uses a mount namespace to trick Joplin into writing to the "wrong" folder (inside the Flatpak namespace). The snap doesn't. Joplin doesn't respect the XDG Desktop specs for placing its data; the only thing that needs to be changed is $HOME itself.
So E.G, you could try:
HOME=$HOME/joplin-work-profile ./Joplin.AppImage
And this might get you reasonable results. It won't unfortunately get two versions open at the same time by itself, but might be slightly more reliable than the --profile flag.
And that's essentially what this does, which is a feature of the AppImage format itself.
Unfortunately, this all misses fixing the actual restart problem, since there'd likely still be only one app running at the same time. (And I unfortunately never figured out how the snap actually avoids that).
Thank you! I'm going to try Flatpak too.
Now, I also... discovered... that I can export a couple of notes in JEX format, and this can also accelerate my testing.
I displaced the 'solved' tag to your last post above.
Thanks again!
H.
