범위 밖

도구 모음이 없는 다른 인기 있는 아이디어를 보여주세요.

39548:

오랫동안 백로그에 있던 문제를 닫

vijayvepa는 2017년 12월 4일 15:34에 이 호를 열었습니다.
vscodebot이 2017년 12월 4일 18:01에 종료했습니다.
...오랜만이네요...벌써 2시간30분 :)

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 코드를 실제로 사용 가능하게 만드십시오.

나는 이것이 구현해야 할 큰 기능이 될 것이라고 확신하지만 이 기능 요청이 로드맵에서 가시성을 얻는 것을 방해해서는 안됩니다.

@alkorsan 도구 모음에 포함할 수 있는 좋은 기능 을 제공하는 목록에 광산을 추가하십시오...

개발자는 각 작업에 대해 클릭 가능한 버튼을 추가할 수 있는 옵션이 있어야 합니다.

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

나는 그것을 은퇴하고 싶습니다!

Atom에서 제공하는 사용자 지정 가능한 도구 모음은 내가 가장 그리워하는 기능 중 하나입니다. 실제 코드에 집중해야 하므로 새로운 단축키를 배울 필요가 없습니다. 가까운 장래에 무언가를 얻을 수 있기를 바랍니다! 훌륭한 일을 계속하십시오, Microsoft.

흥미롭게도 이 문제는 아직 범위를 벗어나지 않았으며 이 기능이 구현되기를 계속 희망합니다.

2018년 공식 로드맵 에서는 "해피 코딩", "신규 사용자와 기존 사용자 모두에게 더욱 즐거운 경험을 제공하고자 합니다" 및 "VS 코드를 도입하기 어렵게 만드는 차단 요소 제거"에 대해 언급하고 있으므로 특별히 언급하지 않습니다. 이 문제는 로드맵에 있으며 로드맵에 있어야 하며 언급된 내용을 기반으로 작업 중입니다.

@bpasero 는 이 문제에서 활동했으며 현재 VSCode 개발자입니다. Microsoft VSCode 팀 개발자가 시간을 내서 이 문제를 기록하고 계획이 무엇인지 말할 수 있다면 정말 좋을 것입니다.

그들은 기록에 남고 기본적으로 가까운 장래에 일어나지 않을 것이라고 말하지 않았습니까? 그것은 내가 모든 미해결 문제와 폐쇄 문제에 대해 이해하고 있는 것처럼 보이며 그것이 백로그에 갇히지 않을 것이라고 말하는 것 같습니다... 그러나 문제가 수없이 제기되었음에도 불구하고 "관심 없음"에 더 가깝습니다.

부정적인 피드백 루프를 시작하려는 것이 아니라... 하지만 이 주제는 아픈 것입니다... 그리고 안티 툴바의 음모 수준이 있는 것 같은 느낌이 듭니다. 어딘가에서 누군가가 그것에 대한 기능 요청의 양이 범용 도구 모음으로 이어지지 않을 것이라고 결정했습니다... 그리고 그들의 마음은 만들어졌습니다.

안녕하세요 @ronnyek 저는 이와 유사한 여러 개의 닫힌 문제를 보았고 귀하의 입장이 어디에서 왔는지 이해합니다. 나는 긍정적인 태도를 유지하려고 노력하고 있다. 이 문제가 오늘날에도 여전히 열려 있다는 사실은 vscode 팀에서 이것이 실제로 유효한 제안이라고 생각할 의향이 있다는 희망을 줍니다.

저도 착각하지 않았으면 좋겠습니다 :)

기본 도구 모음, 플러그인 특정 도구 모음 및 사용자 정의 가능한 사용자 지정 도구 모음의 부족이 신규 사용자를 위한 vscode의 진입/채택에 대한 실질적인 장벽이며 이 누락된 기능은 상관없이 vscode를 고수할 의향이 있습니다.

오 예, 오해하지 마세요... 저는 이 변화를 지지합니다. 그리고 제가 말했듯이 부정적인 피드백 루프가 되고 싶지 않습니다... . VS Code는 진행됨에 따라 도약하고 있으며... 도구 모음에 대한 반대를 정말 이해하지 못합니다. 지금은 웹스톰을 위해 프론트 엔드 편집을 위해 vscode를 쓰지 않았지만 미래에는 vscode를 옵션으로 사용하고 싶습니다.

너무 기초적인 것 같아, 나는 그것을 찾지 못했을 때 매우 놀랐습니다 ... 하지만 디자이너가 매우 최소한의 UI를 유지하는 철학을 가지고 있다면 아마도 지원하기 위해 노력할 가치가 없다고 느낄 것입니다.

아마도 누구나 이 원자 도구 모음 확장을 이식하려고 시도할 수 있습니다. https://github.com/suda/tool-bar

고정된 도구 모음을 수행하는 것을 목표로 하는 일부 코드로 기능 분기를 시작했습니다.
https://github.com/junalmeida/vscode/pull/1
당신이 그것의 일부가 되고 싶은지 나에게 물어보십시오.
나는 이미 3가지 일반적인 기본 작업으로 도구 모음(위치 지정과 같은 UI 항목)에 대한 초기 요구 사항을 만들었습니다. 내가 PR에 넣은 gif를 참조하십시오.

아직 해야 할 일이 많습니다.

@junalmeida 안녕하세요. 현재 이 기능 요청(다른 많은 요청과 마찬가지로)이 열려 있어 사용자로부터 더 많은 피드백을 수집할 수 있습니다. 바로 처리하고 싶기 때문이 아닙니다.
VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.

모든 기능 요청과 마찬가지로 가장 좋은 첫 번째 단계는 일반적으로 즉시 코딩을 시작하지 않고 토론을 시작하는 것입니다.
pull 요청 지침 https://github.com/Microsoft/vscode/wiki/How-to-Contribute#pull -requests를

안부
이시도르

@isidorn
atom은 최소한의 코드 편집기입니다.

notepad++는 매우 미니멀한 코드 편집기입니다.

vscode는 ... vim 방식의 코드 편집기입니다.
왼쪽 패널과 상단 메뉴를 삭제하십시오! 단축키만! 오직 하드코어!

마우스는 1946년에 발명되었지만 키보드를 사용하도록 강요합니다.
나는 많은 프로그램을 사용합니다. 모든 프로그램의 키 조합을 기억할 필요가 없습니다.

당신의 프로그램이 다른 사람들과 함께 사용되기를 원한다면 당신은 호환되어야 합니다. 어울리고 싶지 않다면(ms 방식) 원하는 대로 하면 되지만 신경 쓰는 척 하지는 마세요.

:화난:

@isidorn 요점은 알지만 이 주제와 다른 주제에서 이미 토론이 시작된 것 같습니다. 어쨌든, 나는 이것을 POC로 코딩하기 시작했고 사용된 모든 지침과 UI 코드를 이해하려고 노력했습니다. 이것이 공식 VSCode 팀의 방향이 아니면 문제가 되지 않지만 이것이 오픈 소스의 아름다움입니다. 누구나 포크하고 실험할 수 있으며 이것이 반드시 PR이 수락된다는 것을 의미하지는 않습니다. ;)

이것은 정말 이상한 결정이며 개인적으로 vscode를 채택하는 데 큰 방해가 될 것입니다(많은 다른 사용자도 상상합니다)

또한 도구 모음이 없기 때문에 모든 것이 상태 표시줄에 덤프됩니다. git-history, cmake와 같이 상태 표시줄을 엉망으로 만드는 확장 프로그램이 있습니다. 상태 표시줄 아이콘을 개별적으로 비활성화할 수 없기 때문에 다소 중요한 사항을 위한 공간이 없습니다.

VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.

나는 그것을 완벽하게 이해할 수 있지만, 여기서 필요한 조치는 아닙니다. 확장을 통해 도구 모음을 제공할 수 있도록 확장 작성자를 위해 일부 드로어블 영역을 노출하는 것은 완벽할 것입니다. 그렇게 하면 핵심 편집기가 완전히 지원할 필요가 없고 기본 환경이 확실히 영향을 받지 않습니다.

최근 개발 상황만 보면 VS Code가 모든 것이 구성 파일을 통해 수행되는 "하드 코어" 기능에서 이미 벗어나고 있음이 분명합니다. 완전한 구성 GUI가 제공되므로 VS Code가 이제 더 많은 마우스 중심 사용 사례도 수용하고 있음이 분명합니다. 도구 모음을 갖는 것은 더 작은 사용자 하위 집합을 위한 것이더라도 확실히 좋은 생각일 것입니다. 추가 확장에 대한 많은 가능성을 열어줄 뿐입니다.

+1

도구 모음이 선택적 기능이 될 수 없는 이유를 모르겠습니다. 슈퍼 미니멀을 원하십니까? 전원을 끕니다. 마우스를 통해 기능에 빠르게 액세스하고 싶으십니까? 전원을 켜십시오. 필요한 경우 플러그인으로 구현하십시오. 그러나 이러한 강경한 입장은 사용자가 프로젝트를 죽이기를 원하는 것에 반대합니다(예: Amarok 참조). VSC는 여러 면에서 훌륭하지만 도구 모음이 없다는 것은 많은 사람들에게 분명히 짜증나는 일입니다.

제발 부탁드립니다.. 툴바가 절실히 필요합니다. 툴바가 없으면 완전히 마비됩니다. 파일 사이를 탐색하는 방법을 모르겠습니다.

VS Code 헤더의 메뉴 줄 아래에 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- 스레드를 음소거

GUI보다 명령줄을 더 좋아하지만 이 GUI 편집기에 가장 기본적인 도구 모음조차 없는 것이 터무니없다는 OP에 절대적으로 동의해야 하는 30세 이상의 IT 베테랑(Windows-OS에서 비활성화될 수 있는 선택적 기능일지라도) 갑자기 너무 기본적인 GUI 기능에 반하는 GUI 앱 개발자/사용자).

추가 지원을 위해(부끄러워하지 않고) 가장 기본적인 메모장 교체조차도 가장 기본적인 도구 모음을 추가할 수 있는 기능이 있습니다. Notepad++의 goto - 아래와 같이 EVEN VIM FOR WINDOWS입니다. UNIX VI 포트가 GUI용 도구 모음에 코드를 던질 여유가 있을 때...당신이 요점을 알 것이라고 확신합니다.

그러나 그것은 얼마나 필요하며 그 뒤에 숨겨진 생각은 무엇입니까? IMO, 키보드를 사용하는 만큼 다른 이유 없이 "시각적" 그래픽 버튼을 사용하는 것이 항상 더 편안하다고 느꼈던 것이 있습니다. 바로 기본 파일 작업입니다. 예, 나는 완전히 깨닫고 동의합니다. 하지만 이것은 10/10번의 한 영역입니다. 다른 모든 Microsoft GUI에 대해 말하고 싶은 도구 모음 버튼(있는 경우)을 클릭하기 위해 주요 파일 열기/저장 작업당 4-5초를 기꺼이 사용하겠습니다. 지난 35년 동안 작성된 vscode 이외의 다른 운영자가 사용할 수 있게 되었습니다. 위의 의견을 보면, 가장 시간 효율적이지는 않지만 (나머지 흰머리를 유지하기 위해) 편안함, 편리함 및 단순한 조각이 있는 경우인 일반적인 워크플로 사용에서 저 혼자가 아닌 것 같습니다. 마음이 성과를 이긴다.

그리고 위의 것들(및 오프라인의 다른 많은 것들)과 마찬가지로, 제 기본 편집기가 저에게 얼마나 필수적인지, 사실은 사소한 것처럼 들릴 수 있지만, 이러한 기본 기능이 누락된 vscode는 작성하기에 충분한 편안함을 주지 못한다는 것입니다. 나의 기본 편집자. 예, 부분적으로 작동하는 도구 모음을 추가하는 타사 확장이 있을 수 있지만 핵심 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 팀을 관리하고 있다면 나는 그 디자인 선택을 옹호하는 DEV에게 파일 열기/저장/닫기보다 더 자주 거대한 "확장" 버튼을 클릭할 수 있는 한 사람을 나에게 보여달라고 요청할 것입니다. 파일 - 대신 모든 THOSE 작업이 사용자가 메뉴와 명령 모음을 통해 여러 번 클릭하고 명령을 입력해야 하도록 설계를 방어하세요?!?

해당 문제를 잠금 해제하면 많은 사용자가 여기에서와 같이 동의하게 될 것입니다. 그리고 @BenHayat 당신이 절대적으로 옳습니다. 90년대 후반에 저는 실제로 @ MS의 직위를 제안받았습니다. 그리고 제가 오늘날 그 직책에 있었다면 그것이 바로 제가

