超出范围

向我展示其他没有工具栏的流行 ide

39548：

我们正在关闭积压已久的问题

vijayvepa 于 2017 年 12 月 4 日 15:34 打开了这个问题
vscodebot 于 2017 年 12 月 4 日 18:01 关闭
......这是很长时间......已经两个半小时了:)

18042：

票关了。 感谢您的理解和愉快的编码！

是的！ 没有 vscode :)

因为#18042 已经关闭，我已经切换到另一个 IDE。 对不起，微软！

可悲的是，我认为 Microsoft 或 vscode 团队并不关心客户想要什么。 这个话题早就几乎是明目张胆地无视无数问题的阴谋级别。

我也将通知视为团队中的某个人，他们将 vscode 视为自己的孩子……看到它以自己的方式工作，对相反的事情毫无兴趣。

我已经购买了 jet Brains 的完整订阅，并且没有回头。 我希望将 vscode 放在我的工具箱中......作为一名软件工程师，看到这种对社区建议的反馈......它只是在我嘴里留下了真正的阅读不好的味道。

vscode 团队不会在乎他们失去了更多的用户......所以它就是这样。

我完全同意 OP。 迄今为止，VSCode 中最大的功能差距是缺少工具栏。

我想要一个类似 ms-office-2003 的老式工具栏，带有工具栏和工具栏按钮。 周到的图标，鼠标悬停以查看描述和键盘映射交替。 应该有很好的默认工具栏，并且它们应该可以由用户自定义。 插件也应该能够定义插件特定的工具栏。

工具栏将推动更多的采用，并使用户更容易学习替代键盘。

我是 Visual Studio、eclipse 和 Jetbrains 的长期用户。 我只是花了很多时间设置和学习 VSCode，我可以说VSCode 很棒，除了缺少工具栏。 如果它有一个类似办公室的工具栏，我会专门切换到 VSCode。 但如果没有它，恐怕我将不得不回到 Jetbrains。

微软，请停止破坏你自己的未来。

临时解决方案可以使用状态栏添加您需要的命令。
这个扩展可以做到这一点：
https://marketplace.visualstudio.com/items?itemName=anweber.statusbar-commands
https://marketplace.visualstudio.com/items?itemName=gsppvo.vscode-commandbar
https://marketplace.visualstudio.com/items?itemName=gizak.shortcuts
https://marketplace.visualstudio.com/items?itemName=fabiospampinato.vscode-commands

这个可以向状态栏添加任务：
https://marketplace.visualstudio.com/items?itemName=GuardRex.status-bar-tasks

结果：

我和@morozovsk和@MikeSummit 在一起。 vs 代码有很多用途，但是缺乏功能可发现性，缺乏简单的导航并迫使用户进入 Ctrl+Shift+P 的土地/一切的命令调色板桶确实阻碍了 IMO。

工具栏是 vs 代码所没有的必备功能。

做正确的事。 在用户界面设计中实现作为全球公认标准的用户界面。 通过默认工具栏、插件特定工具栏和用户可定义的可自定义工具栏，使 vs 代码真正可用。

我确信这将是一个需要实现的大型功能，但这不应阻止此功能请求在路线图上可见。

@alkorsan请将我的添加到您的列表中，它提供了一个很好的功能，可以包含在工具栏中...

开发人员应该可以选择为他们的每个任务添加一个可点击的按钮。

https://marketplace.visualstudio.com/items?itemName=GuardRex.status-bar-tasks

我很想退休！

来自 Atom，可定制的工具栏是我最怀念的功能之一。 我宁愿不必学习新的快捷方式，因为我应该专注于实际代码。 我希望我们能在不久的将来得到一些东西！ 继续努力，微软。

有趣的是，这个问题还没有因为超出范围而被关闭，我仍然希望这个功能能够实现。

2018 年官方路线图确实谈到了“Happy Coding”，“我们希望让新用户和现有用户的体验更加愉快”和“消除使人们难以采用 VS Code 的障碍”，所以没有具体说明这个问题在路线图上，它应该在路线图上，并根据所说的内容进行处理。

@bpassero在这个问题上一直很活跃，他是一名活跃的 VSCode 开发人员。 如果 Microsoft VSCode 团队开发人员能够抽出时间在此问题上进行记录并说出计划是什么，那就太好了。

他们不是记录在案并说在可预见的未来基本上不会发生吗？ 这似乎是我对所有开放和封闭问题的理解，并说明它甚至不会被卡在积压中......但更像是“不感兴趣”，即使该问题已被提出无数次。

不是试图开始负面反馈循环或任何东西......但这个话题是一个痛苦的......而且我几乎觉得有反工具栏的阴谋级别。 某个地方的某个人决定对它的任何功能请求都不会导致通用工具栏......他们的想法是

嗨@ronnyek，我已经看到多个与此类似的已解决问题，我确实了解您的立场。 我正在努力保持积极的态度。 今天这个问题仍然存在这一事实让我希望 vscode 团队愿意考虑这确实是一个有效的建议。

我也希望我没有被迷惑:)

我很高兴地重申，缺少默认工具栏、特定于插件的工具栏和用户可定义的可自定义工具栏是新用户进入/采用 vscode 的真正障碍，而这个缺失的功能对于那些使用无论如何都愿意坚持使用 vscode。

哦，是的，不要误会我的意思......我支持这个改变，就像我说的我不想成为一个负面反馈循环或任何东西......只是很惊讶这个问题一直存在. 随着 VS Code 的发展，它正在突飞猛进……只是真的不明白对工具栏的反对。 现在我已经取消了前端编辑的 vscode，转而使用 webstorm，但我希望将来有 vscode 作为一个选项

看起来很基本，当我没有找到时我很惊讶......但我想如果设计师有保持非常小的用户界面的理念，也许他们觉得不值得为支持一个而付出努力

也许任何人都可以尝试移植这个 atom 工具栏扩展https://github.com/suda/tool-bar

我用一些代码开始了一个功能分支，旨在实现固定工具栏：
https://github.com/junalmeida/vscode/pull/1
问我你是否想成为其中的一员。
我已经使用 3 个常见的基本操作创建了工具栏的初始要求（ui 内容，例如定位等）。 请参阅我放在 PR 上的 gif。

还有很多工作要做。

@junalmeida嗨，目前此功能请求（与其他许多请求一样）是开放的，因此我们可以从用户那里收集更多反馈，而不是因为我们想立即解决它。
VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。

与所有功能请求一样，最好的第一步是通常开始讨论而不是立即开始编码。
请参阅我们的拉取请求指南https://github.com/Microsoft/vscode/wiki/How-to-Contribute#pull -requests

亲切的问候
伊西多尔

@isidorn
atom 是一个极简的代码编辑器：

notepad++ 是一个超级简约的代码编辑器：

vscode 是一个... vim 方式的代码编辑器。
请删除左侧面板和顶部菜单！ 只有键盘快捷键！ 只有铁杆！

鼠标是在 1946 年发明的，但你强迫我们使用键盘。
我使用了很多程序。 我不需要记住所有程序中的组合键。

如果您希望您的程序与其他程序一起使用，您必须兼容。 如果你不想兼容（ms way），你可以随心所欲，但不要假装你在乎。

：生气的：

@isidorn我明白你的意思，但我想这里已经开始讨论这个话题和其他话题。 无论如何，我开始将其编码为自己的 POC，试图了解所有使用的指南和 UI 代码。 如果这不是 VSCode 官方团队的方向，没问题，但这就是开源的美妙之处：任何人都可以 fork 和做实验，这并不一定意味着 PR 会被接受。 ;)

这是一个非常奇怪的决定，对于我个人采用 vscode 来说肯定是一个很大的障碍（我想还有很多其他用户）

同样由于缺少工具栏，一切都被转储在状态栏上。 有一些扩展使状态栏非常混乱，例如 git-history、cmake。 由于您无法单独禁用状态栏图标，因此没有空间放置相当重要的东西。

VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。

虽然我可以完全理解这一点，但这并不是这里必要的行动。 为扩展作者公开一些可绘制区域是非常好的，以便他们可以通过扩展发送工具栏。 这样，核心编辑器就不必完全支持它，默认体验当然不会受到它的影响。

如果你只是看看最近的发展，很明显 VS Code 已经摆脱了一切都通过配置文件完成的“核心”功能。 提供了完整的配置 GUI，因此很明显 VS Code 现在也接受更多以鼠标为中心的用例。 拥有一个工具栏肯定是一个好主意，即使它只适用于一小部分用户。 只是它会为额外的扩展开辟很多可能性。

+1

我不明白为什么工具栏不能成为可选功能。 想要超极简？ 把它关掉。 想通过鼠标快速访问功能？ 打开它。 如果需要，请将其作为插件实现。 但是这些强硬立场反对用户想要杀死项目的内容（例如，请参阅 Amarok）。 VSC 在很多方面都很棒，但很明显，缺少工具栏对很多人来说很烦人。

请拜托..我非常需要工具栏..没有它我绝对瘫痪..不知道如何在文件之间导航。

在 VS Code 的标题中，在 Menu 行下，您能否请另一个图标工具栏用于最常用的功能，例如保存文件、打开文件等。例如 Visual Studio。 我们需要能够自己配置它来添加/删除项目。

我不会永远等待 MSFT 添加这个（如果有的话）。 购买 jetbrain 的 WebStorm。

+1
我仍然更喜欢使用键盘做任何事情，但是这个新的（相当基本的）UI 元素为扩展和配置提供了新的可能性，这可能会让我信服。
我会关闭它，但如果我想要它，我仍然希望它作为一种可能性存在。

