Show deletion progress indicator in UI

[sssoleileraaa]

Description

Depending on network speed, connectivity, and how many higher-priority jobs keep getting added to the queue, a source-deletion may take ~30 seconds, maybe longer, so I think we need a way to show that a deletion is in progress.

[ninavizz]

Adding to epic #650

[eloquence]

We discussed this at client sync today.

To recap, the goal is to handle deletion via the queue. A deletion is not finalized on the client until it is completed on the server, which can take a while, depending on network conditions and queue state.

Agreements:

• A source should not be fully deleted if it's not in fact been deleted on the server and the client yet.
• We would prefer to avoid a modal or similar blocking approach, because that is in conflict with handling deletion using the queue.
• Any design changes for this need to be scoped minimally to be achievable for beta.

Jen, Allie and Erik suggested an approach where sources are marked as scheduled for deletion. In this situation, the conversation view would show a placeholder screen (similar to the "Select a source" placeholder screen when the client launches), indicating that the source is scheduled to be deleted. The source list would likely include an icon indicator of the same status. Starring would be hidden or disabled.

Open questions with this approach:

1. What should happen if the client shuts down before deletion is completed, and then restarted (potentially by another user)?
2. What should happen when the deletion is completed?

@ninavizz wants to think on this a bit and offer some potential design ideas.

[eloquence]

Nina shared this exploration on Slack:
https://projects.invisionapp.com/share/FSV7J6456WJ#/screens/397210599_Hover

Crit planned for coming UX meeting, perhaps on Thursday 12/19.

[sssoleileraaa]

We discussed this again today and thought it would be a good idea timebox this to 4 hours. One complexity is that a user could select another source, which deletes and readds all the conversation widgets in the ConversationView. So if a user clicks away from the source that is in the process of being deleted and then clicks back we'll have to make sure the widgets continue to be disabled. I have had problems with changing the CSS of widgets that are disabled in the past, having to instead keep copies of widgets with images in disabled states that are swapped in.

So overall, I think the ideal way to implement this is to disable a couple parent widgets that disable all the children widgets, which have all updated CSS with our custom disable styling (lower opacity with a blue tone rather than gray tone), but I foresee some challenges given our design around the ConversationView and issues I've seen with Qt regarding respecting disabled state CSS changes.

A temporary solution (in the case of being blocked on a major refactor or some Qt issue) would be to have a gradient widget that spans across a source's ConversationView that is in the process of being deleted and make it so clicking on this toplevel widget does nothing.

Another possible temporary solution would be to wait until the source is deleted before allowing the user to click around in the client, so keep the deletion dialog open and close it once the deletion is successful or there is an error which we would show in the error bar of the client.

[eloquence]

Would it be simpler to show a text to the effect "This source is in the process of being deleted" (in the same large font we use for other placeholder text e.g. on launch) in place of the conversation view, for sources in that state? While it's nice to be able to still see the content, it's IMO not critical for beta.

[sssoleileraaa]

yes, this is a good idea for a first iteration and it's much simpler ^

[eloquence]

This issue is now outdated, closing; we're investigating the progress indicator for pending deletions again in the context of the Safe Deletion feature (#1202).