VS 코드에 작은 도구 모음을 갖고 싶습니다.
몇 가지 항목만 있으면 만족할 것입니다(뒤로/앞으로/마지막 편집 위치) - VS Code UX 팀은 도구 모음이 나쁘다고 느낄 수도 있습니다(제품 기본 도구 모음이 너무 많은 경우 동의합니다). 즉, 도구 모음이 이미 있는 것 같습니다(그림 참조). 하지만 거기에 있는 항목은 저에게 쓸모가 없으므로 그냥 교체하고 싶습니다.

나는 마침내 이것에 대한 논평을 나누었습니다. 저는 30년 동안 개발자로 일해 왔으며 한 가지 배운 것은 명령줄에서 완전 자동화된 전달에 이르는 특정 작업에 적합한 도구를 사용하는 것입니다. 각각에 대한 이유가 있으며 고급 AI 통합으로 소프트웨어 개발 도구가 크게 변경됨에 따라 도구 모음은 과거의 명령줄이 될 것입니다. VS 코드에는 IDE에서 명령줄을 생략하는 것과 동일한 기본적인 진화 구성 요소가 없습니다. 제 컨설팅 업무에서는 Visual Studio Professional과 JetBrains Ultimate를 두 가지 기본 패키지로 사용합니다. VS 코드는 도구 모음이 없는 대부분의 전문 IDE 패키지의 유연성과 확실히 일치하지 않습니다. 나는 첫 해 개발자를 VS 코드 앞에 두지 않고 그/그녀가 약화된 IDE를 배우게 하는 데 내 돈을 낭비하지 않을 것입니다. 그냥 내 솔직한 의견.

@pgmolloy 저도 같은 문제가 있습니다. 현재 Visual Studio와 webstorm을 주로 사용합니다... 일반적으로 작동합니다(경우에 따라 다른 플러그인과 더 잘 어울리는 더 완전한 플러그인이 있는 경향이 있음). 하지만 환상은 없습니다. 그것들은 vscode만큼 가벼우며 즐겁게 작업할 수 있습니다.

내 문제는 우리가 실제로 코드 속도를 늦추거나 "경량 코드 편집기"가 아닌 것으로 만드는 훨씬 더 많은 기능에 대해 이야기하고 있지 않다는 것입니다. ). 툴바와 그 버튼 구성은 문자 그대로 바로 그 명령 팔레트 명령을 호출하는 것일 수 있습니다. 구성은 디버깅과 같은 간단한 구성일 수 있습니다(또는 최소한 그랬습니다).

제 생각에는... (그리고 이것이 반드시 사실에 의해 뒷받침되는 것은 아닙니다....), 그것은 방금 결정되었습니다... 누군가, 어딘가에서 그들이 도구 모음의 아이디어를 좋아하지 않는다고 결정했기 때문에 우리는 도구 모음 기능 요청과 모호하게 유사한 문제에 대한 일부 음모 수준의 처리.

이 기능을 가진 풀 요청 심지어 조그마한 작은 기회가 있었지만 IF 더 나은 CSS / HTML로, 그리고 IF I ..받을 수 .would ...이 시간과 노력을 것입니다. "우리는 이것을 하고 싶지만 우리가 직접 작업할 시간이 없다"는 것이 이해가 됩니다. 이전 기록과 거의 즉시 또는 생성 직후에 종료된 수십 가지의 다른 관련 문제를 기반으로 했을 때 꽤 자신합니다. vscode 팀은 도구 모음과 관련된 끌어오기 요청을 원하지 않습니다. 그것은 그들의 비전과 일치하지 않으며, 그들은 총에 집착합니다.

나는 틀렸다는 것이 증명되기를 원합니다.

@ronnyek :

제 생각에는... (그리고 이것이 반드시 사실에 의해 뒷받침되는 것은 아닙니다....), 그것은 방금 결정되었습니다... 누군가, 어딘가에서 그들이 도구 모음의 아이디어를 좋아하지 않는다고 결정했기 때문에 우리는 도구 모음 기능 요청과 모호하게 유사한 문제에 대한 일부 음모 수준의 처리.

@bpasero 와 @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 "적극적인 코딩"은 모든 사람을 위한 보편적인 솔루션이 아닙니다. 웹 개발자는 시간의 절반을 브라우저에서 보내고 레이어를 조정하고 Chrome 개발자 도구와 같은 것을 사용합니다. 게임 개발자는 편집기와 게임 사이를 끊임없이 전환할 수 밖에 없습니다. 둘 다 Photoshop 및 기타 소프트웨어로 전환하여 빠르게 그림을 그리거나 만들 수 있습니다. 따라서 대부분의 경우 손에 마우스가 있으며 마우스를 계속 사용하여 모든 작업을 수행하는 것이 훨씬 좋습니다. 키보드 중심 사용자와 마우스 중심 사용자를 위해 VSCode에 두 가지 모드가 모두 있어야 한다고 생각합니다. 어쩌면 "메인 메뉴"로도 충분하지 않을 수 있습니다. 개인적으로 Photoshop 동작을 모방하거나 MS Office의 리본과 같은 수직 트레이와 같은 것을 만들 수 있는 옵션이 있었으면 합니다. 물론 매우 특정한 작업을 위한 완전한 선택 사항으로 - 내 말은 명령 상자의 모든 기능을 메뉴 항목으로 미러링할 필요는 없습니다. 소유자가 그린 메뉴와 상자를 만들 수 있는 기회를 주기만 하면 됩니다. 유감스럽게도 이 문제로 인해 Iia 또는 IntelliJ IDEA Community Edition으로 이동해야 하며 남은 옵션이 없습니다.

이상적인 도구 모음 기능 요구 사항:

1. MS Office 2003 도킹 가능한 도구 모음에 최대한 가깝습니다. (이것을 한 번도 사용해 본 적이 없다면 완벽한 도구 모음의 가장 좋은 예였습니다.)
2. 관련 도구가 함께 그룹화된 기본 도구 모음 세트를 포함합니다.
3. 도구 모음을 개별적으로 띄우거나 도킹하는 기능. 도킹은 위쪽, 아래쪽, 왼쪽 또는 오른쪽일 수 있습니다.
4. 도구 모음을 표시하거나 숨기는 기능
5. 새 도구 모음을 만드는 기능
6. 기본 및 사용자 생성 도구 모음에 도구를 추가 및 제거하는 기능.
7. 기본 제공 도구는 VSCode 기능 및 명령과 연결됩니다. 사용자 도구는 사용자 스크립트 또는 매크로와 연관될 수 있습니다.
8. 도구 위로 마우스를 가져가면 이름, 간단한 설명 및 해당 키보드가 표시되어 VSCode 기능 및 이에 상응하는 항목을 검색하고 학습하는 데 도움이 됩니다.
9. 사용자는 아이콘을 표시하거나 텍스트 이름을 표시하거나 둘 다를 표시하도록 개별 도구를 구성할 수 있습니다.
10. 도구는 단일 클릭 명령(예: 저장), 명령 드롭다운 목록(예: 빌드, 모두 빌드, ...) 또는 텍스트 입력(예: 글꼴 크기)일 수 있습니다.
11. 도구 모음 구성 및 사용자 정의는 사람이 읽을 수 있는 JSON으로 내보내고 가져올 수 있습니다. 가져오기는 추가적이거나 파괴적일 수 있습니다.
12. 정교한 도구 및 도구 모음을 만들기 위한 간단한 API 및 개체 모델입니다. 상황에 따라 도구를 반응적으로 활성화/비활성화하는 지능형 상태 머신.
13. NOT 현재 MS 오피스 리본있다. 너무 많은 공간을 차지하며 너무 자주 한 번 대신 2-3번의 클릭이 필요합니다.

나는 이것을 돌파하고 제정신을 회복할 수 있는 댐 버스터가 있다고 믿습니다. 바로 접근성입니다.

도구 모음을 포함하지 않거나 허용함으로써 VS Code 팀과 Microsoft는 시각 장애가 있는 사용자를 기꺼이 제외한다는 입장을 취하고 있습니다. 이러한 사용자는 텍스트 편집기 글꼴 크기를 늘리고 음성 판독기 및 편집 도구를 사용할 수 있지만 텍스트 기반 메뉴는 사용하기가 매우 어렵습니다.

Microsoft, 시각 장애가 있는 사람들의 기여를 높이 평가하십니까? 아니면 계속해서 이 제품과 이 제품을 사용해야 하는 직업과 기회에서 제외하시겠습니까?

VSCode는 오픈 소스로 "온" 이후 Microsoft의 과대 광고 프로젝트임이 밝혀졌습니다.
MS는 VSCode가 느리고 느린 Visual Studio XXXX의 경쟁자가 되는 것을 허용하지 않습니다.
프로필 세부 정보로 인해 주요 기여자의 이러한 저항을 이해하는 것은 어렵지 않습니다. 그들은 마이크로소프트에서 일하고 있고 해고될 수 있습니다.
도구 모음이 있는 VSCode의 분기를 기다리고 있습니다.

@NickMaev Visual Studio 자체는 훌륭하게 작동하며 코드보다 훨씬 더 많은 것을 제공합니다. 즉, vscode는 궁극적으로 Microsoft의 프로젝트가 옳거나 그르거나 무관합니다.

나는 도구 모음을 추가하는 것을 강력히 지지해 왔습니다. 왜냐하면 그것은 적어도 많은 소비자(저를 포함하여)가 오랫동안 요구하고 불평해 온 것이기 때문입니다.

헐; 박사; - 도구 모음을 추가해야 할 의무는 없다고 생각하지만 제출, 제출 및 마감, 제출 및 속임수로 표시된 문제, 제출 및 범위를 벗어난 것으로 표시된 문제 등 사람들이 이것을 원하고 제품 관리 또는 vscode 개발이 관리된다는 것은 그것에 대해 약간의 힘이 있습니다. (나는 그들이 왜 그렇게 반대하는지 정당한 이유를 아직 듣지 못했습니다)

마이크로소프트, 그냥 사람들이 원하는/바램을 인정하고, 만약 그것이 정말로 한 두 사람이 도구 모음에 대해 단호하게 반대한다면... 그렇게 말하십시오. 이미 존재하는 포크에 추가하는 데 시간과 노력을 기울이겠습니다.

이 버그는 이제 개발자가 무시할 필터가 있는 블랙홀입니다. 그것은 사람들이 그것을 환기시키고 그것이 실제로 일어날 수 있기를 바랄 수 있게 합니다. 아무 것도 수행되지 않는 동안 문제에 대해 새로운 버그가 열리는 것을 방지합니다. 소프트웨어 개발이 사용자의 필요가 아닌 맹목적인 이념에 의해 주도될 때 발생합니다.

확실히 이것은 확장으로 할 수 있습니까? 핵심 제품에 있어야 하는 이유는 무엇입니까? 그것은 이미 가장 인기 있는 코드 편집기로, 대부분의 사용자가 도구 모음이 없는 것에 대해 완벽하게 만족하고 있음을 나타냅니다. 이것은 확장에 대한 100% 완벽한 시나리오입니다. 코딩하세요 여러분!

이것은 확장에 대한 100% 완벽한 시나리오입니다.

똑똑한 것 같지만... 이봐! vscode는 툴바 생성을 위한 API를 지원하지 않습니다. 티켓을 읽어라 얘들아!

확실히 이것은 확장으로 할 수 있습니까? 핵심 제품에 있어야 하는 이유는 무엇입니까? 그것은 이미 가장 인기 있는 코드 편집기로, 대부분의 사용자가 도구 모음이 없는 것에 대해 완벽하게 만족하고 있음을 나타냅니다. 이것은 확장에 대한 100% 완벽한 시나리오입니다. 코딩하세요 여러분!

사람들이 완벽하게 행복하다는 가정을 하고 싶지는 않지만 API가 있고 모든 사람에게 도구 모음을 강제하지 않는다면 개인적으로도 받아들일 수 있다는 데 동의합니다.

VS Code는 효율적이고 아름답고 훌륭한 코드 편집기입니다... 어쩐지 UX가 완전히 뒷자리에 앉은 것 같습니다.

