General purpose progress monitor extension

[JPinkney]

Hi,

I'm in progress of creating a general purpose progress monitor extension that will show events that are happening in the workspace. Its gotten to a point where I think we should discuss the features that this extension should have as well as the different places that we can leverage the extension.

From Red Hat side, we are interested in using it to display jdt.ls progress reports to the user. This allows us to maintain more transparency with the user with whats going on inside jdt.ls.

It was made as a general extension because I believe there is other places that can leverage this.

The extension currently has a status bar item that tells you whether or not something is in progress, a progress view to display what results are happening, and a simple way to create/update progress bar items.

If it helps to visualize, the progress monitor will be reminiscent of the progress in eclipse.

Currently the progress item corresponds to this interface:

export interface ProgressReport {
    id: string;
    task: string;
    subTask: string;
    status: string;
    workDone: number;
    totalWork: number;
    complete: boolean;
}

Let me know what you think/opinions on this!

[svenefftinge]

Sounds good! No cancellation for now is fine, too.

Would be nice to see the list of running progress items when clicking on the statusbar item.

[simark]

Hi @JPinkney! I had something in mind for some time for the UI part of the notifications/progress reporting, so I thought I would share it. It sounds like we are on the same page with you and @svenefftinge, but I thought it wouId be good to put what's in my head in written (and pictured) form, so we can discuss it. Basically, I think we could have a notification/progress widget that essentially mimics the Android notifications (I never used the other mobile platforms, so I don't know how they work). It offers various kinds of event and progress notifications that cover pretty much all the use cases. For example:

• Instantaneous events (e.g. "Failed to read X")
• In progress tasks that would disappear when done (e.g. "Updating package list")
• In progress tasks that would stay when complete, because it's of interest to the user (e.g. "Cloning git repository xyz.git")

Instantaneous events and tasks with progress that are done are clearable, meaning you can get rid of the notification. In-progress items are not clearable, but eventually could be cancellable.

Clicking on the status bar item would pop-up a floating window containing these elements. Clicking a notification could open a relevant view or file. That pop-up window would disappear when clicking on a notification or somewhere else in Theia. The idea is that it's easily accessible, but does not stay in the way.

Here's a mockup of how it looks in my head:

Clicking that "Clear all" button would only get rid of the finished "Cloning git repository" notification but would not interrupt the build. Just like clicking "clear all" in the Android notification center would clear a "Download finished" notification but would not remove/stop a "Downloading..." notification.

[svenefftinge]

cc @AlexTugarev I remember you wanted to overhaul the notifications we have. Would it make sense to allow them having a progress bar?
Here's the latest state of VS Code explained https://code.visualstudio.com/updates/v1_21#_new-notifications-ui

[svenefftinge]

We should also make sure that the design is close to
https://github.com/Microsoft/vscode/blob/master/src/vs/vscode.d.ts#L6171
So it can be supported in the new plug-in system. cc @benoitf

[AlexTugarev]

@svenefftinge, yes, we discussed the progress feature once. And I still see good use cases to prefer such lightweight indicators. In other cases it’s preferable to reveal such a view.
BTW, the notification issue is #1360, and it aims a similar feature set as vscodes solution. I can push my early prototype soonish.

[svenefftinge]

@JPinkney and @AlexTugarev can you please sync on this?

[AlexTugarev]

@JPinkney, I'd like to share my personal opinion first, then start with collecting options.

At least form JDT's perspective it's a good idea to show progress as it works heavily in background. I'm not sure how chatty other components are on that level of protocol. For our own tasks, especially for running on the backend this is quite interesting. If we would have lots of LSs reporting progress, or any other tools, I think a Progress view would be great. The unified statusbar item showing the progress is really helpful, as demonstrated by status report of Java LS!
I'm a bit concerned about using an Eclipse IDE-like view to show all progress items. Maybe I'm wrong, but I expect it would show only few items for the most of the time and therefore waste screen estate.
Another point is, that if there would be mostly background tasks reported, and into that view we would coerce user notifications with progress, which might have a different value to users, it would be harder to find those items, e.g. mixing "Building workspace", "Compiling", "Downloading Document.pdf", "Git: Fetch...".
From the discussions on progress reporting in user notifications it's worth mentioning, that progress could be part of an interactive dialog, which could potentially include more actions. And separating progress reports into a different widget might not work UX-wise. It depends on the task, right? No one wants to see a toast poping up and showing "Building workspace 2%".

The unified statusbar item would be awesome! Let's think about how we can move forward with progress and notifications to have a nice solution.

WDYT of having a floating widget for the list of all progress items as suggested above? Or maybe even a very similar representation to the items in the notifications center? The items could be navigable with keys and so forth. We can iterate on the UI components and APIs together.

[JPinkney]

I'm a bit concerned about using an Eclipse IDE-like view to show all progress items. Maybe I'm wrong, but I expect it would show only few items for the most of the time and therefore waste screen estate.
Another point is, that if there would be mostly background tasks reported, and into that view we would coerce user notifications with progress, which might have a different value to users, it would be harder to find those items, e.g. mixing "Building workspace", "Compiling", "Downloading Document.pdf", "Git: Fetch...".

Agreed, it seems like the Eclipse IDE-view approach isn't really good because it emits only a few items at each time and probably isn't worth it considering everything you listed above.

And separating progress reports into a different widget might not work UX-wise. It depends on the task, right? No one wants to see a toast poping up and showing "Building workspace 2%".

That was why I originally thought of the view in the first place. The constant spam of notifications would be annoying when a user is working with java.

