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ビューア、トースト、およびUWPOnedriveアプリでさまざまなエキスパンダーコントロールが使用されます。現在、この一般的なUXパターンに対処する一貫した「Windows」の方法はありません。 Expanderコントロールは、多くのアプリシナリオでの使用と、WPFとの同等性の実現の両方によって動機付けられています。

理論的根拠

コンテンツを展開および折りたたむための組み込みの一貫したFluent方法が必要です。
エキスパンダーのシナリオは、ナレーターに適したもの、キーボードコントロール、アニメーション、デザイン、高コントラストの変更など、動作やスタイルが調整されていない多くのサーフェスに存在します。

範囲

* v1 Expanderは、下方向にのみ拡張するようにスコープを設定できます。デフォルトは下方向で、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を配置しますか？逆？

feature proposal team-Controls

ソース

ejserna

👍15

最も参考になるコメント

WinUIプロジェクト@ kat-yへようこそ-Xamlには長い歴史がありますが、初めての人には少し風変わりなことがあります。 WinUIは物事がどのように機能するかを再考する機会ですが、この場合、エキスパンダーは比較的単純なコントロールであるため、WPFからWinUIへの単純な移動で十分です。

@roblooXAMLコントロールテンプレートを再設計する必要がないというあなたの主張に同意しません。 WPF AFAIRには、WinUI / Fluentでは適切ではないクロムのような要素がいくつかあります。

シェブロンとタッチのターゲットサイズの処理、およびフォントのスケーリングサイズの使用。シェブロンは、簡単に取り外したり追加したりできる必要があります。

この例には、テキストに沿った山形があります。

この例にはシェブロンがまったくありません

この例には、シェブロンに面する前側があります

実装に関しては、ユーザーがアニメーションをオフにしない限り、開閉時にアニメーション化された遷移が存在する必要があります。その後、状態が切り替わるだけです。

mdtauk 2020年09月25日

👍4 ❤2

全てのコメント82件

Expanderは非常に便利で、追加されてからWindows CommunityToolkitバージョンを使用しています。私の意見では、ツールキットからコードを移植するだけでバージョン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リリース後にコントロールテンプレートに不必要な重大な変更を加えることになるでしょう。

@roblooこれがどのようにいただけますか？私の理解では、V1が下向きに拡張され、V2がExpandDirectionを追加し、デフォルトで下向きになっているため、破損を回避できます。

kat-y 2020年09月25日

それはコントロールの基本的な機能のように見えます
@mdtaukは、下向き以外のExpandDirectionが一般的なアプリシナリオであると思いますか？私が見ているExpanderの動作の例は、はるかに頻繁に下向きに拡張されています-ExpanderにExpandDirectionを持たせたいのですが、v1では必要ですか？

新しいリストコンテンツを下から上にロードするチャットアプリは、おそらくそれらの1つです。

非常に基本的な本質を超えて：

IsCollapsed
IsExpanding
IsExpanded
IsCollapsing

IsEnabledと同様に

次の核となるのは、どこに拡張するかです。

ExpandUp
ExpandDown
ExpandLeft
ExpandRight

mdtauk 2020年09月25日

新しいリストコンテンツを下から上にロードするチャットアプリは、おそらくそれらの1つです。

@mdtaukこのチャットアプリの例の意味が完全にはわかりません。詳しく
プロパティに関しては、提案されたAPIはWPF Expanderに基づいて、 IsExpandedとExpandDirectionがそれらをカバーすると思います。 IsEnabledは何に使用されますか？エキスパンダーを無効にしたいアプリのシナリオはありますか？

kat-y 2020年09月25日

私が過去に使用したもう1つの例は、通常は非表示にする必要がある2番目の編集可能なプロパティです。これらは、「オプション」ボタンをクリックしてエキスパンダーが上向きに開いた場合にのみ、エディターの下部に表示されます。それは本当にあなたが目指しているデザイン次第です。さまざまな方向に拡大するための多くの有用なケースがあり、特に過去の慣習が非常に強い場合、これを人為的に制限する必要はないようです。特に、コミュニティツールキットとWPFですべての問題がすでに解決されているため、コントロールのV1ではこれがそれほど難しくないと思います。

@roblooこれがどのようにいただけますか？私の理解では、V1が下向きに拡張され、V2がExpandDirectionを追加し、デフォルトで下向きになっているため、破損を回避できます。

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は何に使用されますか？エキスパンダーを無効にしたいアプリのシナリオはありますか？

@mdtauk正解です。これは、IsEnabledもサポートする必要があります。コントロールを無効にすることは、入力または状態が変化する可能性があるときはいつでも、かなり強力な規則です。それを弁護させないでください。

robloo 2020年09月25日

👍3

上のスクリーンショットでは、Windowsセキュリティにウイルス対策セクションのエキスパンダーと左側のナビゲーションメニューがあります。これは、多くのアプリがサポートする必要がある複数の方向でのエキスパンダーの非常に現実的な使用法を示しています。私の投票は、V1で複数の方向をサポートすることです。

JustABearOz 2020年09月25日

@robloo

私が過去に使用したもう1つの例は、通常は非表示にする必要がある2番目の編集可能なプロパティです。これらは、「オプション」ボタンをクリックしてエキスパンダーが上向きに開いた場合にのみ、エディターの下部に表示されます。

シナリオをより理解できるように、これが発生するスクリーンショットまたは特定のアプリについて詳しく説明していただけますか？ オプションボタンがより多くのボタンでポップアップを開くエディターを考えることができますが、私が精通しているエディターでは、他のコンテンツは上に押し上げられません-拡張ではなくポップアップ/フライアウトの動作です。

テンプレートと視覚的な状態の設計に細心の注意を払えば、壊れないようにすることが可能だと思います。ただし、そのためには、とにかく機能を設計する必要があるので、実装したほうがよいでしょう。これはすべてかなり基本的なことであり、このコントロールの最初からV2計画を立てる理由はありません。
私は、車輪の再発明をする魅力があることを知っています。ただし、WPFからWinUIにアプリを移植する人々が、絶対に必要なコードの変更以外は何もせずにそれを実行できるように、それを維持してください。

WPFからWinUIへのアプリの移植は可能な限りスムーズに行う必要があることに同意します。 WinUIチームとの話し合いの中で、下向きに拡張するスコープのV1は開発時間を短縮し、開発者がExpanderをより早く利用できるようにすることが提起され（これまでのExpanderのシナリオはすべて下向きであったため）、計画されたV2はExpandDirectionを追加できますもうすぐ。（この追加のコンテキストを持つように未解決の質問を編集します）これが、開発者が非下向きのエキスパンダーに対して持っている特定のユースケースがあるかどうかを理解したいと思っている理由です！ 😄

コントロールを無効にすることは、入力または状態が変化する可能性があるときはいつでも、かなり強力な規則です。それを弁護させないでください。

これを説明してくれてありがとう、状態変化を無効にすることがこの種の制御にとって望ましい機能であることは完全に理にかなっています！

kat-y 2020年09月25日

上のスクリーンショットでは、Windowsセキュリティにウイルス対策セクションのエキスパンダーと左側のナビゲーションメニューがあります。これは、多くのアプリがサポートする必要がある複数の方向でのエキスパンダーの非常に現実的な使用法を示しています。私の投票は、V1で複数の方向をサポートすることです。

@JustABearOz実際、左側のナビゲーションメニューはNavigationViewだと思います。 😃アンチウイルスセクションがエクスパンダーシナリオであり、この場合は下向きに拡張することに同意します。下向きでないエキスパンダーの特定のユースケースを知りたいです！

kat-y 2020年09月25日

@ kat-yわかりました、これで左/右の必要性がなくなりますが、アプリに簡単に適用できる、拡大しているように見えるウィンドウの2つの例：
1：クイックアクションメニューを含む上のスクリーンショット。それが拡大することはかなり確実です。
2：ウィンドウでは、システムトレイのポップアップカレンダーには、議題/予定を表示するために展開するセクションがあります。

ダウンだけでなく、V1のアップ/ダウンをサポートすることは可能ですか？

JustABearOz 2020年09月25日

👍1

1：クイックアクションメニューを含む上のスクリーンショット。それが拡大することはかなり確実です。

@JustABearOzこれらの例を

