Microsoft-ui-xaml: 제안: WinUI 컨트롤 세트에 익스팬더 컨트롤 추가.

에 만든 2020년 09월 11일 · 82코멘트 · 출처: microsoft/microsoft-ui-xaml

이것은 새로운 기능 또는 API 제안을 위한 템플릿입니다. 예를 들어 이를 사용하여 기존 유형에 대한 새 API를 제안하거나 새 UI 컨트롤에 대한 아이디어를 제안할 수 있습니다. UWP 또는 앱 모델과 관련된 기능 제안의 경우 Project Reunion 리포지토리에서 문제를 여십시오. https://github.com/microsoft/ProjectReunion 모든 세부 정보가 없어도 괜찮습니다. 요약부터 시작할 수 있습니다. 및 근거. 이 링크는 WinUI 기능/API 제안 프로세스를 설명합니다. https://github.com/Microsoft/microsoft-ui-xaml/blob/master/docs/feature_proposal_process.md

제안: WinUI 확장기 제어

이 문제에 대한 PR 과 함께 사양 이 열렸습니다. 이 제안에 대한 일반적인 토론을 자유롭게 계속하십시오!

요약

Windows 전체에서 Windows 보안, 설정, 사진, 그림판 3D, 알림 센터, 3D 뷰어, 알림 및 UWP Onedrive 앱에서 다양한 확장기 컨트롤이 사용됩니다. 현재 이 일반적인 UX 패턴을 처리하는 일관된 "Windows" 방식은 없습니다. Expander 컨트롤은 많은 앱 시나리오에서 사용하고 WPF와 패리티를 달성하기 때문에 동기가 부여됩니다.

이론적 해석

콘텐츠를 확장 및 축소하는 내장된 일관된 Fluent 방식이 있어야 합니다.
확장기 시나리오는 내레이터 친화적, 키보드 컨트롤, 애니메이션, 디자인 및 고대비 변경을 포함하여 동작 및 스타일이 정렬되지 않은 많은 표면에 존재합니다.

범위

| 기능 | 우선순위 |
| :------------ | :--------- |
| WinUI 앱에서 일관된 확장기 동작 제공 | 필수 |
| 컨트롤과의 사용자 상호 작용에 따라 크기 확장(다른 콘텐츠 푸시) 및 축소 | 필수 |
| 비확장 및 확장 콘텐츠에서 Button, ToggleSwitch와 같은 컨트롤 지원 | 필수 |
| 4방향 확장 지원 | 해야* |
| 확장된 상태의 모든 콘텐츠(헤더 포함) 수정 지원 | 수 |
| InfoBar 확장 지원(구현에 대한 공개 질문) | 수 |
| Expanders 사이에 "아코디언 동작" 논리 포함 | 하지 않을 |
| 가볍게 닫을 수 있습니다 | 하지 않을 |

*v1 Expander는 아래쪽 방향으로만 확장되도록 범위를 지정할 수 있으며 기본적으로 down 및 ExpandDirection이 나중에 추가됩니다.

중요 참고 사항

제안된 API

Public enum ExpandDirection 
{ 
Down = 0 
Up = 1 
Left = 2 
Right = 3 
} 

public class Expander : ContentControl 
{ 
Expander(); 

public object Header {get;set;} 
public DataTemplate HeaderTemplate { get;set; } 
public DataTemplate HeaderTemplateSelector {get;set;} 

public static readonly DependencyProperty HeaderProperty; 
public static readonly DependencyProperty HeaderTemplateProperty; 
public static readonly DependencyProperty HeaderTemplateSelectorProperty {get;} 

public bool IsExpanded { get;set} 
public ExpandDirection ExpandDirection { get;set;} 

protected virtual void OnExpanded(); 
protected virtual void OnCollapsed();

public event Expanded; 
public event Collapsed; 

public static readonly DependencyProperty IsExpandedProperty; 
public static readonly DependencyProperty ExpandDirectionProperty; 
} 

Visual States:  
ExpandStates: Expanded/Collapsed 

Accessibility: 
Support Expand/Collapse pattern (IExpandCollapseProvider)

다른 곳에서 확장기 컨트롤

확장기 시나리오의 예

expandcontrol-4 1
expandcontrol-2

열린 질문

WinUI 팀과의 논의에서 아래쪽으로 확장되는 V1은 개발 시간을 단축하고 개발자가 Expander를 더 빨리 사용할 수 있게 하며(지금까지 Expander에 대한 시나리오는 모두 하향 조정되었기 때문에) 계획된 V2에서 ExpandDirection을 추가할 수 있다고 언급되었습니다. 곧바로. 앱에서 Expander가 아래쪽이 아닌 다른 방향으로 확장해야 하는 시나리오가 있습니까?

Expander는 InfoBar와 어떻게 작동해야 합니까? InfoBar에 확장 기능을 추가하시겠습니까? InfoBar를 Expander의 콘텐츠로 사용하시겠습니까? 반전?

feature proposal team-Controls

출처

ejserna

👍15

가장 유용한 댓글

WinUI 프로젝트 @kat-y에 오신 것을 환영합니다. Xaml은 오랜 역사를 가지고 있지만 처음 사용하는 사람들에게는 약간 기이할 수 있습니다. WinUI는 작동 방식을 재고할 수 있는 기회이지만 이 경우 확장기는 비교적 간단한 컨트롤이므로 WPF에서 WinUI로의 간단한 이동으로 충분합니다.

@robloo XAML 컨트롤 템플릿을 다시 엔지니어링할 필요가 없다는 귀하의 주장에 동의하지 않습니다. WPF AFAIR에는 WinUI/Fluent에서 적절하지 않은 많은 크롬 유사 요소가 있습니다.

Chevron 및 터치 대상 크기를 처리하고 글꼴 크기 조정 크기를 사용합니다. Chevron은 제거하거나 추가하기 쉬워야 합니다.

이 예에는 텍스트와 일치하는 갈매기 모양이 있습니다.

이 예에는 갈매기 모양이 전혀 없습니다.

이 예에는 앞 쪽이 갈매기 모양을 향하고 있습니다.

구현과 관련하여 사용자가 애니메이션을 끄지 않는 한 열고 닫을 때 애니메이션 전환이 있어야 합니다. 그러면 상태만 전환됩니다.

mdtauk 에 2020년 09월 25일

👍4 ❤2

모든 82 댓글

Expander는 매우 유용하며 Windows Community Toolkit 버전이 추가된 이후로 계속 사용하고 있습니다. 나는 바퀴를 너무 많이 재발명하지는 않을 것입니다. 제 생각에는 툴킷에서 코드를 포팅하는 것이 버전 1.0에 완벽할 것입니다.

또 다른 예: 'MoreButton'이 있는 ColorPicker가 이것을 사용할 수 있습니다.

robloo 에 2020년 09월 13일

👍3

이 제안을 제출해 주셔서 감사합니다! 내가 생각하는 진정한 Expander 시나리오와 Flyout/MenuFlyout 사용과 유사한 것을 구분하는 것을 포함하여 몇 가지 편집을 할 것입니다.

kat-y 에 2020년 09월 21일

범위, 제안된 API 및 다음 공개 질문에 대한 자세한 내용을 포함하도록 이 제안을 업데이트했습니다.

v1 Expander에서 ExpandDirection을 지원해야 합니까? Expander가 아래쪽이 아닌 다른 방향으로 확장해야 하는 일반적인 앱 시나리오가 있습니까?

이것이 Expander의 사용 사례에 어떻게 적합하거나 적합하지 않은지에 대한 피드백을 원합니다!

kat-y 에 2020년 09월 25일

범위, 제안된 API 및 다음 공개 질문에 대한 자세한 내용을 포함하도록 이 제안을 업데이트했습니다.
v1 Expander에서 ExpandDirection을 지원해야 합니까? Expander가 아래쪽이 아닌 다른 방향으로 확장해야 하는 일반적인 앱 시나리오가 있습니까?
이것이 Expander의 사용 사례에 어떻게 적합하거나 적합하지 않은지에 대한 피드백을 원합니다!

컨트롤의 기본 기능인 것 같습니다.

mdtauk 에 2020년 09월 25일

👍3

컨트롤의 기본 기능인 것 같습니다.

@mdtauk 아래쪽이 일반적인 앱 시나리오가 아닌 ExpandDirection이 보입니까? 내가 보는 Expander 동작의 예는 훨씬 더 자주 아래쪽으로 확장됩니다. Expander에 ExpandDirection이 있으면 좋겠지만 v1에서 꼭 필요한가요?

kat-y 에 2020년 09월 25일

예, 확장 방향이 필요합니다. 이를 사용하는 경우가 많으며 v1 릴리스 이후에 컨트롤 템플릿을 추가하기 위해 불필요한 주요 변경 사항이 될 것입니다. Expander API는 WPF 이후로 많이 변경되지 않았으며 여기에 있는 제안에는 필요한 모든 속성/이벤트/메서드가 이미 있습니다. 이 모든 것을 한 번에 구현할 수 있으며 이 컨트롤로 완료할 수 있습니다. 디자인 면에서 UWP Community Toolkit은 터치 작업을 더 잘 수행하기 위해 필요한 변경 작업을 수행했습니다. 나는 우리가 모든 조각을 가지고 있고 아무것도 다시 발명할 필요가 없다고 생각합니다.

편집: 커뮤니티 툴킷에도 ContentOverlay 속성이 있습니다. V1에서는 건너뛸 수 있습니다.

robloo 에 2020년 09월 25일

👍1

예, 확장 방향이 필요합니다. 이를 사용하는 경우가 많으며 v1 릴리스 이후에 컨트롤 템플릿을 추가하기 위해 불필요한 주요 변경 사항이 될 것입니다.

@roblo 이것이 어떻게 획기적인 변화인지 자세히

kat-y 에 2020년 09월 25일

컨트롤의 기본 기능인 것 같습니다.
@mdtauk 아래쪽이 일반적인 앱 시나리오가 아닌 ExpandDirection이 보입니까? 내가 보는 Expander 동작의 예는 훨씬 더 자주 아래쪽으로 확장됩니다. Expander에 ExpandDirection이 있으면 좋겠지만 v1에서 꼭 필요한가요?

새로운 목록 콘텐츠를 아래에서 위로 로드하는 채팅 앱이 그 중 하나일 수 있습니다.

매우 기본적인 필수 사항 외에:

축소됨
확장 중
확장됨
IsCollapsing

뿐만 아니라 IsEnabled

다음 핵심은 확장할 위치입니다.

확장
아래로 펼치기
왼쪽으로 펼치기
오른쪽으로 펼치기

mdtauk 에 2020년 09월 25일

새로운 목록 콘텐츠를 아래에서 위로 로드하는 채팅 앱이 그 중 하나일 수 있습니다.

@mdtauk 이 채팅 앱의 예가 무엇을 의미하는지 완전히 이해하지 못합니다. 자세히
속성에 관해서는 - 제안된 API는 WPF Expander를 기반으로 하므로 IsExpanded 및 ExpandDirection이 이를 다룰 것이라고 생각합니다. IsEnabled는 무엇에 사용됩니까? Expander를 비활성화하려는 앱 시나리오가 있습니까?

kat-y 에 2020년 09월 25일

과거에 사용한 또 다른 예는 일반적으로 숨겨져야 하는 편집 가능한 보조 속성입니다. 이는 '옵션' 버튼을 클릭하고 확장기가 위쪽으로 열리는 경우에만 편집기 하단에 표시됩니다. 그것은 당신이 원하는 디자인에 달려 있습니다. 서로 다른 방향을 확장하는 데 유용한 경우가 많이 있으며 특히 과거의 관습이 너무 강할 때 이것을 인위적으로 제한하는 것은 불필요해 보입니다. 특히 모든 문제가 커뮤니티 툴킷과 WPF에서 이미 해결되었기 때문에 컨트롤의 V1에서는 이 중 어느 것도 너무 어려울 것이라고 생각하지 않습니다.

@roblo 이것이 어떻게 획기적인 변화인지 자세히

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander/Expander.xaml

템플릿과 시각적 상태를 디자인하는 데 매우 주의한다면 깨지지 않게 만드는 것이 가능하다고 생각합니다. 그러나 그렇게 하려면 어쨌든 기능을 설계해야 하므로 구현하는 것이 좋습니다. 이것은 모두 상당히 기본적이며 이 컨트롤을 처음부터 V2 계획에 사용할 이유가 없습니다.

나는 바퀴를 재발명하는 것이 매력적이라는 것을 압니다. 그러나 WPF에서 WinUI로 앱을 이식하는 사람들이 절대적으로 필요한 코드 변경 없이 수행할 수 있도록 유지하십시오. WinUI는 UWP의 일부 실수를 수정하기 시작해야 합니다.

robloo 에 2020년 09월 25일

👍1

IsEnabled는 무엇에 사용됩니까? Expander를 비활성화하려는 앱 시나리오가 있습니까?

@mdtauk 맞습니다. IsEnabled도 지원해야 합니다. 컨트롤을 비활성화하는 것은 입력 또는 상태 변경 가능성이 있을 때마다 매우 강력한 규칙입니다. 우리가 그것을 변호하게 만들지 마십시오.