可悲的是......但我希望这会有所帮助......
适用于 Windows 的 Visual Studio Code 键盘快捷键
https://code.visualstudio.com/shortcuts/keyboard-shortcuts-windows.pdf

我认为每个人都喜欢这些信息......因为这是我要求工具栏的主要原因......这么多命令要记住或使用命令窗口命令进行搜索。

我真的不认为构建所述工具栏会花费那么多的工作......但问题是我担心 vscode 开发人员仍然没有兴趣，没有计划，对工具栏没有第二个想法。 我相当有信心带有工具栏功能的拉取请求将在很大程度上消失在以太中。

完全同意，一般来说，无论您的业务有什么需求，如果它得到满足，您就会获得更多的存在！

卡罗尔

我认为每个人都喜欢这些信息......因为这是我要求工具栏的主要原因......这么多命令要记住或使用命令窗口命令进行搜索。

我真的不认为构建所述工具栏会花费那么多的工作......但问题是我担心 vscode 开发人员仍然没有兴趣，没有计划，对工具栏没有第二个想法。 我相当有信心带有工具栏功能的拉取请求将在很大程度上消失在以太中。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在 GitHub 上查看https://github.com/Microsoft/vscode/issues/41309#issuecomment-426295027 ，或将线程静音https://github.com/notifications/unsubscribe-auth/AcQg2XMA0_WfTqVGZVt5M- Uw418e3Iy4ks5ug3iYgaJpZM4RW3oS 。

30 多年的 IT 老手，比 GUI 更喜欢命令行，但绝对必须同意 OP 的观点，即这个 GUI 编辑器连最基本的工具栏都没有（即使作为一个可选功能，然后可以为 Windows-OS 禁用）是荒谬的GUI 应用程序开发人员/用户突然变得如此反基本 GUI 功能）。

为了进一步支持（无意羞辱）即使是最基本的记事本替换中最基本的也有能力添加甚至最基本的工具栏 - 比上面提到的那些更传统的反 GUI 功能，甚至我的长期Notepad ++ 的 goto - 是 EVEN VIM FOR WINDOWS，如下所示。 当 UNIX VI 端口能够负担得起为他们的 GUI 放入工具栏的代码时……我相信您明白这一点。

但是，它有多必要，它背后的想法是什么？ IMO，就像我使用键盘一样，如果没有其他原因，我总是觉得拥有“视觉”图形按钮更舒服 - 基本文件操作。 是的，我完全意识到并同意击中 :wq 的速度要快 1000 倍！ 但这是一个区域 10/10 次我很乐意在每个主要文件打开/保存操作中点击 4-5 秒点击工具栏按钮（如果有的话），我想说的是几乎所有其他 Microsoft GUI在过去 35 年中编写的，除了 vscode 已经提供给它的运营商。 从上面的评论来看，在我的典型工作流程使用中，听起来肯定不是我一个人，尽管可能不是绝对最省时的，但在这种情况下（为了保留我剩余的白发）舒适、方便和简单心态胜过性能。

而且，就像上面的那些（以及许多其他离线）一样，由于我的主要编辑器对我来说是多么不可或缺，尽管听起来很小，但现实是 vscode 虽然缺少这些基本功能，但不会给我足够的安慰来制作它我的主要编辑。 是的，可能有 3rd 方扩展添加了部分工作工具栏，但是在任何时候核心 vscode 更新破坏它，或者另一个扩展冲突并导致保存按钮出现故障等.....工具栏真的需要可在核心 vscode 中获得安全性和可靠性。

UNIX-born VIm Windows-port _增强仅以遵守 Windows GUI 标准_ （在 ~2016+ 的明显新 GUI 功能（较少）标准之前）：

任何在 MSFT 负责 VSCode 的人都应该被解雇，因为他们忽略了这些基本要求。 听起来又像是旧的 MSFT。

我以前没有看到一个非常快的“走开，我不想听人们使用我正在开发的东西”问题 #11159，其中有人问为什么侧边栏上给用户的按钮很少， EXTENSIONS 被认为是用户会比基本文件操作更频繁地点击的东西：

https://github.com/Microsoft/vscode/issues/11159

当您看到 DEV 关闭并快速锁定问题并基本上说“走开”时 - 我看到他在瑞士与海外的 MS 一起工作时，该产品的任何 DEV 管理人员在 MS 时都不会认为这是一个大问题客户现在甚至无法就我认为是一个严重尴尬的问题发表意见？ 如果我正在管理那个 DEV 团队，我会要求捍卫该设计选择的 DEV 向我展示一个可能比打开/保存/关闭文件更频繁地点击一个巨大的“扩展”按钮的人，在文件之后，之后文件 - 而不是捍卫设计所有这些操作应该让我们的用户多次点击菜单和命令栏并输入命令？！？

我敢打赌，如果你解锁了这个问题，你的许多用户都会同意这里的情况（这可能是快速关闭的目的）。 @BenHayat你是绝对正确的 - 早在 90 年代末，我实际上得到了一个职位@ MS，如果我今天处于那个职位，那也正是我会采取的行动，我永远不会支持我所看到的在针对产品用户的问题 #11159 中结束。 经过这么多次迭代，这个产品可能会远远超过它，实际产品的用户在寻求改进时应该始终有发言权。 如果没有，开发团队最终会编写仅满足他们需求的应用程序。 当开发人员管理用户反馈时，不幸的是，这些天在 Github 上似乎更常见，有时，无论是来自大型 MS 开发人员，还是来自几个青少年和他们的第一个开源存储库。 ：眨眼：

我希望在 VS 代码中有一个小工具栏。
只有几个项目会让我高兴（后退/前进/最后编辑位置）——也许 VS Code UX 团队觉得工具栏不好（如果产品默认工具栏太多，我同意这一点）。 也就是说，工具栏似乎已经存在（见图片） - 但其中的项目对我来说毫无用处，所以我只想替换它们。

我终于打破了对此发表评论。 我已经做了 30 年的开发人员，我学到的一件事是使用正确的工具来完成从命令行到全自动交付的特定工作。 每个原因都有其原因，随着先进的 AI 集成，软件开发工具将发生巨大变化，工具栏将成为过去的命令行。 VS Code 缺少一个基本的进化组件，这与从 IDE 中省略命令行一样。 也就是说，我的咨询实践使用 Visual Studio Professional 和 JetBrains Ultimate 作为我们的两个基本包。 VS 代码绝对无法与大多数没有工具栏的专业 IDE 包的灵活性相提并论。 我不会把第一年的开发人员放在 VS 代码前面，也不会浪费我的钱让他/她学习一个淡化的 IDE。 只是我的诚实意见。

@pgmolloy我有一些相同的担忧，我目前主要使用 Visual Studio 和 webstorm ......它们通常可以工作（并且在某些情况下，往往有更完整的插件，可以与其他插件更好地配合），但没有错觉它们与 vscode 一样轻巧或易于使用。

我的问题是，我们实际上并不是在谈论大量会减慢代码速度的功能，或者使它不是“轻量级代码编辑器”（这似乎是我听到最多的关于为什么我们没有工具栏的借口）。 可以想象，工具栏及其按钮配置实际上就是调用那些非常命令托盘命令。 配置可以是一个简单的配置，比如调试是（或至少是）

在我看来......（这不一定得到事实的支持......），它刚刚被决定......有人，在某个地方已经决定他们不喜欢工具栏的想法，因此我们已经有了对甚至模糊地类似于工具栏功能请求的问题的一些阴谋级处理。

如果我在 css/html 方面做得更好，如果我认为这个特性的拉取请求的机会很小......会被接受......我会花时间和精力在这上面。 如果这是“我们想做这件事，我们只是没有时间自己做这件事”，我会理解。 根据之前的历史以及几乎立即关闭或创建后不久关闭的数十个其他相关问题，我非常有信心...... vscode 团队不希望与工具栏相关的拉取请求。 这与他们的愿景不符，他们固执己见。

我很想被证明是错误的。

@罗尼耶克：

在我看来......（这不一定得到事实的支持......），它刚刚被决定......有人，在某个地方已经决定他们不喜欢工具栏的想法，因此我们已经有了对甚至模糊地类似于工具栏功能请求的问题的一些阴谋级处理。

@bpassero和@isidorn是我们的“英雄”:)

工具栏对于除 vscode 之外的几乎所有编辑器都是必不可少的，请添加它。

真的很需要这个功能

为了安抚在 MS 的 vscode 团队工作的人们以及觉得这是必要的客户，它甚至可以只是一个可扩展性的挂钩，所以它不是屏幕空间或潜在的开销只是自动采取的吗？

如果使用 vscode 的人反对工具栏（ @isidorn和其他一些人之外），如果没有明显的工具栏开销，我会感到非常惊讶。 它只是能够提供它，使工具栏与代码很好地集成并且不影响性能的问题

我发现这个称为树视图容器的选项可以在 Visual Studio Code 的左侧栏上添加自定义按钮。

• https://code.visualstudio.com/api/extension-guides/tree-view 上的文档和
• https://github.com/Microsoft/vscode-extension-samples/tree/master/tree-view-sample 中的示例

同样有趣的是，这个可定制的状态栏

• https://code.visualstudio.com/api/references/vscode-api#StatusBarItem 上的文档，以及
• https://github.com/Microsoft/vscode-extension-samples/tree/master/statusbar-sample 中的示例）

和浮动工具栏扩展

• https://github.com/JerryGoyal/Shortcut-Menu-Bar-VSCode-Extension 上的文档

我不知道最后一项......似乎这会有所帮助......我仍然认为至少开发一个可扩展点是值得的，即使它不是工具栏本身实际上已集成或启用默认情况下。