2：ウィンドウでは、システムトレイのポップアップカレンダーには、議題/予定を表示するために展開するセクションがあります。
ダウンだけでなく、V1のアップ/ダウンをサポートすることは可能ですか？

私はあなたに同意します、これはヘッダーがエリアの下部にあり、拡大するシナリオです！この場合、カレンダーのエクスパンダー（および全体としてのポップアップ）はタスクバーに関連付けられています-エクスパンダーが上向きの拡張を必要とする同様の関連付けられた位置にあるアプリでシナリオに遭遇しましたか？

kat-y 2020年09月25日

😕1 👍1

@ kat-y私は犯罪ではないという意味ですが、15年前に知られていたことを再説明しなければならないような気がします。実世界での使用における拡張方向の例を示すように求められている理由がわかりません。社内では、これを仕様のレビューに持ち込み、経営陣に弁護する必要があると思います。しかし、説明は単純に（1）ユーザーが設計目標を達成できるようにする必要があるということです。何が何であるかを言うのはMicrosoftの責任ではありません。コントロールを使用して行うことはできません。アプリの開発者/設計者は、何が最善かを見つける必要があります。それらのユースケース（ルックレスコントロールの重要な概念）（2）最も重要なことは、これはまったく新しいアイデアではないということです。この領域の既存のAPIをコピーしており、アプリの互換性を維持する必要があります。繰り返しになりますが、これが新しいアイデアである場合、なぜそれを防御しなければならないのかをより理解できます。機能に時間を費やす前に、機能が有用であることを確認することをお勧めします。

ヘッダーとは別に、このコントロールには文字通り2つのプロパティがあり、C＃の場合は、WCTベースを使用して数時間で書き込むことができます。現在WPF / WCTに存在するように実装するよりも、それについて話すだけの方が多くの工数を費やします。

robloo 2020年09月25日

👍3

入力してくれた@roblooに感謝します。ツールキットなどの他のサードパーティライブラリにこれらの提案が存在する場合に、最初にこれらの提案をより堅牢にする方法について、WinUIチームに連絡します。既存の例を呼び出すことは、問題テンプレートの一部であるべきだと私は確信しています。

参考までに@ ranjeshj @ ryandemopoulos @stmoy

michael-hawker 2020年09月25日

@robloo正直に言ってくれてありがとう！アプリ開発者は自分のユースケースに最適なものを判断できる必要があり、アプリの互換性が重要であることを理解しています。 @ michael-hawkerおよびWinUIチームとの話し合いが、Expanderのスコープを生産的に前進させるのに役立つことを願っています。

以前は、下向き以外の方向で使用されているエキスパンダーの具体的な例はありませんでした。 WinUIコミュニティからの例（ @justABearOzが指摘したカレンダーのフライアウトを含む）とMichaelから学んだことを、Expanderのv1でExpandDirectionを維持する証拠としてWinUIチームとの話し合いに持ち込みます。

私が知っているエキスパンダーコントロールのリストで提案を更新しました-何かを逃した場合は知らせてください。

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からのものであるため、ベースにする必要があります。ゼロから始めないでください。 Xamarin Formsは、WPF-> WinUIの概念と一致していないため、おそらく無視する必要があります（追加機能もありません）。サードパーティのソリューションにも、私が見たものからの画期的な新しいアイデアはありません。この制御は、主に時の試練に耐えてきました。

robloo 2020年09月25日

👍1

@robloo正直に言ってくれてありがとう！アプリ開発者は自分のユースケースに最適なものを判断できる必要があり、アプリの互換性が重要であることを理解しています。 @ michael-hawkerおよびWinUIチームとの話し合いが、Expanderのスコープを生産的に前進させるのに役立つことを願っています。

以前は、下向き以外の方向で使用されているエキスパンダーの具体的な例はありませんでした。 WinUIコミュニティからの例（ @JustABearOzが指摘したカレンダーフライアウトを含む）とMichaelから学んだ例を、Expanderのv1でExpandDirectionを維持する証拠としてWinUIチームとの話し合いに持ち込みます。

さて、私のポイントは、これについてあまり多くの議論があるべきではないということです。このコントロールは完璧な例であるため、ここでフラストレーションを表明することにしました。新しいポケットベルコントロールまたはパンくずコントロールは、より多くの監視が必要であり、プロセスに従うことが重要です。ただし、大規模なプロセスのオーバーヘッドが何度も見られますが、WCTからの制御を実装するだけで、付加価値のない事務処理やディスカッションにはるかに多くの工数を費やすことになります。また、WinUIチームが他の以前の作業を使用しているのを見たことがありませんが、これはやや懸念事項です。 XAMLコントロールテンプレートを再設計する必要はありません。

robloo 2020年09月25日

👍1

この例には、テキストに沿った山形があります。

この例にはシェブロンがまったくありません

この例には、シェブロンに面する前側があります

mdtauk 2020年09月25日

👍4 ❤2

実装に関しては、ユーザーがアニメーションをオフにしない限り、開閉時にアニメーション化された遷移が存在する必要があります。その後、状態が切り替わるだけです。

アニメーションについて聞いてみたところです。レイアウトのアニメーション化に費用がかかりすぎるシナリオなど、コントロールに対してそれらを無効にする方法はありますか？すべてのユーザー/開発者が、応答しなくなったり、単に欲しくない（TreeViewなど）と感じるかもしれないようなもののアニメーションを望んでいるわけではありません。そのポイントをカスタマイズするためにコントロールを再テンプレート化する必要がない方が良いかもしれません。カスタマイズ可能なもう1つの点は、アニメーションの長さです。場合によっては、短いアニメーションの方が長いアニメーションよりも優れています。

chingucoding 2020年09月25日

すべての素晴らしい議論に感謝します。いくつかの考え

@mdtaukが言及しているように、テンプレートを更新して、新しい設計と、可能であれば要素を減らしたりパフォーマンスを向上させたりする機会を説明する必要があります。
IsEnabledはControlから継承されているので、機能することを期待しています。

ranjeshj 2020年09月25日

👍3

実装に関しては、ユーザーがアニメーションをオフにしない限り、開閉時にアニメーション化された遷移が存在する必要があります。その後、状態が切り替わるだけです。
アニメーションについて聞いてみたところです。レイアウトのアニメーション化に費用がかかりすぎるシナリオなど、コントロールに対してそれらを無効にする方法はありますか？すべてのユーザー/開発者が、応答しなくなったり、単に欲しくない（TreeViewなど）と感じるかもしれないようなもののアニメーションを望んでいるわけではありません。そのポイントをカスタマイズするためにコントロールを再テンプレート化する必要がない方が良いかもしれません。カスタマイズ可能なもう1つの点は、アニメーションの長さです。場合によっては、短いアニメーションの方が長いアニメーションよりも優れています。

一部のコントロールには、割り当てることができるTransitionプロパティがあると思います。したがって、アニメーション化されていないストーリーボードがリソースとして含まれている場合、それを適用することができ、再テンプレート化することなくそれを処理します。

システム設定でアニメーションがオフになると、トランジションをオーバーライドする必要があります。

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

また、IsEnabledプロパティでは、Disabled状態である必要があります。 DisabledExpandedとDisabledCollapsedがあるべきですか、それともDisabledは常に折りたたまれていますか？

mdtauk 2020年09月25日

アニメーションについての興味深い点。システム設定ですべてのアニメーションをオフにしますが、現在再テンプレート化する以外に、アニメーションをオフにするためのノブを公開しているとは思いません。

ranjeshj 2020年09月25日

👍1

アニメーションについての興味深い点。システム設定ですべてのアニメーションをオフにしますが、現在再テンプレート化する以外に、アニメーションをオフにするためのノブを公開しているとは思いません。

上書きするトランジションコレクションがあると仮定して、アニメーションをオフにしたい場合は、トランジションコレクションをnullで上書きするスタイルを追加できると思います。

stmoy 2020年09月25日

👍1

ExpandTransitionとCollapseTransitionを含み、コントロールのプロパティで設定された方向を使用できます。これにより、開発者はそれぞれの遷移を設定できます。

私はそのアイデアが好きですが、カスタマイズする機能を制限するカスタムテーマトランジションを作成する方法は今日はないと思います。これにより、削除することで簡単に無効にできます。

mdtauk 2020年09月25日

👍1

