Contribute to the language status

[isidorn]

Hi 👋

Currently the Python extension contributes individual items to the status bar. On my macOS I see the Python version being used on the left side (picture). There might be other items?
I suggest to use the language status bar, Typescript is already using this (picture attached).

This way all the Python status bar items will come under a common item making the whole status bar experience cleaner for our users.

The status bar items which are actually progress our current advise is to use the withProgress-API. With that you announce a long running thing to VS Code. Our current thinking is to add a new progress location which is the extension’s language status. With that we can render something on the composite item as well as on the item itself. This is being discussed here, please chime in.

fyi @brettcannon @jrieken

[brettcannon]

I contributed to the discussion at microsoft/vscode#129037 (comment) where I mentioned what we need in order to adopt the API wholesale (we already use it on web and plan on using it for virtual and untrusted workspaces as-is). @karthiknadig plans to bring up our use-case at the next API sync.

[isidorn]

@brettcannon thanks. I missed your comment in that issue, sorry about that.

I agree that it might be a shock to the user that in one milestone we move to the right and move it inside the language status. Due to that I propose the following:

1. This release simply move your status bar contribution to the right. I see you have explained the reasoning why it is left here but I think we should just change this
2. Listen to user feedback
3. After we hopefully see that the users did not really get alarmed by this change, move the item inside the language status in the following release

Typescript only got the first complaint about this change 2 months after the release. So it was smooth sailing, let's try to do the same for Python :)

[brettcannon]

I'm afraid the level of detail that users need to have about their environment for Python is bit more nuanced and extensive than TypeScript (e.g. if we stopped showing the Python version by default I would be very upset as a user, same goes for the type of environment as users very often have multiple Python versions installed and care whether it's a virtual environment or global install that got automatically selected for them), so I don't think we can equate their experience to what ours would be unfortunately.

We can talk about moving to the right sooner rather than later, but it will require updating a ton of screenshots so it isn't a quick fix. I would rather not try to squeeze it into this iteration unless open capacity shows up unexpectedly.

[brettcannon]

Moving to this is also already in the deferred items list in our iteration plan, so we do hope to tackle this in the upcoming iteration.

[isidorn]

Next iteration would of course work, I missed that this might require to update a lot of screenshots.
Once we do that we can discuss the language status and what capabilities we might need to add for Python to adopt to it.
Thanks a lot!

[karrtikr]

• Move status bar item to the right
• Look into all the screenshots we need to update
• Discuss with VSCode about the capabilities we may need, like pinning.
• ...TBD

[karrtikr]

I attempted to do a basic move

@isidorn Right now it appears weird as it "Python" appears twice. I see that each status bar item has a priority number attached to it, can I set such a number which ensures it always appears next to the language status item? In that case we can simply remove "Python".

[isidorn]

@karrtikr thanks for giving it a try!
Yeah, I think you can and that is exactly what Typescript is doing (once the user pins the typescript version there is no duplication).
As for what is the exact right priority number for this @jrieken might help.

[jrieken]

There is no exact priority number because it's an open system for all extensions. Tho, we want to ensure that pinned language status items are always directly after the language name. So, how about using the new language status API and then we discuss if pinned by default should be a thing or not?

[karrtikr]

Sure. In that case we have decided to follow the approach described by @isidorn in #18040 (comment), but have the 3rd step behind an experiment, as we suspect Users would likely want pinning by default. We can discuss after that.

[jrieken]

I see. For the priority you can try something like 100.09999 but pinned language status items are meant to win. So, that might lead to <Python> <Some_Python_Language_Status> <Your Status Bar Item>

[karrtikr]

Nice, thanks! I'll try it out.

[karrtikr]

Works great:

We plan to remove bitness "64 bit" to make this even shorter. We discussed as a team again and right now the plan is to A/B experiment with this hack, when using language status API, and when in the control group (where this is on the left as it is), so there're 3 experiments to compare. We can decide based on that whether pinning is needed.

[karrtikr]

@isidorn I am working on adopting the language status API and here's how it looks:

After pinning and hovering:

When interpreter selected is invalid:

After pinned:

It looks good. However I discovered a bug where the language status item does not appear when a language mode is changed: microsoft/vscode#140589. We have a getting started experience where we ask the user to create an untitled file and then select an interpreter using the status bar (now language item), so we would need that bug to be addressed before we can adopt the language status API.

[karrtikr]

• Add experiments in experiment tower
• Add pythonInterpreterInfoPinned experiment to where the pinned interpreter status bar item is moved to the right Add experiment to where interpreter status bar item is moved to the right #18282
• Add pythonInterpreterInfoUnpinned experiment to change interpreter status bar item into a language status item Add experiment to change interpreter status bar item into a language status item #18283
• Look into if we need to update the getting started experience regarding each experiment Update getting started experience related to Language status item experiments #18287 @luabud
• Rollout the pythonInterpreterInfoPinned experiment
• Wait for Language status item doesn't appear when language mode is set vscode#140589 to get fixed after which rollout the language status API experiment

[isidorn]

@karrtikr thanks for looking into this and thanks for filling that issue with nice steps. We plan to look into it this milestone.

I do agree that it looks good, much cleaner!

[isidorn]

Joh just pushed a fix for the issue you filled. It should be in Insiders on Monday so try it out and let us know if there is anything else we can do to help you adopt the language status. Thanks

[karrtikr]

Sure, thanks a lot for the quick fix!