原始问题有 103 票，除了之前已关闭的无数问题之外，我认为这应该表明人们对此类功能的兴趣，而不必将其黑进已经很宝贵的状态栏房地产等。

我在奇异的世界吗？
2019年怎么还缺工具栏？ 我们会因为某种原因倒退吗？

@eb7898 ，Visual Studio 和 IDEA 在 2019 年有一个工具栏。Vscode 没有。

没有工具栏选项是不好的 - 但在浏览而不是主动编码时尤其如此（所以我的手远离键盘）。
解决方法都是奶酪（加工奶酪而不是好的 Époisses）...
编辑器工具栏离屏幕右上角太远。
我的状态栏已满……谁想要底部的工具栏？
侧边栏占用了太多的空间。

还有其他想法吗？

@awittaker另一个解决方法是这个扩展，它基于前面提到的树视图代码：

https://marketplace.visualstudio.com/items?itemName=usernamehw.run-commands-view

它仍然不是工具栏，它出现在左侧的树状视图区域中，而不是出现在您希望找到工具栏按钮/选项的常规顶部位置，但它是可配置的，它使人们不必记住过多的按键对于随机的事情。

@awittaker “积极编码”并不是适合所有人的通用解决方案。 Web 开发人员将一半的时间花在浏览器上，调整图层并使用 Chrome 开发人员工具等工具。 游戏开发者别无选择，只能在编辑器和游戏之间不断切换。 两者都切换到 Photoshop 和其他软件来快速绘制或创建一些东西。 因此，大多数时候他们手里拿着鼠标，继续使用鼠标做任何事情要好得多。 我认为我们应该在 VSCode 中同时拥有两种模式——以键盘为中心的人和以鼠标为中心的人。 也许即使是“主菜单”也不够——我个人希望有一个选项来创建类似垂直托盘的东西来模仿 Photoshop 的行为或来自 MS Office 的功能区。 当然，作为非常特定任务的完全可选的东西 - 我的意思是，没有必要将命令框中的每个功能都镜像到菜单项中。 只需给一个机会来创建自绘菜单和框，就是这样。 抱歉，因此我不得不转向 Theia 甚至 IntelliJ IDEA 社区版，没有其他选择了。

理想的工具栏功能要求：

1. 尽可能接近 MS Office 2003 的可停靠工具栏。 （如果您从未使用过它，它是完美工具栏的最佳示例）。
2. 包括一组默认工具栏，相关工具组合在一起。
3. 能够单独浮动或停靠工具栏。 停靠可以是顶部、底部、左侧或右侧。
4. 能够显示或隐藏工具栏
5. 能够创建新的工具栏
6. 能够向默认工具栏和用户创建的工具栏添加和删除工具。
7. 内置工具与 VSCode 函数和命令相关联。 用户工具可以与用户脚本或宏相关联。
8. 将鼠标悬停在工具上会显示名称、简短描述和键盘等效项，以帮助发现和学习 VSCode 功能和等效项。
9. 用户可以配置单个工具来显示图标、显示文本名称或同时显示两者。
10. 工具可以是单击命令（如保存）、命令下拉列表（如构建、全部构建等）或文本输入（如字体大小）。
11. 工具栏配置和自定义可以以人类可读的 JSON 格式导出和导入。 导入可以是附加的，也可以是破坏性的。
12. 用于创建复杂工具和工具栏的简单 API 和对象模型。 智能状态机可根据上下文被动地启用/禁用工具。
13. 不喜欢当前的MS Office功能区。 占用太多空间，而且经常需要 2-3 次点击而不是一次点击。

我相信我有大坝破坏者来突破这个并恢复一些理智：可访问性。

通过不包括甚至不允许使用工具栏，VS Code 团队和 Microsoft 采取的立场是他们乐于排除视力受损的用户。 这些用户可以增加他们的文本编辑器字体大小并使用语音阅读器和编辑工具，但发现基于文本的菜单很难使用。

那么微软，你重视视障人士的贡献吗？ 或者您是否乐意继续将他们排除在该产品以及需要使用它的工作和机会之外？

事实证明，VSCode 是微软的一个炒作项目，因为它“来”了开源。
MS 不会让 VSCode 成为滞后和缓慢的 Visual Studio XXXX 的竞争对手。
由于他们的个人资料详细信息，不难理解主要贡献者的这种抵制。 他们在微软有一份工作，可能会被解雇。
等待带有工具栏的 VSCode 的分支。

@NickMaev视觉工作室本身效果很好，并且提供了很多超越代码的东西。 话虽如此，vscode 最终是微软的项目对、错或无所谓。

我一直是添加工具栏的大力倡导者，因为它至少是许多消费者（包括我自己）多年来一直要求和抱怨的。

tl;博士; - 我不认为他们有任何义务添加工具栏，但我认为只是提交、提交和关闭、提交并标记为欺骗、提交和标记超出范围等的问题的绝对数量似乎表明人们想要这个，并且产品管理或其他 vscode 开发得到管理有一些反对它。 （我还没有听到他们如此反对的正当理由）

微软，只要承认人们的需求/愿望，如果真的是一两个人坚决反对工具栏......请直说。 我将贡献我的时间和精力将它添加到现有的分叉中。

这个错误现在是开发人员可以忽略的黑洞。 它允许人们发泄并希望它真的发生。 它可以防止在问题上打开新的错误，而不会对它做任何事情。 当软件开发由盲目的意识形态而不是用户需求驱动时，就会发生这种情况。

这当然可以通过扩展来完成吗？ 为什么需要在核心产品中？ 它已经是最受欢迎的代码编辑器，这表明它的大多数用户对缺少工具栏感到非常满意。 这是一个 100% 完美的扩展方案。 获取编码家伙！

这是一个 100% 完美的扩展方案。

这听起来很聪明……但是嘿！ vscode 不支持用于创建工具栏的 api。 快来读票吧！

这当然可以通过扩展来完成吗？ 为什么需要在核心产品中？ 它已经是最受欢迎的代码编辑器，这表明它的大多数用户对缺少工具栏感到非常满意。 这是一个 100% 完美的扩展方案。 获取编码家伙！

我不想假设人们非常高兴，但我确实同意，如果有一个 API 并且不强制每个人都使用工具栏，那对我个人来说也是可以接受的。

VS Code 高效、美观，而且是一个很棒的代码编辑器……我感觉 UX 不知何故完全退居次席。

需要工具栏。 我开始更多地了解 PowerShell，对 VBScript 非常有经验。 我使用 Notepad++ 进行大部分 vbscript 编辑，并开始学习 PowerShell ISE。 PowerShell ISE 至少有一个工具栏，但据我所知它是不可定制的。 我听说并安装了 VSCode，希望它有一个比 PowerShell ISE 更好的工具栏。 在自己无法在 VSCode 中找到工具栏后，我搜索并找到了这个线程。 通过此功能请求确认 VSCode 甚至根本没有工具栏，我已经卸载了它。

工具栏必不可少！ 没有它我就无法使用这个编辑器。 我无法相信至少提供必要的钩子的阻力。 显然是团队的意识形态问题。 惊人！

61336

我们终于可以承认这是你们需要做的事情吗？！ 这只是许多人提出同样问题的许多线程中的一个线程。

只需构建一个工具栏框架，这样需要工具栏的人就可以选择使用工具栏。

地狱给了我们一个信念，即 PR 实际上会被考虑接受，我敢打赌你会得到很多人自愿使用该功能

@isidorn您写道：“目前此功能请求（与其他许多请求一样）是开放的，因此我们可以从用户那里收集更多反馈。 . . .'

似乎反馈不断涌入，但没有任何反方向流动。 VSCode 团队中的某个人能否解释一下支持此功能似乎缺乏兴奋，其背后的原因？

“VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。”

在我看来，VSCode 是一个 IDE——或一个 IDE 构建平台——而不仅仅是一个简约的代码编辑器。 一个简约的代码编辑器是另一个 Microsoft 产品，记事本。

“与所有功能请求一样，最好的第一步通常是开始讨论，而不是立即开始编码。”

所以我的问题是，在这个反馈问题中，讨论在哪里？

@ronnyek有正确的想法：公开一个框架供扩展开发人员构建，就像在 VSCode 之上构建的所有其他方式一样。 没有人的极简主义理念需要受到影响。

完全是伟大的产品，但这个问题相当神秘。

这个功能在世界各地都很常见，有什么需要讨论的......

要求？ 就像Visual Studio代码所说的那样，从那里复制一个。
执行器？ 它确实需要一些研究，但这个问题已经有 1.5 年的历史了。

我认为新的状态栏和“菜单栏”之间只有一小步。

vscode 团队不愿意采取的一小步……这是关键点。 在这里，我们在这个问题创建一年多后，大量的人评论和大量的相同功能的其他问题打开了......而且仍然......相同的阴谋级别反对这个功能。

很高兴继续使用 webstorm。 vscode团队加油！

我会为此添加另一个声音。 VS Code 中缺少工具栏对我来说完全是个谜。 我每隔一段时间回来看看它是否已添加，但最终总是回到我的旧编辑器中。 VS Code 中有很多值得喜欢的地方，但缺少的东西让我感到惊讶。

说真的，微软！ 对于我们这些欣赏良好 GUI 设计的人来说，一个原本整洁的代码编辑器 / IDE 变得毫无用处。 都 2019 年了，为什么我们还在玩命令行？

都 2019 年了，为什么我们还在玩命令行？

因为它快了一千倍？

对添加此功能或使扩展可以添加此功能的另一票。

有些人的大脑不处理键盘快捷键。 这种遗漏是很愚蠢的。

这是一个很好的编辑器，但是，不会费心去学习一百个快捷方式或挖掘菜单。 我想不出没有工具栏的 IDE。 排除它们的决定简直是愚蠢的，就像 Windows Phone 一样！