また、IsEnabledプロパティでは、Disabled状態である必要があります。 DisabledExpandedとDisabledCollapsedがあるべきですか、それともDisabledは常に折りたたまれていますか？

IsExpanded IsEnabledプロパティと

Felix-Dev 2020年09月25日

👍3

@roblooXAMLコントロールテンプレートを再設計する必要がないというあなたの主張に同意しません。 WPF AFAIRには、WinUI / Fluentでは適切ではないクロムのような要素がいくつかあります。

@mdtaukさて、私の推奨事項は、 https ： //docs.microsoft.com/en-us/windows/communitytoolkit/controls/expanderで「WCTの実装に従う必要がある」というものでした。タッチに適応するためのデザイン変更と、よりモダンなインターフェースがすでに作成されています。もちろん、あなたほど良いデザインは誰にもできないので、改善の余地はあると思います。それでも「デザイン」を変更しても、すべての展開方向をサポートするようにテンプレートを再設計する必要はありません。 WCTをベースにする必要があります。新しいスタイリングを適用する場合は、非常にうまくできますが、最初から行うことはできません。

robloo 2020年09月25日

👍1

@roblooXAMLコントロールテンプレートを再設計する必要がないというあなたの主張に同意しません。 WPF AFAIRには、WinUI / Fluentでは適切ではないクロムのような要素がいくつかあります。
@mdtaukさて、私の推奨事項は、ここで「WCTの実装に従う必要がある」ということでした...
WPFバージョンのXAMLからの変更はないと思いました

しかし、私はまだWinUI設計チームがそれとそのバリアントを大丈夫にする必要があると思います-figmaツールキットに含める仕様を確認するためだけなら

mdtauk 2020年09月25日

@ kat-yあなたがプロジェクトに不慣れであるならば、私が厳しく聞こえていたならば、私は謝罪します。私は、確かに必要ないくつかの分野でプロジェクトの速度をどのように改善できるかについて、上記の私のポイントを支持します。また、過去にすでに行われ、過去15年間に徹底的に戦闘テストされたものをどのように使用すべきか。もちろん、これはあなたや誰かに個人的に向けられたものではありません。これは、マイクロソフトで長年見られた一般的な「肥大化」の問題であり、コーディングを増やしたりプロジェクト管理を減らしたりするために、チームをより合理化してバランスを取り直す必要があります。計画と同じくらい良いのは試行錯誤に勝るものはないので、最終的には反復の速度が優先されます。

@ranjeshj @ hawkerコミュニティツールキットですでに行われていることを使用してみませんか？ WinUIチームが新たなアプローチを取っているように見えるのはこれが初めてではありません。それは不必要に作業を複製し、最悪の場合に断片化を引き起こします。 WCTバージョンはすでにWPFのアイデアに基づいており、必要な「最新の」変更を加えています。

robloo 2020年09月25日

❤1

@ranjeshj @ hawkerコミュニティツールキットですでに行われていることを使用してみませんか？ WinUIチームが新たなアプローチを取っているように見えるのはこれが初めてではありません。それは不必要に作業を複製し、最悪の場合に断片化を引き起こします。 WCTバージョンはすでにWPFのアイデアに基づいており、必要な「最新の」変更を加えています。

Community ToolkitはC＃であり、WinUIにはC / C ++コードが必要です。

また、WinUI設計チームはToolkitバージョンでAFAIKを言うことができなかったため、WindowsおよびApp設計チームのニーズは、カスタムソリューションに対してコントロールを採用する場合、特定のニーズを持つ可能性があります。

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およびApp設計チームのニーズは、カスタムソリューションに対してコントロールを採用する場合、特定のニーズを持つ可能性があります。

特定の点については、はい。ただし、一般的な制御機能については、同意しない必要があります。 WCTにより、すでに95％完了し、機能が100％完了します。上に適用される設計変更は簡単です。

robloo 2020年09月25日

👍1

@roblooどの機能が違うのか詳しく

ranjeshj 2020年09月25日

@ranjeshj同じページにいない可能性があります。提案されたAPIがWCTまたはWPFと大幅に異なることを示唆していませんでした。

ExpandDirectionは、このコントロールの最初のバージョンではサポートされていない可能性があるとのことです。これは、この機能の長い歴史を持つエキスパンダーにとっては問題のようです。それから、なぜこの機能が必要なのかを正当化する必要があるように思われました。

WCTをベースとして使用して、拡張方向でこれをすばやく実装することを提案しました。 XAMLテンプレートをコピーして貼り付けるときに、C＃-> C ++のポートのみが必要であるため（この場合、コードビハインドは非常に小さいため）、車輪の再発明を行う必要はありません。これにより、必要なすべての機能が実装され、ExpandDirectionを追加するのに十分な時間がないという懸念が回避されます。このアプローチにより、完全に機能する制御が可能になります。次に、 @ mdtaukまたは他の誰かの提案に基づいて、デザイン/スタイルの変更を行うことができます。（1）ExpandDirectionがV1のチョッピングブロックにある可能性がある理由（2）時間が制限である場合、既存のコードを使用しない理由がわかりません。

はい、WinUI 3開発全般に対する私の欲求不満は、このいくつかの場所に波及しています。そのことをお詫びします。

robloo 2020年09月25日

👍1

@robloo何かが見直して、どれが最優先事項であるかを確認し、新しいコントロールを導入するときに問題を取り除く可能性があると思います。またはコントロールをWinUIに移植します。

V1、次にV2に含めるために不可欠な機能に優先順位を付ける場合、コアおよび必須のプロパティと動作のみが存在し、一般的に使用されないレガシーなものは存在しません。

Microsoftは、古いフレームワークと同等に達するだけでなく、顧客のニーズと要望に基づいて追加する機能を決定しているようです。

つまり、それは_正当化_ではなく、開発者がUIでこれらの制御パターンを実際にどのように処理するかを理解しようとしているだけです。
Windowsシェルだけにいくつかのバージョンのエキスパンダー制御パターンがあるという事実は、それを含める十分な理由です。また、動作が異なっていなくても、各実装が異なって見えるという事実は、設計チームが内部チームのニーズを満たすために制御設計を統合するのに十分な理由です。

mdtauk 2020年09月25日

👍1

@mdtaukいつものようにあなたは良い点を作ります。ただし、これが本当にMicrosoftが採用しているアプローチである場合、私はこの哲学に1つの重要な点で反対しなければなりません。 WinUIを成功させるには、既存のアプリ開発者にとって理にかなっている必要があります。 UWPが離陸したことがないことは誰もが知っているので、私は別のUWPシナリオを回避しようとしています。以前のUWPと同様に、MicrosoftがWinUIに参加するよう説得する必要がある開発者は、WPF開発者です。 WPFアプリがUWPにジャンプしなかった理由の1つは、UWPが、特に最初にリリースされたとき、機能のいくつかの主要な領域で非常に貧弱な同等物であったためです。そのため、ロードマップに丸い角がないのを見て、UWPの悪夢を思い出し始めました（WPFの基本的な丸い角はUWPから最も長く除外されていました）。最優先事項は、WPFとUWPの両方からのスムーズな移植エクスペリエンスを実現することです。正直なところ、WPFの方がはるかに多くのアプリがあり、MicrosoftはWinUIを最初に使用するデスクトップケースに重点を置いているため、おそらくWPFの方が優先度が高いはずです。繰り返しになりますが、車輪の再発明には細心の注意を払い、積極的に回避する必要があります。

また、動作が異なっていなくても、各実装が異なって見えるという事実は、設計チームが内部チームのニーズを満たすために制御設計を統合するのに十分な理由です。

デザインを変更する必要があるかもしれないことを私はいつも理解していました。ルックレスコントロールの概念を使用すると、これはExpandDirectionとは別の問題です。デザインをさらに近代化する必要がある場合、または場合によってはより便利にする必要がある場合は、すばらしいです。比較的簡単なはずです。一日の終わりに、それはまた、細かい制御を必要とする人々のために完全に再テンプレート化されるかもしれません。

robloo 2020年09月25日

👍1

アニメーションについての興味深い点。システム設定ですべてのアニメーションをオフにしますが、現在再テンプレート化する以外に、アニメーションをオフにするためのノブを公開しているとは思いません。