WDYT of having a floating widget for the list of all progress items as suggested above? Or maybe even a very similar representation to the items in the notifications center?

Do you mean the UI @simark posted? Because I would be ok with supporting these:

Instantaneous events (e.g. "Failed to read X")
In progress tasks that would disappear when done (e.g. "Updating package list")
In progress tasks that would stay when complete, because it's of interest to the user (e.g. "Cloning git repository xyz.git")

[AlexTugarev]

Do you mean the UI @simark posted? Because I would be ok with supporting these:

Instantaneous events (e.g. "Failed to read X")
In progress tasks that would disappear when done (e.g. "Updating package list")
In progress tasks that would stay when complete, because it's of interest to the user (e.g. "Cloning git repository xyz.git")

Well, AFAIK the notification center of Android would actually be a widget to host all kind of user notifications and progress items. If we separate general progress items from user notifications (which popup), we would not distract users, right?

OTOH, the UI mock of a floating widget could be nice! The statusbar item could be borrowed from Eclipse.

[JPinkney]

If we separate general progress items from user notifications (which popup), we would not distract users, right?

Yes. So in this case we could have progress and notifications shown in different views? I'm guessing notifications would become the vscode style but how should we go about showing the progress? Widget pinned to status bar that on click opens a small UI, some sort of view at the bottom like Eclipse (that I think other then java wouldn't be used very much), or some sort of other thing.

[JPinkney]

@svenefftinge @AlexTugarev @simark WDYT about something like this. Personally I think we should have progress and notifications completely different so this item would only be showing the progress whereas this would do notifications. The status bar item would only appear when there is some sort of progress being contributed to the progress monitor to stop the progress monitor from crowding the status bar.

[simark]

@svenefftinge @AlexTugarev @simark WDYT about something like this. Personally I think we should have progress and notifications completely different so this item would only be showing the progress whereas this would do notifications. The status bar item would only appear when there is some sort of progress being contributed to the progress monitor to stop the progress monitor from crowding the status bar.

That would be fine with me. The idea I'm the most attached to is to be able to quickly pop-up and dismiss the progress monitor/view, your proposal still achieves that.

Could you describe a bit your mockup? What is the difference between the two progress monitor, in which situations would we see what?

[JPinkney]

Ah yes, I should have expanded. Essentially you contribute where the progress is coming from (such as java or git) and then you would add your progress to that corresponding node. For example, if the java extension is getting a progress report notification you can create the java contribution and then contribute the progress report to the java contribution.

The left progress monitor in the picture shows all nodes in the tree collapsed to make it simpler to see which parts of theia are contributing progress at the current time.

The right progress monitor in the picture has the java and git contributions expanded so that you can see more details of whats currently going on inside those areas of theia.

I've put the two side by side to make it easier to see what the collapsed/open views of the progress monitor may look like in comparison to each other but they're just two different views for the same thing.

[simark]

The left progress monitor in the picture shows all nodes in the tree collapsed to make it simpler to see which parts of theia are contributing progress at the current time.

The right progress monitor in the picture has the java and git contributions expanded so that you can see more details of whats currently going on inside those areas of theia.

I've put the two side by side to make it easier to see what the collapsed/open views of the progress monitor may look like in comparison to each other but they're just two different views for the same thing.

Ok, I thought the left one was the case where you had nothing in progress, and you were left with only the "categories" (or contribution, in your words). So when a contribution has no more progress item, it disappears?

[JPinkney]

So when a contribution has no more progress item, it disappears?

That was my current idea. I feel like it might be fine to keep them if its just used in theia internally but if extensions also wanted to contribute items it could end up with a really long list of items with no progress and would be harder to sift through.

[AlexTugarev]

I really like the focused approach here! The mockups (plus explanation) helps to get that idea.

One thing, why is it necessary to create a tree for that widget? You could start with a flat list, and prefix the items with the names sources. For instance:

Git: Pull from origin ...        50%
Java: Building workspace ...     10%

We could add a filter-on-type in the following steps, if we need to focus on a bunch of those.

I propose this, as I see that it would add additional clicks to expand the nodes for the (assumingly) most common case. And please correct me, if I'm wrong, but how likely and often is it, that a user would see ten or more progress items?

[akosyakov]

Have you analyzed VS Code approach? The progress bar looks like that for notifications: microsoft/vscode#22388 (comment)

They don't have a single progress widget but can put progress indicator at different locations. For now, VS Code API allows the following locations: a window (the main area), a notification and sourcecontrol (the git view). They plan to add more locations. We will need to support it to cover VS Code API eventually and also to look familiar for devs used to VS Code.

[akosyakov]

@JPinkney @AlexTugarev @simark could you claify #2299 (comment)

How #2461 is going to match VS Code APIs? Are we going to implement another progress extension to be aligned with VS Code behavior?

// cc @svenefftinge

[AlexTugarev]

@JPinkney, @akosyakov, I've to admit, I missed #2461 :-(

for vscode API, there is a PR to implement window.withProgress #2979.

[JPinkney]

Hi, I think the general purpose progress monitor and VSCode api window.withProgress serve slightly different purposes. My solution: #2461 was for longer living progress items that continuously report their status such as the Java Language Server. From my understanding with window.withProgress once a progress item is finished completing the progress item stops showing.

The problem with using window.withProgress with the Java language server is that progress reports come through all the time so there would be a constant notification reporting the status. Technically, you could display the progress report on the status bar like vscode-java does but then you're only limiting yourself to seeing one progress item at a time.