I'm having a little trouble understanding why so many changes are necessary in the core of Joplin (particularly around sync). Shouldn't it be possible to detect conflict notes without having to get so deep in to the guts of Joplin?
It seems to me that the same thing can be achieved using a simple conflict detection algorithm along with a facility for merging any two files. In that case the plugin would suggest a file to merge with, but the user will be able to select any note that they would prefer merging with (or any 2 non-conflict notes).
The basic plugin that I mention above is exactly what you describe: a simple dialog facility that will provide a diff viewer to aid in merging the 2 conflicting notes. (Like you mentiones, Should be simple to generalize it to work with any 2 notes, not necessarily conflicting)
Why all the other stuff then?
My proposal was actually initially just about this basic plugin but then I had a hard time distributing the work over the 10 weeks because there's simply not much to do As you can see I now have it where the basic plugin will be done in only 4-5 weeks before first evaluation.
So I had to come up with some idea that I can work on after evaluation one until the end of GSoC.
I thought why not make a system that attempts to automatically merge conflicting notes via revision data. (Kinda how git works).
The problem with this idea is that Joplin's revisions were meant for backups and they're not consistent, like there's no guarantees that every sync will have revisions for the changes made and also there's no Revisions API I can access from the plugin so all that will need to be sorted first.
Why this specifically?
I honestly have no idea, I'm not even sure if such an "auromatic merge" feature would be useful or needed by the community. It's simply the only idea I could come up with to fill in the time.
Indeed we should avoid making changes to the synchronizer as there would be performance issues. And the current revision system wouldn't help you in this particular case.
Isn't it possible to get some auto-merging with two way diff? It doesn't have to be perfect, as the result would have to be reviewed and approved by the user anyway, but I think you could get something working.
In any case, a plugin that shows the two versions of the notes side by side with a way to manually merge them would already be very useful, and if it's well done with good test units and documentation it seems like it makes a complete GSoC project.
just wondering if #gsoc-projects:real-time-collaboration could be any help here, as there could be some conflict resolution necessary as well.
I'd say not, the whole point of real-time collaboration is to avoid conflicts while editing.
I've been trying to plan the UI/UX, and this is the initial design I've got in mind:
(Ignore the html code, just a placeholder...)
Pretty basic design for now.. However I'm still not sure how would it "open" best ? I was thinking at first to add a button to the screen which appears when you select multiple notes in one notebook:
However, this idea turns out pretty broken as we can't select notes across different notebooks. And ofcourse conflicts, our main goal of the project, show in a different notebook.
There's the obvious option of just adding Comboboxes into the dialog and the user selects the note from a list but I think this can get very messy with a huge amount of notes.
Do you guys have any suggestions on what would be the option that is best for UX ?
Do you think a live preview of the notes being compared would be beneficial at all ? Or just markdown would do the job ?
I find the option via the context menu or the tools good, because you can also search notes for comparison.
But it should also be possible to select the note in a selection dialog.
In a kind of autocomplete list (Which is dynamically loaded) that shows you the note and the path to it (
I think as a first target only a markdown comparison.
A preview would be nice, but have to be identical to the one in Joplin and if then the users still use css, this must be taken into account also the options from Joplin (
Maybe the plugin could detect that a conflict has occurred and show a popup notification. This may require a change to the plugin API
There is already a very mature UX for reference, please check the merge function of each Git visualization tool. . . Including VSCode, JetBrians IDE
In your proposal you had this:
A plugin will be created that adds a context menu option on conflict notes to open a merge menu. Once clicked a diff viewer will be shown to aid in merging the notes together.
So why are you discussing selecting multiple notes, adding combo boxes, etc. as that seems unrelated? The best UX is what you had in the first line of your proposal - you have a conflict, you right click on the note and there's a diff viewer. If something is missing to get that working, we can add the relevant plugin APIs.
My initial plan in the proposal indeed was that users would only click Compare on the conflict note and then the plugin will automatically find the other note and then show a diff tool.
JackGruber suggested, we can "generalize" the plugin a little to be a diff tool rather then just for Conflicts.. So you would be able to select 2 notes and compare them even if they were not conflicting.
So I was thinking about Jacks idea, but I'm not sure what's the best way to make the users select two notes at once.
So maybe users would right click on the note they want to edit and Click "compare with.." and then a dialog would show up to select which note do they want to compare with. The dialog will have a search box. I think this will work.
Right, sorry I missed @JackGruber's comment. What would be the use case for comparing two unrelated notes? Although I guess it's more like an additional goal and you should make sure it doesn't make the basic case (checking for conflicts on a note) more complex in terms of UX.
Two similar notes, which you may have from a clipped website, import, ...
This was just a question from me, since a compare of these notes is similar to a conflict note.
But this should not be a focus of the plugin, at most a strech goal and was only a thought of mine.
That would be good, I haven't had many conflicts yet, but it's quite easy to overlook the
Conflicts notebook when you have many notebooks.
Since all conflict notes should have a 1-to-1 assignment, you could select the appropriate note for the conflict note directly after clicking on Resolve conflict in the context menue or a menue shows all conflict notes and the user can select from this windows which he wants to compare.
Unfortunately I didn't see if the orginal noteId is assigned to the conflict note somewhere, because the field is_conflict only contains 1 or 0, you might have to adjust something for this when the noteId is currently not available.
I noticed this too. And was thinking about modifying the is_conflict field to be the noteId if it's a conflict and 0 otherwise I could also just add a new column/field but if changing is_conflict won't break anything I believe it's better then a completely new column?
You'd still need to change the column type to a string, so I'm not sure if it's better than creating a new column.
When i was reading the following comment: [quote="laurent, post:9, topic:17489"]
a plugin that shows the two versions of the notes side by side with a way to manually merge them would already be very useful [/quote], I though that the plugin may identify sections that are identical. Each sections may be associated with a checkbox, that could accelerate the manual merging of notes. A checkbox would be associated to identical sections (found in both notes) and unique section (found in a single note).
On the top of the view of the two notes, there could also be checkbox corresponding to each notes because in some case, a single notes may be the correct choice. This would adjust the lateral checking of box correspondingly in order to fit the selection made...
Something similar is already implemented if you check out the plugin There's going to be small buttons in between sections which you can press to move over the changed section from one to the other.
That's a good idea. Will consider adding it.
Ok, but it only is made for the case of conflict detected by joplin. The plugin cannot be used to seek possibly similar notes so that it would then apply its way of working in this case. Correct?
I just had one use case.
I had conflicts on my mobile app. But the mobile app does not allow plugins, and the conflicts folder is local to each instance.
So I created a temp folder and moved all conflicts there, for them to be synced. All this in the hope that the desktop plugin would be useful. It is not, as it is now.
So, I can see two approaches, and maybe BOTH are valid to implement.
- Expand or fork Conflict Resolution Plugin to a generic diff plugin, as others have mentioned here.
- Somehow, sync the Conflicts Folder. Not sure if this is viable.
- Another approach is to put conflicts in the same original folder, with a changed name. Dropbox does this, IIRC.