ただし、公平を期すために、アニメーションを使用するコントロールはほとんどありません。 TreeViewとNavigationViewは基本的にエキスパンダーを使用しますが、どちらも展開/折りたたみにアニメーションを使用しません。アニメーションを使用するほとんどのコントロールは、通常、ProgressBarやProgressRingなどのアニメーションに依存しています。ただし、Expanderはそれに依存していません。それは、「持っていてよかった」ということです。もう1つの例は、アニメーションが気に入らなかったためにWCTExpanderコントロールを使用しなかった人がいることです。できるだけ多くの人を含めたい場合は、不要なアニメーションを無効にする簡単な方法があると、それが簡単になります。

上書きするトランジションコレクションがあると仮定して、アニメーションをオフにしたい場合は、トランジションコレクションをnullで上書きするスタイルを追加できると思います。

しかし、これはそれを無効/有効にする一般的な方法でしょうか？ほとんどの場合、複数のスタイルを提供すると、AccentColorButtonStyleやRevealButtonStyleなど、1つのアニメーションよりも大幅に異なります。

ExpandTransitionとCollapseTransitionを含み、コントロールのプロパティで設定された方向を使用できます。これにより、開発者はそれぞれの遷移を設定できます。

私はこのアイデアが本当に好きです！

私はそのアイデアが好きですが、カスタマイズする機能を制限するカスタムテーマトランジションを作成する方法は今日はないと思います。これにより、削除することで簡単に無効にできます。

それも気になります。カスタムテーマトランジションのないExpandTransitionおよびCollapseTransitionAPIを使用すると、これは「ExpendTransitionEnabled」と「CollapseTransitionEnabled」を持っているだけに近いものになります。

chingucoding 2020年09月25日

👍1

@robloo WinUI 3開発に関する不満についてチャットしたい場合は、私に手紙を書いてください（私のTwitterと仕事用の電子メールは私のGitHubプロファイルにあります）。私はあなたの現在の不満を完全には認識していませんが、私は一般的に顧客またはコミュニティの関与/開発に関連するトピックから始めるのに適した人物であり、昨年はかなりの数のフォーカスグループを運営してきましたこれは、ツール、機能の同等性などに関してリストした考慮事項をカバーしています。

私たちのロードマップは非常にタイトなので、あなたが見たい変更を加えることができるとは約束できませんが、あなたをよりよくサポートするために何ができるかを知ることは常に役に立ちますWinUIの顧客および/または寄稿者であるため、最悪の場合の結果は、少なくともあなたのニーズが前進する私たちのチームによって十分に考慮されることです。最良の場合、それはあなたが探しているものに依存すると思います。チャットしよう？ 😄

@mdtauk明確化へのご支援に感謝します-あなたはいつも調子がいいです！私たちのプレートには明らかに多くのことがあり、チームはすべての分野で最も意味のある、影響力のある進歩を実現するために、可能な限り無駄のない効果的な取り組みを行うことを約束します。継続的な進歩の他のすべての領域の中で新しいコントロール/機能に投資し続けるには、@ kat-yのようなチームメンバーが_非常に_鋭い要件仕様を開発する必要があります。事前の開発コストだけでなく、その後の継続的なメンテナンスコストもあるため、実際には広く使用されていないAPI。私はこのスレッドを軽く解析しただけですが、@ kat-yにとって、特に新しいチームメンバーとして、要求された機能を必要とする実際のアプリに実際のシナリオがあることを確認するために完全に鮮明になりたいのは正しいことです（記載されている理由と、開発されたすべての機能がエッジケースカバレッジを提供する本番環境で必要に応じて実行されることを保証できるプレビュー検証パートナーがあることを確認するための両方の理由で）。この願望への準拠は、検証パートナーが非公開の場合など、必ずしも公開されているとは限りません（また、ここに公開するのに適していないニーズがある場合は、@ kat-yに直接連絡してください。現時点では）ですが、これはすべてのWinUI2 +コントロールリリースの前例です。

これがお役に立てば幸いです。このスレッドを@ kat-yと手元のExpanderトピックに戻すことが私の目標ですが、他に回答できるものがある場合、または検討してほしいフィードバックがある場合は、直接連絡してください。このスレッドとWinUIに費やしたすべての作業、情熱、エネルギーに感謝します。 😄

SavoySchuler 2020年09月25日

👍2 ❤1

@mdtaukいつものようにあなたは良い点を作ります。しかし、それが本当にマイクロソフトが採用しているアプローチである場合、私はこの哲学に1つの重要な点で反対しなければなりません。
私はこのアプローチに同意するかどうかについてコメントしていませんでした。ここでの私の時間から、レポがどのように評価されるかを見ているだけで、チームがこれに取り組んでいると私は信じています。

（前述の理由と、エッジケースカバレッジを提供する本番環境で開発されたすべての機能が必要に応じて実行されることを保証できるプレビュー検証パートナーがあることを確認するための両方）。この願望への準拠は、検証パートナーが非公開の場合など、必ずしも公開されているとは限りません（また、ここに公開するのに適していないニーズがある場合は、@ kat-yに直接連絡してください。現時点では）ですが、これはすべてのWinUI2 +コントロールリリースの前例です。
Microsoft独自のアプリを使用すると、例としてShellを使用すると、認識を引き出す可能性が高くなります。これは、存在しなかった、または目的に適さなかったものに対する内部的なニーズがどこにあったかを示しているためです。自分でロールする」-しかしもちろん、Windows用のアプリを構築するNetflixやFacebookなどの大物も-コントロールやその他のビットを要求します。

WinUIは、WPF、MFC、CommonControls、WinFormsなどと同等に到達するだけではありません（ただし、最新の同等のものがない、これらのレガシーコントロールでより一般的に使用されているものは、真剣に検討する必要があります）

ブレッドクラムバーとエキスパンダーが提案されているという事実は、これが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）。ここで、1セットのアニメーションを作成してExpanderとTreeViewコントロールの両方に見栄えを良くすることができると思います。これは、さまざまなコントロール間で一定レベルの一貫性を自動的にもたらします。説得力のある議論でもある、ユーザーに視覚的な親しみやすさを作成します。

Felix-Dev 2020年09月25日

👍2

理想的には、TreeViewと階層型NavigationViewは、コントロールの準備ができたらExpanderコントロールに切り替えるだけでよいと思います。結局のところ、現在、両方のコントロールは、ExpanderControlによって解決されるまったく同じ問題を処理する必要があります。したがって、共有アニメーションはTreeViewに大きな違いはありません。

ElementAnimatorの特徴（私が理解した方法）は、新しいアニメーションを作成する必要があるということです。ただし、Expanderに活用できるアニメーションはすでに組み込まれています。

エキスパンダーとして表示されるパネル内の内容によっては、やり過ぎになる場合があります。しかし、何らかの方法で接続する方法があった場合、要素を含む展開パネルが、開発者が要素に何かを追加した場合に子アニメーションを駆動する可能性があります。

ElementAnimatorの主なポイントの1つは、ItemsRepeaterなどのパネルやコレクションにアニメーションを追加できるようにすることだったと思います。 Expanderの場合、これは実際には当てはまりませんが、Expanderはアイテムのコレクションをレンダリングするパネルではありません。

chingucoding 2020年09月25日

頭のてっぺんから、イージングを使用して親パネルのサイズを変更します。次に、含まれているオブジェクトのスライドとフェードが正しいと感じます。

Fluent Designモーションチームによって適切なイージングが決定された、一般化されたOS全体の移行になるとしたら、それは良いことです。

mdtauk 2020年09月26日

アニメーションについて話しているので、 @ stmoyにタグを付けます。

ranjeshj 2020年09月26日

@SavoySchulerに参加して、チームの取り組みについてより多くのコンテキストを提供していただきありがとうございます。これが、ExpandDirectionの機能が必要なアプリの例を特に探している理由を説明するのに役立つことを願っています。 Savoyの発言を反映するために、Expanderのニーズがここで共有できないものである場合は、直接私に連絡してください（プライバシーが必要な場合はTwitter DM）。

@roblooお詫び申し上げます。私はあなたの意図を完全に理解しており、WinUIコントロールのスコープを設定し、意味のある効率的な方法で開発することを強く望んでいます。私はチームに不慣れで、WinUIコミュニティがExpanderの範囲と実装について議論するのにとてもフレンドリーで熱心であることを本当に感謝しています！

その点で、私はアニメーションに関するこれらの最近のコメントを読むことに興奮しています！

