Van Arsdel 샘플에 대한 링크를 추가해야 합니다.

툴킷의 보다 일반적인 컨트롤은 항상 C++로 이식되고 Windows UI 라이브러리에서 사용할 수 있는 방법을 찾아야 한다고 생각합니다. 탭은 성숙하고 안정적일 때 이를 제어합니다.

메인 메뉴 컨트롤에서 발생했습니다 :)

제안서에서도 언급된 탭 분리 샘플 에 대한 링크입니다.

제안서에서도 언급된 탭 분리 샘플 에 대한 링크입니다.

탭을 떼면 새 AppWindow, 새 CoreWindow가 생성되며 새 창 API가 없는 경우 대체를 어떻게 처리합니까?

@mdtauk 샘플은 현재 이전 다중 창 ApplicationView API를 사용하며 창은 드래그한 위치 대신 기본 위치에 생성됩니다. 저는 AppWindow를 사용하여 테스트했으며 새 SDK에 대한 샘플을 업데이트하기를 희망합니다.

"이러한 해결 방법이 WPF의 플랫폼 격차를 해소하는 데 도움이 되었지만 다음을 포함하여 여러 가지 제한 사항이 있습니다."

여기에 키보드 입력도 나열해야 합니다. 이것은 단순한 탭 키나 바로 가기 키가 아닙니다. Arrowing은 탭 컨트롤이 없었을 때 우리가 어려움을 겪었던 문제였으며 모든 사람이 탭 컨트롤이 없는 상황에서 일관성을 유지해야 했습니다.

툴킷에서 들은 미해결 질문에 대한 의견:

1. Tab Tearoff는 컨트롤이 처리해야 합니까 아니면 앱이 처리해야 합니까?

탭 컨트롤이 TabView(동일한 데이터 유형 호스팅) 간의 끌기 및 재결합을 처리하고 검사/차단 기능과 함께 끌기 이벤트를 노출하는 것이 중요하다고 생각합니다.

그러나 TabView가 창 수명 주기를 직접 관리하는 것이 더 까다로워지기 때문에 중요한지 모르겠습니다. 개발자는 탭을 끌 때 발생하는 일을 사용자 정의하고 싶을 수도 있습니다. 탭을 제거하거나 탭이 있는 새 '기본' 창과 비교하여 해당 콘텐츠만을 위한 특수 창을 만들 수도 있습니다. 또는 다중 창에 대한 코딩 작업을 처리하고 싶지 않을 수 있습니다.

이벤트를 노출하고 Windows 생성/관리를 돕기 위해 도우미를 사용하는 것이 더 쉬울 수 있습니다(또는 Windows 템플릿 스튜디오와 같은 기존 도우미를 활용). 이 시나리오에서 가장 까다로운 부분은 스레드 간의 "데이터 전송"으로, 최소한 새 창 API가 이를 완화하는 데 도움이 됩니다.

1. 내장된 "새 탭 추가" 버튼이 있어야 합니까? (컨트롤이 탭 컬렉션을 소유하지 않기 때문에 아마 아닐 것 같습니다.)

적절한 헤더 템플릿과 예제가 있는 한 구현자가 '추가' 버튼을 추가하는 것은 사소한 일이므로 패러다임이 다른 이벤트를 필요로 하기 때문에 내장할 필요가 없다고 생각합니다. 이것은 우리가 원래 툴킷에서도 생각했던 것입니다. :)

1. TabItem.Icon은 IconElement 또는 IconElementSource여야 합니까?

NavigationViewItem의 속성을 모방하기 위해 IconElement 를 사용했습니다. 또한 IconElementSource 는 IconElement 이므로 IconElement 가 더 넓을수록 좋지 않습니까? WinUI에 Image 를 호스트할 수 있는 IconElement 하위 클래스가 있으면 좋을 것입니다( BitmapIcon 와 유사하지만 강제 마스킹 없음). 그런 식으로 Icon 속성은 멋진 Vector Symbol/Font Icon 또는 ico/png 파일(브라우저 유형 시나리오 favicon을 생각하세요)을 호스트할 수 있습니다.

1. 어떻게 앱이 Selected 탭의 모양을 사용자 정의할 수 있습니까(예: Edge에서)?

수정하거나 선택한 항목에 대해 완전히 다른 템플릿과 같은 노출된 스타일 속성에 대해 이야기하고 있습니까?