도구 모음이 필요합니다. 저는 VBScript에 대한 경험이 풍부하여 PowerShell에 대해 더 많이 배우기 시작했습니다. 대부분의 vbscript 편집에 Notepad++를 사용하고 PowerShell ISE를 배우기 시작했습니다. PowerShell ISE에는 최소한 도구 모음이 있지만 내가 말할 수 있는 한 사용자 지정할 수는 없습니다. PowerShell ISE보다 더 나은 도구 모음을 갖기를 희망하여 VSCode에 대해 듣고 설치했습니다. VSCode에서 도구 모음을 직접 찾을 수 없어서 이 스레드를 검색하여 찾았습니다. VSCode에 도구 모음이 전혀 없음을 확인하는 이 기능 요청으로 이미 제거했습니다.

툴바 필수! 이 편집기 없이는 사용할 수 없습니다. 나는 최소한 필요한 후크를 제공하는 것에 대한 저항을 믿을 수 없습니다. 분명히 팀의 이념적 소름이 나옵니다. 놀라운!

61336

이것이 여러분이 해야 할 일이라는 것을 마침내 인정할 수 있습니까?! 이것은 매우 똑같은 것을 묻는 많은 사람들의 많은 스레드 중 하나일 뿐입니다.

도구 모음을 원하는 사람들이 도구 모음을 선택할 수 있도록 도구 모음 프레임워크를 구축하기만 하면 됩니다.

지옥은 우리에게 PR이 실제로 수용을 위해 고려될 것이라는 믿음의 표시를 제공합니다. 그리고 나는 당신이 그 기능에 자원하는 많은 사람들을 얻을 것이라고 장담합니다.

@isidorn 귀하는 '현재 이 기능 요청(다른 많은 요청과 마찬가지로)이 열려 있으므로 사용자로부터 더 많은 피드백을 수집할 수 있습니다. . . .'

피드백이 계속 들어오는 것 같지만 다른 방향으로 흐르는 것은 없습니다. VSCodeteam의 누군가가 이 기능을 지원하는 데 흥미가 없어 보이는 이유와 그 이유를 설명할 수 있습니까?

'VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.'

내 생각에 VSCode는 단순한 코드 편집기가 아닌 IDE 또는 IDE 구축 플랫폼입니다. 최소한의 코드 편집기는 또 다른 Microsoft 제품인 메모장입니다.

'모든 기능 요청과 마찬가지로 가장 좋은 첫 번째 단계는 일반적으로 토론을 시작하고 바로 코딩을 시작하지 않는 것입니다.'

이 피드백 문제에서 제 질문은 토론이 어디에 있습니까?

@ronnyek 은 올바른 아이디어를 가지고 있습니다.

훌륭한 제품이지만 이 문제는 다소 신비스럽습니다.

이 기능은 전 세계 어디에서나 공통적으로 논의되어야 할 사항입니다...

요구 사항? Visual Studio 코드가 말한 것처럼 거기에서 하나를 복제하십시오.
기구? 그것은 정말로 약간의 조사가 필요하지만 이 문제는 이미 1.5년이 되었습니다.

새 상태 표시줄과 "메뉴 표시줄" 사이에 작은 단계가 있다고 생각합니다.

vscode 팀이 내키지 않는 작은 단계... 그것이 핵심입니다. 여기에서 우리는 이 문제가 생성된 지 1년이 넘었고 동일한 기능에 대해 많은 사람들이 댓글을 달고 수많은 다른 문제가 발생했습니다. 그러나 여전히... 이 기능에 대한 동일한 음모 수준 반대입니다.

웹스톰을 계속 사용하게 되어 기쁩니다. VScode 팀으로 가는 길!

여기에 다른 목소리를 추가하겠습니다. VS Code에 도구 모음이 없다는 것은 나에게 완전한 미스터리입니다. 나는 그것이 추가되었는지 확인하기 위해 가끔씩 다시 방문하지만 항상 내 이전 편집기로 돌아갑니다. VS Code에는 좋아할 것이 많지만 이 부족한 항목이 나를 놀라게 합니다.

진심으로, 마이크로소프트! 그렇지 않으면 깔끔한 코드 편집기 / IDE는 훌륭한 GUI 디자인을 높이 평가하는 사람들에게 쓸모가 없습니다. 2019년입니다. 정확히 왜 여전히 명령줄을 사용하고 있습니까?

2019년입니다. 정확히 왜 여전히 명령줄을 사용하고 있습니까?

천 배 빠르기 때문에?

이 기능을 추가하거나 확장 프로그램에서 이 기능을 추가할 수 있도록 하는 또 다른 투표입니다.

어떤 사람들의 두뇌는 키보드 단축키를 처리하지 못합니다. 이 생략은 매우 어리석은 일입니다.

그것은 좋은 편집기이지만, 백 가지 단축키를 배우거나 메뉴를 파헤치는 데 방해가 될 수는 없습니다. 도구 모음이 없는 하나의 IDE는 생각할 수 없습니다. 그들을 제외하기로 한 결정은 Windows Phone과 마찬가지로 어리석은 일입니다!

VS Code를 강등하고 간단한 로그 뷰어로 사용합니다.

여전히 절실히 필요합니다. 아마도 현재 나의 가장 큰 사용자 정의 포인트 고통. 내가 가진 확장 프로그램과 명령이 많을수록 크롬에 몇 개를 둘 곳이 더 필요합니다.

거의 2년이 지났지만 여전히 코멘트, 확인, 명시된 의도가 없으며 단순히 다시 한 번 백로그에 추가되었습니다. SSS-SUUUUUPER 듀퍼. (적어도 그냥 삭제되거나 닫히지 않은 것 같아요)

어떻게 그렇게 간단하고 수없이 행해진 일이 소홀히 하기 전에 얼마나 놀라운지. 내가 이미 라이센스를 소유하고 있는 웹스톰으로 밀어붙일 뿐이라고 이전에 말했습니다.

이 전체 상황이 어떻게 된 클러스터인지 정말 놀랐습니다. VScode 팀으로 가는 길!

불만이 충분하면 바뀔 수 있습니다. MSFT 제품에서 많이 발견한 "우리가 당신보다 더 잘 안다"는 또 다른 사례인 것 같습니다. 방금 VSC를 제거하고 메모장++을 다운로드했습니다.

불만이 충분하면 바뀔 수 있습니다. MSFT 제품에서 많이 발견한 "우리가 당신보다 더 잘 안다"는 또 다른 사례인 것 같습니다. 방금 VSC를 제거하고 메모장++을 다운로드했습니다.

똑같이 했다. VsCode는 내 요구에 평행한 경로를 밟았으므로 메모장++(와인에게 감사합니다)/숭고도 다시 돌아갑니다. msft 상호 작용이 없는 소규모 팀이 어떻게 완전히 다른 작업을 수행하고 대부분의 경우 더 잘 수행하는지 재미있습니다. 음, 지속되는 동안 좋았습니다.

도구 모음이 없는 모니터에서 상태 표시줄이 어떻게 엄청나게 길 수 있는지 봅시다.

정직하게 시도했지만 VS 코드를 버리고 메모장++로 돌아갔습니다. 내가 사용해야 하는 모든 명령을 기억할 수 없고 부팅할 리소스가 많이 필요합니다. 제 생각에는 단 하나의 텍스트 파일을 로드하기 위해 700MB 이상의 RAM을 차지하는 것은 확실히 툴바가 있어야 합니다.

도구 모음이 없는 모니터에서 상태 표시줄이 어떻게 엄청나게 길 수 있는지 봅시다.

그것들을 화면 상단으로 옮기면 마술처럼 수평 공간을 덜 차지하지 않습니다...

그것들을 화면 상단으로 옮기면 마술처럼 수평 공간을 덜 차지하지 않습니다...

전용 도구 모음은 다음을 사용할 수 있습니다.

1. 더 큰 아이콘
2. 적은 텍스트
3. 스태킹/목록 숨기기
4. 여러 행
5. 제어 그룹의 손쉬운 관리(일부 플래그 또는 상태에 따라 표시/숨기기)
6. 그리고 아마도 유용하거나 필요한 다른 미묘한 UX 일 것입니다.

이것에 어떤 견인력이 있는지 확인하기 위해 방문하시겠습니까?
툴바를 추가하는 확장용 API가 아직 심각하지 않습니까?

이것은 나를 웃게 했다...
Visual Studio 코드 로드맵 2020

• 접근성 기능에 의존하는 모든 사람을 위한 최고의 편집자가 되십시오.
  ...

:runner: VS Code를 접근성이 뛰어난 개발자 도구로 만듭니다. 우리는 의견과 지침을 얻기 위해 커뮤니티에 참여하고 협력할 것이며 정직하게 유지하기 위해 여러분이 필요합니다.

이 "커뮤니티"는 누구입니까? 누가 뭐래도 소외된 기분... 최대한 팔과 손을 쉬어야 고통을 최소화할 수 있어요. 툴바가 없다는 것은 말 그대로 저를 아프게 합니다.

이 툴바 문제에 대한 개발자의 피드백이 없기 때문에 다음을 해석하는 방법을 모르겠습니다...

워크벤치에서 보다 풍부한 사용자 정의 기능을 안전하게 제공하는 방법 조사
...
상황에 맞는 메뉴와 같은 UI 사용자 정의 지원을 확대합니다.

둘 다 긍정적으로 들리지만 의심스럽습니다. 컨텍스트 메뉴 사용자 정의는 2016년부터 사용되어 왔습니다. 그렇지 않습니까?
2016년 6월 업데이트(버전 1.3)
제가 잘못 이해하고 있는 건가요? 아니면 2020년 로드맵이 2015년부터 복사/붙여넣기 된건가요!?

• 접근성 기능에 의존하는 모든 사람을 위한 최고의 편집자가 되십시오.
  ...

🏃 VS Code를 접근성이 뛰어난 개발자 도구로 만드십시오. 우리는 의견과 지침을 얻기 위해 커뮤니티에 참여하고 협력할 것이며 정직하게 유지하기 위해 여러분이 필요합니다.

LOL... 확실히... 나는 그들이 툴바와 같은 유용한 것들을 원하는 사람들보다 더 많은 시각 장애인 코더를 가지고 있다고 확신합니다(장애를 노크하지 않는 것에 대해 유감스럽게 생각합니다) 그것은 코스와 동등합니다... 모든 유용한 것들은 거절됩니다 범위 밖 으로 릴리스 에는 아무도 신경 쓰지 않는 18 페이지 의 릴리스 정보 가 포함되어 있습니다 .

제 말은... 저는 모두 무료지만 이 기능을 구현하기 위해 더 많은 개발자가 필요하다면 이 유용한 기능 요청을 무시하지 않는다면 "Pro" 버전에 비용을 지불할 것입니다... Visual Studio는 필요없지만, 개발자들이 소홀히 하지 않은 합리적인 가격의 VSC... I'm game...

한편 그들은 도구 모음을 접근성 모드로 전환하고 :/

@minig0d
키보드 단축키를 사용한 적이 있습니까? 또는 프레젠테이션을 위해 편집기에서 글꼴 크기를 늘렸습니까? 알고 있든 모르든 접근성 기능을 사용하고 있습니다.

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

문제가 충분한 찬성표를 받을 때까지 기다릴 수 없다면 언제든지 PR을 제출할 수 있습니다.

@sketchbuch 예, 그것이 무엇인지 잘 알고 있습니다... 풍자였습니다... 핵심에 내장되어 있으면 좋을 유일한 키보드 단축키는 여러 명령("매크로")이지만 이미 플러그인이 있습니다. 그리고 우리는 이미 내가 마지막으로 확인한 글꼴 크기를 늘릴 수 있습니다... 예, 지금 코딩 중이고 아주 잘 작동합니다... 이제 실제 기능을 사용할 수 있습니까?

문제가 충분한 찬성표를 받을 때까지 기다릴 수 없다면 언제든지 PR을 제출할 수 있습니다.

출시된 이러한 "기능"에 대한 찬성 수를 보셨습니까? B/C 지난번 내가 몇 가지를 확인했을 때, 그것들은 많은 ^^^ 유형의 요청보다 훨씬 낮았고 훨씬 더 오래 열려 있었습니다. 나는 전체 찬성 투표가 길을 건너는 버튼과 더 비슷하다고 생각합니다. 빛이 바뀔 때까지 순전히 사람들을 즐겁게 하기 위한 것입니다.

이 스레드에 모든 장단점이 나와 있는데, 그냥 옵션으로 두지 않는 이유는 무엇입니까? 툴바를 좋아하는 사람은 켤 수 있고, 그렇지 않은 사람은 비활성화 상태로 둘 수 있습니다. 이것은 로켓 과학이 아닙니다.

마이크로소프트는 그렇게 하지 않을 것입니다. 우리는 그것을 해야 합니다. 누군가가 이미 그것을 했습니까?

내가 사용하는 제한된 도구 모음인 Jerrygoyal의 Shortcut Menu Bar 가 있습니다.