robloo 에 2020년 09월 25일

👍3

위의 스크린샷에서 Windows 보안에는 바이러스 백신 섹션과 왼쪽 탐색 메뉴에 대한 확장기가 있습니다. 이것은 많은 앱이 지원해야 하는 여러 방향에서 확장기를 매우 현실적으로 사용함을 보여줍니다. 내 투표는 V1에서 여러 방향을 지원하는 것입니다.

JustABearOz 에 2020년 09월 25일

@roblo

과거에 사용한 또 다른 예는 일반적으로 숨겨져야 하는 편집 가능한 보조 속성입니다. 이는 '옵션' 버튼을 클릭하고 확장기가 위쪽으로 열리는 경우에만 편집기 하단에 표시됩니다.

시나리오를 더 잘 이해할 수 있도록 이러한 상황이 발생하는 스크린샷이나 특정 앱으로 자세히 설명해 주시겠습니까? 옵션 버튼이 더 많은 버튼이 있는 팝업을 여는 편집기를 생각할 수 있지만 다른 콘텐츠에 익숙한 편집기에서는 확장이 아닌 팝업/플라이아웃 동작인 다른 콘텐츠가 위쪽으로 푸시되지 않습니다.

템플릿과 시각적 상태를 디자인하는 데 매우 주의한다면 깨지지 않게 만드는 것이 가능하다고 생각합니다. 그러나 그렇게 하려면 어쨌든 기능을 설계해야 하므로 구현하는 것이 좋습니다. 이것은 모두 상당히 기본적이며 이 컨트롤을 처음부터 V2 계획에 사용할 이유가 없습니다.
나는 바퀴를 재발명하는 것이 매력적이라는 것을 압니다. 그러나 WPF에서 WinUI로 앱을 이식하는 사람들이 절대적으로 필요한 코드 변경 없이 수행할 수 있도록 유지하십시오.

WPF에서 WinUI로 앱을 포팅하는 것이 최대한 원활해야 한다는 데 동의합니다! WinUI 팀과의 논의에서 아래쪽으로 확장되는 V1은 개발 시간을 단축하고 개발자가 Expander를 더 빨리 사용할 수 있게 하며(지금까지 Expander에 대한 시나리오는 모두 하향 조정되었기 때문에) 계획된 V2에서 ExpandDirection을 추가할 수 있다고 언급되었습니다. 곧바로. (이 추가 컨텍스트를 포함하도록 공개 질문을 편집할 것입니다.) 이것이 개발자가 다운다운이 아닌 Expander에 대한 특정 사용 사례가 있는지 이해하기를 바라는 이유입니다! 😄

컨트롤을 비활성화하는 것은 입력 또는 상태 변경 가능성이 있을 때마다 매우 강력한 규칙입니다. 우리가 그것을 변호하게 만들지 마십시오.

설명해주셔서 감사합니다. 상태 변경을 비활성화하는 것이 이런 종류의 제어에 필요한 기능이라는 것은 완전히 이해가 됩니다!

kat-y 에 2020년 09월 25일

위의 스크린샷에서 Windows 보안에는 바이러스 백신 섹션과 왼쪽 탐색 메뉴에 대한 확장기가 있습니다. 이것은 많은 앱이 지원해야 하는 여러 방향에서 확장기를 매우 현실적으로 사용함을 보여줍니다. 내 투표는 V1에서 여러 방향을 지원하는 것입니다.

@JustABearOz 왼쪽 탐색 메뉴는 실제로 NavigationView 라고 생각합니다. 😃 바이러스 백신 섹션이 확장 시나리오라는 데 동의합니다. 이 경우 아래쪽으로 확장됩니다. 비 하향식 Expander에 대한 특정 사용 사례를 알고 싶습니다!

kat-y 에 2020년 09월 25일

@kat-y 좋아, 왼쪽/오른쪽이 필요하지 않지만 앱에 쉽게 적용할 수 있는 확장되는 창의 2가지 예:
1: 빠른 작업 메뉴가 있는 위의 스크린샷. 확실히 확장됩니다.
2: Windows에서 시스템 트레이의 팝업 달력에는 의제/약속을 표시하도록 확장되는 섹션이 있습니다.

V1에 Down만 지원하지 않고 Up/Down 지원이 가능한가요?

JustABearOz 에 2020년 09월 25일

👍1

1: 빠른 작업 메뉴가 있는 위의 스크린샷. 확실히 확장됩니다.

@JustABearOz 이러한 예를 대단히 감사합니다! 1의 경우: 이것은 흥미로운 경우라고 생각합니다. 확장은 '헤더'(확장 버튼)에서 '아래로'이지만 컨트롤 자체는 표면의 맨 아래에 위치하므로 헤더(및 확장된 콘텐츠) 위쪽으로 '이동'해야 합니다(그렇지 않으면 화면에서 실행됩니다!). 앱의 '하단'에 확장 항목이 있는 것을 처리하는 좋은 방법인 것 같습니다. 동의하십니까?

2: Windows에서 시스템 트레이의 팝업 달력에는 의제/약속을 표시하도록 확장되는 섹션이 있습니다.
V1에 Down만 지원하지 않고 Up/Down 지원이 가능한가요?

동의합니다. 이것은 헤더가 영역의 맨 아래에 있고 위로 확장되는 시나리오입니다! 이 경우 캘린더의 확장기(및 전체 팝업)가 작업 표시줄에 연결되어 있습니다. 앱에서 확장기가 위쪽 확장을 필요로 하는 유사한 연결 위치가 있는 시나리오를 본 적이 있습니까?

kat-y 에 2020년 09월 25일

😕1 👍1

@kat-y 내 말은 기분 나쁘다는 말은 아니지만 15년 전에 알려졌던 것들을 다시 설명해야 할 것 같은 느낌이 듭니다. 왜 실제 사용에서 확장 방향의 예를 들어달라고 요청하는지 이해가 되지 않습니다. 내부적으로는 이를 사양 검토에 적용하고 경영진에게 이를 방어해야 한다고 생각합니다. 그러나 설명은 간단하게 (1) 사용자가 디자인 목표를 달성할 수 있도록 권한을 부여해야 합니다. 컨트롤로 무엇을 할 수 있는지 여부를 말하는 것은 Microsoft의 책임이 아닙니다. 가장 좋은 것을 찾는 것은 앱 개발자/디자이너의 몫입니다. (2) 가장 중요한 것은 이것이 전혀 새로운 아이디어가 아니라는 점입니다. 이 영역의 기존 API를 복사하고 있으며 앱 호환성을 유지해야 합니다. 다시 말하지만, 이것이 새로운 아이디어라면 왜 우리가 그것을 방어해야 하는지 더 잘 이해할 것입니다. 기능에 시간을 투자하기 전에 기능이 유용한지 확인하는 것이 좋습니다.

헤더를 제외하고 이 컨트롤에는 문자 그대로 두 가지 속성이 있으며 C#이라면 WCT 기반을 사용하여 몇 시간 안에 작성할 수 있습니다. 우리는 WPF/WCT에 오늘날 존재하는 것처럼 구현하는 것보다 그것에 대해 이야기하는 데 더 많은 시간을 할애할 것입니다.

robloo 에 2020년 09월 25일

👍3

의견 을

참고로 @ranjeshj @ryandemopoulos @stmoy

michael-hawker 에 2020년 09월 25일

@roblo 솔직하게

이전에는 비하향 방향으로 사용되는 Expanders의 구체적인 예가 없었습니다. WinUI 커뮤니티의 모든 예( @justABearOz가 지적한 캘린더 플라이아웃 포함)와 내가 Michael에게서 배운 모든 것을 Expander의 v1에서 ExpandDirection을 유지하기 위한 증거로 WinUI 팀과의 토론에 가져올 것입니다.

내가 알고 있는 Expander 컨트롤 목록으로 제안을 업데이트했습니다. 놓친 부분이 있으면 알려주세요.

kat-y 에 2020년 09월 25일

WPF 소스 코드와 WCT 소스 코드를 모두 살펴보았습니다. 나는 이것이 몇 시간 안에 WinUI에서도 구현될 수 있다고 확신합니다. ContentOverlay 속성의 이름을 바꾸거나 V1에서 제외해야 하지만 컨트롤은 내가 본 것의 WCT 구현을 따라야 합니다.

WPF:
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Themes/XAML/Expander.xaml
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Expander.cs

WCT:
https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander

이 두 소스는 모두 Microsoft 및 라이선스가 부여된 MIT에서 가져온 것이므로 기본이 되어야 하며 0에서 시작하지 마십시오. Xamarin Forms는 WPF->WinUI의 개념과 일치하지 않으므로 무시해야 합니다(추가 기능도 없음). 타사 솔루션도 내가 본 것에서 획기적인 새로운 아이디어가 없습니다. 이 통제는 시간의 시험을 크게 견뎠습니다.

robloo 에 2020년 09월 25일

👍1

@roblo 솔직하게

이전에는 비하향 방향으로 사용되는 Expanders의 구체적인 예가 없었습니다. WinUI 커뮤니티( @JustABearOz가 지적한 캘린더 플라이아웃 포함)와 내가 Michael에게서 배운 모든 예를 Expander의 v1에서 ExpandDirection을 유지하기 위한 증거로 WinUI 팀과의 토론에 가져올 것입니다.

글쎄요, 제 요점은 이것에 대해 너무 많은 논의가 있어서는 안 된다는 것입니다. 이 컨트롤이 완벽한 예이기 때문에 여기에서 내 좌절감을 표현하기로 선택했습니다. 새로운 호출기 제어 또는 빵 부스러기 제어는 더 많은 감독이 필요하며 프로세스를 따르는 것이 중요합니다. 그러나 대규모 프로세스의 오버헤드가 여기저기서 나타나고 있으며 WCT에서 제어를 구현하는 것만으로도 부가가치가 없는 서류 작업과 토론을 하는 데 훨씬 더 많은 시간을 소비하게 됩니다. 나는 또한 WinUI 팀이 다소 우려되는 다른 이전 작업을 사용하는 것을 아직 보지 못했습니다. XAML 컨트롤 템플릿을 다시 엔지니어링할 필요가 없습니다.

robloo 에 2020년 09월 25일

👍1

Chevron 및 터치 대상 크기를 처리하고 글꼴 크기 조정 크기를 사용합니다. Chevron은 제거하거나 추가하기 쉬워야 합니다.

이 예에는 텍스트와 일치하는 갈매기 모양이 있습니다.

이 예에는 갈매기 모양이 전혀 없습니다.

이 예에는 앞 쪽이 갈매기 모양을 향하고 있습니다.

구현과 관련하여 사용자가 애니메이션을 끄지 않는 한 열고 닫을 때 애니메이션 전환이 있어야 합니다. 그러면 상태만 전환됩니다.

mdtauk 에 2020년 09월 25일

👍4 ❤2

구현과 관련하여 사용자가 애니메이션을 끄지 않는 한 열고 닫을 때 애니메이션 전환이 있어야 합니다. 그러면 상태만 전환됩니다.

애니메이션에 대해 물어보게 되었습니다. 예를 들어 레이아웃에 애니메이션을 적용하는 데 비용이 너무 많이 드는 시나리오에서 컨트롤에 대해 비활성화할 수 있는 방법이 있어야 합니까? 모든 사용자/개발자가 약간 반응이 없거나 원하지 않는 것과 같은 애니메이션을 원하는 것은 아닙니다(예: TreeView). 해당 지점을 사용자 지정하기 위해 컨트롤을 다시 템플릿하지 않는 것이 더 나을 수 있습니다. 사용자 정의할 수 있는 또 다른 사항은 애니메이션 지속 시간입니다. 경우에 따라 짧은 애니메이션이 긴 애니메이션보다 낫습니다.

chingucoding 에 2020년 09월 25일

모든 훌륭한 토론에 감사드립니다. 몇 가지 생각

@mdtauk가 언급한 대로 템플릿을 업데이트하여 가능한 경우 요소를 줄이고 성능을 개선할 수 있는 기회뿐만 아니라 새로운 디자인을 설명해야 합니다.
IsEnabled는 Control에서 상속되므로 작동할 것으로 예상합니다.

ranjeshj 에 2020년 09월 25일

👍3

구현과 관련하여 사용자가 애니메이션을 끄지 않는 한 열고 닫을 때 애니메이션 전환이 있어야 합니다. 그러면 상태만 전환됩니다.
애니메이션에 대해 물어보게 되었습니다. 예를 들어 레이아웃에 애니메이션을 적용하는 데 비용이 너무 많이 드는 시나리오에서 컨트롤에 대해 비활성화할 수 있는 방법이 있어야 합니까? 모든 사용자/개발자가 약간 반응이 없거나 원하지 않는 것과 같은 애니메이션을 원하는 것은 아닙니다(예: TreeView). 해당 지점을 사용자 지정하기 위해 컨트롤을 다시 템플릿하지 않는 것이 더 나을 수 있습니다. 사용자 정의할 수 있는 또 다른 사항은 애니메이션 지속 시간입니다. 경우에 따라 짧은 애니메이션이 긴 애니메이션보다 낫습니다.