kat-y 2020年09月26日

アニメーション関連のコメントを読んだ後、作業量の多い順に3つの可能なルートがあるように思われます。

セットアニメーションを含まない-これには、シナリオが機能しない、またはセットアニメーションで見栄えが悪い場合に、開発者を思いとどまらせないことを

@mdtaukは、ExpandTransitionとCollapseTransitionを含めること。

これは、コントロールのプロパティで設定された方向を使用できます。これにより、開発者はそれぞれの遷移を設定できます。

ElementAnimatorを使用するよりもスコープが小さいように聞こえます。これにより、開発者はトランジションを設定する際に完全な柔軟性を得ることができますか？

頭のてっぺんから、イージングを使用して親パネルのサイズを変更します。次に、含まれているオブジェクトのスライドとフェードが正しいと感じます。

私はこれの一部を理解していますが、視覚化せずに視覚化するのは難しいです😄。「親パネルのサイズ変更」とは、ヘッダーのサイズが変更されることを意味しますか？「含まれているオブジェクトのスライドとフェード」の意味について詳しく教えてください。

@ Felix-DevはElementAnimatorの使用を提案

StartShowAnimation（）とStartHideAnimation（）を備えたElementAnimator APIは、有望に見えます（「show」は展開に使用され、「hide」は折りたたみに使用されます）。 ElementAnimatorプロパティは、デフォルトのアニメーション実装を使用してコントロールで提供できます。アニメーションが必要ない場合は、プロパティをnullに設定するか、よりきめ細かい制御が必要な場合は、表示または非表示のアニメーションのみをElementAnimatorに提供できます。

@chingucodingは

次に、カスタムElementAnimatorを提供する必要がありますが、それ以外の場合は既存のテーマアニメーションを再利用できます。また、ElementAnimatorは、エキスパンダーコントロールが実際に必要とするよりも多くのメソッドを提供するため、少し扱いにくいように見えます。

ElementAnimatorの主なポイントの1つは、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とHierarchicalNavigationViewは、展開/折りたたみを処理する組み込みのエキスパンダーコントロールを持つことで間違いなく恩恵を受け、その領域でより統一されたエクスペリエンスを実現できるようになります。たとえば、TreeViewは何もアニメーション化しませんが、階層的なNavigationViewはシェブロンの回転をアニメーション化します。

ElementAnimatorは、パネル/コレクションアニメーションを対象としていることを考えると、Expanderアニメーションには行き過ぎですか？

ElementAnimatorをアクティブにサポートするコントロールの1つ（少なくともプレビューでは）は、数十のアイテムをレンダリングする大きなパネルを処理するItemsRepeaterです。一方、Expanderには、このような複雑なシナリオはありませんが、表示/非表示にする単一のアイテムがあります。

私が気付いた別のことは、シェブロンが配置される場所（左/右または上/下）をカスタマイズする方法がないということです。たぶん、これはカスタマイズポイントとして持っていると便利でしょうか？ NavigationViewはシェブロンを右側に配置し、TreeViewはシェブロンを左側に配置します。システム内の既存のエキスパンダーについても同じことが言えます。設定アプリの一部の領域では左側に配置されますが、通知などでは右側に配置されます。

chingucoding 2020年09月26日

私が気付いた別のことは、シェブロンが配置される場所（左/右または上/下）をカスタマイズする方法がないということです。たぶん、これはカスタマイズポイントとして持っていると便利でしょうか？ NavigationViewはシェブロンを右側に配置し、TreeViewはシェブロンを左側に配置します。システム内の既存のエキスパンダーについても同じことが言えます。設定アプリの一部の領域では左側に配置されますが、通知などでは右側に配置されます。

TopLeft、TopRight、BottomCentered（および場合によってはそれ以上（Left、Right、...））などの値を持つExpandGlyphPlacementModeようなものと、開発者が変更するために使用できる追加のExpandGlyphPlacementOffsetプロパティを導入できます。必要に応じて、ベース位置（配置モードで設定）。

それに加えて、 @ 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日

アニメーションのアイデアはかなり良いようです。リストビューなどと同じように、オン/オフを切り替えることができる必要があります。ヘッダーとグリフも、RTL言語のサイドを自動的に切り替える必要があります。ただし、すべてのグリフのカスタマイズは問題を過剰に設計しているようです。カスタム実装があると特定されたすべてのケースで機能するスタイルを作成することは不可能です。代わりに、CheckBoxやその他のコントロールと同様に、デフォルトのデザインが最善の方法である必要がありますが、デフォルトのスタイルは再テンプレート化できるほど単純である必要があります。なぜ誰もがコントロールの再テンプレート化にそれほど不利であるのかわかりません。それが解決策であり、実際には見た目が少ないコントロールの大きな強みです。プロパティを追加することで、私がよく耳にするメンテナンスの負担も増えています。

編集：軽量スタイリングを改善するためにいくつかのリソースを定義することも合理的なオプションかもしれません。

robloo 2020年09月26日

TopLeft、TopRight ...がここで正しい選択であるかどうかはわかりません。たぶん、「開始」や「終了」のようなものがここでより適しているかもしれませんか？
水平レイアウトでは、開始は左側（RTL言語では右側）になり、垂直オープニングモードでは、これが上になります。その場合、「終了」をそれに応じて定義できます。 TopLeftで私が目にする問題は、ほとんどメリットがないために多くの複雑さ（TeachingTipを参照）が発生することです。

@chingucoding NavigationViewは垂直オープニングモードを使用します（NavigationViewItemは垂直方向に展開するため）。次に、ヘッダーの左側または右側にグリフを設定するにはどうすればよいですか？私はあなたのコメントを読んでいます。「開始」が一番上、「終わり」がおそらくヘッダーの一番下になるからです。しかし、グリフを左上隅に配置できるのか、右上隅に配置できるのかを指定する方法がわかりません。よく見られるものにExpandGlyphPlacementOffsetようなAPIを使用する必要はありません。

ボトムセンターのようなものを持っていると、多くのスペースで少しぎこちなく見え、多くのスペースを占めるようになると思います。

私はその例をウェブやアプリなどで見たことがあると確信しています...それが私がそのアイデアを思いついた理由です。例をここに投稿して、それが直接サポートする価値があるかどうか、または再テンプレート化に任せるかどうかを確認するのが最善ですが。

ただし、すべてのグリフのカスタマイズは問題を過剰に設計しているようです。カスタム実装があると特定されたすべてのケースで機能するスタイルを作成することは不可能です。代わりに、CheckBoxやその他のコントロールと同様に、デフォルトのデザインが最善の方法である必要がありますが、デフォルトのスタイルは再テンプレート化できるほど単純である必要があります。なぜ誰もがコントロールの再テンプレート化にそれほど不利であるのかわかりません。それが解決策であり、実際には見た目が少ないコントロールの大きな強みです。

@robloo再テンプレート化することに

一般的なカスタマイズシナリオを特定し、Expanderコントロールから可能な限りアクセスできるようにする必要があります。

たとえば、カスタマイズされたグリフのこのケース（ Fluent UI Webサイトにあります）を考えてみましょう。
fluent-ui-website-expand

グリフシンボルのカスタマイズは、必然的に、組み込みのグリフアニメーションを慎重に検討する必要があることを意味します。また、興味深いことに、顧客がもっと望んでいることは、好みに応じてグリフを簡単にカスタマイズしたり、グリフのアニメーションを組み込んだりする機能です（NavigationViewで見られるように）。個人的には前者の方が重要だと思いますが、それを裏付ける確かなデータはありません。

もう1つのExpanderコントロールはTelerikExpanderコントロールで、ここで説明したカスタマイズAPIの一部（グリオやグリフシンボルの位置を変更する機能など）を公開します。これは、インスピレーションにも使用できます。

Felix-Dev 2020年09月26日

👀1 👍1

ExpandedGlyph
折りたたみグリフ
開発者が適切と考えるようにオーバーライドできるもの

GlyphPlacement.Start .End .Above .Below
多分？

おそらく、コンテンツの配置を使用して、幅を埋めるヘッダーを処理したり、グリフとテキストをまとめたりします。

通知センターの場合、エキスパンダーと同じ行にすべてクリアがありますが、これはどのように処理されますか？拡張パネルを拡張ヘッダーから分離する何らかの方法はありますか？

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
折りたたみグリフ
開発者が適切と考えるようにオーバーライドできるもの