我已将 VS Code 降级并将其用作简单的日志查看器。

还是非常需要的。 可能是我目前最大的定制点痛点。 我拥有的扩展和命令越多，我就越需要一个地方将它们放在 chrome 上。

将近 2 年了，仍然没有评论、确认、陈述意图，只是再次添加到积压中。 SSS-SUUUUUPER 骗子。 （我想至少它不仅仅是删除或关闭）

令人惊讶的是，如此简单的事情，在被忽视之前已经做过无数次了。 我之前说过它只是将我推向了我已经拥有许可证的 webstorm。

我真的很惊讶整个情况变成了一个集群。 vscode团队的路要走！

也许如果有足够多的抱怨，这种情况就会改变。 这似乎是“我们比你更了解”的另一种情况，我在 MSFT 产品中发现了很多。 我刚刚删除了 VSC 并下载了 Notepad++。

也许如果有足够多的抱怨，这种情况就会改变。 这似乎是“我们比你更了解”的另一种情况，我在 MSFT 产品中发现了很多。 我刚刚删除了 VSC 并下载了 Notepad++。

做了同样的事。 VsCode 与我的需求平行，所以回到记事本++（谢谢你的酒）/sublime。 有趣的是，没有 msft 交互的小团队如何做完全不同的事情，而且在大多数情况下，做得更好。 哦，好吧，它持续的时候很好。

让我们看看在没有工具栏的情况下，状态栏如何在监视器上变得异常长。

给它一个诚实的尝试，但放弃了 VS 代码并回到 Notepad++。 只是不记得我需要使用的所有命令，这个东西是一个资源猪来启动。 在我看来，仅加载一个文本文件就需要占用超过 700MB RAM 的东西肯定应该有一个工具栏。

让我们看看在没有工具栏的情况下，状态栏如何在监视器上变得异常长。

将这些东西移动到屏幕顶部不会神奇地让它们占用更少的水平空间......

将这些东西移动到屏幕顶部不会神奇地让它们占用更少的水平空间......

专用工具栏可以使用：

1. 更大的图标
2. 少文字
3. 堆叠/列表隐藏
4. 多行
5. 轻松管理控件组（根据某些标志或状态显示/隐藏）
6. 可能还有其他有用或需要的微妙 UX 内容。

只是顺便看看是否有任何吸引力？
是否仍然没有用于扩展添加工具栏的 API？

这让我发笑...
Visual Studio Code 路线图 2020

• 成为任何依赖辅助功能的人的最佳编辑器
  ...

:runner: 使 VS Code 成为一个非常易于访问的开发人员工具。 我们将与我们的社区合作并获得意见和指导，我们需要您让我们保持诚实。

这个“社区”是谁？ 不管是谁，我都感到被排斥在外……我需要尽可能多地休息我的手臂和手以尽量减少疼痛。 缺少工具栏真的让我很受伤。

由于没有开发人员对此工具栏问题的反馈，我不确定如何解释以下内容...

研究如何在工作台中安全地提供更丰富的可定制性
...
扩大对自定义 UI 的支持，例如上下文菜单。

两者听起来都很积极，但我很怀疑 - 上下文菜单定制自 2016 年以来就已经存在了，不是吗？
2016 年 6 月更新（版本 1.3）
我误解了吗？ 还是 2020 年路线图是从 2015 年复制/粘贴的！？

• 成为任何依赖辅助功能的人的最佳编辑器
  ...

🏃 使 VS Code 成为一个非常易于访问的开发人员工具。 我们将与我们的社区合作并获得意见和指导，我们需要您让我们保持诚实。

大声笑......当然......我相信他们有更多的盲人编码员比想要工具栏这样有用的东西的人更多（对不起，没有敲任何残疾）这只是课程的标准......所有有用的东西都被拒绝了因为超出范围，并且这些版本包含 18 页的发行说明，内容无人关心。

我的意思是......我完全是免费的，但是嘿，如果他们需要更多的开发人员来完成这些东西，如果他们不再忽略这些有用的功能请求，我会为“专业”版本付费......我不需要 Visual Studio，但是开发人员没有忽视价格合理的 VSC ......我是游戏......

同时，也许他们会将工具栏置于辅助功能模式，并且：/

@minig0d
曾经使用过键盘快捷键吗？ 或者在演示文稿的编辑器上增加字体大小？ 好吧，无论您是否知道，您都在使用可访问性功能：

https://vscode.readthedocs.io/en/latest/editor/accessibility/

如果您迫不及待地等待您的问题获得足够的支持，您可以随时提交 PR。

@sketchbuch是的，我很清楚它是什么......这是讽刺......如果将它们内置到核心中，唯一会很好的键盘快捷键是多个命令（“宏”），但它们已经为这些命令提供了插件并且我们已经可以增加我上次检查的字体大小...是的，我现在正在编码并且效果很好...现在我们可以拥有一些真正的功能吗？

如果您迫不及待地等待您的问题获得足够的支持，您可以随时提交 PR。

您是否查看过对这些“功能”发布的投票数？ 上次我抽查了一些 B/C，它们比许多 ^^^ 类型的请求要低得多，而且打开的时间要长得多。 我有点认为整个 upvote 事情更像是过马路的按钮......纯粹是为了逗人们直到光线改变。

在这个线程中展示了所有的优点和缺点，为什么不把它作为一个选项呢？ 喜欢工具栏的可以打开它，不喜欢的可以禁用它。 这不是航天科技。

微软不会这样做。 我们必须这样做。 有人已经做到了吗？

我正在使用一个有限的工具栏，Jerrygoyal 的

但是，主要问题仍然存在：

• VSC 上工具栏的 API 是否可用且完整记录？

我正在使用一个有限的工具栏，Jerrygoyal 的

当然，但是有了这样的扩展 1) 它看起来一点也不像人们习惯于从其他应用程序中使用的工具栏； 和 2）它是不可配置的 - 我们坚持扩展作者添加的内容。

因此需要来自 Microsoft Visual Studio Code 团队的官方工具栏 API/扩展。

因此需要来自 Microsoft Visual Studio Code 团队的官方工具栏 API/扩展。

现在任何一年

来吧MS？！ 让开发者客户满意有多难？ 我们并没有要求那么多。 请记住，我们是您的客户，也是您的利润……想想看……

我们能不能完成这件事……或者来自 vscode 团队的任何有用的意见，为什么这不存在，或者不会存在？ 也许我会去看看它的开发人员是否愿意将其作为 PR 并在那里实施......问题已解决。

最初，当我在 vscode 上找不到任何工具栏时，我也感到同样的困惑，我开始“新技术到底是什么”。

但现在不同了，我比任何工具栏或菜单都更喜欢命令面板。

1. 在键盘上按 F1 以显示命令面板（或按 Ctrl+Shift+P 以获得相同的效果，但需要更多的努力：p）。
2. 键入要搜索的任何命令。 此命令搜索功能非常智能，因此请继续输入要搜索的任何内容。
3. 使用键盘（方向按钮，然后按 Enter）选择命令，或单击它。

查找菜单或工具栏可能令人沮丧。 太多的菜单或工具栏让生活变得困难。 因此，通过键入来搜索任何命令的能力非常有帮助。

最初，当我在 vscode 上找不到任何工具栏时，我也感到同样的困惑，我开始“新技术到底是什么”。

但现在不同了，我比任何工具栏或菜单都更喜欢命令面板。

查找菜单或工具栏可能令人沮丧。 太多的菜单或工具栏让生活变得困难。 因此，通过键入来搜索任何命令的能力非常有帮助。

但这更像是 Windows 中的快速访问工具栏（即放置一些最喜欢/常用的命令），而不是一个完整的办公室类型的功能区。

即我们说的是 1 次点击与至少 2 次击键（假设它是您使用的绝对最后一个命令）（并且可能更像是 3-4 次点击向下箭头并选择或输入几个字母和选择...

调色板非常适合某些事情，但还有其他任务，您手上拿着鼠标并回到键盘上会分心......

@thariqnu-ifm
在没有键盘的情况下，我如何精确地使用命令面板？
为什么我们不能同时拥有命令面板和可选工具栏（或者至少是它的 API）？

应该强烈指出的一点是，VSCode 团队一再表示他们不想添加可以通过扩展完成的功能......与这个观点保持一致，因为没有扩展就无法做到这一点一个 API，这应该相应地实现:)

@thariqnu-ifm
在没有键盘的情况下，我如何精确地使用命令面板？
为什么我们不能同时拥有命令面板和可选工具栏（或者至少是它的 API）？

调色板的另一个问题是它是非结构化的——它只是转储到单个组合框中的所有命令的列表。 （是的，您可以通过键入并希望您猜到正确的命令名称来搜索它。）

他们只是为标签栏添加了鼠标滚轮支持......在某个时候他们可能会让多行标签栏成为可能，我最终将能够在标签栏上看到超过 10~ 标签文档......它是不像他们费心提供显示所有选项卡文档的下拉菜单按钮......相反，您必须打开浏览器侧边栏并查看比单行选项卡上直观显示的更多文档。

MS 如何到 2020 年抛弃所有优秀的 GUI 和 UX，以至于开发人员要求的东西在很多情况下都是 20 年前作为软件核心基础添加的……就像工具栏……

无论如何，当我可以切换某些扩展/功能时，我会很高兴，打开/关闭，并在视觉上看到代表所述扩展/功能打开或关闭的按钮......就在我的屏幕上！ 而且这也可以在很短的时间内点击，而不是通过组合键和敲击键来完成同样的事情......当你忘记需要输入的扩展名称功能命令时很糟糕。 工具栏按钮/图标很棒。

