Tweak Conflict Resolver to be more clear

[Nerdy314159265]

I don't know how to put this into words exactly or what exactly is wrong with it.

However, every single time, without fail, I use the conflict resolver, I pick the wrong option. I have absolutely no clue why or how I'm picking the wrong file every time but I definitely am.

I recently had to migrate the server that was running my main Syncthing instance and it had gotten rather out of date.

In the process of re-syncing file conflicts occurred (not entirely sure why, I'd expect them to just update based on the other devices).

I go to fix the conflicts decide that it should clearly be the most recent files that are the correct ones, so I select them and select most recent. Broke everything.

I also have tried to gauge which device created the conflicting file, if it's the device that I was actively using then I select it and break everything.

I don't know if it's how the information is listed and I wrongly associate it with the wrong file/option or if there is something unclear about what the conflicts are in reference to (e.g. are the new files the ones getting marked or are the out of date files getting marked) but each time I've had to fix conflicts it feels like I'm being pranked.

[fdutheil]

Hello.
Same here, I know the version of the files I wanna keep (local or remote version, related to a firefox profile), but I always end up with the wrong ones (workflow: selected all files then made a choice).
I first thought the french translation was misleading or completely wrong, but it seems it's "well" translated after all.

It's a "major" issue still eady to fix :)

[Oktayey]

The same confusion just happened to me. I guess I got tripped up by intuitively assuming the two dates shown were the different modification dates for the two files.

Luckily, I noticed that the file I thought the dialog was saying is older was larger in size than the newer one, which wouldn't make sense in my case. After being perplexed for several minutes, I realized that the bottom date didn't indicate the modification date of the bottom file, but rather, the time the program found the conflict between the two files. That function fits the label "Conflict Created" more closely, but I guess I assumed it was just an awkward translation because the layout strongly suggested the two dates were for comparing the two files in question, at least in my eyes.

[leaumar]

I came here because I just got tripped up by this dialog again too and it resulted in me losing keepassxc credential updates earlier today, so I decided to not shrug it off this time and dig into what's confusing us all. I understand the dialog (at least for one possible case of a conflict) and syncthing's conflict behavior a little better now, and know what my (and probably your) mistake was. @Oktayey was on the right track. I hope this helps others understand the dialog while giving the devs an idea to make it less confusing.

Before going into details, I'd like to make my 2 concrete suggestions to the devs to improve the UX of this dialog. I know you don't make syncthing, I'm only suggesting you improve the synctrayzor UI :)

• move the Conflict Created date somewhere to the side and fill its place with the Modified Date of the conflicting file of which the Name and Size are to the left and right. Right now this looks like a row by row comparison of the 2 file versions, but the middle column isn't. The label is technically completely correct but placing it there just clashes with the intuitive layout around it.
• move the Modified By label to the top row because that's the row describing the file as modified by the host in question. The bottom row describes the original version that's still on the current machine (but renamed to a conflict filename) and was not touched by the remote host, so the remote host label does not belong there.
  • for my fellow victims: when you get the conflict popup, the original file on disk has already been replaced by the latest remote version, and the original that was on this pc has already been renamed to *.sync-conflict, not the other way around. Syncthing's not asking if you want to accept the remote changes but if you want to revert to the old file this host had until just now.
• perhaps add a note in the dialog that syncthing has already accepted the network version, that choosing the conflict file means rejecting the remote changes and restoring the version that's on the current host. Intuitively most people probably assume the conflict file is the incoming remote version and the local file hasn't been touched/renamed because of the conflict. Or make this clearer on the buttons or something. I'm really tired and gonna stop writing/editing now.

Let me describe my case:

1. starting point: home pc, nas, and work pc in sync
2. friday night I updated a file on my home pc and synced it to my nas, but my work pc was off and did not get the update
3. this morning I started my work pc
   • it failed to connect to my nas and did not get the updated file
   • I made other changes to the same file on my offline work pc, creating the actual conflict by making 2 "child" updates of the same "parent" file within my net, but syncthing had no idea yet
   • I fixed my connectivity and got the conflict prompt on my work pc, and accidentally picked the work pc version, meaning the update I did on friday was lost. I fixed the file and synced it to my nas, assuming my home pc would accept this version from the network when powered up
4. I just turned on my home pc and got the conflict prompt again, and took a real good look at it

Below is what I now see on my home pc after starting it, where I last made changes to my file on friday and to which my work pc is now trying to push an update I did this morning after rejecting the home pc's version. Now it's easy to see the Modified By label is in the wrong place, while the "conflict file" is the version that was on the current host, not the incoming disputed version from the network.

[leaumar]

I just realized this project appears abandoned... #795