일부 컨트롤에는 할당할 수 있는 전환 속성이 있다고 생각합니다. 따라서 애니메이션이 아닌 스토리보드가 리소스로 포함된 경우 적용할 수 있으며 다시 템플릿 없이 처리할 수 있습니다.

시스템 설정이 애니메이션을 끄면 전환을 재정의해야 합니다.

UIElement.Transitions?
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

또한 IsEnabled 속성에는 Disabled 상태가 있어야 합니다. Disabled Expanded와 Disabled Collapsed가 있어야 합니까, 아니면 Disabled가 항상 접혀 있어야 합니까?

mdtauk 에 2020년 09월 25일

애니메이션에 대한 흥미로운 점. 우리는 시스템 설정으로 모든 애니메이션을 끄지만 현재 템플릿을 다시 만드는 것 외에는 애니메이션을 끄도록 손잡이를 노출하지 않는다고 생각합니다.

ranjeshj 에 2020년 09월 25일

👍1

애니메이션에 대한 흥미로운 점. 우리는 시스템 설정으로 모든 애니메이션을 끄지만 현재 템플릿을 다시 만드는 것 외에는 애니메이션을 끄도록 손잡이를 노출하지 않는다고 생각합니다.

덮어쓸 Transition 컬렉션이 있다고 가정하고 애니메이션을 끄려는 경우 Transition 컬렉션을 null로 덮어쓰는 Style을 추가할 수 있다고 생각합니다.

stmoy 에 2020년 09월 25일

👍1

ExpandTransition 및 CollapseTransition을 포함하여 컨트롤의 속성에 의해 설정된 방향을 사용할 수 있습니다. 이를 통해 개발자가 각각에 대한 전환을 설정할 수 있습니다.

나는 그 아이디어가 마음에 들지만, 현재 사용자 정의 기능을 제한하는 사용자 정의 테마 전환을 생성할 수 있는 방법이 없다고 생각합니다. 이렇게하면 제거하여 쉽게 비활성화 할 수 있습니다.

mdtauk 에 2020년 09월 25일

👍1

또한 IsEnabled 속성에는 Disabled 상태가 있어야 합니다. Disabled Expanded와 Disabled Collapsed가 있어야 합니까, 아니면 Disabled가 항상 접혀 있어야 합니까?

IsExpanded 및 IsEnabled 속성을 사용하여 둘 중 필요한 조합을 생성할 수 있는 TreeView 컨트롤을 미러링하지 않는 이유는 무엇입니까? 비활성화된 확장이 어떤 경우에 가장 잘 작동한다면 그렇게 할 수 있습니다. 비활성화 된 축소가 필요한 경우 이 방법으로도 가능합니다.

Felix-Dev 에 2020년 09월 25일

👍3

@robloo XAML 컨트롤 템플릿을 다시 엔지니어링할 필요가 없다는 귀하의 주장에 동의하지 않습니다. WPF AFAIR에는 WinUI/Fluent에서 적절하지 않은 많은 크롬 유사 요소가 있습니다.

@mdtauk 음, 제 추천은 https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander에서 "WCT 구현을 따라야 함"이었습니다

robloo 에 2020년 09월 25일

👍1

@robloo XAML 컨트롤 템플릿을 다시 엔지니어링할 필요가 없다는 귀하의 주장에 동의하지 않습니다. WPF AFAIR에는 WinUI/Fluent에서 적절하지 않은 많은 크롬 유사 요소가 있습니다.
@mdtauk 글쎄, 내 추천은 우리가 여기에서 "WCT 구현을 따라야 한다"는 것이었습니다...
WPF 버전의 XAML에서 변경 사항이 없다고 가정했습니다.

그러나 나는 여전히 WinUI 디자인 팀이 figma 툴킷에 포함할 사양을 확인하기 위해서만 그것을 확인하고 그 변형을 승인해야 한다고 생각합니다.

mdtauk 에 2020년 09월 25일

@kat-y 프로젝트가 처음이라면 제가 거칠게 들렸다면 사과드립니다. 나는 확실히 필요한 일부 영역에서 프로젝트 속도를 향상시킬 수 있는 방법에 대한 위의 요점을 지지합니다. 또한 과거에 이미 수행된 작업과 지난 15년 동안 많은 테스트를 거쳤던 작업을 어떻게 사용해야 하는지에 대해서도 설명합니다. 물론 이 중 어느 것도 귀하나 누구에게나 개인적으로 지시된 것은 아닙니다. 더 많은 코딩/적은 프로젝트 관리를 위해 팀이 더 간소화되고 균형을 재조정해야 하는 수년 동안 Microsoft에서 보아온 일반적인 '팽창' 문제입니다. 계획만큼 좋은 것은 시행착오를 능가하는 것이 없으므로 결국 반복의 속도가 승리합니다.

@ranjeshj @michael-hawker 커뮤니티 툴킷에서 이미 수행된 것을 사용하지 않는 이유는 무엇입니까? WinUI 팀이 새로운 접근 방식을 취하는 것은 이번이 처음이 아닙니다. 이는 불필요하게 작업을 복제하고 최악의 경우 단편화를 일으킵니다. WCT 버전은 이미 WPF 아이디어를 기반으로 했으며 필요한 '현대적' 변경 사항을 적용했습니다.

robloo 에 2020년 09월 25일

❤1

@ranjeshj @michael-hawker 커뮤니티 툴킷에서 이미 수행된 것을 사용하지 않는 이유는 무엇입니까? WinUI 팀이 새로운 접근 방식을 취하는 것은 이번이 처음이 아닙니다. 이는 불필요하게 작업을 복제하고 최악의 경우 단편화를 일으킵니다. WCT 버전은 이미 WPF 아이디어를 기반으로 했으며 필요한 '현대적' 변경 사항을 적용했습니다.

Community Toolkit은 C#에 있으며 WinUI에는 C/C++ 코드가 필요합니다.

또한 WinUI 디자인 팀은 Toolkit 버전에 대해 AFAIK에 대해 말할 수 없었으므로 Windows 및 앱 디자인 팀의 요구 사항은 사용자 지정 솔루션에 대한 제어를 채택하려는 경우 특정 요구 사항이 있을 수 있습니다.

mdtauk 에 2020년 09월 25일

👍1

Community Toolkit은 C#에 있으며 WinUI에는 C/C++ 코드가 필요합니다.

C# 및 C++/WinRT로/에서 코드를 번역하는 것은 비교적 간단합니다. 특히 https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander 코드를 이미 본 Expander의 경우

또한 WinUI 디자인 팀은 Toolkit 버전에 대해 AFAIK에 대해 말할 수 없었으므로 Windows 및 앱 디자인 팀의 요구 사항은 사용자 지정 솔루션에 대한 제어를 채택하려는 경우 특정 요구 사항이 있을 수 있습니다.

특정 포인트의 경우 그렇습니다. 그러나 일반적인 제어 기능에 대해서는 동의하지 않을 수 없습니다. WCT는 우리에게 이미 95% 완성도와 기능 100% 완성도를 가져다 줄 것입니다. 상단에 적용된 모든 디자인 변경 사항은 사소한 것입니다.

robloo 에 2020년 09월 25일

👍1

@roblo 기능이 다른 부분에 대해 자세히

ranjeshj 에 2020년 09월 25일

@ranjeshj 우리는 같은 페이지에 있지 않을 수 있습니다. 제안된 API가 WCT 또는 WPF와 크게 다르다고 제안한 것은 아닙니다.

이 컨트롤의 첫 번째 버전에서는 ExpandDirection이 지원되지 않을 수 있다고 언급했습니다. 이는 이 기능에 대한 오랜 역사를 가진 Expander의 문제인 것 같습니다. 그렇다면 이 기능이 왜 필요한지 정당화해야 할 것 같았습니다.

나는 이것을 확장 방향으로 빠르게 구현하기 위해 WCT를 기반으로 사용할 것을 제안했습니다. XAML 템플릿을 복사하여 붙여넣는 동안 C# -> C++ 포트만 필요하므로(이를 위해 코드 숨김이 매우 작음) 휠을 다시 만들 필요가 없습니다. 그러면 필요한 모든 기능이 구현되고 ExpandDirection을 추가할 시간이 충분하지 않다는 우려를 피할 수 있습니다. 이 접근 방식은 우리에게 완전한 기능적 제어를 제공할 것입니다. 그런 다음 @mdtauk 또는 다른 사람의 제안을 기반으로 디자인/스타일링 변경을 맨 위에 수행할 수 있습니다. 이해가 되지 않습니다. (1) ExpandDirection이 V1의 도마에 있을 가능성이 있는 이유 (2) 시간이 제한적이라면 기존 코드를 사용하지 않는 이유는 무엇입니까?

예, 일반적으로 WinUI 3 개발에 대한 저의 좌절감이 이 부분에 영향을 미치고 있으며 이에 대해 사과드립니다.

robloo 에 2020년 09월 25일

👍1

@robloo 뭔가 도마에

V1에 포함되어야 하고 V2에 포함되어야 하는 기능의 우선 순위를 지정할 때 일반적으로 사용되지 않는 레거시 항목이 아닌 핵심 및 필수 속성 및 동작만 있을 것입니다.

Microsoft는 이전 프레임워크와 동등한 수준에 도달하는 것뿐만 아니라 고객의 요구와 필요에 따라 추가할 기능을 결정하는 것 같습니다.

따라서 _정당화_하는 것이 아니라 개발자가 UI에서 이러한 제어 패턴으로 실제로 무엇을 하는지 이해하려고 합니다.
Windows 셸에만 여러 버전의 확장기 제어 패턴이 있다는 사실은 이를 포함해야 하는 충분한 이유가 됩니다. 그리고 각각의 구현이 다르게 동작하지 않더라도 다르게 보인다는 사실은 디자인 팀이 내부 팀의 요구 사항을 충족하기 위해 제어 디자인을 통합하는 데 충분한 이유가 됩니다.

mdtauk 에 2020년 09월 25일

👍1

@mdtauk 언제나처럼 좋은 지적입니다. 그러나 이것이 진정으로 Microsoft가 취하고 있는 접근 방식이라면 이 철학에 한 가지 중요한 점에서 동의하지 않을 수 없습니다. WinUI가 성공하려면 기존 앱 개발자에게 의미가 있어야 합니다. 나는 UWP가 결코 시작되지 않았다는 것을 우리 모두 알고 있기 때문에 다른 UWP 시나리오를 피하려고 노력하고 있습니다. Microsoft가 WinUI로 넘어가도록 설득해야 하는 개발자는 이전 UWP와 마찬가지로 WPF 개발자입니다. WPF 앱이 UWP로 점프하지 않은 이유 중 하나는 특히 UWP가 처음 출시되었을 때 여러 주요 기능 영역에서 매우 열악한 동등물이었기 때문입니다. 이것이 로드맵에서 둥근 모서리가 누락된 것을 보았을 때 UWP 악몽을 회상하기 시작한 이유입니다(WPF의 기본 둥근 모서리는 가장 오랫동안 UWP에서 제외되었습니다). 1순위 우선 순위는 WPF와 UWP 모두에서 오는 부드러운 포팅 경험을 위한 것이어야 하며 솔직히 WPF는 훨씬 더 많은 앱이 있고 Microsoft가 WinUI를 사용하는 데스크톱 사례에 먼저 초점을 맞추고 있기 때문에 아마도 더 높은 우선 순위여야 합니다. 다시 말하지만, 우리는 바퀴를 재발명하는 것에 대해 매우 조심해야 하고 적극적으로 피해야 합니다.

그리고 각각의 구현이 다르게 동작하지 않더라도 다르게 보인다는 사실은 디자인 팀이 내부 팀의 요구 사항을 충족하기 위해 제어 디자인을 통합하는 데 충분한 이유가 됩니다.

나는 항상 디자인을 수정해야 할 수도 있다는 것을 이해했습니다. 겉보기 제어 개념을 사용하면 이것은 ExpandDirection과는 별개의 문제입니다. 디자인을 더 현대화하거나 경우에 따라 더 유용하게 만들어야 하는 경우에는 아주 좋습니다. 상대적으로 사소해야 합니다. 하루가 끝나면 미세 제어가 필요한 사람들을 위해 완전히 다시 템플릿을 사용할 수도 있습니다.

robloo 에 2020년 09월 25일

👍1

애니메이션에 대한 흥미로운 점. 우리는 시스템 설정으로 모든 애니메이션을 끄지만 현재 템플릿을 다시 만드는 것 외에는 애니메이션을 끄도록 손잡이를 노출하지 않는다고 생각합니다.

하지만 공정하게 말하면 애니메이션을 사용하는 컨트롤은 거의 없습니다. TreeView와 NavigationView는 기본적으로 Expander를 사용하지만 둘 다 확장/축소에 애니메이션을 사용하지 않습니다. 애니메이션을 사용하는 대부분의 컨트롤은 일반적으로 이에 의존합니다(예: ProgressBar 또는 ProgressRing). 그러나 Expander는 이에 의존하지 않으며 "있으면 좋은" 것입니다. 또 다른 예는 일부 사람들이 애니메이션을 싫어해서 WCT Expander 컨트롤을 사용하지 않았다는 것입니다. 가능한 한 많은 사람을 포함시키려면 원치 않는 애니메이션을 비활성화하는 쉬운 방법이 있으면 더 쉽게 만들 수 있습니다.