真的很惊讶这个功能没有被优先考虑，因为它应该是。

VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。

哈！ :))
极简主义是什么意思？

无法自定义高度的Tab键，像地铁窗一样，是不是很简约？

菜单、操作栏等中的巨大按钮填充，在屏幕上比编辑器区域占用更多空间，意味着简约吗？

我在 vscode 编辑器定制上浪费了三个月，想着——是的，我找到了，我的编辑器！

你认为我在哪里编码，
是的，你说得对 - 在记事本++中

嗨，目前此功能请求（与其他许多请求一样）是开放的，因此我们可以从用户那里收集更多反馈，而不是因为我们想立即解决它。
VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。

@isidorn对您的回复表示次是否足以向您展示该回复有多脱节？

你说极简主义，但我认为 Notepad++ 之类的东西非常简约......同时，我们内置了 git / 版本控制（据我所知，“极简主义”编辑器中没有一个包括......调试......我认为它更像是一个 IDE 功能而不是一个极简的代码编辑器吗？有自己的进程监视器吗？不要认为我见过带有其中一个的代码编辑器......

但你知道它没有什么吗？工具栏...知道什么有工具栏吗？大多数代码编辑器，发布 VIM（几乎）......哪个没有？ Sublime 可能是我能想到的唯一一个远程主要的可能没有（不确定从未使用过它），那么目标是极简主义，还是试图吸引 Sublime 用户进入 MS 生态系统的 Sublime 仿冒品？

哦...是的，我差点忘了... Microsoft 不是开发这 3 个远程编辑扩展（远程 - SSH、远程 - 容器、远程 - WSL 等）的公司吗？我不记得有任何内置这些功能的简约编辑器......并且认为哲学是 MS 正在开发由 3rd 方扩展处理的编辑器和可扩展性？耸耸肩……

来吧 Microsoft - 做一次正确的事情并倾听您的​​客户群。 我相信您已经准备好了工具栏，只需要将它包含在构建中，并让额外 50% 的观众感到满意。 这都是关于选择的。 那些想要工具栏的人，打开它。 那些不这样做的人，就别管了。 问题是什么？？？？？

VSCode 是一个简约的代码编辑器，因此我们不愿意接受添加自定义工具栏的 PR。

也许只有 isidorn 这么认为，也许当他换工作时，我们会在一个月内得到一个工具栏。 也许问题不只在他身上。

来吧 Microsoft - 做一次正确的事情并倾听您的​​客户群。 我相信您已经准备好了工具栏，只需要将它包含在构建中，并让额外 50% 的观众感到满意。 这都是关于选择的。 那些想要工具栏的人，打开它。 那些不这样做的人，就别管了。 问题是什么？？？？？

他们正试图根据客户需求“确定优先级”……换句话说，他们正在开发他们的下一个摇滚明星功能版本……可能类似于 Raspberry Pi 的 API 嵌入到他们的咖啡机中……以防万一想用他们的 Java 编写一些 Java 程序？ 你知道超高要求的东西......他们可能试图将VSCode翻译成汉谟拉比语言代码......我听说在某些地方很受欢迎......

我开玩笑......但说真的......我只是喜欢 MS 以一种或另一种方式的官方回应......因为所提供的有关他们将如何向前发展以及未来愿景的信息没有'似乎与当前的行动一致...

如果他们无法管理构建可选工具栏/api 所需的 30 分钟……那么我们中的很多人可能确实需要返回另一个编辑器……

一个人的无用填充的想法是另一个定义明确的界面的想法......记事本++设计得不好或不好使用。 我曾经使用 notepad++ 和 editpad pro，后者很棒，但两者看起来都过时了，而且按钮狭窄。 我很高兴 VSC 没有，当我第一次尝试 atom 时，我不喜欢命令面板 - 或 vsc - 但是在使用它几年后，我不会错过按钮或发现命令面板难以使用. 也许只是给它一些时间而不是回到记事本++。

...让额外 50% 的观众感到高兴...

大约 240 人在 OP 中添加了积极的表情符号……是什么让您认为 VSC 只有大约 480 人使用？？？

我们不会强迫您使用工具栏。 它可以被禁用。
你强迫我们不要使用工具栏。
你觉得有什么不同吗？
“唯一正确的道路”的时代是在苏联。

不要告诉我该做什么，我也不会告诉你该去哪里。

一个人的无用填充的想法是另一个定义明确的界面的想法......记事本++设计得不好或不好使用。 我曾经使用 notepad++ 和 editpad pro，后者很棒，但两者看起来都过时了，而且按钮狭窄。 我很高兴 VSC 没有，当我第一次尝试 atom 时，我不喜欢命令面板 - 或 vsc - 但是在使用它几年后，我不会错过按钮或发现命令面板难以使用. 也许只是给它一些时间而不是回到记事本++。

正是为什么问题标题说“可选”。 我从不使用顶部的选项卡来访问文件——它们都在左侧。 他们为什么在那里？ 仅仅因为一种工作流程适合您并不意味着它适合所有人。 可配置的 UI 可以使其更好地适用于更广泛的用户 - 对我来说这是一个辅助功能。 我使用粘滞键，因此如果需要重复几次，按某些组合键（主要是撤消/重做）可能会很乏味。 它会让我的生活更轻松，不会影响你的生活，所以你为什么在这里告诉我我不需要它？ 你为什么在乎？

它甚至可以是一个插件，不需要它的人甚至不需要知道它的存在。

@morozovsk没有工具栏 - 没有人可以强迫您不要使用
不存在。

我不介意他们添加一个，我只是不希望它被优先考虑......似乎有很多开发人员想要它，所以你为什么不组建一个团队并提交 PR？

我不介意他们添加一个，我只是不希望它被优先考虑......似乎有很多开发人员想要它，所以你为什么不组建一个团队并提交 PR？

人们提供了，去看看关于同一问题的许多其他错误报告。 MS 表示他们可能会拒绝它。 他们甚至不想添加钩子来使插件成为可能。 所以这不是资源问题，而是意识形态问题。

这显然没有被优先考虑。 MS 甚至几个月都没有对此发表评论。 再说一次，我不知道你为什么会在意。

一个人的无用填充的想法是另一个定义明确的界面的想法......记事本++设计得不好或不好使用。 我曾经使用 notepad++ 和 editpad pro，后者很棒，但两者看起来都过时了，而且按钮狭窄。 我很高兴 VSC 没有，当我第一次尝试 atom 时，我不喜欢命令面板 - 或 vsc - 但是在使用它几年后，我不会错过按钮或发现命令面板难以使用. 也许只是给它一些时间而不是回到记事本++。

呃……知道notepad++有什么吗？ 配置文件...知道你可以用这些文件做什么吗？ 删除你不想看的项目...你可以从字面上让它只有一个带有一个菜单选项的文件菜单，如果你想要的话，没有工具栏......为什么会这样？ 因为它允许人们根据对他们最有效的方式进行定制，而不会将人们锁定在对他们来说效率不高的工作流程中。 所以说你觉得它很杂乱，所以不应该实施一个你不会被迫使用的可选功能，因为你发现它是那样的，听起来非常自负。

我喜欢深色主题……也许 VSCode 应该删除所有选项来自定义颜色选择并强制每个人使用我喜欢的颜色？ 他们为什么不呢？ 嗯，因为就像工具栏一样，很容易构建代码，让用户自定义最适合他们的东西，而不会对其他用户产生负面影响......

我不介意他们添加一个，我只是不希望它被优先考虑......似乎有很多开发人员想要它，所以你为什么不组建一个团队并提交 PR？

你想要什么优先？ 烤面包机的 API？

除了由于编码团队的类似顽固而导致实际数据被破坏的文件系统问题之外，我还没有看到似乎应该具有更高优先级的请求……但我想我们都应该向 Sketchbuch 国王致敬？

在票证中添加了常见问题解答。
向尚未弄清楚该主题但已经反对该主题的人回答相同的问题是很累的。

@thariqnu-ifm
在没有键盘的情况下，我如何精确地使用命令面板？
为什么我们不能同时拥有命令面板和可选工具栏（或者至少是它的 API）？

没有键盘你是怎么写代码的？

在票证中添加了常见问题解答。
向尚未弄清楚该主题但已经反对该主题的人回答相同的问题是很累的。

OP 中的趋势截图并未显示您认为它显示的内容......

我不介意他们添加一个，我只是不希望它被优先考虑......似乎有很多开发人员想要它，所以你为什么不组建一个团队并提交 PR？

显然已经有过几次尝试……有些比其他的更进一步。 问题是 vscode 团队过去曾阻止过这些努力，并且回避了他们无意允许的事实。

有一个愿景……那个愿景不包括工具栏。 为什么让我难以置信...但一直在等待... Webstorm 刚刚变得越来越好，并扩大了差距。

对别人来说......他们没有问题向后弯曲以获得一些超级晦涩的支持 2％的代码用户将使用......但是简单的可选工具栏...... Nooooooope。

年复一年，无数问题逐渐消失。 我想可能是时候打电话了。

没有键盘你是怎么写代码的？

有人说他们在没有键盘的情况下编写代码吗？
根据我的经验，开发不仅仅是键入代码 - 从开始时花时间弄清楚遗留系统到最后调试。

我的手臂疼痛，这使键盘时间成为一种宝贵的商品。 这也是一种在鼠标和键盘使用之间切换的努力。 所以为了让我的手休息，我尽可能使用鼠标。 有了一点支持（例如 _toolbar_），我就可以坐下来仔细阅读代码和参考文档、调试等，而无需在键盘附近数小时。

