Mark folders which are not accepted by remote

Development
1

I want to develop a small UX improvement regarding whether a shared folder is actually syncing with a remote device. Currently, only the remote device completion permanently being less than 100 % indicates when it might not have accepted the folder. I’d like feedback on several aspects before starting off with an implementation.

The information is already available while a connection is active, because we can track missing entries in the remote’s ClusterConfig messages.

UI Integration

a. My minimal approach to present the information would be appending an asterisk mark to entries the “Shared With” device list where we know they are not sharing back. Same under the “Folders” list for each remote device. Might need hovering for the tooltip to see all of them.

b. Add a new field below said entries titled “Waiting to Accept” (or similar) and listing the respective devices / folders again. The line is hidden like others without content.

c. Open for other suggestions. They should be rather low-profile IMHO as to not really disturb the user, as this is usually a temporary condition where no action can be taken locally.

d. Longer-term such info about the cluster connectivity / density / health could be summarized into a new dialog, as sketched previously. Mainly as a “task list”, but maybe even with an interactive graph showing the relationships.

API Extension

a. As this is kind of the inverse of the /rest/cluster/pending/* information, I propose a new /rest/cluster/unaccepted endpoint to list the device / folder ID combinations we know won’t actually exchange data, possibly augmented by the last ClusterConfig timestamp that assumption is based on.

b. Alternatively, the /rest/system/connections endpoint could be extended with a list of unaccepted folder IDs. Kind of makes sense because the info is always based on an active connection. But I’d prefer to keep it semantically separate from the connections hodgepodge.

A related question is whether we want to update the list on the UI (client) side using a new event type, extend the existing PendingFoldersChanged event or just fetch the endpoint data again when a connection is made / closed / replaced (don’t think there is a separate event type?).

Internal Model Representation

a. We already have a remotePausedFolders map[protocol.DeviceID]map[string]struct{} // deviceID -> folders with a similar purpose, which could be mirrored to remoteMissingFolders map[protocol.DeviceID][]string. It gets updated from the ClusterConfig() receiving function or from Closed().

b. There is also a cache for helloMessages map[protocol.DeviceID]protocol.Hello, why shouldn’t we add the same for clusterConfigs map[protocol.DeviceID]protocol.ClusterConfig? This could be used to feed other API endpoints depending on the information without much processing (remotePausedFolders, pending folders or the suggested “candidates” feature, possibly others) without introducing purpose-built data structures for each one.

Note that this information depends on the remote being well-behaved regarding their BEP ClusterConfig messages. But if they don’t announce the folder back, I think synchronization already won’t work.

Please let me know what you think about the above design choices. I want to avoid long discussions after much work has gone into a PR, as we had in the past.

1 Like
2

This seems like a worthy goal. In order to not keep more state than required I’d suggest maybe replacing the remotePausedFolders map with something like a remoteFolderState map which has values of a folder state type (Valid, Paused, Missing or something like that). (If Missing is the default you might even get the correct accounting automatically just by way of not having set either Paused or Valid when we got the cluster config.)

As for the API… I’d first look to extend something existing, perhaps the folder completion API which already asks for status for a given folder on a given device. If we could get away with just adding a boolean there, that’d be fine.

3

Why not store the whole ClusterConfig message then, where both Paused and Missing state can be identified dynamically when needed?

4

Because storing the info we need is better than deriving it from first principles on every use?

1 Like
5

Suggested implementation:

I went for brackets around the folder / device name in the GUI, with a short explanation in the tooltip. Otherwise pretty much following the suggestions from @calmh, hopefully :wink:

One caveat I’d like feedback on here: Right now, the implementation causes disconnected / paused devices to show all their folders as not accepted. That is probably not helpful and should be reverted to just not marking them specially? So we only add markings where we have up-to-date info and it’s the “wrong” / intermediate unaccepted state.

1 Like
6

Maybe the following would be options that is pleasing to the eye:

  1. Option A:

    [=| ] for not having been accepted at remote. (The font in the forum here makes the right side smaller than it should. Imagine another “spacebar”.

    [=|=] for having been accepted at remote

  2. Option B:

    [ ] for not having been accepted at remote.

    [x] for not having been accepted at remote.

Examples:

exampledevice [x], exampledevice [ ], exampledevice [=| ], exampledevice [=|=], exampledevice [x], exampledevice [x], exampledevice [x], exampledevice [ ], exampledevice [x], exampledevice [x], exampledevice [x], exampledevice [x], exampledevice [=|=], exampledevice [=|=], exampledevice [=| ], exampledevice [=|=], exampledevice [=|=], exampledevice [=|=], exampledevice [=|=], exampledevice [=|=],

While Option A seems semantically proper to express accepted on home and accepted on remote, it kinda looks off. I personally would favour Option B or simply brackets, as Acolomb proposed.

7

Thanks for your suggestions. However I think adding anything after device / folder names where the connection is alright would be distracting and should be avoided. Let’s keep the feature out of users’ way as far as possible, only to aid in diagnosing sync issues mainly.

1 Like
8

In view of the concern about GUI clutter, you could perhaps treat this as normal tri-state notification. Something like:

Not shared: empty square Share offered: square with tick, no background colour Share accepted: square with tick, green background

This is simple, unambiguous and should be reasonably clear to users. And it leaves detailed explanations where they belong; in the Documentation.

9

Do you mean in the “Edit Device” / “Edit Folder” dialogs? Maybe take a look at the linked PR and its screenshots. I was primarily talking about the list that is shown directly in the foldable device / folder details. Though by now the PR implements both places with brackets around the device / folder name.

Having tri-state check boxes seems confusing to me, because it suggests that the user has control over the third state. And it can’t be mirrored to the list where no check boxes are present at all.

10

Thanks for this helpful improvement (see #8310).
At the moment the “²” is hard to spot, especially in combination with folders like “Files 2022²”

Suggestions for marking the remotely paused folder:

  • (colored) pause icon,
  • different colored text
  • strike through text
  • add a second line with “[icon]: [device A], [device B]” to make more clear distinction
11

It would be nice to be able to see some kind of a mock-up with all those options applied, so that it would be much easier to judge how each of them really looks.