1. API는 현재 툴킷에서 많은 영감을 얻습니다. 반복/개선할 기회가 있습니까?

우리가 받은 피드백 항목 중 하나는 탭 끝에 있는 공간을 사용자 지정하는 것이었습니다. 예를 들어 왼쪽/오른쪽 수평 정렬을 사용하여 가장자리와 두 개의 개별 영역에 물건을 붙일 수 있는 단일 템플릿 영역이어야 합니까?

다른 질문:

• [ ] 콘텐츠 영역으로 드래그하는 방법과 헤더가 모두 대상인 경우 드래그를 처리하는 방법이 흥미롭습니다. 앱이 탭 영역에 다른 항목(예: 탐색기의 파일)을 놓을 수 있도록 허용하려면 어떻게 해야 합니까?
• [ ] "앱에서 탭의 위치/크기를 결정할 수 있음"이 TabStripPlacement 속성에 대해 말하는 것입니까?

또한 요구 사항 9에 대해 언급하는 것을 잊었습니다. 우리는 원래 Edge 모델(현재 툴킷 컨트롤이 작동하는 것과 같은)을 사용할지 아니면 드롭다운 갈매기 모양을 만드는 NavigationView 모델을 사용할지 여부에 대해 논의했습니다. 우리는 아마도 미래에 우리가 둘 다 지원할 것이라고 생각했습니다.

우리는 SplitObservableCollection 유형 개체가 필요하지 않았기 때문에 구현이 더 간단했기 때문에 Edge 모델을 사용하게 되었습니다. 나는 하나의 테스트로 작업을 시작했지만 그것이 노출하는 데 유용한 구성이 될지 궁금합니다.

@stmoy 위에서 우리가 툴킷 디자인에서 가지고 있던 미해결 문제/피드백을 닫았습니까?

Edge 탭 모델을 포기하는 Windows 세트의 소식이 이 컨트롤을 개발하는 방법에 어떤 영향을 줍니까?

Edge와 ChromiumEdge(Edgium)를 위해 UI가 거의 버려졌기 때문에 이 컨트롤을 사용할 수 있는 앱 유형에 더 적합하도록 이 컨트롤의 모양이나 동작을 재고해야 합니까?

• 속성 대화 상자;
• MDI(다중 문서 인터페이스) - Photoshop과 유사합니다.
• 고정된 도구 팔레트(Visual Studio/Blend/Adobe CC);

Pivot 및 개발 중인 UWP Ribbon과 같은 유사한 컨트롤은 말할 것도 없습니다. 어떤 사용 사례에 권장되며 누군가가 다른 것보다 하나를 선택하는 이유는 무엇입니까? 이러한 질문에 답할 수 있는 지침과 예는 혼동을 피하거나 성능이 뛰어나고 가벼운 컨트롤 대신 더 무거운 컨트롤이 사용되는 것을 방지하기 위해 명확해야 합니다.

퍼스트 파티 컨트롤은 올바른 목적을 위해 올바른 컨트롤을 사용하여 일관된 사용을 주도해야 합니다.

#629 @mdtauk 에서 기능 제안이 있었습니다.

ToDo 목록에 대한 아이디어일 수도 있습니다. 탭 배치? 하단, 왼쪽, 오른쪽.

예, 탭 배치는 마이그레이션 시나리오의 WPF 패리티와 일치하기 위해 어느 시점에서 우선 순위 목록에 있어야 합니다. 하지만 초기 툴킷 버전에도 추가할 시간이 없었습니다.

이 기능의 범위를 지정할 때 "속성 시트 탭" 시나리오를 지원하고 브라우저 탭 시나리오에 집중하는 것이 목표가 아닙니다. 속성 시트와 겹치는 부분이 있지만 속성 시트 은유는 유창한 디자인의 일부가 아닙니다. 현재 해당 시나리오에 대한 NavigationView(왼쪽/상단 모드가 있음)가 있습니다.

Navigation View는 무거운 컨트롤이며 전체 화면을 차지하려고 합니다. 또한 Edge의 XAML 버전과 마찬가지로 세트가 로드맵에서 사라졌습니다.

따라서 TabView/Control을 다시 생각하여 미래에 더 유연하고 유용하게 만들 수 있습니다.

TabView 컨트롤에 추가 및 닫기 단추를 숨길 수 있는 기능이 있는 경우 이러한 시나리오는 UWP XAML 앱에서 가능할 수 있습니다.