在票证中添加了常见问题解答。
向尚未弄清楚该主题但已经反对该主题的人回答相同的问题是很累的。

编辑：致 Microsoft Visual Studio Code 团队：

交付该功能不是更有成效的行动吗？

@rei-vilo

交付该功能不是更有成效的行动吗？

你可能很困惑:)
我是话题发起人。 我不是为 MS 工作。 我无法提供该功能。

@rei-vilo

交付该功能不是更有成效的行动吗？

你一定很困惑:)
我是话题发起人。 我不是为 MS 工作。 我无法提供该功能。

抱歉，该消息是针对 Microsoft Visual Studio Code 团队发送的。

就我而言，我尝试使用扩展，但文档很难挖掘。

我是话题发起人。 我不是为 MS 工作。 我无法提供该功能。

您在上面的帖子 1 的常见问题更新中确实说过这一点🤣

有些人在发表无关紧要的废话评论之前不会阅读它或试图理解这个问题的含义。

OP 有点 tl;dr，也许 FAQ 应该移到最上面。

别再当苹果了。 从某物中去除一些有用的东西并不会使那件事变得更好。

就我个人而言，在此线程之前，我从未注意到它没有工具栏。 我喜欢现在的方式。 无论如何，它的左侧都有一个活动栏形式的工具栏。 但是我认为 vscode 开发人员可以更好地解释不包含工具栏的决定，例如，也许工具栏会使窗口看起来很杂乱（我认为会）。 当然，在他们的实现中，他们可以只包括工具栏作为一个选项，但它可能在优先级列表中较低。 但是，一些有用的评论会很好。

就我个人而言，在此线程之前，我从未注意到它没有工具栏。 我喜欢现在的方式。 无论如何，它的左侧都有一个活动栏形式的工具栏。 但是我认为 vscode 开发人员可以更好地解释不包含工具栏的决定，例如，也许工具栏会使窗口看起来很杂乱（我认为会）。 当然，在他们的实现中，他们可以只包括工具栏作为一个选项，但它可能在优先级列表中较低。 但是，一些有用的评论会很好。

你也可以争辩说左边的巨大酒吧（不管你怎么称呼它）那是什么？ 100px+ 宽，比 20px 的工具栏更混乱...

另外...刚刚意识到...知道还有什么工具栏是微软拥有的...？ Github...就在这个框中，我正在输入...想知道这是为什么...我的意思是如果每个人都是键盘专家，我们不应该都知道markdown吗？ 哈哈

至少，我想要一个“工具面板”，我可以在不同的面板容器中移动（和复制？）。

所以它可以在活动栏中有一个专用图标，或者是现有窗格中的面板，等等。

利用最近添加的可移动面板。

就我个人而言，在此线程之前，我从未注意到它没有工具栏。 我喜欢现在的方式。 无论如何，它的左侧都有一个活动栏形式的工具栏。 但是我认为 vscode 开发人员可以更好地解释不包含工具栏的决定，例如，也许工具栏会使窗口看起来很杂乱（我认为会）。 当然，在他们的实现中，他们可以只包括工具栏作为一个选项，但它可能在优先级列表中较低。 但是，一些有用的评论会很好。

在其他封闭线程中，开发人员表示他们甚至不愿意或不愿意为插件开发人员包含钩子来制作工具栏插件。 因此，这些开发人员似乎积极反对甚至将完全可选的工具栏作为插件，而不是仅仅作为低优先级。 正如OP所说，这似乎是意识形态。

只是添加到桩...

这个问题是我不使用 VS Code 做任何事情的首要原因。 事实上，我大约每个月检查一次，看看他们是否意识到并添加了一个按钮栏。 但唉，听起来好像甚至允许插件开发人员集成一个栏都超出了范围。

我将继续使用 Notepad++ 和其他提供此基本功能的编辑器。 但是，这次我将真正卸载 VS Code，而且我认为我不会很快重新安装。

我只是想将我的 +1 添加到此功能请求中。

有趣的是，开发团队似乎拒绝了如此有用的东西，而像“打开编辑器”这样的完全无用的东西却一直在我们的屏幕上杂乱无章。 即使在 VC++ 6 天期间也不需要那个东西，这是编码时代的黑暗时期，我们没有选项卡显示哪些文件已打开。

在一些疯狂的开发人员把我的语法错误弄错之前，让我试着说清楚：

• 可配置的工具栏 -> 非常有用。
• 显示哪些文件已打开的选项卡 -> 非常有用。 收下！
• 打开编辑器 -> 完全没用。 丢它！

TLDR
一个可配置的工具栏将非常有用，而且比我目前看到的一堆正在实施的东西更重要。

只需右键单击打开的编辑器视图，如果您不想看到它，请取消选中它

只需右键单击打开的编辑器视图，如果您不想看到它，请取消选中它

您知道什么...如果有人抱怨他们不喜欢工具栏，您可以逐字逐句地说完全相同的行吗？ 多才多艺！

不，不是。 自第一个版本以来，隐藏视图的选项一直存在。

工具栏没有。 没有工具栏是核心设计目标。 现在添加它会占用资源和开发时间，并且需要多个团队协作才能添加此“功能”。 然后一旦有了懒惰的扩展开发人员将只为工具栏编写而不提供使用没有工具栏的扩展的方法。 很可能甚至不会将单击事件与实际命令挂钩，它们只会在单击时执行某些操作，而没有人有机会使用命令面板。 我认为现在添加这个“功能”将是一个错误，这就是为什么我不希望它完成。 它也会使 API 膨胀。 对功能区的所有 MS 研究表明，无尽的菜单选项是多么无用，以及工具栏地狱如何无法帮助任何人更有效地使用应用程序。

如果 MS Studies 认为工具栏是无用的，那么为什么该设计仍然是应用程序的基本范例？ 您是否在浏览器中打开了工具栏/功能区？ 单词？ 优秀吗？ 探险家？ 视觉工作室？ Photoshop？ Windows 中的固定应用程序是一种工具栏形式。 如果您个人从未在上述任何一种情况下使用过这些软件，您是否认为确实使用过这些软件的用户使用不当？ 例如，命令选项板结构最好替换 Word 中的功能区？ 诚实的问题。

至于工程方面的问题，您不必启用在单击事件内运行的代码。 该框架很容易从一开始就仅限于一个函数触发器，这对我来说似乎是无论如何实现它的唯一合乎逻辑的方法。 我曾经构建的工具栏/菜单的任何应用程序都只调用一个函数。 为什么它允许将代码嵌入到按钮的点击事件中？ 为什么开发人员甚至可以访问工具栏后面的事件？ 添加一个框架来支持带有命令挂钩的按钮将非常简单，因为您已经拥有执行相同操作的命令面板，因此它似乎只是该结构的扩展。

出于好奇，我一直留在这个线程上，但对我来说，真正的原因是我的大多数团队都选择不使用 Code，理由是界面存在缺陷。 这是令人失望的，因为它是一个很棒的产品。

如果您正在阅读此线程，并且缺少工具栏对您来说本质上是一个阻碍，就像对我一样，那么我推荐 Notepad++。 我卸载了 VSC，安装了 NPP 并没有回头。 NPP 工具栏可通过插件完全扩展，并且我添加了按钮以通过 Python、bash 脚本和内部编辑器语言执行近 20 项重复性任务。 另外，它还有许多其他插件用于特定语言的任务等。我相信还有其他不错的选择，但我没有发现 NPP 有任何我无法在默认情况下或自己编写代码的地方。

哈哈哈哈……我刚刚发现了 Sketchbuch 不想要工具栏的真正原因……他正忙着将状态栏用作工具栏（无论出于何种原因，认为出于意外目的“破解”状态栏更容易被接受而不是拥有一个合法的状态栏......

来吧伙计......如果你担心轻量级......让我们减少一些真正的膨胀......再次比VSC轻得多的编辑器具有工具栏......

...诚实的问题。

不，它只是无视我所说的。 我从来没有说工具栏没用，我说工具栏地狱没用……这就是我担心这会变成的。 功能区有按钮，但它们背后有 UX 研究，不会为想要按钮的用户改进 UX。 将回到在工具栏下方有数百个按钮和工具栏的状态。 它会变成一个臃肿的烂摊子——我想。

如果 MS 在人们想要多个工具栏之前多久提供一个工具栏，或者工具栏下方的工具栏能够通过拖放来排列栏，那么人们将需要一种自定义按钮和更改顺序的方法。 他们会想要对命令进行分组的按钮文件夹。这个简单的按钮 API 有可能变成一个怪物，使 API 和 UI 膨胀并耗尽开发人员的时间。

我喜欢小 api，一开始我觉得它很受限制。 在做了一些扩展之后，我明白了为什么所有的扩展自定义显示都在编辑器中，这是 API 允许您创建自定义内容的唯一地方。

顺便说一句，当我们收集无用的轶事证据时……与我合作的每个团队都使用 VS Code

是的，这些是我的扩展，但它们会在已有按钮系统的地方添加按钮。 这不是黑客攻击，这些扩展不会做任何 API 未向开发人员公开的事情。 看看他们是否添加了按钮 api 并且它已经完全制定并经过测试，我不介意。 我只是不想让他们搞砸编辑器。

Zen 终端按钮 btw 使用编辑器标题栏作为按钮位置 - 而不是状态栏 ;)。 您始终可以为自己创建一个私人扩展，在那里添加按钮。

至于工程问题，

是的，按钮可以连接到命令，但也可以在 package.json 中停止通过调色板调用的命令。 这是我不希望发生的事情，无论出于何种原因，开发人员开始只使用按钮进行操作。

@sketchbuch ：

我不希望发生这种情况，开发人员开始只使用按钮来制作东西——无论出于何种原因。