그러나 주요 질문은 다음과 같습니다.

• VSC의 도구 모음용 API가 사용 가능하고 완전히 문서화되어 있습니까?

내가 사용하는 제한된 도구 모음인 Jerrygoyal의 Shortcut Menu Bar 가 있습니다.

물론, 그러나 그러한 확장을 사용하면 1) 다른 모든 응용 프로그램에서 사용되는 도구 모음처럼 보이지 않습니다. 2) 구성할 수 없습니다. 확장 작성자가 추가한 내용이 그대로 남아 있습니다.

따라서 Microsoft Visual Studio Code 팀의 공식 도구 모음 API/확장이 필요합니다.

따라서 Microsoft Visual Studio Code 팀의 공식 도구 모음 API/확장이 필요합니다.

지금은 어떤 해

가자 MS?! 개발자 고객을 행복하게 유지하는 것이 얼마나 어려울 수 있습니까? 우리는 그렇게 많이 요구하지 않습니다. 우리는 당신의 고객이고 당신의 이익이라는 것을 기억하십시오... 그것에 대해 생각하십시오...

이 작업을 완료할 수 있습니까... 아니면 vscode 팀에서 이것이 없는지 또는 없을지에 대한 유용한 정보가 있습니까? 아마도 저는 개발자들이 기꺼이 PR로 받아들이고 거기에 구현하려는 것이 있는지 보러 갈 것입니다. 문제가 해결되었습니다.

처음에는 vscode에서 도구 모음을 찾을 수 없을 때와 같은 혼란을 느꼈고 "신기술이 대체 무슨 일인가"라고 생각했습니다.

하지만 지금은 다릅니다. 저는 어떤 도구 모음이나 메뉴보다 Command Palette를 더 좋아합니다.

1. 키보드에서 F1 키를 눌러 명령 팔레트를 표시합니다(또는 Ctrl+Shift+P를 눌러 동일한 효과를 나타내지만 더 많은 노력이 필요합니다 :p).
2. 검색하려는 명령을 입력합니다. 이 명령 검색 기능은 매우 스마트하므로 검색하려는 항목을 입력하십시오.
3. 키보드를 사용하여 명령을 선택하거나(방향 버튼을 누른 다음 Enter 키를 누름) 클릭합니다.

메뉴나 도구 모음을 찾는 것은 답답할 수 있습니다. 메뉴나 도구 모음이 너무 많으면 생활이 어려워집니다. 따라서 입력하여 모든 명령을 검색하는 기능은 매우 유용합니다.

처음에는 vscode에서 도구 모음을 찾을 수 없을 때와 같은 혼란을 느꼈고 "신기술이 대체 무슨 일인가"라고 생각했습니다.

하지만 지금은 다릅니다. 저는 어떤 도구 모음이나 메뉴보다 Command Palette를 더 좋아합니다.

메뉴나 도구 모음을 찾는 것은 답답할 수 있습니다. 메뉴나 도구 모음이 너무 많으면 생활이 어려워집니다. 따라서 입력하여 모든 명령을 검색하는 기능은 매우 유용합니다.

그러나 이것은 완전한 사무실 유형의 리본이 아니라 Windows의 빠른 액세스 도구 모음(예: 소수의 즐겨찾는/자주 사용하는 명령을 넣는 것)에 대해 더 많이 이야기하고 있습니다.

즉, 1 클릭 대 최소 2회의 키 입력(사용한 절대 마지막 명령이라고 가정)(그리고 아래쪽 화살표를 몇 번 누르고 선택하거나 몇 글자를 입력하고 선택하다...

팔레트는 특정 작업에 적합하지만 마우스를 손에 들고 키보드로 돌아가는 것이 산만해지는 다른 작업이 있습니다...

@thariqnu-ifm
키보드 없이 명령 팔레트를 얼마나 정확하게 사용합니까?
왜 우리는 명령 팔레트와 선택적 도구 모음(또는 최소한 API)을 가질 수 없나요?

한 가지 강력하게 짚고 넘어가야 할 점은 VSCode 팀이 확장 기능으로 수행할 수 있는 기능을 추가하고 싶지 않다고 반복해서 밝혔습니다. API, 이것은 그에 따라 구현되어야 합니다 :)

@thariqnu-ifm
키보드 없이 명령 팔레트를 얼마나 정확하게 사용합니까?
왜 우리는 명령 팔레트와 선택적 도구 모음(또는 최소한 API)을 가질 수 없나요?

팔레트의 또 다른 문제는 구조화되어 있지 않다는 것입니다. 단일 콤보 상자에 덤프된 모든 명령의 목록일 뿐입니다. (예, 올바른 명령 이름을 추측하고 입력하여 검색할 수 있습니다.)

그들은 단지 탭바에 대한 마우스휠 지원을 추가했을 뿐입니다... 언젠가는 여러 줄 탭바를 가질 수 있게 될 것이고 마침내 탭바에서 10개 미만의 탭 문서를 볼 수 있게 될 것입니다... 그들이 모든 탭 문서를 보여주는 드롭 메뉴 버튼을 제공하는 것을 귀찮게하는 것처럼 ... 대신에 단일 행 탭 막대에 시각적으로 표시된 것보다 더 많은 문서를 보려면 탐색기 사이드 바를 열어야합니다.

MS가 2020년에 와서 개발자들이 20년 전에 소프트웨어의 핵심 기본 사항으로 추가한 것을 요구할 정도로 좋은 GUI와 UX를 모두 버리게 된 이유는... 툴바처럼...

어쨌든 특정 확장/기능, 켜기/끄기를 토글할 수 있고 해당 확장/기능이 켜짐 또는 꺼짐을 나타내는 버튼을 시각적으로 볼 수 있을 때 ... 바로 내 화면에서 기쁠 것입니다! 또한 동일한 작업을 수행하기 위해 키 콤보와 망치질 키를 수행하는 대신 짧은 시간 내에 클릭할 수도 있습니다. 입력해야 하는 확장 이름 기능 명령을 잊어버리면 짜증이 납니다. 도구 모음 버튼/아이콘이 놀랍습니다.

이 기능이 우선 순위에 있어야 하기 때문에 이 기능이 우선 순위에 있지 않다는 사실에 정말 놀랐습니다.

VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.

하! :))
미니멀리즘이란 무엇을 의미합니까?

높이를 조절할 수 없고 지하철 창과 같은 탭 버튼은 미니멀리즘을 의미합니까?

편집기 영역보다 화면에서 더 많은 공간을 차지하는 메뉴, 작업 표시줄 등의 거대한 버튼 패딩은 미니멀리즘을 의미합니까?

vscode 편집기 사용자 정의에 3개월을 낭비했습니다. 예, 찾았습니다, 내 편집기!

그리고 내가 어디에서 코딩하고 있다고 생각합니까?
예, 맞습니다 - 메모장에서 ++

안녕하세요, 현재 이 기능 요청(다른 많은 요청과 마찬가지로)이 열려 있으므로 사용자로부터 더 많은 피드백을 수집할 수 있습니다. 바로 처리하고 싶기 때문이 아닙니다.
VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.

@isidorn 당신의 답장에 20개의 엄지손가락을 얼마나 무심한지 알 수 있을까요?

