Allow more control of the status bar text for a LanguageStatusItem

[DanTup]

I'm trying to adopt the LanguageStatusItem API for some things that were previously just standard status bar entries, however the way the text is rendering makes it a much worse experience than before even if when items are pinned.

For example, in Flutter we currently show the selected device on the status bar:

There's a tooltip that tells you how many devices are connected. It isn't prefixed with "Flutter" because that consumers more space.

Using the new API, it's natural to set text to something like "Flutter Device" and detail to the device name:

However if you want the original behaviour and you pin the item, you just get "Flutter Device" and not what you really wanted:

And if we just set text to the device name, then the main flyout doesn't look so good because it doesn't have a description of what it is.

It would be nice if we could control the status bar text separately, otherwise we have to decide between a better experience, or users being able to collapse the item into the flyout. Right now for Flutter devices it feels like status bars are better (even though I'd like for users to be able to move it into the flyout).

Slightly related (and I can raise separate issues if worthy), things I'd also love:

• Add tooltips
• The ability for text/detail to be display like columns rather than just joined with a hyphen. The current layout in my screenshot above looks a bit messy and I think would look better if the detail fields were all lined up.

[isidorn]

While talking to extension authors that have adopted to the language status the feedback that I usually got is that some functionality is missing. Since most of the extensions have now shipped the language status bar, I would like us to revisit this, and see if you all feel like something is missing still.

So can you please share what exactly you are trying to achieve that you can not with the current language status bar? Based on each scenario we can decide if that truly belongs to the status bar and if we need to add functionality so you can all achieve what you want. Thanks all 🙏

@DanTup @bobbrow @AlexandraKemperMS @luabud @brettcannon @akaroml @maddymontaquila

[DanTup]

My main request is still what's written above. The Flutter device selector is still not part of this because of the above (we can't get text that looks good both in pinned/unpinned mode).

It could also be nice if an extension could set defaults for which items are pinned - for example I suspect most Flutter devs would still like the device selector pinned, but for those that only use a single device type might want to fold it away. By not providing this, extensions are motivated to just use standard status entries if they think that's a better default, and that prevents the user from folding it into the language status menu.

[bobbrow]

100% agree with @DanTup.

• Having a separate text property for the pinned item would solve most of our issues.
• Having a way to set the default pinned state would allow us to put an item back in the LanguageStatus that we had to remove because our A/B experiment showed less engagement with it after putting it in the flyout.

[isidorn]

Thanks all. This is very helpful. Let's assume we add these two capabilities from @bobbrow comment above.

• What is the exact text that you would display when pinned vs what text when not pinned?
• What items would you pin by default?

Specific examples would really help!

[DanTup]

What is the exact text that you would display when pinned vs what text when not pinned?

For me, I want to show the name of the current device when pinned ("Pixel 4a (android)") and show a label alongside it when in the popup menu ("Flutter Device - Pixel 4a (android) - [Change]"). Today, the first label is used in the status bar so we either don't get "Flutter Device" in the popup menu, or we get "Flutter Device" in the pinned status bar).

What items would you pin by default?

Just the Flutter device for me. Everything else is already in the popup. It's very convenient to be able to glance and see what device is selected before you hit F5 to run.

[bobbrow]

For us, we generally want descriptions in the flyout and icons or something less verbose pinned in the status bar. Right now we have to put both in there because we don't know what the context is.

We would pin the "Win32" (active configuration) item in the status bar. In the flyout we would be able to have the description visible as well.

[testforstephen]

@isidorn from the perspective of Java extension, the main issue for us is that it only shows the status view when the relevant document is opened in the editor (e.g., a Java file or a build file such as pom.xml/build.gradle is opened). If no relevant file is open, the status view is hidden. This can make users unaware of the Java extension’s activity in some scenarios. For instance, when users open a Java project, Java extension automatically imports the project, downloads the dependencies and builds the workspace. However, if users do not open any Java file, they cannot see the background activity of the Java extension.

To enhance the user experience, we have two requests:

• Allow extension to set the status to be pinned or unpinned by default.
• The pinned status should always be visible in the status bar, regardless of the current open editor.

We have a general icon 👍 to indicate whether the Java language server is running. We would like to make it pinned by default if the requests above are supported.

[DanTup]

If no relevant file is open, the status view is hidden

This bugs me slightly too. I think in part it's because the design is that this is "language status" so it's attached to the language status item, but some of the things we end up putting in it are "project-wide". For example in Dart we show the language server status and for Flutter we show the select device. These are really Dart/Flutter project items, not specific to a file or the language of an open file. It seems odd that they become inaccessible if you don't have any files open (even though you have a Dart/Flutter project open and things like the LSP server are running even without any open files).

[jrieken]

the main issue for us is that it only shows the status view when the relevant document is opened in the editor (e.g., a Java file or a build file such as pom.xml/build.gradle is opened). If no relevant file is open, the status view is hidden.

That's the major objective for introducing the language status API and something we have not planned to change. The rule is that all project specific things should go left and editor specific things go right. Long running init-operations should use the Window progress location.

Using the new API, it's natural to set text to something like "Flutter Device" and detail to the device name:

We are listening but I have trouble understanding why it is such a big deal to then use the API the "other way" around, e.g use device name for text and detail for the descriptive part. The hyphen might not be the best UI but the arrangement of "<primary_label> <secondary_label>" isn't novel, e.g quick pick puts the "important" part before the detail part. So, we could experiment with other styling/separators here but I am a bit reluctant to add a new API for 'pinned text' because 'text' is meant for that.

[DanTup]

The hyphen might not be the best UI but the arrangement of "<primary_label> <secondary_label>" isn't novel, e.g quick pick puts the "important" part before the detail part.

Ah sorry, I never realised it was intended to be this way. The names text and detail felt to me like "label" and "value" so I had assumed it was intended to be the way I had it. However, I now see that TypeScript has it the other way:

So if this is how it's expected to be used, I will swap Dart around for consistency (although FWIW I do think it looked better the other way).

(apologies for not seeing and responding to this before #192880 - the proposal there makes more sense now I've seen this)

[akaroml]

the main issue for us is that it only shows the status view when the relevant document is opened in the editor (e.g., a Java file or a build file such as pom.xml/build.gradle is opened). If no relevant file is open, the status view is hidden.

That's the major objective for introducing the language status API and something we have not planned to change. The rule is that all project specific things should go left and editor specific things go right. Long running init-operations should use the Window progress location.

Great point. It's super helpful to clarify what fits and doesn't. This picture shows three use cases.

• Show Build Status is the visualization of the long-running backend build task status. The status bar is the ideal place because we want to help users understand that the server is busy building and set the right expectations that it may not respond to requests timely.
• Open Config File is the project-level info (not specific to the active editor). So it's supposed to be pinned to the status bar by default. But the same file is accessible from many entries (File Explore, Maven/Gradle Explorer, Project Viewer). So maybe we don't need another entry.
• Configure Java Runtime also looks like project-level info, but it also has a close relationship with the active editor. So to me, it's a mix. The JDK configuration has been one of the most complained areas and deserves high visibility.

Another thought is that the physical appearances of different visualizations result in different visibilities. Something that appears straight in the status bar gets more attention than the ones folded into the language status. So we can consider the attention level we want to have when deciding. @testforstephen