I have created a PR to implement this suggestion here Desktop: Add sync pending indicator by mrjo118 · Pull Request #13277 · laurent22/joplin · GitHub
I think it is a reasonable suggestion that can benefit everyone, but we’ll have to see how things go in code review
Thank you for working on improving the sync button and behavior. One of the pull requests mentioned that maybe the 15 second delay on desktop was perhaps due to the distraction due to things changing near the sync button on the screen. I find the button to be distracting because the icon is animated and the debug text changes as the sync happens. I’d prefer no debug text and an icon that didn’t rotate. Maybe a mouse hover tooltip showing when it was last successfully completed. I think the addition of the red dot or some other kind of dot (maybe purple to match the default UI color) is a nice way to indicate that a sync is needed.
All I need to know from the button is that: If a sync is needed, in progress, or done/successful. If it isn’t successful, some way to access more details about the failure. The button should let me trigger a sync or cancel a sync. All of the movement, changing text, is more distracting than any other application I’ve used that saves changes remotely.
This is an accessibility matter for some: ”For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.” Understanding Success Criterion 2.2.2: Pause, Stop, Hide | WAI | W3C
@scottku I think you should make a new thread for your feedback, as this thread is getting long and the scope of the discussion is expanding too much.
I’m glad that the dot indicator seems logical and beneficial to you. I did have second thoughts about the colour of the dot though. A red dot can suggest error or urgency and ChatGPT suggested that blue would be a more suitable colour which is commonly used for a more neutral type of indicator
I made a new PR now to replace the other one Desktop, Mobile: Implement a dirty state indicator which shows when there are pending outgoing changes to be synced by mrjo118 · Pull Request #13312 · laurent22/joplin · GitHub
I think this style of dot is more fitting, and I’ve also added mobile support (see the ‘Justification’ section in the PR description for why that is beneficial)
@Matt-NL In response to your OP, this issue is now addressed in the latest Joplin 3.6 prerelease via this PR:
dev ← mrjo118:warn-unsynced-changed-on-quit
opened 12:40AM - 03 Dec 25 UTC
This serves as an alternative to PR https://github.com/laurent22/joplin/pull/133… 12. While not as comprehensive at warning the user about potential sync issues, this change helps reduce the possibility of the user getting note conflicts when using Joplin desktop.
Joplin desktop has a delay of 15 seconds before it automatically triggers the sync as a result of making a change to a note, in contrast to the mobile app which has a mere 1 second delay (the period is longer on desktop because the sync button is always visible and is distracting to some users if it is spinning too frequently). This means that if a user quits Joplin desktop without waiting 15 seconds after their last change and without clicking the sync button manually, they will get a conflict if they edited the same note another device without first returning to the original device.
This PR seeks to address this issue by triggering the sync and opening a prompt upon quitting Joplin desktop, if a scheduled sync originally scheduled by an outgoing change has not yet been run or is in progress. The prompt says 'Synchronising remaining changes, please wait...' and gives the option to 'Quit anyway' or to 'Cancel' quitting the application.
**Screenshot of the new prompt:**
<img width="1920" height="1037" alt="sync before quit" src="https://github.com/user-attachments/assets/e7593453-5087-4e20-b6e0-ead886e7d51e" />
### Implementation details
1. Any outgoing changes which have not yet been synced which exist upon opening Joplin, will not trigger the prompt
2. This prompt will **only** be triggered when quitting Joplin via the File > Quit menu option, the keyboard shortcut to quit (ctrl+q / cmd+q), or the option to quit in the tray icon context menu. This is to avoid interfering with application restarts. The prompt will not be triggered by shutting down the OS or putting it to sleep / hibernating
3. If the sync of an eligible run of the sync is cancelled while in progress, the sync pending state will be cleared, and therefore will not trigger the prompt or another sync. The same applies when any kind of error is reported below the sync button, but this should already draw attention from the user and therefore not be much of an issue. The reason for not prompting the user in these cases is because if there is some kind of persistent error, it could become intrusive (and not useful) to the user if the prompt appears every time they quit Joplin
4. Note that after making a change, you have to wait about a second before marked as sync pending (due to de-bounce logic)
5. If there are no outgoing changes to sync when the user manually triggers a sync, or when a full sync triggers at the user configured sync interval, then quitting Joplin while the sync is running will not trigger the prompt. This is by design, to avoid being intrusive to the user when it is not necessary. The prompt will only appear when a partial sync is scheduled or in progress, or when the sync is manually run by the user while a partial sync was scheduled
### Testing
Testing has been done for the scenarios detailed in the implementation details above. Additionally, the following scenarios have been tested:
1. When sync is set to none, the sync pending status is not set to true when changes are made, and therefore will not show the prompt
2. When authentication for a sync target is not yet set up, the sync pending is not set to true when changes are made
3. When the sync target is changed in the configuration, the sync pending status is reset
4. When clicking cancel on the prompt, quit will be cancelled, when clicking yes on the prompt, Joplin will quit
5. I tested the new modal buttons work correctly by temporarily removing the automatic trigger of the sync when the modal opens, for testing purposes
6. Clicking the veil around the prompt does not dismiss it, so behaviour does not need to be tested
7. I tested escape will also cancel the quit in the same way as pressing cancel, and that if the prompt opens a second time after already being opened, that the sync is correctly triggered again and the application will still quit when completed
8. I tested that the prompt appears both when a sync (which was triggered by making change to a note) is scheduled or in progress
9. I have verified when the sync fails with an error (by forcing a failsafe error) that is correctly clears the syncPending state and does not get stuck in a loop
10. I have produced the 'There are more outgoing changes to sync, schedule the sync again' scenario in the synchronizer by triggering sync of many outgoing changes and typing in a note while it is syncing, then quitting the application before it completes. I verified from the log that when this happens, the hook in QuitSyncDialog will immediately trigger another sync (instead of waiting 15 seconds) and the app will quit after that sync has completed, where the dialog is still open
11. I have tested that making changes while a sync is in progress does not reset the syncPending status to false, due to the synchronizer producing a 'alreadyStarted' error. But the prompt will still appear when attempting to quit the app in this scenario
12. I have tested quit via the tray icon work correctly by building a release build of the app
## Summary by CodeRabbit
* **New Features**
* Desktop: Quit confirmation dialog appears when a sync is pending, offering "Quit anyway" or "Cancel".
* **Improvements**
* Quit flow now respects pending synchronisation, triggers a partial sync when needed, and only quits once handled.
* Menu and tray quit actions follow the updated quit-with-sync flow for consistent behaviour.
* App state tracks pending sync and dialog visibility for more reliable shutdown handling.
* **Chores**
* Updated project ignores to exclude generated/temporary GUI artefacts.
That’s great news, thank you! Will test.
Works well and as expected. Cheers!