당신은 미니멀리즘적이라고 말하지만 나는 Notepad++와 같은 것을 매우 미니멀한 것으로 간주할 것입니다... 한편, 우리는 git / 버전 제어가 내장되어 있습니다(내가 아는 한 "최소한의" 편집자는 포함하지 않습니다... 디버깅을 받았습니다... 최소한의 코드 편집기보다 IDE 기능에 가깝다고 생각하십니까? 자체 프로세스 모니터가 있습니까? 그런 기능이 있는 코드 편집기를 본 적이 없다고 생각합니다...

그러나 그것이 가지고 있지 않은 것이 무엇인지 아십니까? TOOLBAR... 도구 모음이 무엇인지 아십니까? 대부분의 코드 편집기는 VIM을 게시합니다(대부분)... 어느 것이 그렇지 않습니까? Sublime은 내가 생각할 수 있는 유일한 원격 주요 기능이 아닐 수도 있습니다(사용한 적이 없는지 확실하지 않음). 그래서 목표는 미니멀리스트입니까, 아니면 숭고한 사용자를 MS 생태계로 유인하기 위한 Sublime 모조품입니까?

아... 야 내가 거의 잊어버렸는데... 3가지 원격 편집 확장 프로그램(원격 - SSH, 원격 - 컨테이너, 원격 - WSL 등)을 개발하는 것은 마이크로소프트가 아닌가? 그런 기능이 내장된 최소한의 편집기를 기억할 수 없습니다... 그리고 철학은 MS가 편집기를 개발하고 타사 확장을 통해 확장성을 처리한다는 철학이라고 생각했습니다. 어깨를 으쓱하다 ...

Microsoft와 함께하십시오. 올바른 일을 한 번만 수행하고 고객 기반에 귀를 기울이십시오. 도구 모음이 이미 준비되어 있다고 확신합니다. 이 도구 모음을 빌드에 포함하고 청중의 50%를 추가로 만족시키기만 하면 됩니다. 선택에 관한 모든 것입니다. 툴바를 원하는 사람들은 켜십시오. 안하시는 분들은 놔두세요. 문제는 무엇입니까?????

VSCode는 최소한의 코드 편집기이므로 사용자 지정 도구 모음을 추가하는 PR을 받아들이기를 꺼립니다.

아마도 isidorn만 그렇게 생각하고 그가 직업을 바꾸면 한 달 안에 도구 모음이 제공될 것입니다. 문제는 그에게만 있는 것이 아닐 수도 있습니다.

Microsoft와 함께하십시오. 올바른 일을 한 번만 수행하고 고객 기반에 귀를 기울이십시오. 도구 모음이 이미 준비되어 있다고 확신합니다. 이 도구 모음을 빌드에 포함하고 청중의 50%를 추가로 만족시키기만 하면 됩니다. 선택에 관한 모든 것입니다. 툴바를 원하는 사람들은 켜십시오. 안하시는 분들은 놔두세요. 문제는 무엇입니까?????

그들은 고객 요구를 기반으로 "우선 순위를 지정"하려고 노력하고 있습니다... 즉, 다음 Rockstar 기능 릴리스에서 작업하고 있습니다... 아마도 커피 메이커에 내장된 Raspberry Pi용 API와 같은 것입니다... 만일을 대비하여 Java로 일부 Java를 프로그래밍하고 싶습니까? 당신은 수요가 매우 높은 물건을 알고 있습니다... 그들은 VSCode를 함무라비 법전 언어로 번역하려고 할 것입니다... 나는 그것이 일부 지역에서 꽤 유명하다고 들었습니다...

농담입니다... 하지만 진지하게 말하자면... 저는 MS의 공식적인 답변을 어떤 식으로든 좋아할 것입니다... 왜냐하면 그들이 앞으로 어떻게 발전할 것이며 미래 비전에 대한 정보는 제공되지 않기 때문입니다. 현재 행동과 일치하는 것 같습니다 ...

그들이 30분을 관리할 수 없다면 선택적 도구 모음/api를 구축하는 데 걸릴 것입니다... 그러면 우리 중 많은 사람들이 아마도 다른 편집기로 돌아가야 할 것입니다...

쓸모없는 패딩에 대한 한 사람의 아이디어는 잘 정의된 인터페이스에 대한 또 다른 아이디어입니다... notepad++는 잘 설계되지 않았거나 사용하기에 적합하지 않습니다. 나는 메모장++과 에디트패드 프로를 사용했는데 나중에는 훌륭했지만 둘 다 버튼이 비좁은 구식으로 보입니다. VSC에 아무것도 없어서 다행입니다. 처음 atom을 시도했을 때 명령 팔레트 - 또는 vsc -가 마음에 들지 않았지만 몇 년 동안 사용한 후에는 버튼을 놓치지 않거나 사용하기 어려운 명령 팔레트를 찾지 못했습니다. . 메모장++로 되돌아가는 대신 시간을 좀 주세요.

... 청중의 50%를 추가로 만족시키십시오...

약 240명이 OP에 긍정적인 이모티콘을 추가했습니다... VSC가 약 480명만 사용한다고 생각하는 이유는???

도구 모음을 사용하도록 강요하지 않습니다. 비활성화할 수 있습니다.
당신은 우리가 도구 모음을 사용하지 않도록 강요합니다.
차이가 느껴지시나요?
"유일한 올바른 길"의 시대는 소비에트 연방이었습니다.

무엇을 해야할지 말하지 마십시오. 어디로 가야하는지 알려주지 않을 것입니다.

쓸모없는 패딩에 대한 한 사람의 아이디어는 잘 정의된 인터페이스에 대한 또 다른 아이디어입니다... notepad++는 잘 설계되지 않았거나 사용하기에 적합하지 않습니다. 나는 메모장++과 에디트패드 프로를 사용했는데 나중에는 훌륭했지만 둘 다 버튼이 비좁은 구식으로 보입니다. VSC에 아무것도 없어서 다행입니다. 처음 atom을 시도했을 때 명령 팔레트 - 또는 vsc -가 마음에 들지 않았지만 몇 년 동안 사용한 후에는 버튼을 놓치지 않거나 사용하기 어려운 명령 팔레트를 찾지 못했습니다. . 메모장++로 되돌아가는 대신 시간을 좀 주세요.

문제 제목이 "선택 사항"인 정확한 이유. 파일에 액세스하기 위해 상단의 탭을 사용하지 않습니다. 모두 왼쪽에 있습니다. 그들이 왜 거기에 있습니까? 하나의 워크플로가 자신에게 적합하다고 해서 모든 사람에게 좋은 것은 아닙니다. 구성 가능한 UI는 더 넓은 범위의 사용자에게 더 나은 기능을 제공할 수 있습니다. 저에게는 접근성 기능입니다. 저는 고정 키를 사용하므로 여러 번 반복해야 하는 경우 특정 키 조합(대부분 실행 취소/다시 실행)을 누르는 것이 지루할 수 있습니다. 그것은 내 삶을 더 쉽게 만들고 당신에게 영향을 미치지 않을 것입니다. 그런데 왜 당신은 내가 필요하지 않다고 말합니까? 왜 신경써?

플러그인이 될 수도 있습니다. 원하지 않는 사람은 플러그인이 존재한다는 사실조차 알 필요가 없습니다.

@morozovsk 도구 모음이 없습니다.
존재하지 않습니다.

추가해도 상관없지만 우선순위를 두지 않을 뿐... 원하는 개발자가 많은 것 같으니 팀을 구성하여 PR을 제출하는 것은 어떻습니까?

추가해도 상관없지만 우선순위를 두지 않을 뿐... 원하는 개발자가 많은 것 같으니 팀을 구성하여 PR을 제출하는 것은 어떻습니까?

사람들이 제안했고 동일한 문제에 대해 작성된 다른 많은 버그 보고서를 살펴보십시오. MS는 거부할 가능성이 있다고 말했다. 그들은 플러그인을 가능하게 하기 위해 후크를 추가하고 싶어하지도 않습니다. 따라서 이것은 자원의 문제가 아니라 이념적인 문제입니다.

우선순위가 아닌 것은 분명합니다. MS는 몇 달 동안 그것에 대해 언급조차 하지 않았습니다. 다시 말하지만, 나는 당신이 왜 관심을 가질지 모르겠어요.

쓸모없는 패딩에 대한 한 사람의 아이디어는 잘 정의된 인터페이스에 대한 또 다른 아이디어입니다... notepad++는 잘 설계되지 않았거나 사용하기에 적합하지 않습니다. 나는 메모장++과 에디트패드 프로를 사용했는데 나중에는 훌륭했지만 둘 다 버튼이 비좁은 구식으로 보입니다. VSC에 아무것도 없어서 다행입니다. 처음 atom을 시도했을 때 명령 팔레트 - 또는 vsc -가 마음에 들지 않았지만 몇 년 동안 사용한 후에는 버튼을 놓치지 않거나 사용하기 어려운 명령 팔레트를 찾지 못했습니다. . 메모장++로 되돌아가는 대신 시간을 좀 주세요.

어... 메모장++이 뭔지 알아? config 파일... 그 파일로 무엇을 할 수 있는지 아십니까? 보고 싶지 않은 항목을 제거하십시오... 문자 그대로 하나의 메뉴 옵션이 있는 파일 메뉴만 있고 원하는 경우 도구 모음이 없도록 만들 수 있습니다... 왜 그런가요? 사람들을 비효율적인 워크플로에 가두지 않고도 가장 효율적으로 작동하도록 사용자 지정할 수 있기 때문입니다. 따라서 사용하지 않아도 되는 선택적 기능이 어수선해져서 구현하지 않아야 한다는 것은 너무 이기적으로 들립니다.

나는 어두운 테마를 좋아합니다... VSCode는 색상 선택을 사용자 정의하고 모든 사람이 내가 좋아하는 것을 사용하도록 모든 옵션을 제거해야 할까요? 왜 안 돼? 흠, 툴바와 마찬가지로 사용자가 자신에게 가장 잘 맞는 것을 사용자 정의할 수 있도록 코드를 작성하기 쉽고 다른 사용자에게 부정적인 영향을 미치지 않기 때문입니다...

추가해도 상관없지만 우선순위를 두지 않을 뿐... 원하는 개발자가 많은 것 같으니 팀을 구성하여 PR을 제출하는 것은 어떻습니까?

무엇을 우선시하고 싶습니까? 토스터용 API?

코딩팀의 비슷한 고집으로 인해 실제 데이터가 파괴되는 파일 시스템 문제가 아니라 더 높은 우선 순위가 되어야 할 것 같은 요청을 본 적이 없습니다... 하지만 우리 모두 스케치부흐 왕을 만세해야 할 것 같은데요?

티켓에 FAQ를 추가했습니다.
주제를 파악하지 못했지만 이미 반대하는 사람들에게 같은 질문에 대답하는 것은 지겹습니다.

@thariqnu-ifm
키보드 없이 명령 팔레트를 얼마나 정확하게 사용합니까?
왜 우리는 명령 팔레트와 선택적 도구 모음(또는 최소한 API)을 가질 수 없나요?

키보드 없이 어떻게 코드를 작성합니까?

티켓에 FAQ를 추가했습니다.
주제를 파악하지 못했지만 이미 반대하는 사람들에게 같은 질문에 대답하는 것은 지겹습니다.

OP의 해당 추세 스크린샷에는 표시되는 내용이 표시되지 않습니다...

추가해도 상관없지만 우선순위를 두지 않을 뿐... 원하는 개발자가 많은 것 같으니 팀을 구성하여 PR을 제출하는 것은 어떻습니까?

분명히 여러 번의 시도가 있었습니다... 일부는 다른 것보다 더 잘 지냈습니다. 문제는 vscode 팀이 과거에 이러한 시도를 차단하고 허용할 의사가 없다는 사실을 회피했다는 것입니다.

비전이 있습니다... 그 비전에는 도구 모음이 포함되어 있지 않습니다. 왜 내 마음이 흔들릴까... 하지만 이 모든 시간을 기다리기만 하면... Webstorm은 점점 더 좋아지고 그 격차가 벌어지고 있습니다.

다른 사람의 요점으로 ... 그들은 코드 사용자의 2 %가 사용할 매우 모호한 지원을 위해 뒤로 구부리는 데 문제가 없었습니다 ... 그러나 간단한 선택적 도구 모음 ... 아니요.

몇 년이 지났고 수많은 문제가 망각으로 낭비되었습니다. 부를 때가 된 것 같아요.

키보드 없이 어떻게 코드를 작성합니까?

누군가 키보드 없이 코드를 작성한다고 말했습니까?
개발은 내 경험에서 코드를 입력하는 것 이상입니다. 처음에 레거시 시스템을 파악하는 데 시간을 보내는 것부터 마지막에 디버깅하는 것입니다.

나는 키보드 시간을 귀중한 상품으로 만드는 팔에 통증이 있습니다. 또한 마우스와 키보드 사용 사이를 전환하려는 노력입니다. 그래서 손을 쉬기 위해 가능하면 마우스를 사용합니다. 약간의 지원(예: _toolbar_)으로 몇 시간 동안 키보드 근처에 가지 않고도 앉아서 코드와 참조 문서, 디버그 등을 정독할 수 있습니다.

티켓에 FAQ를 추가했습니다.
주제를 파악하지 못했지만 이미 반대하는 사람들에게 같은 질문에 대답하는 것은 지겹습니다.

편집: Microsoft Visual Studio Code 팀:

기능을 제공하는 것이 보다 생산적인 조치가 되지 않을까요?

@레이빌로

기능을 제공하는 것이 보다 생산적인 조치가 되지 않을까요?

아마 헷갈리실거에요 :)
저는 토픽 스타터입니다. 저는 MS에서 일하지 않습니다. 기능을 전달할 수 없습니다.

@레이빌로

기능을 제공하는 것이 보다 생산적인 조치가 되지 않을까요?

헷갈리실텐데요 :)
저는 토픽 스타터입니다. 저는 MS에서 일하지 않습니다. 기능을 전달할 수 없습니다.

죄송합니다. 이 메시지는 Microsoft Visual Studio Code 팀을 위한 것입니다.

제 입장에서는 확장 프로그램을 가지고 놀아보려고 했지만 문서를 파헤치기가 어렵습니다.

저는 토픽 스타터입니다. 저는 MS에서 일하지 않습니다. 기능을 전달할 수 없습니다.

위의 게시물 1에 대한 FAQ 업데이트에서 말 그대로 이 말을 했습니다. 🤣

어떤 사람들은 관련 없는 말도 안되는 논평으로 넘어가기 전에 그것을 읽지 않거나 이 문제가 무엇에 관한 것인지 이해하려고 시도하지 않을 것입니다.

OP는 약간 tl;dr입니다. 아마도 FAQ를 맨 위로 옮겨야 할 것입니다.

그만 애플이 되십시오. 어떤 것에서 유용한 것을 제거한다고 해서 그 것이 더 좋아지는 것은 아닙니다.

개인적으로 나는 이 스레드가 나올 때까지 도구 모음이 없다는 것을 결코 눈치채지 못했습니다. 현재 방식이 마음에 듭니다. 어쨌든 왼쪽에 활동 표시줄 형태의 도구 모음이 있습니다. 하지만 vscode 개발자가 도구 모음을 포함하지 않기로 한 결정을 더 잘 설명할 수 있었다고 생각합니다. 물론 구현 시 도구 모음을 옵션으로 포함할 수 있지만 우선 순위 목록에서 더 낮을 수 있습니다. 그래도 도움이 되는 댓글이 있었으면 좋았을 텐데.

개인적으로 나는 이 스레드가 나올 때까지 도구 모음이 없다는 것을 결코 눈치채지 못했습니다. 현재 방식이 마음에 듭니다. 어쨌든 왼쪽에 활동 표시줄 형태의 도구 모음이 있습니다. 하지만 vscode 개발자가 도구 모음을 포함하지 않기로 한 결정을 더 잘 설명할 수 있었다고 생각합니다. 물론 구현 시 도구 모음을 옵션으로 포함할 수 있지만 우선 순위 목록에서 더 낮을 수 있습니다. 그래도 도움이 되는 댓글이 있었으면 좋았을 텐데.

당신은 또한 왼쪽에 있는 거대한 막대(당신이 무엇이라고 부르기로 결정했든)가 무엇이라고 주장할 수 있습니까? 100px 이상의 너비는 20px 도구 모음보다 훨씬 더 복잡합니다...

또한... 방금 깨달았습니다... Microsoft가 소유한 도구 모음이 또 무엇인지 아십니까...? Github... 바로 이 상자에 내가 입력하고 있습니다... 그게 왜... 모든 사람이 키보드 전문가라면 마크다운을 알아야 하지 않을까요? ㅋ ㅋ ㅋ

최소한 다른 패널 컨테이너에서 이동(및 복제?)할 수 있는 "도구 패널"이 필요합니다.

따라서 활동 표시줄에 전용 아이콘이 있거나 기존 창의 패널 등이 될 수 있습니다.

최근 추가된 가동 패널을 활용합니다.

개인적으로 나는 이 스레드가 나올 때까지 도구 모음이 없다는 것을 결코 눈치채지 못했습니다. 현재 방식이 마음에 듭니다. 어쨌든 왼쪽에 활동 표시줄 형태의 도구 모음이 있습니다. 하지만 vscode 개발자가 도구 모음을 포함하지 않기로 한 결정을 더 잘 설명할 수 있었다고 생각합니다. 물론 구현 시 도구 모음을 옵션으로 포함할 수 있지만 우선 순위 목록에서 더 낮을 수 있습니다. 그래도 도움이 되는 댓글이 있었으면 좋았을 텐데.