我们不是您的奴隶，可以在我们可以使用按钮时征求您的许可，何时不能使用。 出票。

操你妈，我不需要你的许可就一个开放的问题发表评论。 如果你不喜欢它长大了离开自己

不，它只是无视我所说的。 我从来没有说工具栏没用，我说工具栏地狱没用……这就是我担心这会变成的。

谢谢回复。 我同意工具栏地狱可能是一个问题（我在看你的 Office），但当工具栏可编辑时，我也将其置于“用户的决定”类别中。 （如果工具栏不可编辑，那么这是另一个问题）当我可以选择在应用程序中自定义工具栏时，它们并不是“开箱即用”的，默认情况下每个项目都启用，它们带有理智的选择的常见项目，我可以添加/删除使我的工作流程更高效的内容。 对我来说，它与允许我设置首选缩进选项、间距、字体大小等的编辑器相同。

即使 VSCode 附带一个默认隐藏的空白工具栏，也没关系。 对我来说，这是关于用户的选择，而不是强迫他们采用他们不喜欢的方法。 我承认我从未为 VS Code 构建过扩展，但是我认为它仅限于添加位图资源和启用该选项的扩展清单条目。 这不允许开发人员滥用它。 只要基本框架存在，为调色板制作默认位图的工作就交给社区。 然后像今天一样发布 VS Code，如果我选择以我的方式优化我的工作流程，我可以选择。

并不是要抛出轶事证据。

@sketchbuch

操你妈，我不需要你的许可就一个开放的问题发表评论。

但实际上你应该，因为这是我的未解决的问题:)
PS：现在你被禁止了。 感谢您的建设性对话:)

是的，这些是我的扩展，但它们会在已有按钮系统的地方添加按钮。 这不是黑客攻击，这些扩展不会做任何 API 未向开发人员公开的事情。 看看他们是否添加了按钮 api 并且它已经完全制定并经过测试，我不介意。 我只是不想让他们搞砸编辑器。

Zen 终端按钮 btw 使用编辑器标题栏作为按钮位置 - 而不是状态栏 ;)。 您始终可以为自己创建一个私人扩展，在那里添加按钮。

仅仅因为您可以在那里添加按钮并不意味着 VSC 允许您这样做，因为他们希望您将其变成工具栏...我实际上记得看到开发人员的一些评论，他明确表示并非如此。 （我知道令人震惊的是他们实际上可能会回复......）

PS：现在你被禁止了。 感谢您的建设性对话:)

在进行适当的讨论时，这是一种无用的行为。 你不能只是关闭你不同意的人。 关于如何不说服别人你的观点是有效的第 1 课。

他在每条信息中都重复同样的话：“我不想”、“我反对”、“我不喜欢这样”。 他完全没有为建设性对话做任何事情。

我不希望发生这种情况，开发人员开始只使用按钮来制作东西——无论出于何种原因。

在此之前，我认为他只是一个巨魔。 说了这几句话后，很明显她不想让 vscode 变得更好或更糟。 她只是想限制其他人，不管他们是否愿意。
好吧，我对他做了同样的事情，现在他可能会明白当你违背自己的意愿被限制时是什么。

他在每条信息中都重复同样的话：“我不想”、“我反对”、“我不喜欢这样”。 他完全没有为建设性对话做任何事情。

我不希望发生这种情况，开发人员开始只使用按钮来制作东西——无论出于何种原因。

在此之前，我认为他只是一个巨魔。 说了这几句话后，很明显她不想让 vscode 变得更好或更糟。 她只是想限制其他人，不管他们是否愿意。
好吧，我对他做了同样的事情，现在他可能会明白当你违背自己的意愿被限制时是什么。

对不起 sBrecht，我完全同意 morozovsk。 他没有添加任何建设性的批评。 老实说，基于他说话的方式（好像他在这件事上有某种权威）这就是我查看他的个人资料的原因……我以为他可能是微软的卧底员工……但不是……他只是个巨魔……

他给谈话带来的唯一好处是增加了帖子数……这可能会让 MS 更加关注这个问题耸耸肩

大声笑看......巨魔仍在拖钓......大拇指压低我的帖子......保持巨魔......我喜欢你如何证明我的观点！

是的，在 Sketchbuch 之前我们在第二页，现在我们在第一页。
所以感谢@sketchbuch的帮助:)

大声笑看......巨魔仍在拖钓......大拇指压低我的帖子......保持巨魔......我喜欢你如何证明我的观点！

是的。 你也可以禁止他并忘记他的存在:)

笑死MS因为你幼稚的行为关闭了这个问题

帐户已于 4 分钟前创建

@krytenjrobot ， @sketchbuch

相反，您将被禁止，因为注册垃圾邮件的新帐户。
如果我用新账号再次看到你，我会写信投诉到github，你的主账号将被禁止。

老头子，却表现得像个少年。

PS：现在你被禁止了。 感谢您的建设性对话:)

在进行适当的讨论时，这是一种无用的行为。 你不能只是关闭你不同意的人。 关于如何不说服别人你的观点是有效的第 1 课。

“去你的”不是一个适当的讨论。 这家伙显然是在拖钓，当有人指出他的论点有缺陷时，他移动了球门柱。 他只是在浪费大家的时间。

你好，我叫 Claude Dupré，我是一名 40 年的电子工程师和分析师程序员。 我在我的职业生涯中使用了大量的开发产品，甚至不得不开发在 Dos 环境中不存在的打印机驱动程序。 那时 Windows 甚至不存在。 即使我知道如何在面向对象中编程，机器还不够强大（8088、8k 内存、64k 磁盘空间等）来支持这种技术，所以我们不得不使用快捷键来实现经常使用的功能，并且每个程序都使用一个批处理文件，与带有链接文件的链接器相同。 几年以来，我一直在 Atmel 工作室工作，因为我对产品非常了解，因为在我的职业生涯中，我使用汇编程序、C、C++、.Net 和其他您可能从未听说过的语言（如 dbase、PLM、Clipper 等）进行编程。现在因为Atmel studio 不支持STM 产品，所以我不得不找另一个产品来开发我基于STM 的产品Cortex。 我找到了 Visual Studio Code。 所以我对自己说，Hourra，我找到了圣杯。 我不得不工作一个多星期来设置它，然后发现就产品的意识形态而言，我在 80 年代被拉回来了。 看到如此受欢迎的产品虽然不是一种有效的工具，我感到非常失望。 没有上下文菜单。 没有可配置的菜单。 插件不生成自己的菜单和工具栏，也不根据环境自行配置。 没有基本的工具栏。 因此，轻量级产品适用于紧张环境（我知道我在说什么）时是很好的，而如今的技术显然并非如此。 因此，如果有人想要使用新产品，他希望能够在最短的周转时间内安装和使用它。 如果我将 Visual Studio Code 与 Atmel Studio 进行比较，vscode 会落后数光年。 似乎，根据我在此处阅读的内容，vscode 团队不同意在我看来必不可少的升级。 总结一下。 我认为应该采用编码标准来定义更稳定和高效的插件，就使用、效率和文档而言，使最终产品更加集成和用户友好（事实并非如此，sorrrry）我希望 vscode团队将有更远见的眼光。 问候克劳德

如果 MS 在人们想要多个工具栏之前多久提供一个工具栏，或者工具栏下方的工具栏能够通过拖放来排列栏，那么人们将需要一种自定义按钮和更改顺序的方法。 他们会想要对命令进行分组的按钮文件夹。这个简单的按钮 API 有可能变成一个怪物，使 API 和 UI 膨胀并耗尽开发人员的时间。

好吧，对您来说是个大消息：人们已经想要上述所有内容。 这就是该提案的全部目的 - 允许用户添加他们想要的命令，以及他们想要的方式，以及他们想要的位置。 不要依赖扩展作者为他们准备命令，在一个不适合他们的组件中，并且没有定制。

就“UI 和 API 膨胀”的争论而言，现在最需要的功能 #10121 是能够将窗格拖到主窗口之外。 很明显，人们对他们喜欢的工作流程有很多不同的想法。 VSCode 有许多我不使用的功能。 这并不意味着我认为它们应该被删除。 这意味着如果我需要/想要它们，它们应该在那里。

就“UI 和 API 膨胀”的争论而言，现在最需要的功能 #10121 是能够将窗格拖到主窗口之外。 很明显，人们对他们喜欢的工作流程有很多不同的想法。 VSCode 有许多我不使用的功能。 这并不意味着我认为它们应该被删除。 这意味着如果我需要/想要它们，它们应该在那里。

这......或者至少能够扩展程序以解决所需的功能......如果人们想要浮动窗口，为什么不直接打开 VSC 的第二个副本或在两个显示器上扩展窗口并选择不同的布局......（查看 > 编辑器布局）他们已经有很多不同的......但老实说，这听起来不应该花几天时间来淘汰......

但是，如果您查看最新版本的发行说明（帮助 > 发行说明，如果您想将它们拉起来亲自查看），请查看这些更改中有多少是“高级功能”或仅迎合一小部分用户， 等等..

应该在这个问题的 2 周年纪念日举行一个聚会，以纪念所有那些刚刚以out of scope等关闭的其他问题等等

只需添加我的声音即可优先添加适当的可自定义工具栏选项。

FFS 早就该 MS 了！！

MS充其量是天龙人...

有些问题只是简单地扔掉，这个 IDE 就像只有一个人在做，而不是几十个……

就像渲染不佳的问题，或者“这里没有工具栏！”。
我真的认为这个 IDE 的开发者不会使用它！

我不知道这个线程并提交了一个可定制工具栏的请求。 它被拒绝/关闭，因为这不是他们打算在未来两年内考虑的功能。 我也被提到了这个线程。