덮어쓸 Transition 컬렉션이 있다고 가정하고 애니메이션을 끄려는 경우 Transition 컬렉션을 null로 덮어쓰는 Style을 추가할 수 있다고 생각합니다.

그러나 이것이 그것을 비활성화/활성화하는 일반적인 방법입니까? 대부분의 경우 여러 스타일을 제공할 때 AccentColorButtonStyle 또는 RevealButtonStyle과 같이 하나의 애니메이션보다 훨씬 더 크게 다릅니다.

ExpandTransition 및 CollapseTransition을 포함하여 컨트롤의 속성에 의해 설정된 방향을 사용할 수 있습니다. 이를 통해 개발자는 각각에 대해 전환을 설정할 수 있습니다.

이 아이디어가 정말 마음에 듭니다!

나는 그 아이디어가 마음에 들지만, 현재 사용자 정의 기능을 제한하는 사용자 정의 테마 전환을 생성할 수 있는 방법이 없다고 생각합니다. 이렇게하면 제거하여 쉽게 비활성화 할 수 있습니다.

저도 그게 걱정입니다. 사용자 정의 테마 전환 없이 ExpandTransition 및 CollapseTransition API를 사용하면 "ExpendTransitionEnabled" 및 "CollapseTransitionEnabled"만 있는 것과 비슷합니다.

chingucoding 에 2020년 09월 25일

👍1

@robloo WinUI 3 개발과 관련된 불만 사항에 대해 이야기하고 싶다면 저에게 편지를 보내주세요(제 Twitter와 직장 이메일은 제 GitHub 프로필에 있습니다). 귀하의 현재 불만 사항에 대해 완전히 알고 있지는 않지만, 저는 일반적으로 고객 또는 커뮤니티 참여/개발과 관련된 주제에 대해 시작하기에 좋은 사람일 뿐만 아니라 지난 1년 동안 상당한 수의 포커스 그룹을 운영했습니다. 도구, 기능 패리티 등에 대해 나열한 고려 사항을 다뤘습니다.

로드맵이 매우 빡빡하기 때문에 원하는 변경을 할 수 있다고 장담할 수는 없지만, 고객 및/또는 WinUI 기여자이므로 최악의 경우 결과는 최소한 귀하의 요구 사항이 앞으로 나아가는 우리 팀에서 충분히 고려된다는 것입니다. 가장 좋은 경우는 당신이 찾고 있는 것에 달려 있다고 생각합니다. 채팅하자? 😄