다른 닫힌 스레드에서 개발자는 플러그인 개발자가 도구 모음 플러그인을 만들 수 있는 후크를 포함하는 것조차 꺼리거나 꺼린다고 말했습니다. 따라서 이러한 개발자들은 우선 순위가 낮기보다는 완전히 선택적 도구 모음을 플러그인으로 사용할 수 있도록 하는 것조차 적극적으로 반대하는 것으로 보입니다. OP가 말했듯이 이것은 이념적으로 보입니다.

그냥 더미에 추가...

이 문제는 내가 VS Code를 사용하지 않는 가장 큰 이유입니다. 사실 한 달에 한 번 정도 체크인을 해서 눈치를 챘는지 확인하고 버튼바를 추가했다. 그러나 애석하게도 애드온 개발자가 막대를 통합하도록 허용하는 것조차 범위를 벗어난 것처럼 들립니다.

이 기본 기능을 제공하는 메모장++ 및 기타 편집기를 계속 사용하겠습니다. 그러나 이번에는 실제로 VS Code를 제거할 예정이며 조만간 다시 설치할 생각은 없습니다.

이 기능 요청에 +1을 추가하고 싶었습니다.

"OPEN EDITORS"와 같은 완전히 쓸모없는 것이 계속 화면을 어지럽히는 동안 어떻게 그렇게 유용한 것이 개발 팀에 의해 거부되는 것처럼 보이는지 재미있습니다. 어떤 파일이 열려 있는지 보여주는 탭이 없었던 코딩 시대의 암흑기인 VC++ 6일 동안에도 그런 것은 필요하지 않았습니다.

그리고 어떤 미친 개발자가 내 말투가 문법 실수로 가득 차 있기 전에 분명히 하려고 노력하겠습니다.

• 구성 가능한 도구 모음 -> 매우 유용합니다.
• 열려 있는 파일을 보여주는 탭 -> 매우 유용합니다. 보관해라!
• 편집기 열기 -> 완전히 쓸모가 없습니다. 던져!

TLDR
구성 가능한 도구 모음은 현재 구현 중인 많은 항목보다 매우 유용하고 훨씬 더 중요합니다.

열려 있는 편집기 보기를 마우스 오른쪽 버튼으로 클릭하고 보기를 원하지 않으면 선택을 취소하십시오.

열려 있는 편집기 보기를 마우스 오른쪽 버튼으로 클릭하고 보기를 원하지 않으면 선택을 취소하십시오.

당신이 아는 것은... 누군가가 도구 모음이 마음에 들지 않는다고 불평할 때 말할 수 있는 단어와 정확히 같은 줄입니다. 얼마나 다재다능한가!

아니요. 보기를 숨기는 옵션은 첫 번째 릴리스부터 있었습니다.

도구 모음은 없었습니다. 도구 모음이 없는 것이 핵심 디자인 목표였습니다. 지금 추가하면 리소스와 개발 시간을 낭비하고 이 "기능"을 추가하기 위해 여러 팀이 협력해야 합니다. 그런 다음 게으른 확장 프로그램 개발자는 도구 모음에 대해서만 작성하고 도구 모음 없이 확장을 사용하는 방법을 제공하지 않습니다. 대부분은 클릭 이벤트를 실제 명령에 연결하지도 않을 것이며 클릭 시 아무에게도 명령 팔레트를 사용할 기회를 제공하지 않고 무언가를 실행할 것입니다. 이 "기능"을 지금 추가하는 것은 실수가 될 것이므로 수행하고 싶지 않습니다. 또한 API를 부풀릴 것입니다. 리본에 대한 모든 MS 연구는 끝없는 메뉴 옵션이 얼마나 쓸모없고 도구 모음 지옥이 앱을 더 효과적으로 사용하는 데 도움이 되지 않는지를 보여주었습니다.

MS 연구에서 도구 모음이 쓸모없는 쓰레기라고 생각한다면 디자인이 여전히 응용 프로그램의 기본 패러다임인 이유는 무엇입니까? 브라우저에서 도구 모음/리본이 켜져 있습니까? 단어? 뛰어나다? 탐침? 비주얼 스튜디오? 포토샵? Windows에서 고정된 응용 프로그램은 일종의 도구 모음입니다. 위의 상황에서 개인적으로 이러한 기능을 사용하지 않는다면 사용하는 사용자가 소프트웨어를 잘못 사용하고 있다고 생각하십니까? 예를 들어 명령 팔레트 구조가 Word의 리본을 가장 잘 대체합니까? 정직한 질문.

엔지니어링 문제의 경우 클릭 이벤트 내에서 코드를 실행할 필요가 없습니다. 프레임워크는 처음부터 함수 트리거로 쉽게 제한될 수 있으며, 이는 어쨌든 구현하는 유일한 논리적 방법인 것 같습니다. 도구 모음/메뉴를 만든 모든 응용 프로그램은 함수만 호출합니다. 버튼의 클릭 이벤트에 코드가 포함될 수 있는 이유는 무엇입니까? 개발자가 도구 모음 뒤의 이벤트에 액세스할 수 있는 이유는 무엇입니까? 명령 후크가 있는 버튼을 지원하는 프레임워크를 추가하는 것은 매우 간단합니다. 이미 동일한 작업을 수행하는 명령 팔레트가 있으므로 해당 구조만 확장한 것처럼 보입니다.

나는 호기심을 위해 이 스레드에 머물렀지만 나에게 진짜 이야기는 대부분의 팀이 인터페이스 단점을 인용하여 코드를 사용하지 않기로 선택했다는 것입니다. 다른 점은 훌륭한 제품이기 때문에 실망스럽습니다.

이 스레드를 읽고 있고 도구 모음이 없다는 것이 나처럼 본질적으로 쇼 스토퍼라면 메모장 ++을 권장합니다. VSC를 제거하고 NPP를 설치했지만 뒤돌아보지 않았습니다. NPP 도구 모음은 플러그인을 통해 완전히 확장할 수 있으며 Python, bash 스크립트 및 내부 편집기 언어를 통해 거의 20가지 반복 작업을 수행하는 버튼을 추가했습니다. 또한, 언어별 작업 등을 위한 다른 플러그인이 많이 있습니다. 다른 좋은 대안도 있다고 확신하지만 기본적으로 또는 직접 코딩할 수 없는 NPP를 사용하여 아무 것도 찾지 못했습니다.

하하하하...스케치부흐가 도구 모음을 원하지 않는 진짜 이유를 방금 찾았습니다... 그는 상태 표시줄을 도구 모음으로 사용하느라 바쁘고 어떤 이유에서든 의도하지 않은 목적으로 상태 표시줄을 "해킹"하는 것이 더 적합하다고 생각합니다 합법적인 상태 표시줄을 갖는 것보다...

이봐... 경량이 걱정된다면... 진짜 부풀려진 부분을 좀 줄여보자... 다시 VSC보다 훨씬 가벼운 편집기에는 도구 모음이 있습니다...

... 정직한 질문.

아니, 내 말을 무시하는 것뿐이야. 나는 툴바가 쓸모없다고 말한 적이 없다. 나는 툴바 지옥이 쓸모없다고 말했다... 이것이 내가 걱정하는 바이다. 리본에는 버튼이 있지만 그 뒤에는 UX가 포함되어 있으며 버튼을 원하는 사용자를 위해 UX를 개선하는 연구는 수행되지 않습니다. 도구 모음 아래에 수백 개의 버튼과 도구 모음이 있는 상태로 돌아갑니다. 그것은 부풀려진 엉망이 될 것입니다 - 제 생각에는.

MS가 사람들이 드래그 앤 드롭을 통해 막대를 정렬할 수 있는 기능이 있는 여러 도구 모음 또는 도구 모음 아래의 도구 모음을 원하는 시점까지 도구 모음을 제공하면 사람들은 버튼을 사용자 정의하고 순서를 변경하는 방법을 원할 것입니다. 그들은 명령을 그룹화하는 버튼 폴더를 원할 것입니다.. 원하는 버튼에 대한 이 간단한 API는 API와 UI를 부풀리고 개발자 시간을 소모시키는 괴물로 변할 가능성이 있습니다.

나는 작은 API를 좋아하는데 처음에는 상당히 제한적이라는 것을 알았습니다. 몇 가지 확장을 만든 후에 확장에 대한 모든 사용자 지정 표시가 편집기에 있는 이유를 알 수 있습니다. 편집기에서 API를 사용하여 사용자 지정 콘텐츠를 만들 수 있는 유일한 곳입니다.

그건 그렇고 우리가 쓸모없는 일화적인 증거를 둘러싸고 ... 나와 함께 일하는 모든 팀은 VS 코드를 사용합니다.

예, 그것들은 제 확장 기능이지만 이미 버튼 시스템이 있는 곳에 버튼을 추가합니다. 해킹이 아닙니다. 이러한 확장은 API가 개발자에게 노출하지 않는 작업을 수행하지 않습니다. 그들이 버튼 API를 추가했는지 확인하고 완전히 해결되고 테스트를 거쳤습니다. 저는 상관없습니다. 나는 그들이 편집자를 괴롭히는 것을 원하지 않을 뿐입니다.

Zen 터미널 버튼 btw는 상태 표시줄이 아니라 버튼 위치에 대해 편집기 제목 표시줄을 사용합니다. 거기에 버튼을 추가하여 언제든지 개인용 확장 프로그램을 만들 수 있습니다.

엔지니어링 문제에 관해서는,

예, 버튼을 명령에 연결할 수 있지만 package.json에서 팔레트를 통해 호출되는 명령을 중지할 수도 있습니다. 이것은 내가 원하지 않는 일입니다. 어떤 이유에서건 개발자가 버튼으로만 작동하도록 만들기 시작하는 것입니다.

@sketchbuch :

어떤 이유로든 개발자가 버튼으로만 작동하도록 만들기 시작하는 일이 발생하고 싶지 않습니다.

우리는 버튼을 사용할 수 있을 때와 사용할 수 없을 때 허락을 구하는 당신의 노예가 아닙니다. 티켓에서 나가.

젠장, 미해결 문제에 대해 논평하는 데 당신의 허가가 필요하지 않습니다. 싫으면 자라서 버려라

아니, 내 말을 무시하는 것뿐이야. 나는 툴바가 쓸모없다고 말한 적이 없다. 나는 툴바 지옥이 쓸모없다고 말했다... 이것이 내가 걱정하는 바이다.

답장을 보내 주셔서 감사합니다. 툴바 지옥이 문제가 될 수 있다는 데 동의하지만(저는 Office를 보고 있습니다) 툴바를 편집할 수 있을 때 "사용자의 결정" 범주에 넣습니다. (도구 모음을 편집할 수 없는 경우 그것은 완전히 다른 문제입니다.) 응용 프로그램에서 도구 모음을 사용자 정의하는 옵션이 있을 때 기본적으로 모든 항목이 활성화된 상태에서 "즉시 사용 가능한" 것이 아니라 정상적인 선택과 함께 제공됩니다. 공통 항목을 추가/제거할 수 있으며 내 워크플로를 보다 효율적으로 만드는 요소를 추가/제거할 수 있습니다. 나에게 그것은 내가 선호하는 들여쓰기 옵션, 간격, 글꼴 크기 등을 설정할 수 있도록 하는 편집기와 동일합니다.

VSCode가 기본적으로 숨겨져 있는 빈 도구 모음과 함께 제공되더라도 괜찮을 것입니다. 나에게 그것은 사용자 선택에 관한 것이며 그들이 편안하지 않은 방법론을 강요하지 않는 것입니다. 나는 VS Code용 확장을 구축한 적이 없다는 것을 인정하지만 추가된 비트맵 리소스와 옵션을 활성화하는 확장 매니페스트에 대한 항목으로 제한되는 것을 상상할 것입니다. 그것은 개발자가 그것을 남용하는 것을 허용하지 않습니다. 기본 프레임워크가 존재하는 한 커뮤니티에 팔레트의 기본 비트맵을 만드는 작업을 오프로드합니다. 그런 다음 VS Code를 오늘처럼 깨끗하게 배송하고 내 방식대로 워크플로를 최적화하기로 선택하면 옵션이 있습니다.

일화적인 증거를 버리려는 것은 아닙니다.

@sketchbuch

젠장, 미해결 문제에 대해 논평하는 데 당신의 허가가 필요하지 않습니다.

그러나 이것은 나의 미해결 문제이기 때문에 실제로 해야 합니다. :)
추신: 이제 당신은 금지되었습니다. 건설적인 대화 감사합니다 :)