这确实是我使用 VS Code 的唯一问题，它与我自从 Windows 成为一门事物以来使用的所有其他 MS 程序都不同。

另一方面，VS Code 可免费供个人和企业使用，并以“轻量级”编辑器的形式呈现，而不是成熟的 IDE。 MS Visual Studio 不是免费的。 我想他们希望避免 VS Code 完全取代 MS Visual Studio 的可能性。 我不是专业的开发人员，也没有使用过很多不同的 IDE。 除了工具栏之外，我对 MSVS 2019 还不够熟悉，无法看到使用它的任何其他好处，而且它似乎在其他一些领域有所不足。

我想用户可以通过某种方式编写可能添加此功能的兼容扩展（超出现有功能，这些功能很棒但不是很健壮）。 然而，正如我所说，我不是很了解，所以也许没有。

我希望他们最终重新打开这个问题，如果 VSCode 继续快速扩大其用户群，他们可能会这样做。 同时，鉴于它是完全免费的，它是一款相当不错的软件。

我想用户可以通过某种方式编写可能添加此功能的兼容扩展（超出现有功能，这些功能很棒但不是很健壮）。 然而，正如我所说，我不是很了解，所以也许没有。

没有......（我相信答案在上面的某个地方，但我认为这个问题类似于 api 只允许访问 10 个硬编码函数，而不是像 IDE 的所有其他部分那样公开所有命令进入。

令我感到困惑的是，尽管它已经开放了搜索流量的时间长度、支持量、为他们实施应该是容易的等等。仍然没有来自开发团队的任何评论......

无论是否免费，许多其他功能已经发布，这些功能对更少的用户有益（这显然比实现这个功能花费的时间要多得多），所以这真的很遗憾。

没有......（我相信答案在上面的某个地方，但我认为这个问题类似于 api 只允许访问 10 个硬编码函数，而不是像 IDE 的所有其他部分那样公开所有命令进入。

有一种有点平庸的方法来创建扩展工具栏（称为“菜单”，原因只有 vscode microsoft 人员知道）和带有任何所需命令的右键单击上下文菜单。 我称之为平庸，因为目前可行的方法存在许多问题。

1. 没有用于添加命令、工具栏按钮、上下文菜单项等的 vscode API。让东西出现在工具栏和上下文菜单中的模式是由扩展 package.json 文件中的声明性contributes条目驱动的，这个文件必须编译成扩展名。 这个漏洞意味着没有办法在运行时从配置中以编程方式构建工具栏或菜单，并且任何类似的东西都必须硬连接到扩展代码中。
2. 右上角区域的工具栏可以进行一定程度的扩展，并不是通常意义上的功能齐全的应用程序工具栏区域。 尽管可以将带有命令的按钮添加到该区域，但我发现该区域的位置很奇怪，因为它是内联的并且位于编辑器选项卡的右侧，而不是放置在编辑器上方。
3. 缺乏 (1) 中提到的 API 以及没有可扩展的工具栏容器区域（除了右上角的东西）是阻止任何人开发可能被任何人使用的灵活且可配置的通用工具栏扩展的障碍。

我为我自己的目的创建了一个hacked together 扩展，虽然它确实消除了一些我最常用的命令必须处理 vscode 的命令托盘桶的痛苦，但它仍然远非理想的解决方案。

对于上下文，黑客攻击的扩展会产生如下所示的内容。 需要明确的是，我不提倡将此解决方法作为此问题的可接受解决方案。

此功能请求是相关的，因为需要工具栏才能实现：
功能请求：简化文本编辑器

请给它一个upvote，然后它可能会被放在积压中。

说实话，每次给同事推荐Vscode的时候，Vscode都太特别（死板），让他们不知道怎么上手。
没有人想（很难）记住这么多组合键。

我不明白添加这个明显必要的功能的明显阻力

• 请添加一个可选/可配置的工具栏。
  当我从顶部菜单中执行“全部保存”感到沮丧时，我开始寻找 VS 工具栏 - Ctrl K + S 会弹出一个屏幕，显示有关配置快捷方式的信息 - 我不想在简单的工具栏单击时浪费时间配置快捷方式无缘无故省略。
  停止浪费时间并完成它 - Microsoft 拥有来自 Visual Studio 的大量代码，可以重新调整其用途以加快此任务的速度。

带有工具栏的 Vscode 最终将取代记事本 ++ ..如果他们真的为添加扩展可以支持的适当工具栏支持而烦恼（用户自定义以在每个工作区中剔除东西）

我得到的每一个新的 VSCODE 更新，我都坐在这里希望 MS 和团队能把这个功能放进去，我们可以看一些关于工具栏的精美小动画 gif ......但是不......仍然只是无数可能的功能受益 <1% 的用户群......然后像这样，显然至少有一定数量的用户群对此充满热情，仍然只是被扔在地毯下，在垃圾桶中，路由到 /dev/null，无论如何.

哦，好吧...我想团队会用他们的行动说话，他们的行动是公然的“不”，我想我们都只是希望我们至少能表现出对这个功能的兴趣。 显然已经做出了决定。

有趣的是，其他开发团队很可能正在关注并最终发布具有我们一直要求的功能的编辑器 - 并且可能更多。

那时，MS 可能会从他们的谚语中撤出他们的拇指 - 但为时已晚。 为什么太晚了？ 他们显然没有关注他们的客户——这很可能意味着他们错过了许多其他可以改进的简单东西，竞争对手可以利用这些东西。

在那之前，我们等待下一个伟大的文本操纵器。

来自：韦斯顿通知@ github.com
发送时间：2020 年 8 月 24 日 23:35
至：microsoft/vscode [email protected]
抄送：DigoFuerte [email protected] ； 评论[email protected]
主题: Re: [microsoft/vscode] 在菜单下方添加一个可选的可配置工具栏 (#41309)

我得到的每一个新的 VSCODE 更新，我都坐在这里希望 MS 和团队能把这个功能放进去，我们可以看一些关于工具栏的精美小动画 gif ......但是不......仍然只是无数可能的功能受益 <1% 的用户群......然后像这样，显然至少有一定数量的用户群对此充满热情，仍然只是被扔在地毯下，在垃圾桶中，路由到 /dev/null，无论如何.

哦，好吧...我想团队会用他们的行动说话，他们的行动是公然的“不”，我想我们都只是希望我们至少能表现出对这个功能的兴趣。 显然已经做出了决定。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在 GitHub 上查看https://github.com/microsoft/vscode/issues/41309#issuecomment-679400537 ，或者退订https://github.com/notifications/unsubscribe-auth/AFC3662TUXE67KO6LPNRNR3SCLTKNANCNFSM4EK3PIJA 。

在可预见的未来，它似乎不会成为高优先级功能，所以我制作了这个扩展，它在 VSCode 的编辑器菜单栏中添加了方便的按钮，如美化、列表文件、撤消、重做、保存等。 快捷菜单栏

@GorvGoyl考虑到您必须在其中工作的限制，我将该扩展称为胜利。 我真正想要的是撤消/重做，所以谢谢！ 5星给我。

@GorvGoyl非常好！ 5星！

@GorvGoyl非常好！ 5星！

不，太可怕了，太可怕了标签组的空间

@GorvGoyl非常好！ 5星！

不，太可怕了，太可怕了标签组的空间

哈哈。 您实际上可以根据需要禁用/启用这些图标。

在可预见的未来，它似乎不会成为高优先级功能，所以我制作了这个扩展，它在 VSCode 的编辑器菜单栏中添加了方便的按钮，如美化、列表文件、撤消、重做、保存等。 快捷菜单栏

不错，感谢您完成了整个 ms vscode 团队都不愿意做的事情。

我猜在这个阶段不可能把它放在一个单独的工具栏上？

@GorvGoyl非常好！ 5星！

不，太可怕了，太可怕了标签组的空间

这就是为什么我们需要公开一个 API 以允许“单独的可配置工具栏”

但就目前而言，这可能是最好的。鉴于它有 10k+ 用户，我会说肯定存在对工具栏的需求。这对我来说“足够好”了。

@GorvGoyl ：非常感谢您的扩展。 它对我来说是最好的工具栏。 太糟糕了，当您在扩展面板中搜索“工具栏”时它没有出现。

我是 VSCode 的新手，虽然我最初在安装过程中错过了显示工具栏的设置！ 找了很久才找到这个贴。

但是，我很容易找到了“打印机友好”的键盘快捷键 pdf。 （讽刺）大声笑。

所以......在开发团队看来，一个典型的 VSCode 用户在他的桌子上有一个键盘、一个鼠标和一堆备忘单。 不是我。 更讽刺的哈哈。

几乎每次我看到 vscode 更新时……我都阅读了 10 多种我实际上从未使用过的东西（诚然，这并不意味着没有人会使用）并认为……是的，但是……仍然没有工具栏。

我很欣赏人们试图开发尽可能提供帮助的扩展程序所付出的努力......但我觉得这个问题仍然存在并且几乎没有来自 ms devs没有任何理由就公然关闭的问题）。

一路走好团队！

请改用 Atom。 向 Atom 添加工具栏非常容易。 然而，现在 GitHub/Atom 已经被吞并，更新变得罕见和严重的错误（即语法着色）一直存在。 很遗憾看到他们让一个编辑器死亡，而不太关心另一个编辑器的用户需要什么。

哦，我将 webstorm 用于我将使用 vscode 的大多数事情......我仍然安装了它......我只是不希望用它替换一个称职的IDE（无论如何）。

我也喜欢一个工具栏，我可以在其中添加扩展操作。 键盘快捷键很酷，但我无法记住每个扩展程序所做的一切。