@mdtauk 설명을 도와 주셔서 감사합니다. 항상 잘 지내고 있습니다! 우리 팀에는 분명히 많은 것이 있으며 팀은 모든 영역에서 가장 의미 있고 영향력 있는 진전을 제공하기 위해 가능한 한 야위고 효과적인 데 전념하고 있습니다. 계속 진행되는 다른 모든 영역 중에서 새로운 제어/기능에 계속 투자하려면 @kat-y와 같은 팀원이 _매우_ 날카로운 요구 사항 사양을 개발해야 합니다. 개발 초기 비용뿐만 아니라 유지 관리 비용이 계속 발생하기 때문에 실제로 널리 사용되지 않는 API입니다. 방금 이 스레드를 간단히 구문 분석했지만 @kat-y, 특히 새 팀 구성원으로서 요청된 기능이 필요한 실제 앱의 실제 시나리오가 있는지 확인하는 데 완벽하게 명확하기를 원하는 것이 옳습니다( 명시된 이유와 개발된 모든 기능이 엣지 케이스 적용 범위를 제공하는 프로덕션 환경에서 요구되는 대로 수행되도록 도울 수 있는 미리 보기 검증 파트너가 있는지 확인하기 위해서입니다. 이러한 열망의 준수는 검증 파트너가 비공개인 경우와 같이 공개적으로 방송되지 않을 수 있습니다(여기에 공개적으로 게시하기에 적합하지 않은 요구사항이 있는 경우 @kat-y에 직접 연락할 수 있습니다. 현재) 그러나 이것은 모든 WinUI 2+ 컨트롤 릴리스에서 선례였습니다.

도움이 되었나요? 이 스레드를 @kat-y 및 현재의 Expander 주제로 다시 넘기는 것이 제 목표입니다. 하지만 답변할 수 있는 내용이 더 있거나 고려하고 싶은 피드백이 있으면 직접 연락해 주세요. 이 스레드와 WinUI에 쏟은 모든 작업, 열정 및 에너지에 감사드립니다! 😄

SavoySchuler 에 2020년 09월 25일

👍2 ❤1

@mdtauk 언제나처럼 좋은 지적입니다. 그러나 이것이 진정으로 Microsoft가 취하고 있는 접근 방식이라면 이 철학에 한 가지 중요한 점에서 동의하지 않을 수 없습니다.
나는 접근 방식에 동의하는지 여부에 대해 언급하지 않았으며, 여기에서 내가 레포를 평가하는 방법을 지켜보면서 팀이 이 작업을 하고 있다고 생각합니다.

(명시된 이유와 개발된 모든 기능이 에지 케이스 적용 범위를 제공하는 프로덕션 환경에서 필요에 따라 수행되도록 도울 수 있는 미리 보기 검증 파트너가 있는지 확인하기 위함입니다.) 이러한 열망의 준수는 검증 파트너가 비공개인 경우와 같이 공개적으로 방송되지 않을 수 있습니다(여기에 공개적으로 게시하기에 적합하지 않은 요구사항이 있는 경우 @kat-y에 직접 연락할 수 있습니다. 현재) 그러나 이것은 모든 WinUI 2+ 컨트롤 릴리스에서 선례였습니다.
Microsoft의 자체 앱과 Shell을 예로 사용하면 존재하지 않거나 목적에 적합하지 않은 내부 필요가 있는 곳을 보여주기 때문에 인식을 이끌어낼 가능성이 더 높다고 생각합니다. " 자신의 것을 롤백해야 합니다." - 물론 Windows용 앱을 빌드하는 Netflix, Facebook 등과 같은 거대 기업은 컨트롤 및 기타 비트도 요구할 것입니다.

WinUI는 WPF, MFC, CommonControls, WinForms 등과 같은 패리티에 도달하는 것에 관한 것이 아닙니다. (그러나 현대적인 등가물 없이 이러한 레거시 컨트롤을 더 일반적으로 사용하는 경우 진지하게 검토해야 함)

Breadcrumb Bars 및 Expanders가 제안되고 있다는 사실은 이것이 IMO에서 일어나기 시작했다는 신호입니다. 그리고 앱 디자이너가 목적에 맞는지 확인하기 위해 항상 UI와 UX를 재평가해야 하는 것처럼 모든 컨트롤 또는 API 추가는 이상적인 환경에서 평가되고 "정당화"되어야 합니다. - 이 경우에는 명백해 보일 수 있지만 포함 사례를 강화하기 위해 이 패턴과 이러한 API가 사용되는 예를 계속 제시해야 합니다.

mdtauk 에 2020년 09월 25일

애니메이션 정보: ItemsRepeater가 제공하는 것과 같은 ElementAnimator 접근 방식을 사용하는 것은 어떻습니까? StartShowAnimation() 및 StartHideAnimation() 가 있는 ElementAnimator API는 유망해 보입니다(확장에는 "표시", 축소에는 "숨기기" 사용). 기본 애니메이션 구현을 사용하여 컨트롤에 ElementAnimator 속성을 제공할 수 있습니다. 애니메이션이 필요하지 않은 경우 속성을 null로 설정하거나 보다 세분화된 제어가 필요한 경우 ElementAnimator에 표시 또는 숨기기 애니메이션만 제공할 수 있습니다.

저는 ElementAnimator API에 익숙하지 않으며 https://github.com/microsoft/microsoft-ui-xaml/issues/166 문제가 존재하기 때문에 모든 시나리오에서 아직 사용할 수 없는 것 같습니다. 그러나 여전히 기능적 격차가 있는 경우 이러한 작업 항목(Expander 컨트롤 및 ElementAnimator가 Expander 컨트롤에서 사용할 수 있도록 작동)을 동기화하고 함께 엔지니어링할 수 있습니다.

Felix-Dev 에 2020년 09월 25일

흠 ElementAnimator 아이디어는 정말 흥미롭습니다. 여기서 제 걱정은 이것이 너무 복잡하거나 과도하게 엔지니어링된 것일 수 있다는 것입니다. 결국 ExpanderControl의 경우 사용자 지정 ElementAnimator를 제공해야 하지만 그렇지 않으면 기존 테마 애니메이션을 재사용할 수 있습니다. 또한 ElementAnimator는 확장기 컨트롤이 실제로 필요로 하는 것보다 더 많은 방법을 제공하므로 다소 어색한 것처럼 보입니다.

chingucoding 에 2020년 09월 25일

ElementAnimator가 화면에 나타나는 자식 또는 포함된 요소의 오프셋을 처리하기 위한 것이라고 생각하는 것이 맞습니까?

확장기로 표시되는 패널 내에 무엇이 있는지에 따라 과도할 수 있습니다. 그러나 어떻게든 연결할 수 있는 방법이 있다면 요소를 포함하는 확장 패널이 요소에 무언가를 추가하는 경우 하위 애니메이션을 구동할 수 있습니다.

따라서 Expander는 자식 요소 전환을 직접 제어하지 않지만 개발자가 원하는 경우 활성화할 수 있습니다.

mdtauk 에 2020년 09월 25일

예, 여기에서 재사용 가능한 애니메이션을 만들 수 있고 고객에게 만족스러운 수준의 사용자 지정 옵션을 제공할 수 있다면 탐색할 가치가 있을 것입니다. 예를 들어 항목이 확장/축소될 때 TreeView 컨트롤에 애니메이션을 추가하라는 요청을 이미 보았습니다(https://github.com/microsoft/microsoft-ui-xaml/issues/208). Expander와 TreeView 컨트롤 모두에 대해 멋지게 보이도록 한 세트의 애니메이션을 빌드할 수 있는 경우가 여기에서 만들어질 수 있다고 상상합니다. 다른 컨트롤 간에 일관성 수준이 자동으로 제공됩니다. 사용자에게 시각적 친숙함을 만드는 것도 매력적인 주장입니다.

Felix-Dev 에 2020년 09월 25일

👍2

이상적으로는 TreeView와 계층적 NavigationView가 컨트롤이 준비되면 Expander 컨트롤로 전환되어야 한다고 생각합니다. 결국, 현재 두 컨트롤은 ExpanderControl로 해결되는 똑같은 문제를 처리해야 합니다. 따라서 공유 애니메이션은 TreeView에 큰 차이를 만들지 않습니다.

ElementAnimator의 문제(내가 이해한 방법)는 새 애니메이션을 작성해야 한다는 것입니다. 그러나 Expander에 활용할 수 있는 애니메이션이 이미 내장되어 있습니다.

확장기로 표시되는 패널 내에 무엇이 있는지에 따라 과도할 수 있습니다. 그러나 어떻게든 연결할 수 있는 방법이 있다면 요소를 포함하는 확장 패널이 요소에 무언가를 추가하는 경우 하위 애니메이션을 구동할 수 있습니다.

ElementAnimator의 주요 포인트 중 하나는 패널과 컬렉션(예: ItemsRepeater)에 애니메이션을 추가할 수 있다는 것이었습니다. Expander의 경우 실제로는 그렇지 않지만 expander는 항목 모음을 렌더링하는 패널이 아닙니다.

chingucoding 에 2020년 09월 25일

내 머리 꼭대기에서 여유가있는 상위 패널의 크기 조정. 그러면 포함하는 개체에 대한 슬라이드 및 페이드가 올바르게 느껴질 것입니다.

Fluent Design 모션 팀에서 결정한 적절한 완화로 일반화된 OS 전체 전환이 된다면 좋을 것입니다.

mdtauk 에 2020년 09월 26일

애니메이션에 대해 이야기하고 있으므로 @stmoy에 태그를 지정합니다.

ranjeshj 에 2020년 09월 26일

참여하고 우리 팀의 약속에 대해 더 많은 컨텍스트를 제공한 @SavoySchuler 에게 감사합니다. 이것이 내가 왜 ExpandDirection의 기능이 필요한 앱의 예를 특별히 찾고 있는지 설명하는 데 도움이 되기를 바랍니다! 사보이의 말을 되풀이하려면 여기에서 공유할 수 없는 확장 프로그램이 필요한 경우 저에게 직접 연락하세요(프라이버시가 필요한 경우 트위터 DM).

@robloo 사과

그런 점에서 저는 애니메이션에 대한 최신 댓글을 읽게 되어 기쁩니다!

kat-y 에 2020년 09월 26일

애니메이션 관련 댓글을 읽어보니 작업량이 늘어나는 순서대로 3가지 경로가 있는 것 같습니다.

세트 애니메이션을 포함하지 않음 - 시나리오가 작동하지 않거나 세트 애니메이션이 좋아 보일 때 @chingucoding 이 개발자를

@mdtauk 는 ExpandTransition 및 CollapseTransition을 포함하여 제안했습니다

컨트롤의 속성에 의해 설정된 방향을 사용할 수 있습니다. 이를 통해 개발자가 각각에 대한 전환을 설정할 수 있습니다.

ElementAnimator를 사용하는 것보다 작은 범위처럼 들립니다. 이렇게 하면 개발자가 전환을 설정할 때 완전한 유연성을 얻을 수 있습니까?

내 머리 꼭대기에서 여유가있는 상위 패널의 크기 조정. 그러면 포함하는 개체에 대한 슬라이드 및 페이드가 올바르게 느껴질 것입니다.

나는 이것의 일부를 이해하지만 시각적 😄 없이는 시각화하기가 어렵습니다. "상위 패널의 크기 조정"은 헤더의 크기가 변경됨을 의미합니까? "포함하는 개체의 슬라이드 및 페이드"가 무엇을 의미하는지 자세히 설명해 주시겠습니까?

@Felix-Dev는 ElementAnimator를 사용하여 제안했습니다.

StartShowAnimation() 및 StartHideAnimation()이 있는 ElementAnimator API는 유망해 보입니다("표시"는 확장에 사용, "숨김"은 축소에 사용). 기본 애니메이션 구현을 사용하여 컨트롤에 ElementAnimator 속성을 제공할 수 있습니다. 애니메이션이 필요하지 않은 경우 속성을 null로 설정하거나 보다 세분화된 제어가 필요한 경우 ElementAnimator에 표시 또는 숨기기 애니메이션만 제공할 수 있습니다.

@chingucoding 은 다음과 같이 언급했습니다.

그런 다음 기존 테마 애니메이션을 재사용할 수 있는 동안 사용자 지정 ElementAnimator를 제공해야 합니다. 또한 ElementAnimator는 확장기 컨트롤이 실제로 필요로 하는 것보다 더 많은 방법을 제공하므로 다소 어색한 것처럼 보입니다.

ElementAnimator의 주요 포인트 중 하나는 패널 및 컬렉션(예: ItemsRepeater)에 애니메이션을 추가할 수 있다는 것입니다. Expander의 경우 실제로는 그렇지 않지만 expander는 항목 모음을 렌더링하는 패널이 아닙니다.

TreeView 및 계층적 NavigationView는 컨트롤이 준비되면 Expander 컨트롤로 전환되어야 합니다. 결국, 현재 두 컨트롤은 ExpanderControl로 해결되는 똑같은 문제를 처리해야 합니다. 따라서 공유 애니메이션은 TreeView에 큰 차이를 만들지 않습니다.

TreeView와 계층적 NavigationView가 Expander와 정확히 동일한 애니메이션 시나리오를 가지고 있는지 잘 모르겠습니다. Expander가 근처에 있는 모든 콘텐츠(텍스트/버튼이 아닐 수도 있음)를 푸시할 때와 Expander가 서로 '아코디언'되는 시나리오는 어떻습니까? 잠재적으로 서로의 확장에 따라 닫거나 열 수 있는 논리가 있습니다.

ElementAnimator가 패널/컬렉션 애니메이션용이라는 점을 감안할 때 Expander 애니메이션에 과도합니까?

kat-y 에 2020년 09월 26일

@mdtauk 는 ExpandTransition 및 CollapseTransition을 포함하여 제안했습니다
컨트롤의 속성에 의해 설정된 방향을 사용할 수 있습니다. 이를 통해 개발자가 각각에 대한 전환을 설정할 수 있습니다.
ElementAnimator를 사용하는 것보다 작은 범위처럼 들립니다. 이렇게 하면 개발자가 전환을 설정할 때 완전한 유연성을 얻을 수 있습니까?
내 머리 꼭대기에서 여유가있는 상위 패널의 크기 조정. 그러면 포함하는 개체에 대한 슬라이드 및 페이드가 올바르게 느껴질 것입니다.
나는 이것의 일부를 이해하지만 시각적 😄 없이는 시각화하기가 어렵습니다. "상위 패널의 크기 조정"은 헤더의 크기가 변경됨을 의미합니까? "포함하는 개체의 슬라이드 및 페이드"가 무엇을 의미하는지 자세히 설명해 주시겠습니까?

expander_motion

늦어서 죄송합니다. 이 작은 목업 애니메이션을 만들어야 했습니다.
실제 애니메이션 타이밍은 무시하십시오. 단지 설명을 위한 것입니다. 분홍색 윤곽선은 확장기 헤더이고 녹색 테두리는 확장기 창/콘텐츠 등입니다.

mdtauk 에 2020년 09월 26일

❤1

TreeView와 계층적 NavigationView가 Expander와 정확히 동일한 애니메이션 시나리오를 가지고 있는지 잘 모르겠습니다. Expander가 근처에 있는 모든 콘텐츠(텍스트/버튼이 아닐 수도 있음)를 푸시할 때와 Expander가 서로 '아코디언'되는 시나리오는 어떻습니까? 잠재적으로 서로의 확장에 따라 닫거나 열 수 있는 논리가 있습니다.

문제는 Expander가 애니메이션을 적용해야 합니까? TreeView 및 Hierarchical NavigationView는 확장/축소를 처리하고 해당 영역에서 보다 통합된 경험을 할 수 있도록 하는 확장기 컨트롤이 내장되어 있어 확실히 이점이 있습니다. 예를 들어 TreeView는 아무 것도 애니메이션하지 않는 반면 계층적 NavigationView는 갈매기 모양의 회전에 애니메이션을 적용합니다.

ElementAnimator가 패널/컬렉션 애니메이션용이라는 점을 감안할 때 Expander 애니메이션에 과도합니까?

ElementAnimator(적어도 미리 보기에서는)를 적극적으로 지원하는 컨트롤 중 하나는 수십 개의 항목을 렌더링하는 대형 패널을 처리하는 ItemsRepeater일 수 있습니다. 반면 Expander에는 복잡한 시나리오가 아니라 하나의 항목을 표시하거나 숨길 수 있습니다.

내가 알아차린 다른 점은 갈매기 모양이 배치될 위치(왼쪽/오른쪽 또는 위쪽/아래쪽)를 사용자 지정할 수 있는 방법이 없다는 것입니다. 아마도 이것은 사용자 정의 포인트로 유용하지 않을까요? NavigationView는 갈매기 모양을 오른쪽에 배치하고 TreeView는 왼쪽에 갈매기 모양을 배치합니다. 시스템의 기존 확장기에도 동일하게 적용되며 설정 앱의 일부 영역에서는 왼쪽에 배치하고 예를 들어 알림은 오른쪽에 배치합니다.

chingucoding 에 2020년 09월 26일

내가 알아차린 다른 점은 갈매기 모양이 배치될 위치(왼쪽/오른쪽 또는 위쪽/아래쪽)를 사용자 지정할 수 있는 방법이 없다는 것입니다. 아마도 이것은 사용자 정의 포인트로 유용하지 않을까요? NavigationView는 갈매기 모양을 오른쪽에 배치하고 TreeView는 왼쪽에 갈매기 모양을 배치합니다. 시스템의 기존 확장기에도 동일하게 적용되며 설정 앱의 일부 영역에서는 왼쪽에 배치하고 예를 들어 알림은 오른쪽에 배치합니다.

TopLeft, TopRight, BottomCentered(및 더 많은 (Left, Right, ...)) 및 추가 ExpandGlyphPlacementOffset 속성을 수정하는 데 사용할 수 있는 ExpandGlyphPlacementMode 와 같은 값을 도입할 수 있습니다. 필요한 경우 기본 위치(배치 모드로 설정).

그 외에도 @mdtauk가 이미 알아차린 것처럼 확장/축소 글리프를 사용자 지정하는 API(일부 컨트롤은 > 사용, 다른 컨트롤은 확장 글리프에 v ) 및 글리프.

Felix-Dev 에 2020년 09월 26일

TopLeft, TopRight, BottomCentered(및 더 많은 (Left, Right, ...)) 값이 있는 ExpandGlyphPlacementMode와 필요한 경우 개발자가 기본 위치(배치 모드로 설정)를 수정하는 데 사용할 수 있는 추가 ExpandGlyphPlacementOffset 속성을 도입할 수 있습니다. .

TopLeft, TopRight ... 여기에서 올바른 선택인지 확실하지 않습니다. "시작" 및 "끝"과 같은 것이 여기에 더 적합할 수 있습니까?
가로 레이아웃에서 시작은 왼쪽(RTL 언어의 경우 오른쪽)에 있고 세로 열기 모드에서는 위쪽이 됩니다. "끝"은 그에 따라 정의될 수 있습니다. TopLeft에서 볼 수 있는 문제는 ... 이점은 거의 없지만 복잡성이 많이 발생한다는 것입니다(TeachingTip 참조). ExpanderControl이 오른쪽으로 열리면 TopLeft와 TopRight가 동일합니다. 하단 중앙과 같은 것이 많은 공간에서 다소 어색해 보이고 많은 공간을 차지할 것이라고 생각합니다.

그 외에도 @ mdtauk(받은 편지함을 스팸하지 않기 위해 언급 나누기)에서 이미 확인했듯이 확장/축소 글리프를 사용자 지정하는 API(일부 컨트롤은 >를 사용하고 다른 컨트롤은 확장 글리프에 v를 사용) 글리프.

문제는 이것을 달성하는 방법입니다. 계층적 NavigationView가 수행하는 것과 유사하게 아이콘에 애니메이션을 적용하려는 경우 접힌 경우 v 또는 >로 전환하는 데 사용할 수 있는 확장 및 축소 글리프를 교체하는 API를 허용할 수 없습니다. 접힌 글리프 방향을 나타내는 API를 가질 수 있을까요?

chingucoding 에 2020년 09월 26일

애니메이션에 대한 아이디어는 꽤 좋은 것 같습니다. List View와 마찬가지로 on/off가 가능해야 합니다. 헤더와 글리프도 RTL 언어의 측면을 자동으로 전환해야 합니다. 그러나 모든 글리프 사용자 정의는 문제를 과도하게 엔지니어링하는 것으로 보입니다. 사용자 정의 구현이 있는 식별된 모든 경우에 작동하는 스타일을 만드는 것은 불가능합니다. 대신 CheckBox 및 기타 컨트롤과 마찬가지로 기본 디자인이 우리가 할 수 있는 최선이어야 하지만 기본 스타일은 다시 템플릿을 작성할 수 있을 만큼 단순해야 합니다. 나는 왜 모든 사람들이 컨트롤을 다시 템플릿화하는 데 그렇게 부정적인지 잘 모르겠습니다. 그것이 해결책이며 실제로는 컨트롤이 덜 보이는 큰 장점입니다. 더 많은 속성을 추가하면 내가 많이 듣는 유지 관리 부담도 증가합니다.

편집: 가벼운 스타일을 개선하기 위해 몇 가지에 대한 리소스를 정의하는 것도 합리적인 옵션일 수 있습니다.

robloo 에 2020년 09월 26일

TopLeft, TopRight ... 여기에서 올바른 선택인지 확실하지 않습니다. "시작" 및 "끝"과 같은 것이 여기에 더 적합할 수 있습니까?
가로 레이아웃에서 시작은 왼쪽(RTL 언어의 경우 오른쪽)에 있고 세로 열기 모드에서는 위쪽이 됩니다. "끝"은 그에 따라 정의될 수 있습니다. TopLeft에서 볼 수 있는 문제는 ... 이점은 거의 없지만 복잡성이 많이 발생한다는 것입니다(TeachingTip 참조).

@chingucoding NavigationView는 세로 열기 모드를 사용합니다(NavigationViewItem이 세로로 확장되기 때문에), 맞죠? 그러면 헤더의 왼쪽이나 오른쪽에 글리프를 어떻게 설정할 수 있습니까? "시작"이 맨 위에 있고 "끝"이 아마도 헤더의 맨 아래에 있을 것이라고 귀하의 의견을 읽고 있습니다. 그러나 글리프를 왼쪽 상단 모서리 또는 오른쪽 상단 모서리에 배치할 수 있는지 여부를 지정하는 방법이 표시되지 않습니다. 우리가 흔히 볼 수 있는 ExpandGlyphPlacementOffset 와 같은 API를 사용할 필요가 없습니다.

하단 중앙과 같은 것이 많은 공간에서 다소 어색해 보이고 많은 공간을 차지할 것이라고 생각합니다.

나는 웹, 앱 등에서 그 예를 보았을 것이라고 확신합니다. 이것이 제가 그 아이디어를 생각해 낸 이유입니다. 여기에 예제를 게시하여 직접 지원할 가치가 있는지 또는 다시 템플릿에 맡길지 여부를 확인하는 것이 가장 좋습니다.

그러나 모든 글리프 사용자 정의는 문제를 과도하게 엔지니어링하는 것으로 보입니다. 사용자 정의 구현이 있는 식별된 모든 경우에 작동하는 스타일을 만드는 것은 불가능합니다. 대신 CheckBox 및 기타 컨트롤과 마찬가지로 기본 디자인이 우리가 할 수 있는 최선이어야 하지만 기본 스타일은 다시 템플릿을 작성할 수 있을 만큼 단순해야 합니다. 나는 왜 모든 사람들이 컨트롤을 다시 템플릿화하는 데 그렇게 부정적인지 잘 모르겠습니다. 그것이 해결책이며 실제로는 컨트롤이 덜 보이는 큰 장점입니다.

@robloo 재템플릿에 반대하지는 않지만 지금까지 게시된 예제를 보면 일부 개발자는 확장 글리프에 ">"를 사용하고 다른 개발자는 수직으로 확장할 때 확장 글리프에 "v"를 사용합니다. 글리프의 위치와 동일합니다. Expander 컨트롤을 사용하면 개발자가 원하는 대로 글리프를 쉽게 설정할 수 있습니다. 다시 템플릿은 항상 절충점을 수반하며 주로 WinUI의 컨트롤 템플릿에 대한 향후 변경 사항으로 인해 자동으로 이점을 얻지 못할 것입니다. 대신, 그 부담은 이제 개발자가 사용자 정의된 템플릿을 유지 관리해야 합니다.

일반적인 사용자 지정 시나리오를 식별하고 Expander 컨트롤을 통해 가능한 한 액세스할 수 있도록 노력해야 합니다.

예를 들어 다음과 같은 사용자 정의 글리프의 경우( Fluent UI 웹 사이트 에서 찾을 수 있음)를 살펴보겠습니다.
fluent-ui-website-expand

글리프 기호 사용자 정의는 모든 내장 글리프 애니메이션이 신중하게 고려되어야 함을 의미합니다. 또한 흥미롭게도 고객이 더 원하는 것 - 기호에 따라 글리프를 쉽게 사용자 정의하거나 글리프에 대한 내장 애니메이션(NavigationView에서 볼 수 있는 것처럼)을 갖는 기능. 나는 개인적으로 전자가 더 중요할 것이라고 생각하지만 그것을 뒷받침할 하드 데이터가 없습니다.

또 다른 Expander 컨트롤은 Telerik Expander 컨트롤 로 여기에서 논의한 일부 사용자 지정 API(예: 글리오 또는 글리프 기호의 위치를 변경하는 기능)를 노출하며 영감을 얻기 위해 사용할 수도 있습니다.

Felix-Dev 에 2020년 09월 26일

👀1 👍1

ExpandedGlyph
접힌 글리프
개발자가 적절하다고 생각하는 대로 재정의할 수 있는 항목

GlyphPlacement.Start .End .Above .Below
아마도?

너비를 채우는 헤더를 처리하기 위해 콘텐츠 정렬을 사용하거나 Glyph와 텍스트를 함께 묶을 수도 있습니다.

알림 센터의 경우 확장기와 같은 줄에 모두가 명확하게 표시되어 있는데 어떻게 처리할까요? 확장 패널을 확장 헤더에서 분리하는 방법이 있습니까?

mdtauk 에 2020년 09월 26일

👍1

@chingucoding NavigationView는 세로 열기 모드를 사용합니다(NavigationViewItem이 세로로 확장되기 때문에), 맞죠? 그러면 헤더의 왼쪽이나 오른쪽에 글리프를 어떻게 설정할 수 있습니까? "시작"이 맨 위에 있고 "끝"이 아마도 헤더의 맨 아래에 있을 것이라고 귀하의 의견을 읽고 있습니다. 그러나 글리프를 왼쪽 상단 모서리 또는 오른쪽 상단 모서리에 배치할 수 있는지 여부를 지정하는 방법이 표시되지 않습니다. 우리가 일반적으로 보고 있는 것에 ExpandGlyphPlacementOffset과 같은 API를 사용할 필요가 없습니다.

제가 말을 잘못했네요 "수평 열기 모드"는 수평 차원이 고정되어 있으므로 내용이 수평 방식으로 표시된다는 의미입니다. 세로 모드도 마찬가지입니다. 또한 왼쪽 상단과 왼쪽 하단 모서리는 무엇입니까? 나는 아이콘이 중앙에 위치한다고 가정할 것이고, 대부분의 경우 헤더는 확장 영역에서 많은 공간을 차지하지 않아야 하거나 차지하지 않아야 하며 왼쪽 상단과 왼쪽 하단은 거의 동일하게 될 것입니다.

명확하게 하기 위해 확장기가 수직 방향으로 확장되면 start 가 왼쪽(RTL에서 오른쪽)이고 end 가 오른쪽(RTL에서 왼쪽)입니다. 수평 확장에서 start 는 상단이고 end 는 하단입니다. CSS flex-start 및 flex-end와 유사합니다.

Visual Studio는 가운데 아이콘을 사용하지만 확장 단추 영역은 전체 컨트롤을 늘립니다.

닫은:

퍼지는:

GlyphPlacement.Start .End .Above .Below
아마도?

아주 멋진 아이디어 같습니다! 위와 아래는 어떻게 생겼을까요? Visual Studio가 하는 일과 비슷합니까?

ExpandedGlyph
접힌 글리프
개발자가 적절하다고 생각하는 대로 재정의할 수 있는 항목

이것은 이것을 하는 방법이 될 것이지만, 이것은 우리가 아이콘을 움직이는 것을 허용하지 않을 것입니다(예: 회전). 그러나 여기에 애니메이션이 있는 것보다 아이콘을 완전히 전환할 가능성을 우선시하는 것이 더 합리적이라고 생각합니다.

너비를 채우는 헤더를 처리하기 위해 콘텐츠 정렬을 사용하거나 Glyph와 텍스트를 함께 묶을 수도 있습니다.

100%

알림 센터의 경우 확장기와 같은 줄에 모두가 명확하게 표시되어 있는데 어떻게 처리할까요? 확장 패널을 확장 헤더에서 분리하는 방법이 있습니까?

나는 이 특정 시나리오가 확장기 제어로 간단히 달성하기에는 너무 복잡할 수 있다고 우려합니다. 버튼의 배치는 매우 독특하지만 더 중요한 것은 헤더와 확장 아이콘이 같은 줄에 있지 않다는 것입니다. 헤더와 아이콘을 서로 옆에 두는 표준 확장 컨트롤로 하기에는 상당히 어려울 것입니다. 다음은 참조용 예입니다.

chingucoding 에 2020년 09월 26일

👍1

나는 다시 템플릿을 만드는 것에 반대하지 않지만 지금까지 게시된 예제를 보면 일부 개발자는 확장 글리프에 ">"를 사용하고 다른 개발자는 수직으로 확장할 때 확장 글리프에 "v"를 사용합니다. 글리프의 위치와 동일합니다. Expander 컨트롤을 사용하면 개발자가 원하는 대로 글리프를 쉽게 설정할 수 있습니다.

@Felix-Dev 유창한 디자인 시스템에서 표준화해야 하는 것 중 하나입니다. 사용자가 일관된 모양과 느낌을 갖는 것이 중요합니다. 이것이 변경되어야 하는 유일한 경우는 앱이 자체 디자인 언어를 충족하기 위해 이를 수행해야 하거나 우리가 생각하지 못한 새로운 사용 사례가 있는 경우입니다. 이 경우 -- 템플릿을 다시 작성하십시오.

편집: 처음 읽을 때 Telerik 예제를 놓쳤습니다. 여전히 우리가 복잡성을 너무 많이 증가시키고 너무 많은 설계 옵션을 허용한다고 생각합니다. (1) 사용자가 쉽게 인식하지 못합니다 (2) 역사적으로 필요하지 않은 많은 복잡성을 노출합니다. 물론 여기에는 미세한 선이 있습니다. 우리는 사용자가 다시 템플릿을 만들 필요가 없는 충분한 기능을 노출하고 싶지만 디자인 언어가 흐릿해질 정도로 많은 기능을 노출하고 싶지도 않습니다.

WPF 또는 내가 생각할 수 있는 다른 확장 컨트롤은 이를 제어하기 위해 속성을 노출한 적이 없습니다. 실제로 보기의 많은 부분을 차지하며 XAML에서만 지속되어야 합니다. 보기 모델(즉, 이 경우 컨트롤의 DP)은 깨끗하지 않은 컨트롤에서 이러한 스타일 선택에 대해 아무것도 알지 않아야 합니다.

robloo 에 2020년 09월 26일

👍1

WPF 또는 내가 생각할 수 있는 다른 확장 컨트롤은 이를 제어하기 위해 속성을 노출한 적이 없습니다. 실제로 보기의 많은 부분을 차지하며 XAML에서만 지속되어야 합니다. 보기 모델(즉, 이 경우 컨트롤의 DP)은 깨끗하지 않은 컨트롤에서 이러한 스타일 선택에 대해 아무것도 알지 않아야 합니다.

@robloo 글리프 커스터마이징을 노출할 수 있는 한 가지 가능성은 경량 스타일링을 통하는 것입니다. 이러한 리소스는 DP와 마찬가지로 컨트롤의 공개 API 표면의 일부로 간주되어야 하지만 컨트롤 템플릿(컨트롤의 모양)에 훨씬 가깝습니다. 따라서 ExpanderExpandGlyph 및 ExpanderCollapseGlyph (예: NavigationView에는 NavigationViewItemExpandedGlyph 리소스가 있음)와 같은 리소스를 노출할 수 있습니다.

그런 식으로 글리프 기호 사용자 지정을 노출하는 것은 Fluent Design 승인 아이콘을 사용하여 MDL2 글꼴에 있는 글꼴 요소를 제공하기 위한 권장 사항으로 읽을 수도 있습니다. MDL2 글꼴을 보면 웹의 예에서 본 일반적으로 사용되는 확장/축소 글리프 아이콘(다른 갈매기 모양, +/-, +/- 원 등)이 모두 포함된 것 같습니다. 개발자는 여전히 FontFamily( SymbolThemeFontFamily 리소스에서 제공)를 재정의할 수 있지만 ExpanderExpandGlyph ,... 리소스를 컨트롤에 대한 공용 리소스로만 직접 노출하므로 개발자는 잠재적으로 먼저 아이콘을 사용자 정의하려는 경우 MDL2 글꼴 패밀리를 살펴보십시오(글리프용 Expander에서 사용하는 기본 글꼴 패밀리이기 때문에).

관심 있는 사람들을 위해, 주어진 컨텍스트(NumberBox 스핀 버튼 글리프 사용자 정의)에서 고정된 아이콘 세트만 의미가 있을 때 WinUI가 손쉬운 사용자 정의 글리프 옵션을 제공하기 위해 얼마나 멀리 갈 것인지에 대한 아직 해결되지 않은 다른 문제가 하나 이상 있습니다. : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 적어도 여러분 중 일부는 이미 그 문제를 알고 있다는 것을 알고 있습니다. (글리프) 사용자 정의 옵션을 노출하는 방법과 관련하여 여기에서 참조할 가치가 있다고 느꼈습니다. 아마도 여기에서 찾은 솔루션은 WinUI의 일관성을 위해 NumberBox의 경우에도 적용될 수 있습니다.

Felix-Dev 에 2020년 09월 26일

@Felix-Dev 가벼운 스타일링에 대한 당신의 추천이 가장 의미가 있습니다. "편집: 가벼운 스타일을 개선하기 위해 몇 가지에 대한 리소스를 정의하는 것도 합리적인 선택일 수 있습니다."가 의미하는 바입니다. 위의 몇 가지 의견.

robloo 에 2020년 09월 26일

문제는 개발자가 글리프를 제공하지 않고 BitmapIcon 또는 사용자 정의 FontIcon의 일부 형태와 같은 다른 아이콘 형태를 가질 가능성이 얼마나 되는지입니다. 글리프가 아닌 아이콘이 실제로 많은 개발자가 사용하는 사용자 지정 지점이 아닌 경우 @robloo 및 @Felix-가 제안한 것처럼 글리프(심볼 글꼴용)에 사용할 경량 스타일링 리소스가 여기에서 가장 좋은 방법이라고 생각합니다. 개발 .

chingucoding 에 2020년 09월 26일

글리프 또는 사용자 정의 글꼴이 충분하지 않은 경우 다시 템플릿은 항상 옵션입니다.

Segoe MDL2 또는 FluentIcons가 있는 글꼴 글리프가 가장 가능성이 높으며 아마도 기본값일 것입니다.
글리프도 일반적이지 않습니다.
그런 다음 가능성은 적지만 매우 가능한 SVG인 경로가 있습니다.
그런 다음 PNG 또는 전체 비트맵은 가능성이 없지만 개발자에게는 가능한 옵션일 수 있습니다.

어떤 접근 방식을 사용하든 처음 두 시나리오에 초점을 맞춰야 하지만 세 번째 시나리오에서는 항상 다시 템플릿을 허용해야 합니다.

그런 다음 글리프용 ContentPresenter를 사용하고 그 위에 무엇이든 넣을 수 있습니다. 그러나 Collapsed에서 Expanded로 이동하기 위해 VisualStates와 어떻게 작동하는지 잘 모르겠습니다.

아이콘에 애니메이션을 적용하는 경우 - Lottie 컨트롤을 여기에서 사용할 수 있습니까?

또 다른 생각은 RadioButton과 RadioButton이 그룹으로 있는 것처럼 ...

확장기 그룹이 아코디언 컨트롤을 만들어야 합니까? 한 번에 하나의 확장기만 확장할 수 있는 동작을 허용하는 것은 무엇입니까?

https://explore.fast.design/components/fast-accordion

mdtauk 에 2020년 09월 26일

👍2

글리프 또는 사용자 정의 글꼴이 충분하지 않은 경우 다시 템플릿은 항상 옵션입니다.
Segoe MDL2 또는 FluentIcons가 있는 글꼴 글리프가 가장 가능성이 높으며 아마도 기본값일 것입니다.
글리프도 일반적이지 않습니다.
그런 다음 가능성은 적지만 매우 가능한 SVG인 경로가 있습니다.
그런 다음 PNG 또는 전체 비트맵은 가능성이 없지만 개발자에게는 가능한 옵션일 수 있습니다.
어떤 접근 방식을 사용하든 처음 두 시나리오에 초점을 맞춰야 하지만 세 번째 시나리오에서는 항상 다시 템플릿을 허용해야 합니다.

다시 템플릿은 항상 선택 사항이지만 물론 컨트롤에 (주요) 변경 사항이 있는 경우 시간이 지남에 따라 중단될 수 있습니다. 따라서 글리프(및 아이콘 글꼴)를 전환하는 것이 가장 일반적인 시나리오이므로 가벼운 리소스를 사용하는 것이 가장 좋습니다.

그런 다음 글리프용 ContentPresenter를 사용하고 그 위에 무엇이든 넣을 수 있습니다. 그러나 Collapsed에서 Expanded로 이동하기 위해 VisualStates와 어떻게 작동하는지 잘 모르겠습니다.

ContentPresenter를 사용하는 것은 축소/확장과 관련하여 차이가 없으며 다른 것과 같은 요소일 뿐입니다.

아이콘에 애니메이션을 적용하는 경우 - Lottie 컨트롤을 여기에서 사용할 수 있습니까?

문제는 어떤 종류의 애니메이션을 갖고 싶냐는 것입니다. 간단한 회전은 이미 추첨 없이 할 수 있습니다.

또 다른 생각은 RadioButton과 RadioButton이 그룹으로 있는 것처럼 ...
확장기 그룹이 아코디언 컨트롤을 만들어야 합니까? 한 번에 하나의 확장기만 확장할 수 있는 동작을 허용하는 것은 무엇입니까?

어쩌면 그것은 별도의 통제가 될 수 있습니까? 서로 배타적일 수 있는 시나리오가 있지만 많은 경우에 여러 개를 열어도 문제가 되지 않는다고 생각합니다.

chingucoding 에 2020년 09월 26일

그런 다음 글리프용 ContentPresenter를 사용하고 그 위에 무엇이든 넣을 수 있습니다. 그러나 Collapsed에서 Expanded로 이동하기 위해 VisualStates와 어떻게 작동하는지 잘 모르겠습니다.
ContentPresenter를 사용하는 것은 축소/확장과 관련하여 차이가 없으며 다른 것과 같은 요소일 뿐입니다.
그러나 두 상태에서 모두 사용되는 ContentPresenter입니까, 아니면 스왑 아웃/토글되는 상태당 하나씩입니까?

아이콘에 애니메이션을 적용하는 경우 - Lottie 컨트롤을 여기에서 사용할 수 있습니까?
문제는 어떤 종류의 애니메이션을 갖고 싶냐는 것입니다. 간단한 회전은 이미 추첨 없이 할 수 있습니다.
회전은 글리프가 방향 화살표/갈매기형일 때 의미가 있습니다. 하지만 일종의 팁 또는 힌트 시나리오에 대해 전구가 켜지고 꺼지면 어떻게 될까요? Lottie #2802를 사용하여 일반화된 애니메이션 아이콘 제어에 대한 제안이 있습니다. 기본/가장 일반적인 사용이 단순한 아이콘 회전일지라도 이 상황에서 이를 요구합니까?

또 다른 생각은 RadioButton과 RadioButton이 그룹으로 있는 것처럼 ...
확장기 그룹이 아코디언 컨트롤을 만들어야 합니까? 한 번에 하나의 확장기만 확장할 수 있는 동작을 허용하는 것은 무엇입니까?
어쩌면 그것은 별도의 통제가 될 수 있습니까? 서로 배타적일 수 있는 시나리오가 있지만 많은 경우에 여러 개를 열어도 문제가 되지 않는다고 생각합니다.
Fast Design에 아코디언 컨트롤이 포함되어 있고 본질적으로 확장기 무리와 동일하기 때문에 언급한 것뿐입니다. 다만 함께 작동하는 방식을 변경하는 다중 및 단일 동작 API가 있다는 점뿐입니다. Expander 컨트롤이 만들어지면 Accordion은 논리적인 다음 단계가 될 것이며 개별 방향을 재정의하는 방향 속성을 사용하여 비교적 쉽게 달성할 수 있어야 합니다.

mdtauk 에 2020년 09월 26일

그런 다음 글리프용 ContentPresenter를 사용하고 그 위에 무엇이든 넣을 수 있습니다. 그러나 Collapsed에서 Expanded로 이동하기 위해 VisualStates와 어떻게 작동하는지 잘 모르겠습니다.
ContentPresenter를 사용하는 것은 축소/확장과 관련하여 차이가 없으며 다른 것과 같은 요소일 뿐입니다.
그러나 두 상태에서 모두 사용되는 ContentPresenter입니까, 아니면 스왑 아웃/토글되는 상태당 하나씩입니까?

두 옵션 모두 의미가 있습니다. ContentPresenter의 콘텐츠를 전환하는 것이 ContentPresenter를 바꾸거나 두 개를 갖고 하나를 숨기거나 표시하는 것보다 낫다고 생각합니다.

아이콘에 애니메이션을 적용하는 경우 - Lottie 컨트롤을 여기에서 사용할 수 있습니까?
문제는 어떤 종류의 애니메이션을 갖고 싶냐는 것입니다. 간단한 회전은 이미 추첨 없이 할 수 있습니다.
회전은 글리프가 방향 화살표/갈매기형일 때 의미가 있습니다. 하지만 일종의 팁 또는 힌트 시나리오에 대해 전구가 켜지고 꺼지면 어떻게 될까요? Lottie #2802를 사용하여 일반화된 애니메이션 아이콘 제어에 대한 제안이 있습니다. 기본/가장 일반적인 사용이 단순한 아이콘 회전일지라도 이 상황에서 이를 요구합니까?

회전 애니메이션은 애니메이션을 만드는 한 가지 방법이며 쉽게 달성할 수 있습니다. 다른 아이콘으로 움직이는 아이콘을 갖는 것은 상당히 다를 것입니다. 또한 API를 더 복잡하게 만들 수도 있습니다(이러한 동작을 어떻게 지원합니까? 애니메이션 2개와 아이콘 2개? 또는 중지하는 애니메이션 1개?)

또 다른 생각은 RadioButton과 RadioButton이 그룹으로 있는 것처럼 ...
확장기 그룹이 아코디언 컨트롤을 만들어야 합니까? 한 번에 하나의 확장기만 확장할 수 있는 동작을 허용하는 것은 무엇입니까?
어쩌면 그것은 별도의 통제가 될 수 있습니까? 서로 배타적일 수 있는 시나리오가 있지만 많은 경우에 여러 개를 열어도 문제가 되지 않는다고 생각합니다.
Fast Design에 아코디언 컨트롤이 포함되어 있고 본질적으로 확장기 무리와 동일하기 때문에 언급한 것뿐입니다. 다만 함께 작동하는 방식을 변경하는 다중 및 단일 동작 API가 있다는 점뿐입니다. Expander 컨트롤이 만들어지면 Accordion은 논리적인 다음 단계가 될 것이며 개별 방향을 재정의하는 방향 속성을 사용하여 비교적 쉽게 달성할 수 있어야 합니다.

알겠습니다. 예, 아코디언 컨트롤은 익스팬더 컨트롤 이후에 확실히 좋은 아이디어이며 구현하기 쉬울 것입니다!

chingucoding 에 2020년 09월 26일

회전은 글리프가 방향 화살표/갈매기형일 때 의미가 있습니다. 하지만 일종의 팁 또는 힌트 시나리오에 대해 전구가 켜지고 꺼지면 어떻게 될까요? Lottie #2802를 사용하여 일반화된 애니메이션 아이콘 제어에 대한 제안이 있습니다. 기본/가장 일반적인 사용이 단순한 아이콘 회전일지라도 이 상황에서 이를 요구합니까?
회전 애니메이션은 애니메이션을 만드는 한 가지 방법이며 쉽게 달성할 수 있습니다. 다른 아이콘으로 움직이는 아이콘을 갖는 것은 상당히 다를 것입니다. 또한 API를 더 복잡하게 만들 수도 있습니다(이러한 동작을 어떻게 지원합니까? 애니메이션 2개와 아이콘 2개? 또는 중지하는 애니메이션 1개?)

이것은 큰 질문이며 솔직히 말해서 Animated Icon 제안에 대한 것입니다.

항상 화살표인 경우 글리프/아이콘에 애니메이션을 적용하는 것이 좋습니다. 그러나 애니메이션 자체를 제거하거나 변경할 수 있는 쉬운 방법이 없는 한 고정됩니다.

회전하는 Lottie 애니메이션을 만들면 기본 애니메이션이 유지되므로 구현해야 할 작업이 조금 더 많아지지만 필요한 경우 아이콘과 애니메이션을 변경할 수 있어 더 유연합니다.

가장 쉬운 옵션은 글리프에 애니메이션이 없는 것입니다. 그러나 더 많이 추가할수록 재정의하거나 변경하기 쉽게 만드는 것이 더 중요해집니다.

mdtauk 에 2020년 09월 26일

웹을 살펴보면 일반적인 Expander UI 예제에서 확장/축소 글리프에 사용되는 정적 아이콘을 많이 볼 수 있습니다. 그러나 Windows에서는 애니메이션을 선호하는 것으로 보이는 이 컨트롤의 잠재 고객도 있습니다(예: 셸의 NavigationView 및 알림 알림 참조). 모션 은 Fluent Design의 초석 중 하나이므로 컨트롤을 다시 템플릿화할 필요 없이 애니메이션 글리프를 원하는 고객을 위해 옵션을 열어 두는 것이 합리적일 것입니다.

이상적으로는 MS의 여러 팀이 애니메이션 글리프(예: 애니메이션 화살표 글리프)가 있는 Expander를 사용하려는 경우 컨트롤이 내장 옵션을 제공하므로 기본적으로 일관된 경험을 갖게 됩니다. 각 팀이 애니메이션에 대한 책임을 져야 한다면 다른 애니메이션 지속 시간, 다른 애니메이션 방향(예: 시계 방향 또는 시계 반대 방향),...내가 올바르게 기억한다면 알림에 대한 문자 모양의 애니메이션을 보게 될 것입니다. 액션 센터는 NavigationView의 글리프 애니메이션과 다릅니다. 가능하면 피해야 합니다.

Felix-Dev 에 2020년 09월 26일

애니메이션은 더 즐겁고 UI를 매끄럽게 만드는 데 도움이 됩니다. 회전 스토리보드의 하드 코딩은 애니메이션을 추가하는 간단한 방법이지만 해당 애니메이션을 제거하거나 변경하기 어려운 경우 AnimatedIcon 컨트롤을 사용하는 것이 사용자 정의를 가능하게 하는 유연한 방법을 만드는 좋은 방법일 수 있습니다.

한 가지 방법이 다른 방법보다 낫다고 말하는 것이 아닙니다. 아이콘에 애니메이션 효과를 주기 때문에 여기에서 주의를 기울이면 됩니다. 이것이 새 컨트롤의 Raison Detra입니다.

그리고 글리프를 사용자 정의할 수 있어야 한다는 것이 인정된 경우 - 회전 애니메이션이 항상 적절하지 않을 수 있습니다.

mdtauk 에 2020년 09월 26일

무엇을 움직이고 무엇을 움직이지 말아야 하는지는 매우 어려운 질문입니다. Martin이 이미 언급했듯이 회전 애니메이션이 항상 의미가 있는 것은 아닙니다. 그리고 애니메이션 아이콘에는 여전히 많은 미해결 질문이 있습니다.

v1용 글리프/아이콘 애니메이션을 긁는 것이 더 나을 수도 있다고 생각합니다. 특히 일반적이지 않기 때문입니다. 그런 다음 재고해야 할 한 가지는 계층적 NavigationView에서 기존 애니메이션을 제거하여 균일한 경험을 제공하는 것입니다. 현재 TreeView와 h-NavigationView 사이에는 이미 아이콘 전환을 애니메이션화하거나 애니메이션화하지 않는 불일치가 있습니다.

chingucoding 에 2020년 09월 26일

정확히. 마지막 단락에서 여기에서 모든 탐색을 방해하려는 의도는 없었지만 여기서 우리가 직면한 과제 중 하나는 "궁극적인 것" 이외의 충분한 사용자 지정 옵션을 제공하는 것입니다. 그러나 여전히 컨트롤이 Windows에 잠재적으로 덜 일관성을 가져오는 대신 더 많은 일관성을 가져오는 데 도움이 되도록 합니다.

이미 보았듯이 아이콘 사용자 정의와 애니메이션 지원(일관성을 위해 내장된 애니메이션에 추가하여)을 모두 제공하려는 것이 서로 쉽게 충돌할 수 있기 때문에 여기에 완벽한 솔루션이 없을 수도 있습니다.

Windows Shell과 같은 잠재 고객이 여기에서 애니메이션을 보는 방식을 확인하는 것이 도움이 될 수 있습니다. 10X는 애니메이션에 약간의 초점을 맞출 것이며 Windows Shell 및 기본 제공 Windows 앱은 여기에서 "고객"이 될 수 있습니다. 애니메이션 글리프가 Windows 팀이 10X로 노력하고 있는 전체 UX에서 중요한 부분으로 간주되는 경우 지금은 이 도전에 "펀트"하지 않고 대신 V1에서 애니메이션 지원을 제공해야 할 수 있습니다.

Felix-Dev 에 2020년 09월 26일

👍2

저는 아이콘에 애니메이션을 적용하는 일관된 접근 방식을 보고 싶습니다. 현재로서는 Animated Icon 제안으로 보입니다.

나는 NavigationView에서 애니메이션을 제거하지 않을 것입니다. 이는 WinUI에 대한 완전히 자체적으로 포함된 새로운 패러다임이기 때문입니다. 그리고 이러한 모든 유사한 컨트롤에 애니메이션을 추가하려는 의도인 것처럼 보입니다. 따라서 일단 준비가 되면 컨트롤은 NavigationView에 추가됨

mdtauk 에 2020년 09월 26일

👍1

ElementAnimator 는 Expander에 애니메이션을 적용하기에는 너무 많고 ExpandTransition 및 CollapseTransition 이면 충분합니다.

@mdtauk 목업 애니메이션 만들어주셔서 감사합니다! 확장 및 축소 애니메이션에 대해 말씀하신 내용을 이해합니다.

나는 아코디언 동작이 IsExpanded를 사용하여 목록 수준 논리(새로운 Accordion 컨트롤이 아닌)를 통해 달성될 것이라고 생각합니다. 이 논리는 개발자가 이를 다른 시나리오(예: 일부 확장기가 서로 닫히고 다른 확장기가 동시에 확장될 수 있는 경우)에 맞게 사용자 지정할 수 있습니다.

@Felix-Dev - 제안에 Telerik Expander를 추가했습니다. 공유해 주셔서 감사합니다!

다음과 같은 방향으로 커스터마이징이 가능하기를 바라는 것 같습니다.

글리프 모양 : ExpanderExpandGlyph 및 ExpanderCollapseGlyph 하여 글리프와 아이콘 글꼴을 전환하는 데 경량 스타일이 선호되는 것 같습니다. v1 Expander에 이 수준의 사용자 정의가 필요합니까?

@Felix-Dev 개발자는 여전히 FontFamily(SymbolThemeFontFamily 리소스에서 제공)를 재정의할 수 있지만 ExpanderExpandGlyph 만 직접 노출합니다. 따라서 개발자는 잠재적으로 원하는 경우 MDL2 글꼴 패밀리를 먼저 살펴볼 것입니다. 아이콘을 사용자 정의합니다(글리프용 Expander에서 사용하는 기본 글꼴 모음이기 때문에).

글리프 애니메이션 : 확장 시 다른 글리프로의 변경 포함 - AnimatedIcon #2802로 부분적으로 해결되었습니다. 이 수준의 사용자 정의는 v1 Expander에 필요하지 않은 것 같습니다.
@chingucoding이 명시되어 있으며 동의하는 경향이 있습니다.

v1용 글리프/아이콘 애니메이션을 긁는 것이 더 나을 수도 있다고 생각합니다. 특히 일반적이지 않기 때문입니다.

글리프 위치 : v1 Expander에서 이 수준의 사용자 정의가 필요합니까? v1에 ExpandDirection 과 글리프 위치 변경 옵션이 포함된 경우 이는 더욱 복잡합니다. @Felix-Dev 설명

TopLeft, TopRight, BottomCentered(및 더 많은(Left, Right, ...)) 값이 있는 ExpandGlyphPlacementMode와 필요한 경우 개발자가 기본 위치(배치 모드로 설정)를 수정하는 데 사용할 수 있는 추가 ExpandGlyphPlacementOffset 속성이 있습니다.

이번 주말에 있었던 훌륭한 토론을 제대로 이해했길 바랍니다. 제가 잘못 알고 있는 부분이 있으면 알려주세요! 이에 대해 통찰력 있는 생각을 해주셔서 감사합니다. 😄

kat-y 에 2020년 09월 29일

👍1

글리프 모양
글리프 위치

V1에 포함할 수 있는 가장 쉽고 중요한 사용자 정의라고 생각합니다.

나는 또한 글리프를 숨기는 방법을 추가할 것입니다

글리프 애니메이션
상태 전환

우선 순위 지정이 필요하고 핵심 동작 및 기능이 너무 오래 걸리는 경우 우선 순위가 낮을 수 있습니다.

mdtauk 에 2020년 09월 29일

우선순위 @mdtauk에 감사드립니다!

새로운 공개 질문을 추가했습니다.

Expander는 InfoBar와 어떻게 작동해야 합니까? InfoBar에 확장 기능을 추가하시겠습니까? InfoBar를 Expander의 콘텐츠로 사용하시겠습니까? 반전?

kat-y 에 2020년 09월 30일

내용을 대체할 것이라고 생각하지만 정보 표시줄을 디자인하는 사람들은 확장기 디자이너가 볼 수 있는 접을 수 있는 표시줄에 대한 디자인 사양을 제공해야 한다고 생각합니다.

할 대화다.

mdtauk 에 2020년 09월 30일

여기 _많은_ 대화가 있습니다! 애니메이션 주제에...

ElementAnimator가 Expander에 애니메이션을 적용하기에는 너무 많은 것처럼 들리며 ExpandTransition 및 CollapseTransition이면 충분합니다.

ElementAnimator가 Expander에 애니메이션을 적용하기에는 너무 많다는 데 동의합니다. 모든 것이 ItemsRepeater에 있으면 작동할 수 있지만 ElementAnimator는 아직 ItemsRepeater 외부에서 작동하지 않으므로 이를 파악해야 합니다.

나는 이론적으로 ExpandTransition과 CollapseTransition이 있다는 아이디어를 좋아하지만 Transition API가 이론상으로는 좋지만 실제로는 사용자 정의할 수 없기 때문에 실제로 좋지 않다는 피드백을 많이 받았습니다. 일반적으로 컨트롤과 밀접하게 연결되어 있습니다. 사용되며 OS hooks에 의존하기 때문에 WinUI 2.x 시리즈에서 빌드할 수 없다고 생각합니다. 이러한 특정 전환이 존재하지 않기 때문에 ThemeTransition API 컬렉션에 추가하는 것보다 다른 옵션을 살펴보고 싶습니다.

무엇보다도 새로운 UI 요소가 페이지에 들어가고/늘고/줄이거나/떠나면서 콘텐츠가 이동하는 "레이아웃 애니메이션"의 일반적인 영역은 오늘날 플랫폼인 Xaml에서 제대로 지원되지 않습니다. 이 문제를 해결하려면 WinUI 3도 필요하지만 즉각적인 로드맵에는 없습니다.

특히 Expander의 경우 적절한 조치는 다음과 같을 것입니다.
1) Expander 코드에 애니메이션 확대/축소를 하드 코딩합니다(그리고 API를 포함하여 해제하는 것을 고려합니다. 개인적으로 필요하다고 생각하지는 않지만)
2) 확장기 아래의 콘텐츠가 아래로 "뛰어내리는" 것이 아니라 아래로 미끄러지도록 확장기 주변의 콘텐츠에 애니메이션을 적용하는 방법에 대해 앱 개발자에게 지침을 제공합니다.