예, 그것들은 제 확장 기능이지만 이미 버튼 시스템이 있는 곳에 버튼을 추가합니다. 해킹이 아닙니다. 이러한 확장은 API가 개발자에게 노출하지 않는 작업을 수행하지 않습니다. 그들이 버튼 API를 추가했는지 확인하고 완전히 해결되고 테스트를 거쳤습니다. 저는 상관없습니다. 나는 그들이 편집자를 괴롭히는 것을 원하지 않을 뿐입니다.

Zen 터미널 버튼 btw는 상태 표시줄이 아니라 버튼 위치에 대해 편집기 제목 표시줄을 사용합니다. 거기에 버튼을 추가하여 언제든지 개인용 확장 프로그램을 만들 수 있습니다.

거기에 버튼을 추가할 수 있다고 해서 VSC가 이를 허용한다는 의미는 아닙니다. 그들이 그것을 도구 모음으로 바꾸기를 원하기 때문입니다... 실제로는 그렇지 않다고 명시적으로 언급한 개발자의 의견을 본 기억이 있습니다. (그들이 실제로 답장을 보낼지도 모른다는 충격적인 사실을 알고 있습니다...)

추신: 이제 당신은 금지되었습니다. 건설적인 대화 감사합니다 :)

제대로 된 논의가 있을 때만 해도 소용없는 행동이었다. 당신은 당신이 동의하지 않는 사람들을 그냥 끌 수 없습니다. 사람들에게 당신의 관점이 타당하다고 설득하지 않는 방법에 대한 교훈 #1.

그는 모든 메시지에서 같은 말을 되풀이했다: "나는 원하지 않는다", "나는 반대한다", "나는 이것을 좋아하지 않는다". 그는 건설적인 대화를 위해 아무 것도 하지 않았습니다.

어떤 이유로든 개발자가 버튼으로만 작동하도록 만들기 시작하는 일이 발생하고 싶지 않습니다.

그 전에는 그냥 트롤인 줄 알았다. 이 말 후에 그녀는 vscode를 더 좋게 만들거나 더 나쁘게 만들고 싶지 않다는 것이 분명해졌습니다. 그녀는 다른 사람들을 제한하고 싶을 뿐이고 그들이 원하는지 아닌지는 중요하지 않습니다.
글쎄, 내가 그에게 한 것과 같은 일을, 이제 그는 아마도 당신이 당신의 의지에 반하는 제한을 받았을 때 그것이 무엇인지 이해할 수 있습니다.

그는 모든 메시지에서 같은 말을 되풀이했다: "나는 원하지 않는다", "나는 반대한다", "나는 이것을 좋아하지 않는다". 그는 건설적인 대화를 위해 아무 것도 하지 않았습니다.

어떤 이유로든 개발자가 버튼으로만 작동하도록 만들기 시작하는 일이 발생하고 싶지 않습니다.

그 전에는 그냥 트롤인 줄 알았다. 이 말 후에 그녀는 vscode를 더 좋게 만들거나 더 나쁘게 만들고 싶지 않다는 것이 분명해졌습니다. 그녀는 다른 사람들을 제한하고 싶을 뿐이고 그들이 원하는지 아닌지는 중요하지 않습니다.
글쎄, 내가 그에게 한 것과 같은 일을, 이제 그는 아마도 당신이 당신의 의지에 반하는 제한을 받았을 때 그것이 무엇인지 이해할 수 있습니다.

죄송합니다 sBrecht, 나는 morozovsk에 완전히 동의합니다. 그는 건설적인 비판을 한 번도 추가하지 않았습니다. 솔직히 말해서 (그 문제에 대해 일종의 권위가 있는 것처럼) 내가 그의 프로필을 본 이유는... 그가 마이크로소프트의 비밀 직원일지도 모른다고 생각했지만... 아니... 그는 그냥 트롤이었어...

유일한 그가 대화에 가져온 혜택은 희망 MS는 문제의 어깨를 으쓱에 더 많은 관심을 지불받을 수있는 ... 카운트 게시물을 얻고 있었다

롤 봐... 트롤은 여전히 ​​트롤링 중입니다... 내 게시물에 엄지손가락을 치켜세우고 있습니다... 계속 트롤... 난 당신이 내 요점을 증명한 방법을 좋아합니다!!!

예, Sketchbuch 이전에는 두 번째 페이지에 있었습니다. 이제 첫 번째 페이지에
도움을 주신 @sketchbuch 에게 감사드립니다. :)

롤 봐... 트롤은 여전히 ​​트롤링 중입니다... 내 게시물에 엄지손가락을 치켜세우고 있습니다... 계속 트롤... 난 당신이 내 요점을 증명한 방법을 좋아합니다!!!

예. 당신은 또한 그를 금지하고 그의 존재를 잊을 수 있습니다 :)

니 유치한 행동으로 MS가 이 이슈를 닫을 때 웃어

4분 전에 계정이 생성되었습니다.

@krytenjrobot , @sketchbuch

오히려 스팸에 대한 새 계정을 등록하기 때문에 차단됩니다.
새 계정으로 다시 여기에서 만나면 github에 항의서를 작성하고 귀하의 기본 계정이 차단됩니다.

노인이지만 십대처럼 행동합니다.

추신: 이제 당신은 금지되었습니다. 건설적인 대화 감사합니다 :)

제대로 된 논의가 있을 때만 해도 소용없는 행동이었다. 당신은 당신이 동의하지 않는 사람들을 그냥 끌 수 없습니다. 사람들에게 당신의 관점이 타당하다고 설득하지 않는 방법에 대한 교훈 #1.

"나를 망쳐라"는 적절한 토론이 아닙니다. 그 사람은 분명히 트롤링을 하고 있었습니다. 그의 주장에 결함이 있다는 것이 지적되자 그는 골대를 옮겼습니다. 그는 단지 모든 사람의 시간을 낭비하고 있습니다.

안녕하세요, 제 이름은 Claude Dupré이고 40년 경력의 전자 엔지니어이자 분석가 프로그래머입니다. 나는 Dos 환경에 존재하지 않는 프린터 드라이버까지 개발해야 하는 내 경력에서 수많은 개발 제품을 사용했습니다. 그 당시에는 윈도우가 존재하지도 않았습니다. 객체지향으로 프로그래밍하는 방법을 알고 있었음에도 불구하고 머신은 그런 종류의 기술을 지원하기에 충분히 강력하지 않았습니다(8088, 8k 메모리 64k 디스크 공간 등). 그래서 우리는 자주 사용하는 기능을 위해 바로 가기 키를 사용해야 했고 모든 프로그램은 다음을 사용하여 컴파일되었습니다. 링크 파일이 있는 링커와 동일한 배치 파일입니다. 몇 년 동안 저는 Atmel studio와 함께 일해 왔습니다. 제 경력에서 Assembler, C, C++, .Net 및 dbase, PLM, Clipper 등과 같이 들어본 적이 없는 다른 언어로 프로그래밍한 이후로 제품을 아주 잘 알고 있었기 때문입니다. 이제 Atmel 스튜디오는 STM 제품을 지원하지 않았기 때문에 STM 기반 Cortex 제품을 개발하기 위해 작업할 다른 제품을 찾아야 했습니다. 비주얼 스튜디오 코드를 찾았습니다. 그래서 나는 내 자신에게 말했다, Hourra, 나는 성배를 발견했다. 나는 그것을 설정하기 위해 일주일 이상 일해야했고 제품의 이념이 우려되는 한 80 년대로 후퇴했다는 것을 알게되었습니다. 그렇게 인기가 많은 제품이 효율적인 도구가 아닌 것을 보니 매우 실망스럽습니다. 상황에 맞는 메뉴가 없습니다. 구성 가능한 메뉴가 없습니다. 플러그인은 자체 메뉴와 도구 모음을 생성하지 않으며 환경에 맞게 자체적으로 구성하지 않습니다. 기본 도구 모음이 없습니다. 따라서 경량 제품은 TIGHT 환경(내가 말하는 내용을 알고 있음)에 적용할 때 좋습니다. 따라서 누군가가 새 제품을 사용하려는 경우 최소한의 처리 시간으로 설치하여 사용할 수 있기를 기대합니다. Visual Studio Code를 Atmel Studio와 비교하면 vscode가 몇 년 뒤쳐져 있습니다. 내가 여기에서 읽은 바에 따르면 vscode 팀은 나에게 필수적인 것으로 보이는 업그레이드에 동의하지 않습니다. 이것을 결론짓기 위해. 사용, 효율성 및 문서가 최종 제품을 보다 통합되고 사용자 친화적으로 렌더링하는 데 관심이 있는 한 더 안정적이고 효율적인 플러그인을 정의하기 위해 코딩 표준을 채택해야 한다고 생각합니다(사실이 아닙니다. 죄송합니다). 팀은 더 많은 비전을 갖게 될 것입니다. 클로드 안부

MS가 사람들이 드래그 앤 드롭을 통해 막대를 정렬할 수 있는 기능이 있는 여러 도구 모음 또는 도구 모음 아래의 도구 모음을 원하는 시간까지 도구 모음을 제공하면 사람들은 버튼을 사용자 지정하고 순서를 변경하는 방법을 원할 것입니다. 그들은 명령을 그룹화하는 버튼 폴더를 원할 것입니다.. 원하는 버튼에 대한 이 간단한 API는 API와 UI를 부풀리고 개발자 시간을 소모시키는 괴물로 변할 가능성이 있습니다.

자, 여러분께 큰 소식이 있습니다. 사람들은 이미 위의 모든 것을 원합니다. 이것이 이 제안의 전체 목적입니다. 사용자가 원하는 명령과 원하는 방식, 원하는 위치에 추가할 수 있도록 하는 것입니다. 확장 작성자가 의도하지 않은 구성 요소에서 사용자 정의 없이 명령을 준비하는 데 의존해서는 안 됩니다.

현재 가장 많이 요청된 기능인 "UI 및 API 팽창"에 대한 논쟁이 있는 한 #10121은 창을 기본 창 외부로 드래그하는 기능입니다. 분명히 사람들은 선호하는 워크플로에 대해 다양한 아이디어를 가지고 있습니다. VSCode에는 내가 사용하지 않는 많은 기능이 있습니다. 그렇다고 해서 그것들을 제거해야 한다고 생각하는 것은 아닙니다. 내가 필요로 하는/원하는 경우 그들이 있어야 함을 의미합니다.

현재 가장 많이 요청된 기능인 "UI 및 API 팽창"에 대한 논쟁이 있는 한 #10121은 창을 기본 창 외부로 드래그하는 기능입니다. 분명히 사람들은 선호하는 워크플로에 대해 다양한 아이디어를 가지고 있습니다. VSCode에는 내가 사용하지 않는 많은 기능이 있습니다. 그렇다고 해서 그것들을 제거해야 한다고 생각하는 것은 아닙니다. 내가 필요로 하는/원하는 경우 그들이 있어야 함을 의미합니다.

이것은... 또는 최소한 필요한 기능을 처리하기 위해 프로그램을 확장할 수 있어야 합니다... 사람들이 부동 창을 원하는 경우 VSC의 두 번째 복사본을 열거나 창을 두 대의 모니터로 확장하고 다른 레이아웃을 선택하는 것이 어떻습니까? ( 보기 > 편집기 레이아웃) 그들은 이미 다양한 것을 가지고 있습니다... 하지만 솔직히 말해서, 그것은 녹아웃하는 데 며칠 이상 걸리지 않아야 할 것 같습니다...

그러나 최신 버전의 릴리스 정보를 보면(직접 확인하려면 도움말 > 릴리스 정보를 가져와서) 이러한 변경 사항 중 "고급 기능"이 얼마나 많은지 또는 소수의 사용자에게만 제공되는지 확인하십시오. , 등..

out of scope 등으로 마감된 다른 모든 문제를 기념하기 위해 이 문제의 2주년 기념 파티를 했어야 했습니다.

적절한 사용자 정의 도구 모음 옵션을 우선 순위 문제로 추가하기 위해 내 목소리를 추가하기만 하면 됩니다.

FFS 오랜만이야 MS!!

MS는 기껏해야 드라코니우스...

몇 가지 문제는 그냥 버리면 됩니다. 이 IDE는 수십 명이 아닌 한 사람이 만드는 것과 같습니다.

렌더링 불량 문제 또는 "여기에 도구 모음이 없습니다!"와 같이.
나는 정말로 이 IDE의 개발자들이 그것을 사용하지 않는다고 생각합니다!

이 스레드를 모르고 사용자 지정 가능한 도구 모음에 대한 요청을 제출했습니다. 향후 2년 이내에 고려할 기능이 아니기 때문에 거부/종료되었습니다. 저도 이 스레드를 참고했습니다.