これはこれを行う方法ですが、アイコンをアニメーション化することはできません（回転など）。ただし、ここでアニメーションを作成するよりも、アイコンを完全に切り替える可能性を優先する方が理にかなっていると思います。

おそらく、コンテンツの配置を使用して、幅を埋めるヘッダーを処理したり、グリフとテキストをまとめたりします。

100％

通知センターの場合、エキスパンダーと同じ行にすべてクリアがありますが、これはどのように処理されますか？拡張パネルを拡張ヘッダーから分離する何らかの方法はありますか？

この特定のシナリオは複雑すぎて、エキスパンダーコントロールだけでは実現できないのではないかと心配しています。ボタンの配置は非常にユニークですが、さらに重要なことに、ヘッダーと展開アイコンが同じ行にないため、ヘッダーとアイコンを並べて配置する標準のエキスパンダーコントロールでは非常に困難です。参考例を次に示します。

chingucoding 2020年09月26日

👍1

再テンプレート化することに反対ではありませんが、これまでに投稿された例を見ると、一部の開発者は拡張グリオに「>」を使用し、他の開発者は垂直方向に拡張するときに拡張グリフに「v」を使用します。グリフの位置と同じです。 Expanderコントロールを使用すると、開発者が希望に応じてグリフを簡単に設定できるようになります。

@ Felix-Devこれは、フルーエントデザインシステムで標準化する必要があるものの1つです。ユーザーが一貫したルックアンドフィールを持つことが重要です。これを変更する必要があるのは、アプリが独自のデザイン言語を満たすために変更する必要がある場合、または私たちが考えていなかった新しいユースケースがある場合のみです。その場合-再テンプレートします。

編集：私は最初に読んだときにあなたのTelerikの例を見逃しました。それでも、複雑さが増しすぎて、次のような設計オプションを許可しすぎていると考えてください。（1）ユーザーが簡単に認識できない（2）これまで必要とされていなかった多くの複雑さが明らかになる。もちろん、ここには細い線があります。ユーザーが再テンプレート化する必要がないほど十分な機能を公開したいのですが、デザイン言語が混乱するほど多くの機能を公開したくないのです。

WPF、または私が考えることができる他のエキスパンダーコントロールは、これを制御するためのプロパティを公開したことはありません。これは実際にはビューの大部分を占めており、XAMLでのみ存続する必要があります。ビューモデル（つまり、この場合はコントロールのDP）は、クリーンなルックレスコントロールでのそのようなスタイリングの選択について何も知らないはずです。

robloo 2020年09月26日

👍1

WPF、または私が考えることができる他のエキスパンダーコントロールは、これを制御するためのプロパティを公開したことはありません。これは実際にはビューの大部分を占めており、XAMLでのみ存続する必要があります。ビューモデル（つまり、この場合はコントロールのDP）は、クリーンなルックレスコントロールでのそのようなスタイリングの選択について何も知らないはずです。

@roblooグリフのカスタマイズを公開する1つの可能性は、軽量スタイリングによるものです。これらのリソースは、DPと同様に、コントロールのパブリックAPIサーフェスの一部と見なす必要がありますが、コントロールテンプレート（コントロールの外観）にはるかに近いものです。したがって、 ExpanderExpandGlyphやExpanderCollapseGlyphなどのリソースを公開できます（たとえば、NavigationViewにはNavigationViewItemExpandedGlyphリソースがあります）。

グリフシンボルのカスタマイズをそのように公開することは、MDL2フォントに存在するフォント要素を提供するための推奨事項として読み取ることもできます。したがって、FluentDesignが承認したアイコンを使用します。 MDL2フォントを見ると、Webの例で見た、一般的に使用されているすべての展開/折りたたみグリフアイコン（さまざまなシェブロン、円の+ /-、+ /-など）が特徴のようです。開発者はおそらくFontFamily（ SymbolThemeFontFamilyリソースによって提供される）をオーバーライドできますが、 ExpanderExpandGlyph 、...リソースをコントロールのパブリックリソースとして直接公開するだけなので、開発者は最初にアイコンをカスタマイズする場合は、MDL2フォントファミリを確認してください（これは、Expanderがグリフに使用するデフォルトのフォントファミリであるため）。

興味のある人のために、固定されたアイコンのセットだけが特定のコンテキストで意味をなす場合に、WinUIが簡単なカスタマイズグリフオプションを提供するためにどこまで行きたいかについて、少なくとも1つのまだ解決されていない問題があります（NumberBoxスピンボタングリフのカスタマイズ）： https ：

Felix-Dev 2020年09月26日

@ Felix-Dev軽量スタイリングに関するあなたの推奨は私にとって最も理にかなっています。それは私が「編集：軽量スタイリングを改善するためにいくつかのリソースを定義することも合理的なオプションかもしれない」という意味です。上記のいくつかのコメント。

robloo 2020年09月26日

問題は、開発者がグリフを提供するのではなく、BitmapIconやカスタムFontIconなどの何らかの形の他のアイコンを提供する可能性がどの程度あるかということです。非グリフのアイコンは、本当に多くの開発者が使用するカスタマイズポイントでない場合は、私が使用するグリフのための軽量なスタイリングリソースと思う（多分シンボルフォントのための1）@roblooによって提案され、@ Felix-として、ここでは最高のものです開発。

chingucoding 2020年09月26日

グリフまたはカスタムフォントでは不十分な場合は、常に再テンプレート化を選択できます。

Segoe MDL2またはFluentIconsのいずれかを使用するフォントグリフが最も可能性が高く、おそらくデフォルトである必要があります。
グリフもまったく一般的ではありません。
次に、可能性は低いが非常に可能性の高いパス、SVGがあります。
そして、PNGまたはフルビットマップはありそうもないが、開発者にとっては可能なオプションかもしれない。

どのアプローチを使用する場合でも、おそらく最初の2つのシナリオに焦点を当てる必要がありますが、常に3番目のシナリオの再テンプレート化を許可する必要があります。

次に、グリフにContentPresenterを設定し、その上に何でも配置できるようにする可能性があります。ただし、CollapsedからExpandedに移行するためにVisualStatesでどのように機能するかはわかりません。

アイコンのアニメーションについては、おそらくここでLottieコントロールを使用できますか？

別の考えとして、RadioButtonとRadioButtonをそれらのグループとして持っているのと同じように...

エキスパンダーのグループはアコーディオンコントロールを作成する必要がありますか？一度に1つのエキスパンダーしか展開できない動作を可能にするのはどれですか？

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

mdtauk 2020年09月26日

👍2

グリフまたはカスタムフォントでは不十分な場合は、常に再テンプレート化を選択できます。
Segoe MDL2またはFluentIconsのいずれかを使用するフォントグリフが最も可能性が高く、おそらくデフォルトである必要があります。
グリフもまったく一般的ではありません。
次に、可能性は低いが非常に可能性の高いパス、SVGがあります。
そして、PNGまたはフルビットマップはありそうもないが、開発者にとっては可能なオプションかもしれない。
どのアプローチを使用する場合でも、おそらく最初の2つのシナリオに焦点を当てる必要がありますが、常に3番目のシナリオの再テンプレート化を許可する必要があります。

再テンプレート化は常にオプションですが、もちろん、コントロールに（主要な）変更があった場合、時間の経過とともに破損する可能性があります。したがって、グリフ（およびアイコンフォント）の切り替えが最も一般的なシナリオであるため、ここでは軽量のリソースを使用するのがおそらく最善です。

次に、グリフにContentPresenterを設定し、その上に何でも配置できるようにする可能性があります。ただし、CollapsedからExpandedに移行するためにVisualStatesでどのように機能するかはわかりません。

ContentPresenterを使用しても、折りたたみ/展開に関しては違いはありません。他の要素と同じように要素になります。

アイコンのアニメーションについては、おそらくここでLottieコントロールを使用できますか？

問題は、どのようなアニメーションが必要かということです。単純な回転は、ロッティなしですでに実行できます（そして実行されています）。

別の考えとして、RadioButtonとRadioButtonをそれらのグループとして持っているのと同じように...
エキスパンダーのグループはアコーディオンコントロールを作成する必要がありますか？一度に1つのエキスパンダーしか展開できない動作を可能にするのはどれですか？