나는 (2)가 "레이아웃 애니메이션" 없이 일반적으로 해결할 수 있다고 생각하지 않지만 아마도 Expander 아래의 콘텐츠에서 RepositionThemeAnimation을 사용하여 해결할 수 있을 것입니다.

stmoy 에 2020년 09월 30일

👍3

@stmoy 기존 것과 함께 사용하려면 (1)에 PopInThemeAnimation을 사용할 수 있습니다.

ranjeshj 에 2020년 10월 01일

이 제안은 사양 작성을 위해 승인되었습니다.

WinUI 팀과의 논의의 일환으로 우리는 Expander가 V1의 위/아래 확장을 위해 ExpandDirection을 지원하도록 범위를 지정할 수 있다고 결정했습니다. 이것은 Expander에 대해 본 시나리오를 다루고 향후 잠재적으로 왼쪽/오른쪽 확장을 추가할 수 있는 토대를 마련합니다.

여기에서 논의를 계속하는 것이 좋습니다. 사양 및 관련 PR이 제공되면 더 자세한 논의가 있을 것입니다. 특히 이 공개 질문에 대한 귀하의 생각을 듣고 싶습니다.

Expander는 InfoBar와 어떻게 작동해야 합니까? InfoBar에 확장 기능을 추가하시겠습니까? InfoBar를 Expander의 콘텐츠로 사용하시겠습니까? 반전?