그러나 피벗 컨트롤도 있지만 상단의 피벗 헤더만 지원하며 탭은 상단, 하단, 왼쪽 또는 오른쪽으로 이동할 수 있습니다...

닫기 버튼이 없는 것을 지원한 툴킷에서 추가 버튼은 구현자가 스스로 추가해야 하는 것이기도 했습니다. 이것이 문서와 클래식 탭 간에 이러한 다양한 모드를 설정하는 데 도움이 되도록 TabWidthBehavior 속성을 사용하는 이유입니다. 아직 지원하지 않은 주요 기능 중 하나는 탭 위치 지정이었습니다.

모든 훌륭한 대화에 감사드립니다! 빙글빙글 돌아...

콘텐츠 영역 대 헤더로의 드래그를 처리하는 방법에 대한 드래그가 흥미롭습니다. 두 대상 모두입니까? 앱이 탭 영역에 다른 항목(예: 탐색기의 파일)을 놓을 수 있도록 허용하려면 어떻게 해야 합니까?

흥미로운 질문입니다. 순진하게도 TabControl이 탭 스트립 영역과 콘텐츠 영역을 모두 호스팅하므로 둘 다 동일한(큰) 대상이 될 것이라고 생각합니다. 그러나 이 모델은 Edge와 같은 앱을 고려할 때 무너집니다(예:). Edge가 최대화되고 사용자가 탭 스트립 밖으로 탭을 드래그하지만 최대 크기이기 때문에 여전히 콘텐츠 위에 있는 경우 사용자는 탭이 새 창을 생성할 것으로 기대합니다.

따라서 머리글 영역/탭 스트립만 끌어서 놓기 대상이 되어야 한다고 생각합니다.

"앱이 탭의 위치/크기를 결정할 수 있음"이 TabStripPlacement 속성에 대해 말하는 것입니까?

이것은 TabStripPlacement가 아니라 "TabWidthBehavior" 속성 및 열거형을 설명하기 위한 것입니다. 요구 사항을 업데이트하고 탭 배치 요구 사항도 추가했습니다(아래에서 조금 더 설명).

Edge의 XAML 버전과 마찬가지로 세트가 로드맵에서 사라졌습니다.

현재 이 작업의 주요 동기는 실제로 새로운 Windows 터미널 앱 입니다. 계속해서 Tab 컨트롤을 사용하는 다른 앱을 확장/탐색할 것이지만, 우리의 주요 초점은 현재로서는 해당 시나리오를 활성화하는 것입니다.

탭 배치는 마이그레이션 시나리오에 대한 WPF 패리티와 일치하도록 특정 지점에서 우선 순위 목록에 있어야 합니다. 하지만 초기 툴킷 버전에도 추가할 시간이 없었습니다.

탭 배치는 특히 WPF 패리티와 관련하여 멋진 아이디어입니다. 그러나 위의 내용에 따르면 우리는 주로 터미널이 필요로 하는 것을 기반으로 범위를 지정하고 있기 때문에 "필요"보다 "할 수 있음"에 더 가깝습니다. 즉, 위의 요구 사항 표에 추가했습니다.

TabView 컨트롤에 추가 및 닫기 단추를 숨길 수 있는 기능이 있는 경우 이러한 시나리오는 UWP XAML 앱에서 가능할 수 있습니다.

TabControl은 탭 자체에서 닫기 버튼 숨기기를 지원합니다. 또한 "추가" 버튼은 앱 자체(컨트롤 아님)에서 제공하므로 위에서 설명한 대로 컨트롤을 사용하여 속성 스타일 탭 시나리오를 만들 수 있을 것으로 기대합니다.

탭 추가 버튼이 컨트롤의 일부가 아닌 경우 컨트롤이 사용되는 곳마다 일관성 있게 버튼을 구현할 수 있도록 컨트롤에 버튼 스타일과 XAML 명령을 포함하는 것이 좋습니다.

@stmoy 드래그 시나리오의 경우 헤더로 드래그하면 영역이 다르거나 같을 수 있는 경우가 있다고 생각합니다. 샘플이 떼어내기에 대한 드래그를 보여줄 수 있다면 좋을 것입니다. 또한 예를 들어 기본 콘텐츠 영역에 파일을 드롭하고 이를 잡는 방법(컨트롤 자체의 범위를 벗어날 수 있지만 유용합니다. 그것의 사용법에).

버튼 스타일 및 XAML 명령 [새 탭 추가용]