多分それは別のコントロールかもしれませんか？それらが互いに排他的である可能性があるシナリオがありますが、多くの場合、複数が開いているかどうかは実際には問題ではないと思います。

chingucoding 2020年09月26日

次に、グリフにContentPresenterを設定し、その上に何でも配置できるようにする可能性があります。ただし、CollapsedからExpandedに移行するためにVisualStatesでどのように機能するかはわかりません。
ContentPresenterを使用しても、折りたたみ/展開に関しては違いはありません。他の要素と同じように要素になります。
しかし、それは両方の状態で使用されるContentPresenterでしょうか、それともスワップアウト/トグルされる状態ごとに1つでしょうか？

アイコンのアニメーションについては、おそらくここでLottieコントロールを使用できますか？
問題は、どのようなアニメーションが必要かということです。単純な回転は、ロッティなしですでに実行できます（そして実行されています）。
グリフが方向矢印/シェブロンの場合、回転は意味がありますが、ある種のヒントやヒントのシナリオで電球がオンまたはオフになった場合はどうなりますか？ Lottie＃2802を使用した一般化されたアニメーションアイコンコントロールの提案があります-デフォルト/最も一般的な使用法が単純なアイコンの回転である場合でも、この状況ではこれが必要ですか？

別の考えとして、RadioButtonとRadioButtonをそれらのグループとして持っているのと同じように...
エキスパンダーのグループはアコーディオンコントロールを作成する必要がありますか？一度に1つのエキスパンダーしか展開できない動作を可能にするのはどれですか？
多分それは別のコントロールかもしれませんか？それらが互いに排他的である可能性があるシナリオがありますが、多くの場合、複数が開いているかどうかは実際には問題ではないと思います。
Fast Designにはアコーディオンコントロールが含まれているため、基本的には一連のエクスパンダーと同じです。ただし、マルチ動作APIとシングル動作APIがあり、それらの連携方法が変更されます。エキスパンダーコントロールを作成すると、アコーディオンは論理的な次のステップになり、個々の方向をオーバーライドする方向プロパティを使用して比較的簡単に実現できるはずです。

mdtauk 2020年09月26日

次に、グリフにContentPresenterを設定し、その上に何でも配置できるようにする可能性があります。ただし、CollapsedからExpandedに移行するためにVisualStatesでどのように機能するかはわかりません。
ContentPresenterを使用しても、折りたたみ/展開に関しては違いはありません。他の要素と同じように要素になります。
しかし、それは両方の状態で使用されるContentPresenterでしょうか、それともスワップアウト/トグルされる状態ごとに1つでしょうか？

どちらのオプションも理にかなっています。 ContentPresenterのコンテンツを切り替える方が、ContentPresenterを交換したり、2つ持って、1つを非表示/表示したりするよりも優れていると思います。

アイコンのアニメーションについては、おそらくここでLottieコントロールを使用できますか？
問題は、どのようなアニメーションが必要かということです。単純な回転は、ロッティなしですでに実行できます（そして実行されています）。
グリフが方向矢印/シェブロンの場合、回転は意味がありますが、ある種のヒントやヒントのシナリオで電球がオンまたはオフになった場合はどうなりますか？ Lottie＃2802を使用した一般化されたアニメーションアイコンコントロールの提案があります-デフォルト/最も一般的な使用法が単純なアイコンの回転である場合でも、この状況ではこれが必要ですか？

回転アニメーションは、アニメーション化する1つの方法であり、簡単に実現できます。別のアイコンにアニメーション化するアイコンがあると、まったく異なります。それはおそらくAPIをより複雑にするでしょう（そのような動作をどのようにサポートしますか？2つのアニメーションと2つのアイコン？または1つのアニメーションを停止しますか？）

別の考えとして、RadioButtonとRadioButtonをそれらのグループとして持っているのと同じように...
エキスパンダーのグループはアコーディオンコントロールを作成する必要がありますか？一度に1つのエキスパンダーしか展開できない動作を可能にするのはどれですか？
多分それは別のコントロールかもしれませんか？それらが互いに排他的である可能性があるシナリオがありますが、多くの場合、複数が開いているかどうかは実際には問題ではないと思います。
Fast Designにはアコーディオンコントロールが含まれているため、基本的には一連のエクスパンダーと同じです。ただし、マルチ動作APIとシングル動作APIがあり、それらの連携方法が変更されます。エキスパンダーコントロールを作成すると、アコーディオンは論理的な次のステップになり、個々の方向をオーバーライドする方向プロパティを使用して比較的簡単に実現できるはずです。

そうですね。はい、アコーディオン制御はエキスパンダー制御の後で間違いなく良い考えであり、おそらく実装するのは簡単でしょう！

chingucoding 2020年09月26日

グリフが方向矢印/シェブロンの場合、回転は意味がありますが、ある種のヒントやヒントのシナリオで電球がオンまたはオフになった場合はどうなりますか？ Lottie＃2802を使用した一般化されたアニメーションアイコンコントロールの提案があります-デフォルト/最も一般的な使用法が単純なアイコンの回転である場合でも、この状況ではこれが必要ですか？
回転アニメーションは、アニメーション化する1つの方法であり、簡単に実現できます。別のアイコンにアニメーション化するアイコンがあると、まったく異なります。それはおそらくAPIをより複雑にするでしょう（そのような動作をどのようにサポートしますか？2つのアニメーションと2つのアイコン？または1つのアニメーションを停止しますか？）

これは大きな質問であり、正直なところ、アニメーションアイコンの提案にとっては何かです。

グリフ/アイコンが常に矢印になる場合は、アニメーション化しても問題ありません。ただし、アニメーション自体を削除または変更する簡単な方法がない限り、それは一種のロックインです。

回転するロッティアニメーションを作成すると、デフォルトのアニメーションが維持され、実装する作業が少し増えますが、必要に応じてアイコンとアニメーションを変更できるようになります。

最も簡単なオプションは、グリフのアニメーションを作成しないことです。ただし、追加するほど、オーバーライドや変更を簡単に行えるようにすることが重要になります。

mdtauk 2020年09月26日

Webを見ると、典型的なExpander UIの例で、展開/折りたたみグリフに使用されている静的アイコンがかなりたくさんあります。ただし、Windowsでは、アニメーションを好むように見えるこのコントロールの潜在的な顧客もいます（たとえば、NavigationViewとシェルのトースト通知を参照してください）。 モーションはフルーエントデザインの基礎の1つであるため、コントロールを再テンプレート化する必要なしに、アニメーション化されたグリフが必要な顧客のためにオプションを開いたままにしておくことはおそらく理にかなっています。

理想的には、MSのさまざまなチームが、アニメーション化されたグリフ（つまりアニメーション化された矢印グリフ）を備えたエキスパンダーを使用したい場合、コントロールは組み込みのオプションを提供するため、デフォルトで一貫したエクスペリエンスが得られます。各チームが自分でアニメーションを担当する場合、アニメーションの長さ、アニメーションの方向（時計回りまたは反時計回り）が異なる可能性があります...正しく思い出せば、通知用のグリフのアニメーションはアクションセンターは、NavigationViewのグリフのアニメーションとは異なります。可能であれば、それは避けるべきです。

Felix-Dev 2020年09月26日

アニメーションは楽しいものであり、UIをスムーズに感じるのに役立ちます。回転ストーリーボードでのハードコーディングは、アニメーションを追加する簡単な方法ですが、そのアニメーションを削除または変更するのが難しい場合は、おそらくAnimatedIconコントロールを使用して、カスタマイズを有効にする柔軟な方法を作成することをお勧めします。

私は、一方の方法がもう一方の方法よりも優れていると言っているのではありません。アイコンをアニメーション化しているので、ここで注意を向けるだけです。これが、新しいコントロールの存在意義です。

また、グリフをカスタマイズ可能にする必要があることが認められている場合、回転アニメーションが常に適切であるとは限りません。

mdtauk 2020年09月26日

何をアニメートし、何をアニメートしないかは非常に難しい質問です。マーティンがすでに述べたように、回転アニメーションは必ずしも意味をなさない。そして、アニメーションアイコンにはまだ多くの未解決の質問があります。

