Can anyone (please please) explain why addidng to the activity bar from extensions was removed from the ui please ? according to this it is still supported.
I am just trying to understand the reasoning here. To me this feels like a very narrow way of extending the platform and i find it very restrictive for unnecessary reasons.
Thank you
@ymolists we have decided that before we enable extensions to contribute to the activity bar directly, we add API so that you can contribute a section to the Explorer or Debugger viewlet (eventually the SCM viewlet). We wanted to see how far we get with this approach.
When I look today and see the number of extensions that are contributing sections shows that this was a good thing. If we would have added the API to contribute to the activity bar up front, then I'm convinced that all this section contributions would have been done as separate viewlets, which would have resulted in a crowded activity bar.
@egamma I really don't understand the reasoning or the worry that the activity bar will get crowded. That seems to be the major argument i heard and i still don't get it. For one thing once you open the Explorer/Debugger viewlet there is nothing stopping potential extensions from crowding that space as well. The major problem is that people will feel less inclined to write extensions if they feel they are contributing to an already crowded space.
Part of me feels like a story of Abraham Wald when you mentioned the stats about what people are doing today with the current extensions. Meaning there could be stats about people abandoning the platform because of how it is today. Now please hear me out here. I am not arguing against being very conservative. I actually applaud that. We all know there are other platforms like Atom/Electron that people writing extensions can chose and not be restricted in any way. But maybe there is no need to be worried about over crowding the activity bar in this particular case ?
At the end of the day i think we should give the user control on how these extensions are displayed on the screen and let the user decide if he/she actually wants it instead of us controlling it via an API. Meaning its not the platform to decide how its displayed out on the screen. In the same vein i like that the user can actually disable an extension from the activity bar. Maybe another thing the platform can do is allow the user to "group" viewlets and force certain extensions to be inside the Explorer/Debugger as a customization step. Maybe that would alleviate this overcrowding concern ?
This is clearly a question of the workflow, so different options for different users is a solution.
I tried to reach out in the vscode gitter channel
ymolists @ymolists Sep 14 16:23
I am about to give up on this ... Microsoft/vscode#33609 ... am i asking for too much ?
I cant understand the reasoning and there is not much anyone else can do beside walking away and going ... ¯(ツ)/¯. For starters the statusbar/ menubar or anything that is open as an API today can be cluttered already ! so saying that we are afraid it will get cluttered does not really make sense to me
Here is a response i got:
Remy Suen @rcjsuen Sep 14 17:18
I think letting users choose where a viewlet goes is a noble cause. I'm just not sure how many users are going to do that. Certainly, I agree with you that you're either going to have a crowded activity bar or a crowded 'Explorer'.
Any feedback (beside silence) will be greatly appreciated :)))
@ymolists no worry, we are still listening and thinking about the trade-offs.
@egamma Would love to know the status of that "adding sections to the scm viewlet" plan you mentioned above.
*EDIT -- Occurs to me this isn't quite the original poster's use-case; happy to submit a separate issue / move this conversation if need be
@develleoper Unfortunately I recently saw an that an issue was closed that was explicitly about adding to the SCM viewlet. They said they weren't going to support adding to the SCM viewlet itself to keep it uncluttered or something along those lines. I was certainly saddened, because imo GitLens belongs there MUCH more than on the explorer.
Oh, no! Haha, GitLens was my exact concern. It is essential functionality, but unfortunately clutters up an already-overloaded interface. Oh well, sad day. Thanks for the info!
Np - sorry for the bad news. Hopefully they will reconsider -- or if nothing else let me add it to it own top level (though I still feel in the SCM viewlet is more ideal).
@eamodio @develleoper we have the following exploration added to our February plan.
February plan: https://github.com/Microsoft/vscode/issues/43361
The Plan Item: https://github.com/Microsoft/vscode/issues/43645
@ymolists uh.. use
quote
not
for quotes
@egamma, duplicate of #43645
@usernamehw thanks for pointing this out and the feature is now available - closing.
Most helpful comment
@ymolists no worry, we are still listening and thinking about the trade-offs.