kat-y 에 2020년 10월 02일

InfoBar의 경우 구체적으로 무엇이 필요하고 이 Expander 컨트롤을 어떻게 활용할 수 있는지 자세히 알아보기 위해 별도의 제안을 열어야 한다고 생각합니다. 내 첫 번째 생각은 다음과 같습니다.

InfoBar는 Expander 컨트롤의 헤더와 콘텐츠/창을 사용자 지정해야 합니다. InfoBar는 접힐 때 헤더에 "잘라내기" 메시지를 표시해야 하고 열 때 확장된 콘텐츠/창에 전체 메시지를 표시해야 합니다.
InfoBar는 자르기를 허용하지 _have_ 하지 않으며 개발자가 "shouldTruncate" 속성을 통해 필요한 경우 현재 래핑 동작을 선택할 수 있는 옵션이 있어야 합니다.
콘텐츠가 더 이상 한 줄에 맞지 않고 shouldTruncate가 true로 설정된 경우 InfoBar는 Expander가 될 수/있어야 합니다. 이것을 구현하고 확장 동작을 정확히 언제 추가해야 하는지 이해하는 것은 까다로워지는 부분입니다 😊 MessageBar는 isMultiline 속성을 통해 이를 완화하지만 이 영역에 대해 더 많은 생각이 필요합니다.