@mdtauk - 좋은 생각입니다. 사양에 추가하겠습니다.

샘플이 떼어내기에 대한 드래그를 보여줄 수 있다면 좋을 것입니다. 또한 예를 들어 기본 콘텐츠 영역에 파일을 드롭하고 이를 잡는 방법도 있습니다.

@michael-hawker - 동의합니다. 샘플이 가치가 있을 것입니다. 파일을 끌어오는 것이 콘텐츠 영역에서 처리되기 때문에 탭별로 지정해야 하는지 모르겠습니다.

안녕하세요. 현재 PR 용으로 제공되는 Tabs 사양 을 반복하고 있음을 알려드리고자 합니다. 피드백이 있는 경우 PR에 의견을 추가하십시오!

Edge의 탭보다 Chrome의 탭처럼 느껴진다는 손가락이 교차했습니다.

Edge의 탭보다 Chrome의 탭처럼 느껴진다는 손가락이 교차했습니다.

우리는 상호 작용 디자인이 "올바른 느낌"을 주기를 원하므로 배송 전에 바로 받을 수 있도록 미리 보기 버전에 대한 특정 피드백이 있는 문제를 확실히 제출하십시오!

@chigy 와 같은 사람이 이미 TabView 컨트롤에 대한 디자인 구성 요소를 만들었는지 확실하지 않지만 빠르게 진행했으며 앞으로 나올 수 있는 측면 및 하단 배치 옵션도 시연했습니다.

닫기 버튼 호버/눌림 상태가 버튼의 전경이 아닌 배경을 변경하는 것을 좋아하지 않습니다. 배경을 변경하면 버튼이 너무 강조되고(탭 제목에서 멀어짐) 후자가 훨씬 더 우아해집니다.

예를 들어 Edge UWP의 닫기 버튼(전경 변경만 해당) 또는 Edge(Chromium)의 탭 오디오 음소거 버튼을 참조하세요.

나는 전경 변경을 고수하는 것을 고려했지만 배경 변경이 다른 컨트롤 및 제목 표시줄 동작과 인라인이 될 것이라고 생각했지만 기본적으로 전경이 될 수 있습니다.

@mdtauk - 당신은 바위입니다. 이러한 디자인 구성 요소를 만들어 주셔서 감사합니다. 컨트롤의 첫 번째 드롭에 대해 측면 배치를 수행하지 않을 것이지만 그것이 어떻게 보일지 보는 것은 좋습니다.

@chigy 와 저는 Windows 원칙(둥근 모서리, 표준 그림자 등 포함)과 일치하는 몇 가지 디자인 구성 요소를 구축하기 위해 협력하고 있지만 귀하가 제공한 디자인 구성 요소는 우리에게 영감을 주는 데 도움이 될 것입니다.

닫기 버튼 호버/눌림 상태가 버튼의 전경이 아닌 배경을 변경하는 것을 좋아하지 않습니다. 배경을 변경하면 버튼이 너무 강조되고(탭 제목에서 멀어짐) 후자가 훨씬 더 우아해집니다.

우리의 현재 생각은 여기에서 제안하는 것처럼 배경이 아닌 전경색을 변경하는 것입니다. 이것은 우리가 고려하고 있는 둥근 모서리에 조금 더 잘 맞는 추가 이점이 있습니다.

Edge 탭은 닫기 글리프 뒤에 배경을 사용하지만 내가 제안한 것보다 작습니다. 그러나 Edgium 탭은 아직 어떤 터치 모드도 지원하지 않습니다.

툴킷 디자인을 위한 사이드 탭을 생각할 때 @mdtauk 에서 보여주듯이 회전된 텍스트를 사용하여 세로로 탭을 수행하거나 여전히 가로로 유지하고 OneNote에서 사용하는 것처럼 왼쪽/오른쪽으로 더 큰 여백을 차지하는 것 사이에서 고민했습니다. 최신 재설계 이전에 WPF(호환성을 위해 중요하다고 생각함)와 유사합니다.

따라서 WPF가 넓은 여백과 가로를 사용하는 것처럼 유지하되 여기에 표시된 것처럼 둘 다 지원하는 것을 매우 간단하게 만드는 것이 좋습니다. 이것이 #546을 지원하는 또 다른 이유입니다.

@michael-hawker 저는 여백이 넓은 오른쪽에 세로 탭 목록이 있고 Visual Studio에서처럼 쉽게 회전할 수 있도록 하는 것을 지지합니다.

