I’m often tapping into the situation that after I remove a folder on a peer and then delete or move the data somewhere, this folder recreates itself and the folder pops up again in my GUI on that peer. Obviously because deleting is not automatically adding it to the ignored folders, so they popup again.
Would be great if deleting a folder is automatically adding this folder in the ignored folder list. Everything else doesn’t make sense from the perspective of a normal user and is for me an unnecessary extra step.
Don’t agree. Someone might just want to drop any stored information about a folder or move it to another path, in which case they want to readd it shortly after. I think it’s less surprising in your use case to remove a folder and then ignore it in a prompt, than in one of my use cases to remove a folder and then having to go to settings to remove the folder from ignored folders (which one might not be aware that it even exists).
Well a second prompt (after “Do you really want”) would be fine too, if I want to ignore this folder. That would give to flexibility everyone needs :)! Or 3 buttons on the first prompt: No, Yes and ignore, Yes and dont ignore (labels - for intuitivity - can be discussed).
But less experienced user will probably like to get rid of this folder when they press delete, not moving it in a random unknown short time to another place and recreate the folder manually via GUI before its popping up again automatically. And I think being mainstream compatible and saving time for experienced user is a nice goal for this project
One deletion Popup -> One click for either “Delete (and wait for recreation)” and “Delete (and prevent recreation)”. Maybe this issue applies only if you delete something on an introducer node, as there is no popup to accept a “new” shared folder. It’s just getting added. But using an introducer as “master” is the only way to have a real dropbox replacement setup (it act’s like the central dropbox server, containing all folder, and can be backed up).
I am disagreeing with adding the folder to ignored ones being a good idea, as it’s definitely unexpected that once I remove a folder that it takes so many steps to get it back.
All of your suggestions seem to optimize for your use case (which seems like introducer with autoaccept).
Sadly, I think your usecase too niche to warrant UI changes, and would cause confusion for the rest of the users (as it adds options where there should not be options).
If you are not using autoaccept, then surely pressing ignore next time it comes up is easy enough.
No folder is added automatically as you claim, unless auto-accept is enabled.
I agree with the general point (anything automatic is definitely bad and the use-case is pretty specific). However I think in the confirmation dialog after removing a folder it would not be UI bloat to add an “ignore” option to the existing “yes” and “no”. This seems like a nice convenience feature to me, because in practice the folder addition banner will not pop up immediately, but only after the connections has been dropped, re-established and the cluster config exchanged. So I wouldn’t be opposed to a contribution doing that.
Actually I just changed my mind, as apparently not even I did fully understand what ignoring a folder share invitation does: It’s on device level, i.e. it ignores that a specific device wants to share that folder with us. It does not ignore a specific folder for all devices. And the prompt is a good notification that you should probably modify the settings on the device wanting to share the folder (if you ignore, the other device will be perpetually confused why you won’t talk to it).
Is an introducer equals to auto-accept? Because afaik I didnt change a setting here.
This is an interesting statement as my described use-case (also in other issues) just wants to make syncthing more dropbox-like from a users perspective. And dropbox is for a good reason so successful. It’s easy to use (intuitive behavior and GUI), efficient in sync and reliable. Syncthing just needs a bit more intuitivity and GUI/file system integration. And if there is one or more hoster one day providing a master node with private relayserver and backup, it can become a real open source dropbox alternative for the average user.
Neither me This sounds like a bad impact.
Is this simple conclusion correct then? It’s not possible and will be not possible to delete a syncthing-folder from an introducer then (as long as it exists on peers of an introducer)?
UPDATED conclution:
It’s not possible and will be not possible to delete a syncthing-folder from an peer with “auto-accept folder” then (as long as it exists as shared on peers).
We really need need to make sure we don’t mangle “introducer” and “auto-accept” here, those are different concepts. Introducing is just about devices and auto-accept about folders.
You can always remove folders, regardless of any introducing. If as you describe a folder (not the share request at the top) pops up automatically, you did modify the “auto-accept” setting. That’s another story then: If you are set to auto accept folders from a remote, and you remove such an auto-accepted folder, it will indeed be readded immediately. And that’s expected, after all by setting auto accept, you stated “I want all folders from that device without any user interaction”.
This sounds like a bad impact.