현재 이 Expander 동작의 이점을 얻을 수 있는 WinUI의 다른 컨트롤도 조사할 수 있다고 생각합니다.

InfoBar를 자르기 위한 몇 가지 초기 구성 요소:
Expand/collapse

구현을 위해 내 초기 생각은 InfoBar가 Expander에서 파생되어야 하고 Expander의 콘텐츠 안에 중첩되어서는 안 된다는 것입니다. 생각?

gabbybilka 에 2020년 10월 02일

현재 이 Expander 동작의 이점을 얻을 수 있는 WinUI의 다른 컨트롤도 조사할 수 있다고 생각합니다.
InfoBar를 자르기 위한 몇 가지 초기 구성 요소:
익스팬더는 확장되는 콘텐츠에서 갈매기 모양 버튼을 분리할 수 있어야 한다고 생각합니다.

알림이 이 작업을 수행합니다.

또한 InformationBar 컨트롤이 Expander를 통합할 수 있도록 합니다.

분리하면 행동/속성이됩니까? 따라서 이 속성에 UI 요소 또는 버튼을 지정하면 확장기 헤더에 해당 버튼이 표시되지 않습니까?

구현을 위해 내 초기 생각은 InfoBar가 Expander에서 파생되어야 하고 Expander의 콘텐츠 안에 중첩되어서는 안 된다는 것입니다. 생각?
Expander가 Toggle/Disclose 버튼에서 콘텐츠와 헤더를 분리할 수 없는 경우 구현하려면 InformationBar에 더 많은 작업이 필요합니다.

Expander 컨트롤은 특히 Windows Shell에서 사용할 수 있을 뿐만 아니라 앞으로 다양한 다른 컨트롤에 통합할 수 있도록 최대한 유연해야 합니다.

mdtauk 에 2020년 10월 02일

👍2

Expander 사양 에 초기 정보를 추가 하고 PR을 열었습니다. 여기에서 사양에 대한 토론을 계속해 주세요! 사양 리포지토리에 있는 PR 100입니다 😄

kat-y 에 2020년 10월 29일

🎉2 👍1

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Microsoft-ui-xaml: 제안: WinUI 컨트롤 세트에 익스팬더 컨트롤 추가.

제안: WinUI 확장기 제어

요약

이론적 해석

범위

중요 참고 사항

제안된 API

다른 곳에서 확장기 컨트롤

확장기 시나리오의 예

열린 질문

가장 유용한 댓글

모든 82 댓글

관련 문제