탭스팟 전후에 영향을 미치겠지만 월요일에 집에가면 디자인 목업을 해보도록 하겠습니다

탭스팟 전후에 영향을 미치겠지만 월요일에 집에가면 디자인 목업을 해보도록 하겠습니다

나는 집에 있고 여기 그 디자인이 있습니다:

컨트롤을 위한 디자인 목업을 다듬었습니다.

_탭 오버플로 및 탭 크기 추가_

마찬가지로 탭 개념은 Edge Chromium 탭보다 Edge UWP 탭과 훨씬 유사합니다. IMO 탭 컨트롤의 모양은 Edge UWP의 탭 컨트롤과 최대한 유사해야 합니다. Edge UWP와 같은 탭 컨트롤 배경으로 아크릴도 꽤 좋을 것입니다.

여전히 탭 닫기 버튼이 Edge UWP와 같이 만들어질 수 있기를 희망합니다. 여기에서 버튼은 현재 선택된 탭이나 탭 마우스 호버에만 표시됩니다.

WinUI 팀: @stmoy 분명히 Windows 터미널 팀은 탭 컨트롤의 배경으로 아크릴을 사용할 수 없습니다(https://github.com/microsoft/terminal/issues/1375 참조). 터미널 팀은 아키텍처 제한 때문이라고 주장합니다. 그것이 WinUI 팀이 도울 수 있는 일입니까? Edge UWP에서와 같이 탭 컨트롤에 대한 아크릴 배경의 팬이 꽤 있는 것 같습니다.

@Felix-Dev Edgeium이 앞으로 나아가야 할 새로운 디자인이라는 것을 알고 있지만 UWP Edge 디자인이 조금 더 멋지다고 생각합니다. 그래서 그 격차를 좁히려고 노력했습니다.

여전히 탭 닫기 버튼이 Edge UWP와 같이 만들어질 수 있기를 희망합니다. 여기에서 버튼은 현재 선택된 탭이나 탭 마우스 호버에만 표시됩니다.

CloseButtonOverlay 내가 생각하는 속성입니다

@mdtauk
명확히 하기 위해 닫기 버튼이 모든 탭에 지속적으로 표시되는 대신(탭 제목 imo에서 공간을 불필요하게 차지함) CloseButtonOverlay = OnHover가 탭 컨트롤의 기본값이 되도록 하고 싶습니다.

항상 표시는 터치 사용자에게 가장 적합하므로 기본값은 가능한 한 포괄적이어야 한다고 생각합니다.

닫기 버튼의 오버레이 모드는 사용자의 디스플레이 기능에 따라 달라질 수 있습니까?

디스플레이 유형에 따라 탭 컨트롤에 약간의 시각적 차이가 있을 수 있으므로 그것이 어떻게든 문제가 될 수 있는지 확실하지 않습니다.

닫기 버튼의 오버레이 모드는 사용자의 디스플레이 기능에 따라 달라질 수 있습니까?

디스플레이 유형에 따라 탭 컨트롤에 _약간_ 시각적인 차이가 있을 수 있으므로 그것이 어떻게든 문제가 될 수 있는지 확실하지 않습니다.

이는 플라이아웃을 트리거한 입력 유형을 감지하여 터치 입력으로 호출되는 경우 더 큰 터치 대상을 제공할 수 있기 때문에 플라이아웃과 같은 작업에 적합합니다.

일부 터치 장치에는 마우스가 연결되어 있기 때문에 항상 표시되는 컨트롤에는 작동하지 않습니다.

개발자는 물론 기본 옵션을 변경할 수 있으며 앱에서 닫기 버튼이 호버링 시에만 표시되도록 요구하는 많은 피드백을 받으면 변경하도록 선택할 수 있습니다.

탭 오버플로에 대한 아이디어를 추가했습니다.

이거 너무 좋아.

작은 것 하나. 그림자와 둥근 모서리가 있는 경우 선택한 탭 항목과 배경 가장자리 사이에 약간의 간격이 필요할 수 있습니다.

이거 너무 좋아.

작은 것 하나. 그림자와 둥근 모서리가 있는 경우 선택한 탭 항목과 배경 가장자리 사이에 약간의 간격이 필요할 수 있습니다.

왜 필요한지 궁금합니다... 창틀에 그림자가 잘리지 않습니까? 그림자가 위에 보이도록 미학적 선택입니까?

탭 크기 조정

@mdtauk : 저는 이 디자인들을 보는 것을 좋아합니다! 몇 가지 조사 질문이 있습니다.

• 보라색이 포인트 컬러인가요?
• 오버플로 스크린샷의 목적은 범퍼를 표시하기 위한 것입니까? 나는 단지 내가 그림을 올바르게 읽고 있는지 확인하고 싶을 뿐입니다.
• 탭의 모서리 반경은 얼마입니까?
• 탭의 높이는 얼마입니까?
• 어떤 글꼴 크기가 사용되었습니까?

이 디자인을 사용하여 터미널에서 친구들과 이야기하고 그들이 어떻게 생각하는지 볼 것입니다. 이러한 디자인에는 현재 방향의 몇 가지 델타가 포함되어 있지만 이를 사용하여 대화를 촉진할 것입니다.

@Felix-Dev : 피드백 주셔서 감사합니다. 아래에서 귀하의 요점 중 일부를 해결합니다.

마찬가지로 탭 개념은 Edge Chromium 탭보다 Edge UWP 탭과 훨씬 유사합니다. IMO 탭 컨트롤의 모양은 Edge UWP의 탭 컨트롤과 최대한 유사해야 합니다. Edge UWP와 같은 탭 컨트롤 배경으로 아크릴도 꽤 좋을 것입니다.

우리는 이러한 앱 경험 전반에 걸쳐 탭을 정렬하기 위해 다양한 팀(터미널 및 에지 팀 포함)과 적극적으로 반복하고 있습니다. 계속해서 반복하면서(그리고 #524와 같은 항목을 구현하면) 탭 컨트롤 디자인이 업데이트된 컨트롤과 더 일관성 있게 보일 것입니다.

여전히 탭 닫기 버튼이 Edge UWP와 같이 만들어질 수 있기를 희망합니다. 여기에서 버튼은 현재 선택된 탭이나 탭 마우스 호버에만 표시됩니다.

단기적으로는 터미널이 필요로 하는 시나리오를 구현하고 적절한 경우 API 표면을 다듬는 데 집중하고 있습니다. v1의 경우 Persistent만 지원합니다. 그렇긴 하지만, 나는 그것이 좋은 아이디어라고 생각하기 때문에 원래 호버 동작도 지정했습니다. 컨트롤의 다음 버전에서 재평가할 수 있도록 이러한 종류의 질문(예: x-on-hover, 탭 배치 등)을 추적하고 있습니다.

WinUI 팀: @stmoy 분명히 Windows 터미널 팀은 탭 컨트롤의 배경으로 아크릴을 사용할 수 없습니다(microsoft/terminal#1375 참조). 터미널 팀은 아키텍처 제한 때문이라고 주장합니다. 그것이 WinUI 팀이 도울 수 있는 일입니까? Edge UWP에서와 같이 탭 컨트롤에 대한 아크릴 배경의 팬이 꽤 있는 것 같습니다.

우리는 터미널 팀과 적극적으로 협력하고 있습니다. 불행히도 이 시나리오는 Tabs가 아닌 Xaml Islands의 알려진 제한 사항의 결과입니다. 앱이 TabControl.Background를 아크릴 브러시로 설정하는 경우 비 터미널 앱은 아크릴 배경을 "선택" 기능으로 사용할 수 있어야 합니다.

보라색이 포인트 컬러인가요?

예 - 내 디자인을 공식 디자인 컴포지션과 혼동하고 싶지 않았습니다.

오버플로 스크린샷의 목적은 범퍼를 표시하기 위한 것입니까? 나는 단지 내가 그림을 올바르게 읽고 있는지 확인하고 싶을 뿐입니다.

예, 왼쪽 및 오른쪽 버튼의 모양과 탭이 잘리는 방법을 보여줍니다.

탭의 모서리 반경은 얼마입니까?

4 epx - 안내가 2epx라는 것을 알고 있지만 선택한 표시기의 4epx 높이는 4로 더 잘 보입니다.

탭의 높이는 얼마입니까?

40epx

어떤 글꼴 크기가 사용되었습니까?

탭 제목 텍스트의 경우 14, MDL2 아이콘의 경우 16

Edge Canary에는 New tab-loading animation - edge://flags#new -tab-loading-animation이라는 플래그가 있습니다.

사양의 일부에는 다음과 같은 테마 및/또는 암시적 애니메이션이 포함되어야 합니다.

• 탭추가애니메이션
• TabRemove애니메이션
• TabSwitchTo애니메이션
• 애니메이션에서 탭 전환
• TabSelectedSwitchToAnimation
• TabSelectedSwitchFromAnimation
• TabDragOut애니메이션
• 탭 배치 애니메이션

@stmoy

우리는 터미널 팀과 적극적으로 협력하고 있습니다. 불행히도 이 시나리오는 Tabs가 아닌 Xaml Islands의 알려진 제한 사항의 결과입니다.

Xaml Island의 향후 버전에서 이 제한 사항을 해결할 수 있습니까? 예를 들어 Windows 터미널 앱에서 배경 아크릴에 대한 강한 열망이 있는 것 같습니다. https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390, 특히 해당 게시물의 마지막 이미지(제목 표시줄에 배경 아크릴 포함)를 참조하세요. 또한 해당 게시물이 😉를 받은 많은 찬성표를 확인하세요. 여기에 많은 찬성표가 있는 또 다른 게시물: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

탭 UI 디자인에 대해 더 광범위하게 말하면 Edge UWP 탭이 Edge Chromium 탭 모양보다 선호되는 사용자 의견에 대한 지지적인 반응도 확인하세요. https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 및 바로 아래에 게시합니다.

Edge Chromium 탭이 (현대) Windows 탭의 미래 모습을 나타내기 위한 것이라면 이러한 압도적인 사용자 반응은 Edge Chromium과 WinUI 모두에서 사용되는 탭의 모양을 재고해야 하는 이유일 수 있습니다. (또한 여기에 @chigy 를 추가하여 Windows 터미널 리포지토리에서 해당 탭 UI 반응을 확인할 수 있습니다.)

편집: 또한 Windows Terminal 팀이 이 문제를 "고칠 수 없을 것"이라고 재확인했기 때문에 이 주제에 대해 @marb2000 의 주의를 환기시켰습니다. WinUI 팀은 Windows 터미널에서 아크릴 제목 표시줄(매우 요청됨!)이 발생할 가능성을 어떻게 보고 있습니까? @stmoy

@marb2000 @stmoy 아래 질문에 댓글을 달아주세요.

또한 Windows 터미널 팀이 이 문제[(터미널의 아크릴 제목 표시줄)]를 "고칠 수 없음"을 재확인했기 때문에 이 주제에 대해 @marb2000 의 주의를 환기시켰습니다. WinUI 팀은 Windows 터미널에서 아크릴 제목 표시줄(매우 요청됨!)이 발생할 가능성을 어떻게 보고 있습니까?

@jjjjjjjjjjjjjjjjjjjjj 넘 넘 넘넘 감사 해

최근 커뮤니티 콜에서 여러분 중 한 명에게 핑을 보냈습니다 😁
Xaml Islands(Windows 터미널)의 기술 아크릴 제목 표시줄 지원에 대해 @stmoy 가 이미 부분적으로 답변한 위의 내 게시물을 참조하십시오.

내 게시물과 위의 답변에서 가져온 세 가지 주요 사항은 다음과 같습니다.

WinUI 팀의 경우: 분명히 Windows Terminal 팀은 탭 컨트롤의 배경으로 아크릴을 사용할 수 없습니다(microsoft/terminal#1375 참조). 터미널 팀은 아키텍처 제한 때문이라고 주장합니다. 그것이 WinUI 팀이 도울 수 있는 일입니까? Edge UWP에서와 같이 탭 컨트롤에 대한 아크릴 배경의 팬이 꽤 있는 것 같습니다.

@stmoy 의 답장:

우리는 터미널 팀과 적극적으로 협력하고 있습니다. 불행히도 이 시나리오는 Tabs가 아닌 Xaml Islands의 알려진 제한 사항의 결과입니다. 앱이 TabControl.Background를 아크릴 브러시로 설정하는 경우 비 터미널 앱은 아크릴 배경을 "선택" 기능으로 사용할 수 있어야 합니다.

내 질문:

또한 Windows 터미널 팀이 이 문제[(터미널의 아크릴 제목 표시줄)]를 "고칠 수 없음"을 재확인했기 때문에 이 주제에 대해 @marb2000 의 주의를 환기시켰습니다. WinUI 팀은 Windows 터미널에서 아크릴 제목 표시줄(매우 요청됨!)이 발생할 가능성을 어떻게 보고 있습니까?

답변 감사합니다 😁