Support two variants of `LanguageStatusItem#text`

[jrieken]

The LanguageStatusItem#text properties is the text that shows when an item is pinned and when an item is rendered in the hover (as [ ]). There are cases in which it is hard to find a short text that works well for the pinned and unpinned case. We should explore to extend the API to text: string | { value:string, shortValue: string} so that both cases can be caters for

[jrieken]

fyi @DanTup

[DanTup]

I'm not sure if this will cover the case I had, but it might depend exactly what you're planning to show in the tooltip (for ex. will it include detail?).

Assuming with the new API we now have variables for text.value, text.shortValue, detail, would the display be:

• Pinned status bar: text.shortValue
• Pinned status hover: ${text.value} - ${detail}
• Unpinned entry: ${text.value} - ${detail}

If so, I think I could then use:

{
  text: { shortValue: "Android Device", text: "Flutter Device" }
  detail: "Android Device"
}

Which would give me what I want (the status bar text to show only the device name, and the tooltip/unpinned text to have both the label "Flutter Device" and the device name). It feels slightly odd that I'm essentially putting detail into text because I want the status item to show the useful part of the entry (not the label).

[jrieken]

If so, I think I could then use:

That would be as bogus as it is today. The text property is the important part and detail is optional. You should be using text: 'Android Device' or text: { value: 'Android Device', shortValue: 'Android'} (or use a device theme icon for shortValue)

[DanTup]

Putting "Android Device" in the text means the unpinned text won't have a label explaining what this is. Based on the current unpinned display, it seems like text needs to include a description of what the item is, not just its value.

I'm not currently using language status for this today because it doesn't do what I want/users expect. I guessed the reason for the ping above was because of #165940, but it doesn't seem like this change will address the scenario described there.

It's very possible I'm using this wrong, but the way we're currently using this feels good except for this one case (the device selection). Out other entries use text=description of item, detail=value and include SDK versions and the status of the language server:

(this screenshot is from that other issue where I'd tried to migrate the devices.. those are not currently in the shipped extension because it results in bad text when pinned)

Edit: I only just saw #165940 (comment), and this change feels less odd now I know I was using text/detail the wrong way around.

[jrieken]

@DanTup Is is that you are preferring the "Flutter Device - macOS (darwin)" layout/rendering over "macOS (darwin) - Flutter Device". Do I understand correctly that this makes you use text/details properties swapped wrt to the API semantics?

[jrieken]

I guessed the reason for the ping above was because of #165940, but

Totally, that issues became fuzzy due to various other asks and I wanted to do a focused effort.

[DanTup]

is that you are preferring the "Flutter Device - macOS (darwin)" layout/rendering over "macOS (darwin) - Flutter Device".

Yep, although that goes for all the items in the list not just this. I had assumed the text on the left was intended as a description of the value on the right, like:

Dart SDK - v1.2.3
Flutter SDK - v2.3.4
Flutter Device - Android Foo
Dart Analysis Server - Starting

However if other languages (and the intention) are the other way around, then I should probably update to be consistent:

v1.2.3 - Dart SDK
v2.3.4 - Flutter SDK [change]
Android Foo - Flutter Device [change]
Dart Analysis Server [restart]

This doesn't look as good to me, but I think I should be using the labels in the same way as others so in future if the layout changes, it doesn't look odd.