You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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鈥檚 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.
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). Karthik Nadig (@karthiknadig) plans to bring up our use-case at the next API sync.
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:
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
Listen to user feedback
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 :)
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.
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!
Isidor Nikolic (@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".
Kartik Raj (@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 Johannes Rieken (@jrieken) might help.
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?
Sure. In that case we have decided to follow the approach described by Isidor Nikolic (@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.
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>
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.
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.
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
Activity
brettcannon commentedon Nov 16, 2021
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). Karthik Nadig (@karthiknadig) plans to bring up our use-case at the next API sync.
isidorn commentedon Nov 18, 2021
Brett Cannon (@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:
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 commentedon Nov 18, 2021
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 commentedon Nov 18, 2021
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 commentedon Nov 18, 2021
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 commentedon Dec 9, 2021
karrtikr commentedon Dec 9, 2021
I attempted to do a basic move

Isidor Nikolic (@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 commentedon Dec 13, 2021
Kartik Raj (@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 Johannes Rieken (@jrieken) might help.
jrieken commentedon Dec 13, 2021
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 commentedon Dec 13, 2021
Sure. In that case we have decided to follow the approach described by Isidor Nikolic (@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 commentedon Dec 13, 2021
I see. For the priority you can try something like
100.09999but pinned language status items are meant to win. So, that might lead to<Python> <Some_Python_Language_Status> <Your Status Bar Item>karrtikr commentedon Dec 13, 2021
Nice, thanks! I'll try it out.
karrtikr commentedon Dec 13, 2021
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 commentedon Jan 12, 2022
Isidor Nikolic (@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 commentedon Jan 13, 2022
pythonInterpreterInfoPinnedexperiment 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聽#18282pythonInterpreterInfoUnpinnedexperiment to change interpreter status bar item into a language status item Add experiment to change interpreter status bar item into a language status item聽#18283pythonInterpreterInfoPinnedexperimentisidorn commentedon Jan 13, 2022
Kartik Raj (@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 commentedon Jan 14, 2022
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 commentedon Jan 14, 2022
Sure, thanks a lot for the quick fix!