이것은 실제로 VS Code의 유일한 문제이며 Windows가 된 이후로 내가 사용한 다른 모든 MS 프로그램에서 이상한 출발입니다.

다른 한편으로 VS Code는 개인 및 업무용으로 무료이며 본격적인 IDE가 아닌 "경량" 편집기로 제공됩니다. MS Visual Studio는 기업용으로 무료가 아닙니다. VS Code가 MS Visual Studio를 완전히 대체할 수 있는 가능성을 피하고 싶다고 생각합니다. 저는 전문 개발자가 아니며 다양한 IDE를 많이 사용하지 않았습니다. 툴바 외에 MSVS 2019를 사용하면서 얻을 수 있는 다른 이점을 볼 만큼 익숙하지 않고 다른 영역에서는 부족한 것 같습니다.

사용자가 이 기능을 추가할 수 있는 호환 가능한 확장을 코딩할 수 있는 방법이 있다고 생각합니다(이미 존재하는 것 이상, 훌륭하지만 강력하지 않음). 그러나 내가 말했듯이 지식이 많지 않기 때문에 없을 수도 있습니다.

VSCode가 계속해서 사용자 기반을 빠르게 확장할 경우 이 문제가 다시 열리기를 바랍니다. 그 동안 완전히 무료라는 점을 감안할 때 꽤 좋은 소프트웨어입니다.

사용자가 이 기능을 추가할 수 있는 호환 가능한 확장을 코딩할 수 있는 방법이 있다고 생각합니다(이미 존재하는 것 이상, 훌륭하지만 강력하지 않음). 그러나 내가 말했듯이 지식이 많지 않기 때문에 없을 수도 있습니다.

없습니다 ... (답은 위 어딘가에 있다고 생각하지만 IDE의 다른 모든 부분과 같이 전체 명령 스펙트럼을 노출하는 대신 api가 10개의 하드 코딩된 기능에 대한 액세스만 허용하는 것과 같은 문제라고 생각합니다. 액세스.

그리고 검색 트래픽이 열린 시간, 지원의 양, 구현해야 하는 용이성 등 검색 트래픽에도 불구하고 여기에서 개발 팀의 의견이 단 한 개도 없다는 사실이 저를 당황하게 합니다...

무료든 아니든 간에 훨씬 적은 수의 사용자에게 도움이 되는 수많은 다른 기능이 출시되었으므로(이 기능은 구현하는 것보다 훨씬 더 많은 시간이 소요됨) 정말 부끄럽습니다.

없습니다 ... (답은 위 어딘가에 있다고 생각하지만 IDE의 다른 모든 부분과 같이 전체 명령 스펙트럼을 노출하는 대신 api가 10개의 하드 코딩된 기능에 대한 액세스만 허용하는 것과 같은 문제라고 생각합니다. 액세스.

도구 모음(vscode microsoft 사람들에게만 알려진 이유로 "메뉴"라고 함)을 확장하는 확장을 만드는 다소 평범한 방법과 필요한 모든 명령이 포함된 오른쪽 클릭 컨텍스트 메뉴가 있습니다. 현재 할 수 있는 일에 여러 가지 문제가 있기 때문에 나는 이것을 보통이라고 부릅니다.

1. 명령, 도구 모음 버튼, 상황에 맞는 메뉴 항목 등을 추가하기 위한 vscode API는 없습니다. 도구 모음 및 상황에 맞는 메뉴에 항목을 표시하는 패턴은 확장 package.json 파일의 선언적 contributes 항목에 의해 구동됩니다. 파일은 확장자로 컴파일해야 합니다. 이 구멍은 런타임에 구성에서 도구 모음이나 메뉴를 프로그래밍 방식으로 빌드할 방법이 없고 이와 같은 것은 확장 코드에 연결해야 한다는 것을 의미합니다.
2. 어느 정도 확장할 수 있는 오른쪽 상단 영역의 도구 모음은 정상적인 의미에서 실제로 완전한 기능을 갖춘 응용 프로그램 도구 모음 영역이 아닙니다. 명령이 있는 버튼을 이 영역에 추가할 수 있지만 이 영역의 위치가 편집기 위에 배치되지 않고 편집기 탭의 오른쪽에 인라인으로 배치되어 이상하다는 것을 알았습니다.
3. (1)에서 언급한 API의 부족과 확장 가능한 도구 모음 컨테이너 영역(오른쪽 상단 제외)이 없다는 것은 누구나 사용할 수 있는 유연하고 구성 가능한 범용 도구 모음 확장을 개발하는 것을 방해하는 차단기입니다.

나는 내 자신의 목적을 위해 함께 해킹된 확장 프로그램 을 만들었으며 가장 많이 사용하는 명령 중 일부에 대해 vscode의 모든 접근 방식에 대한 명령 팔레트 버킷을 처리해야 하는 고통을 일부 제거했지만 여전히 이상적인 솔루션과는 거리가 멉니다.

문맥상, hacked together 확장은 다음과 같은 결과를 낳습니다. 분명히 말씀드리자면 저는 이 해결 방법을 이 문제에 대한 수용 가능한 솔루션으로 옹호 하지 않습니다 .

이 기능 요청은 관련이 있습니다. 이를 수행하려면 도구 모음이 필요합니다.
기능 요청: 간소화된 텍스트 편집기

찬성표를 주시면 백로그에 기록될 수 있습니다.

솔직히 말해서 Vscode를 동료에게 추천할 때마다 Vscode는 시작하는 방법을 알려주기에는 너무 특별합니다(단단함).
아무도 그렇게 많은 키 조합을 기억하고 싶어하지 않습니다.

이 분명히 필요한 기능을 추가하려는 명백한 저항을 이해하지 못합니다.

• 옵션/구성 가능한 도구 모음을 추가하십시오.
  상단 메뉴에서 모두 저장을 하는 것이 답답할 때 VS 도구 모음을 찾기 시작했습니다. - Ctrl K + S는 바로 가기 구성에 대한 정보를 보여주는 화면을 표시합니다. - 간단한 도구 모음을 클릭했을 때 바로 가기를 구성하는 데 시간을 낭비하고 싶지 않습니다. 정당한 이유 없이 생략되었습니다.
  시간 낭비를 멈추고 완료하세요. Microsoft는 이 작업의 속도를 높이기 위해 용도를 변경할 수 있는 Visual Studio의 풍부한 코드를 보유하고 있습니다.

도구 모음이 있는 Vscode는 마침내 메모장++을 대체합니다.

내가 받는 모든 새로운 VSCODE 업데이트, 나는 MS와 팀이 그 기능을 도입하고 도구 모음에 대한 멋진 작은 애니메이션 gif를 볼 수 있기를 바라며 여기에 앉아 있습니다. 사용자 기반의 <1%의 이점... 그런 다음, 분명히 사용자 기반의 적어도 일부는 열정적으로 느끼고 있지만 여전히 깔개 아래, 쓰레기통에 던져지고 /dev/null로 라우팅되는 것과 같은 것입니다. .

오 글쎄... 팀이 그들의 행동에 대해 이야기하고 그들의 행동이 노골적인 "NO"라고 생각합니다. 우리 모두는 우리가 이 기능에 대해 최소한 관심이 있다는 것을 보여주기를 바랐던 것 같습니다. 분명히 결정이 내려졌습니다.

재미있는 점은 다른 개발 팀이 관심을 기울이고 있으며 결국에는 우리가 요청한 기능, 그리고 아마도 더 많은 기능을 갖춘 편집기를 출시할 가능성이 더 높다는 것입니다.

그 시점에서 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로 라우팅되는 것과 같은 것입니다. .

오 글쎄... 팀이 그들의 행동에 대해 이야기하고 그들의 행동이 노골적인 "NO"라고 생각합니다. 우리 모두는 우리가 이 기능에 대해 최소한 관심이 있다는 것을 보여주기를 바랐던 것 같습니다. 분명히 결정이 내려졌습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/microsoft/vscode/issues/41309#issuecomment-679400537 에서 확인하거나 https://github.com/notifications/unsubscribe-auth/AFC3662TUXE67KO6LPNRNR3SCLTKNANCNFSM4EK3PI를 구독 취소

가까운 장래에 우선 순위가 높은 기능이 아닌 것 같아서 VSCode의 편집기 메뉴 모음에 미화, 파일 나열, 실행 취소, 다시 실행, 모두 저장 등과 같은 편리한 버튼을 추가하는 이 확장을 만들었습니다. 바로 가기 메뉴 모음

@GorvGoyl 은 작업해야 하는 제약 조건을 감안할 때 해당 확장을 승리라고 부를 것입니다. 내가 정말로 원했던 것은 실행 취소/다시 실행이었습니다. 그래서 감사합니다! 나에게서 별 5개.

@GorvGoyl 아주 좋아요! 별 5개!

@GorvGoyl 아주 좋아요! 별 5개!

아니요, 탭 그룹의 공간을 너무 많이 차지하는 것은 무섭습니다.

@GorvGoyl 아주 좋아요! 별 5개!

아니요, 탭 그룹의 공간을 너무 많이 차지하는 것은 무섭습니다.

ㅋ ㅋ ㅋ. 실제로 필요에 따라 해당 아이콘을 비활성화/활성화할 수 있습니다.

가까운 장래에 우선 순위가 높은 기능이 아닌 것 같아서 VSCode의 편집기 메뉴 모음에 미화, 파일 나열, 실행 취소, 다시 실행, 모두 저장 등과 같은 편리한 버튼을 추가하는 이 확장을 만들었습니다. 바로 가기 메뉴 모음

ms vscode 팀 전체가 귀찮게 할 수 없는 일을 해주셔서 감사합니다.

이 단계에서 별도의 도구 모음에 두는 것이 불가능하다고 생각합니까?

@GorvGoyl 아주 좋아요! 별 5개!

아니요, 탭 그룹의 공간을 너무 많이 차지하는 것은 무섭습니다.

이것이 "별도의 구성 가능한 도구 모음"을 허용하기 위해 API를 노출해야 하는 이유입니다.

그러나 현재로서는 이것이 최선일 것입니다. 10,000명 이상의 사용자가 있다는 점을 감안할 때 도구 모음의 필요성은 분명히 존재합니다. 그것은 나에게 "충분히 좋다".

@GorvGoyl : 연장해주셔서 감사합니다. 그것은 나에게 사용 가능한 최고의 도구 모음입니다. 확장 패널에서 "도구 모음"을 검색할 때 나타나지 않는 것이 너무 아쉽습니다.

저는 VSCode를 처음 사용하고 처음에는 도구 모음을 표시하기 위해 설치하는 동안 설정을 놓쳤습니다! 이 스레드를 찾을 때까지 오랫동안 검색했습니다.

그러나 "프린터 친화적" 키보드 단축키 pdf를 쉽게 찾았습니다. (비꼬며) ㅋㅋㅋㅋ

그래서.... 개발 팀의 관점에서 일반적인 VSCode 사용자는 책상 위에 키보드, 마우스 및 치트 시트 더미를 가지고 있습니다. 내가 아니야. 더 비꼬는 LOL.

말 그대로 내가 vscode 업데이트를 볼 때마다... 나는 말 그대로 절대 사용하지 않을 10가지 항목을 읽고(아무도 사용하지 않을 것이라는 것을 인정합니다) 생각하고... 예, 하지만... 여전히 도구 모음이 없습니다.

최대한 도움이 되는 확장 기능을 개발하려는 사람들의 노력에 감사드립니다.... 하지만 이 문제가 여전히 존재하며 ms devs의 의견이나 관심이 거의 또는 전혀 없었다는 사실을 느낍니다. 아무런 이유 없이 뻔뻔하게 종결된 문제들).

팀 가자!

대신 Atom을 사용하십시오. Atom에 도구 모음을 추가하는 것은 매우 쉽습니다. 그러나 이제 GitHub/Atom이 사용되면서 업데이트가 드물어지고 심각한 버그(예: 구문 색상 지정)가 계속해서 발생합니다. 그들이 한 편집자를 죽게 내버려두고 다른 편집자의 사용자가 필요로 하는 것에 대해 별로 신경 쓰지 않는 것을 보는 것은 슬픈 일입니다.

오, 나는 vscode를 사용하는 대부분의 일에 webstorm을 사용합니다... 여전히 설치되어 있습니다... 유능한 IDE를 (아직은) 그것으로 교체하는 것은 꿈도 꾸지 않을 것입니다.

또한 확장에 대한 작업을 추가할 수 있는 도구 모음을 원합니다. 키보드 단축키는 훌륭하지만 모든 확장 프로그램이 하는 모든 것을 외울 수는 없습니다.