その場合、特にあまり一般的ではないため、v1のグリフ/アイコンアニメーションをスクラッチする方が良いと思います。次に再考する必要があるのは、階層型NavigationViewの既存のアニメーションを削除して、統一されたエクスペリエンスを実現するかどうかです。現在、アイコンの切り替えをアニメーション化する/アニメーション化しないために、TreeViewとh-NavigationViewの間にすでに矛盾があります。

chingucoding 2020年09月26日

丁度。私は最後の段落でここでの探索を思いとどまらせるつもりはありませんでしたが、ここで直面している課題の1つは、一般的な顧客を満足させるために、「究極の」以外に十分なカスタマイズオプションを提供することです。望んでいますが、それでも、コントロールがWindowsの一貫性を低下させるのではなく、向上させるのに役立つことを確認しています。

すでに見てきたように、アイコンのカスタマイズとアニメーションのサポートの両方を提供したい場合（おそらく一貫性のための組み込みのアニメーションに加えて）、互いに簡単に衝突する可能性があるため、ここでは完璧な解決策がない可能性があります。

Windows Shellのような潜在的な顧客をここに参加させて、アニメーションがどのように表示されるかを確認すると役立つ場合があります。 10Xはおそらくアニメーションに焦点を当て、WindowsシェルとインボックスのWindowsアプリはここで「顧客」になる可能性があります。アニメーション化されたグリフが、Windowsチームが10Xで目指しているUX全体の重要な部分と見なされる場合、今のところこの課題に「パント」する必要はなく、代わりにV1でのアニメーションサポートを備えている可能性があります。

Felix-Dev 2020年09月26日

👍2

アイコンをアニメーション化するための一貫したアプローチを望んでいます。これは現在、アニメーションアイコンの提案のようです。

これはWinUIの完全に自己完結型の新しいパラダイムであり、これらすべての同様のコントロールにアニメーションを追加することを意図しているように見えるため、NavigationViewからアニメーションを削除しません。準備ができたら、コントロールは次のようになります。 NavigationViewに追加されました

mdtauk 2020年09月26日

👍1

ElementAnimatorはExpanderをアニメーション化するには多すぎるようで、 ExpandTransitionとCollapseTransition十分です。

@mdtaukモックアップアニメーションを作ってくれてありがとう！アニメーションの拡大と縮小の意味を理解しました。

アコーディオンの動作は、開発者がこれをさまざまなシナリオにカスタマイズできるように、IsExpandedを使用したリストレベルのロジック（新しいアコーディオンコントロールではなく）によって実現されると思います（例：一部のエクスパンダーが互いに閉じ、他のエクスパンダーを同時に拡張できる場合）。

@ Felix-Dev-提案にTelerikExpanderを追加しました。共有していただき、ありがとうございます。

次の方向でカスタマイズ可能性が望まれているようです。

グリフの外観： ExpanderExpandGlyphとExpanderCollapseGlyph使用することで、軽量のスタイリングがグリフとアイコンフォントを切り替えるための推奨ルートのようです。 このレベルのカスタマイズはv1Expanderで必要ですか？

@ Felix-Dev開発者はおそらくFontFamily（SymbolThemeFontFamilyリソースによって提供される）をオーバーライドできますが、 ExpanderExpandGlyph直接公開するだけです...したがって、開発者は、必要に応じて最初にMDL2フォントファミリーを調べる可能性があります。アイコンをカスタマイズします（これは、エキスパンダーがグリフに使用するデフォルトのフォントファミリーであるため）。

グリフアニメーション：拡張時に別のグリフへの変更を含みます-これはAnimatedIcon＃2802で部分的に解決されています。 このレベルのカスタマイズはv1Expanderには必要ないようです。
@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を配置しますか？逆？

kat-y 2020年09月30日

コンテンツに取って代わると思いますが、情報バーを設計する人は、エキスパンダーの設計者が見ることができる折りたたみ可能なバーの設計仕様を提供する必要があると思います。

会話です

mdtauk 2020年09月30日

ここには素晴らしい会話がたくさんあります！アニメーションのトピックについて...

ElementAnimatorはExpanderをアニメーション化するには多すぎるようで、ExpandTransitionとCollapseTransitionで十分です。

ElementAnimatorはExpanderをアニメーション化するには多すぎることに同意します。すべてがItemsRepeaterにある場合は機能する可能性がありますが、ElementAnimatorはItemsRepeaterの外部ではまだ機能しないため、それを理解する必要があります。

理論的にはExpandTransitionとCollapseTransitionを使用するというアイデアが好きですが、Transition APIは理論的には優れていますが、カスタマイズできないため実際にはあまり良くないというフィードバックがたくさん寄せられています。それらはOSフックに依存しているため、WinUI2.xシリーズで構築できるとは思いません。これらの特定のトランジションは存在しないため、ThemeTransitionAPIのコレクションに追加する以外のオプションを検討したいと思います。

それに加えて、新しいUI要素がページに入る/拡大する/縮小する/離れる結果としてコンテンツが移動する「レイアウトアニメーション」の一般的な領域は、今日のプラットフォームとしてのXamlでは十分にサポートされていません。これを修正するにはWinUI3も必要ですが、当面のロードマップには含まれていません。

特にExpanderの場合、適切な行動方針は次のようになる可能性が高いと思います。
1）エキスパンダーコードに拡大/縮小アニメーションをハードコーディングします（そして、APIを含めてオフにすることを検討してください-個人的には必要だとは思いませんが）
2）エキスパンダーの下のコンテンツが「ジャンプ」するのではなく、下にスライドするように、エキスパンダーの周囲のコンテンツをアニメーション化する方法についてアプリ開発者にガイダンスを提供します

（2）は「レイアウトアニメーション」なしでは一般的に解決できるとは思いませんが、エキスパンダーの下のコンテンツでRepositionThemeAnimationを使用して回避できる可能性があります。

stmoy 2020年09月30日

👍3

@stmoy既存のものを使用したい場合は、（1）にPopInThemeAnimationを使用できます。

ranjeshj 2020年10月01日

この提案は仕様書作成のために承認され

WinUIチームとの話し合いの一環として、V1でのアップ/ダウン拡張のためにExpandDirectionをサポートするようにExpanderをスコープできると判断しました。これは、Expanderで見たシナリオをカバーし、将来的に左/右の拡張を追加する可能性のある基礎を築きます。

ここで議論を続けることをお勧めします。仕様と関連するPRが利用可能になり次第、より詳細な議論が行われます。この未解決の質問についてのあなたの考えを特に聞きたいです：

ExpanderはInfoBarとどのように連携する必要がありますか？ InfoBarに拡張機能を追加しますか？エキスパンダーのコンテンツとしてInfoBarを配置しますか？逆？

kat-y 2020年10月02日

InfoBarについては、具体的に何が必要で、このExpanderコントロールをどのように利用できるかを詳しく説明するために、別の提案を開く必要があると思います。これが私の最初の考えのいくつかです：

InfoBarは、Expanderコントロールのヘッダーとコンテンツ/ペインをカスタマイズする必要があります。 InfoBarは、折りたたまれたときにヘッダーに「カットオフ」メッセージを表示し、開いたときに展開されたコンテンツ/ペインに完全なメッセージを表示する必要があります。
InfoBarには切り捨てを許可するオプションがなく、開発者が必要に応じて「shouldTruncate」プロパティを介して現在の折り返し動作を選択できるオプションが必要です。
コンテンツが1行に収まらず、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のコンテンツ内にネストされるべきではないということです。考え？
エキスパンダーがコンテンツとヘッダーを切り替え/開示ボタンから分離できない場合は、InformationBarを実装するためにより多くの作業が必要になります。

Expanderコントロールは、Windowsシェルで使用するだけでなく、今後さまざまな他のコントロールに統合するために、可能な限り柔軟にする必要があります。

mdtauk 2020年10月02日

👍2

Expander仕様に初期情報を追加し、PRを

kat-y 2020年10月29日

🎉2 👍1

このページは役に立ちましたか？

0 / 5 - 0 評価

Microsoft-ui-xaml: 提案：WinUIコントロールのセットにエキスパンダーコントロールを追加します。

提案：WinUIエキスパンダーコントロール

概要

理論的根拠

範囲

重要な注意事項

提案されたAPI

エキスパンダーは他の場所を制御します

エキスパンダーシナリオの例

未解決の質問

最も参考になるコメント

全てのコメント82件

関連する問題