VanArsdelサンプルへのリンクを追加する必要があります

ツールキットのより一般的なコントロールは、常にC ++に移植され、WindowsUIライブラリで利用できるようにする必要があると思います。 タブは、それが成熟して十分に安定しているときを制御します。

それはメインメニューコントロールで起こりました:)

提案でも指摘されているタブティアオフサンプルへのリンク。

提案でも指摘されているタブティアオフサンプルへのリンク。

タブを切り離すと、新しいAppWindow、新しいCoreWindowが生成されますか？また、新しいウィンドウAPIが存在しない場合のフォールバックをどのように処理しますか？

@mdtaukサンプルは現在古いマルチウィンドウApplicationViewAPIを使用しており、ウィンドウはドラッグされた場所ではなくデフォルトの位置で作成されます。 私はAppWindowでテストしており、新しいSDKのサンプルを更新したいと思っています。

「これらの回避策は、プラットフォームのギャップをWPFから埋めるのに役立ちましたが、次のようないくつかの制限があります。」

ここにもキーボードをリストする必要があります。 これは、タブキーやショートカットキーだけではありません。 矢印は、タブコントロールがないときに苦労したことであり、タブコントロールがない場合は全員に一貫性を持たせる必要がありました。

ツールキットで聞いたことからの未解決の質問へのコメント：

1. Tab Tearoffは、コントロールが処理するものにする必要がありますか、それともアプリが処理するものにする必要がありますか？

Tab Controlが、TabView（同じデータ型をホストしている）間のドラッグと再結合を処理し、ドラッグアウトイベントを公開し、検査/インターセプトする機能を備えていることが重要だと思います。

しかし、TabViewがウィンドウのライフサイクルを直接管理することも重要であるかどうかはわかりません。 開発者は、タブをドラッグしたときに何が起こるかをカスタマイズしたい場合もあります。タブを削除したり、そのコンテンツ専用の特別なウィンドウを作成したり、タブ付きの新しい「メイン」ウィンドウを作成したりしますか？ または、複数のウィンドウ用にコーディングする必要があることを処理したくない場合もあります。

イベントを公開し、Windowsの作成/管理を支援するヘルパー（またはWindows Template Studioのような既存のものを活用する）を用意する方が簡単な場合があります。 このシナリオで最も難しい部分は、スレッド間の「データ転送」です。これは、少なくとも新しいウィンドウAPIが軽減に役立つはずです。

1. 「新しいタブを追加」ボタンが組み込まれている必要がありますか？ （コントロールがタブのコレクションを所有していないため、おそらくそうではないと思います。）

適切なヘッダーテンプレートと例がある限り、実装者に「追加」ボタンを追加させるのは簡単だと思います。そのため、パラダイムに別のイベントが必要になるため、組み込みである必要はないと思います。 これは、ツールキットでも最初に考えていたものです。 :)

1. TabItem.IconはIconElementまたはIconElementSourceである必要がありますか？

IconElementを使用して、NavigationViewItemのプロパティを模倣しました。 また、 IconElementSourceはIconElementなので、幅が広いのでIconElementの方が良いのではないでしょうか。 WinUIにIconElementサブクラスがあり、ストレートアップのImageをホストできると便利です（ BitmapIconと似ていますが、強制的なマスキングはありません）。 そうすれば、Iconプロパティは、素敵なVector Symbol / FontIconやico / pngファイル（ブラウザタイプのシナリオファビコンを考えてみてください）など、何でもホストできます。

1. [選択済み]タブがどのように表示されるか（つまり、Edgeで）をアプリでカスタマイズするにはどうすればよいですか？

変更できる公開スタイルのプロパティについて話しているのですか、それとも選択したアイテムの完全に異なるテンプレートのようですか？

1. APIは現在、ツールキットから多くのインスピレーションを得ています。 反復/改善する機会はありますか？

私たちが得たフィードバック項目の1つは、タブの端のスペースのカスタマイズに関するものでした。 たとえば、2つの別々の領域ではなく、左右の水平方向の配置を使用してエッジに物を貼り付けることができる単一のテンプレート領域にする必要がありますか？

その他の質問：

• []コンテンツ領域へのドラッグとヘッダーへのドラッグを処理する方法については、ドラッグで興味深いです。どちらもターゲットですか？ アプリがタブ領域に何か他のもの（エクスプローラーからのファイルなど）をドロップできるようにしたい場合はどうなりますか？
• []「アプリはタブの位置/サイズを決定する可能性があります」はTabStripPlacementプロパティについて話しているのですか？

また、要件9の呼び出しを忘れたため、元々、Edgeモデル（ツールキットコントロールが現在動作しているように）またはドロップダウンシェブロンを作成するNavigationViewモデルを使用するかどうかについて話し合いました。 将来的には両方をサポートすると思いました。

SplitObservableCollection型のオブジェクトが必要なかったため、実装が簡単だったため、最終的にEdgeモデルを使用することになりました。 私はテストとして1つに取り組み始めましたが、それを公開するのに役立つ構成になるのではないかと思います。

@stmoyは、ツールキットの設計から得た未解決の問題/フィードバックを上から締めくくりましたか？

エッジタブモデルを放棄したWindowsセットのニュースは、このコントロールの開発方法にどのように影響しますか？

EdgeとそのUIが廃止され、ChromiumEdge（Edgium）が採用されたため、このコントロールの外観や動作を、それを使用する可能性のあるアプリの種類により適したものにするために再考する必要がありますか？

• プロパティダイアログ;
• MDI（マルチドキュメントインターフェイス）-Photoshopのように;
• ドッキングされたツールパレット（Visual Studio / Blend / Adob​​e CC）;

Pivotや開発中のUWPリボンなどの同様のコントロールは言うまでもありません。 どのユースケースにどちらが推奨され、なぜ誰かがどちらかを選択するのでしょうか？ 混乱を避けたり、パフォーマンスが高く軽いコントロールの代わりに重いコントロールが使用されたりしないように、ガイダンスと例を明確にしてこれらの質問に答える必要があります。

ファーストパーティのコントロールは、一貫した使用で道を切り開くために、適切な目的のために適切なコントロールを使用する必要があります。

＃629に、 @ mdtaukに機能の提案がありました。

たぶん、ToDoリストのアイデアです。 タブの配置？ 下、左、右。

ええ、移行シナリオのWPFパリティと一致するように、ある時点でタブ配置が優先順位リストの上位にある必要があります。 ただし、Toolkitの初期バージョンに追加する時間がなかったものです。

この機能のスコープを設定すると、「プロパティシートタブ」シナリオをサポートし、ブラウザタブシナリオに焦点を当てることは目標ではなくなりました。 プロパティシートとの重複は見られますが、プロパティシートのメタファーは流暢なデザインの一部ではありません。現在、そのシナリオ用のNavigationView（左/上モード）があります。

ナビゲーションビューは重いコントロールであり、画面全体を占有したいと考えています。 また、EdgeのXAMLバージョンと同様に、Setsはロードマップから削除されました。

そのため、TabView / Controlを再考して、将来に向けてより柔軟で便利なものにする余地があるかもしれません。

これらのシナリオは、TabViewコントロールに追加ボタンと閉じるボタンを非表示にする機能がある場合、UWPXAMLアプリで可能になる可能性があります。

ただし、ピボットコントロールもありますが、それは上部のピボットヘッダーのみをサポートし、タブは上、下、左、または右に配置できます...

私たちがサポートしたツールキットでは、閉じるボタンがなく、追加ボタンも実装者が自分で追加する必要がありました。 これが、ドキュメントとクラシックタブの間でこれらの異なるモードを設定するのに役立つTabWidthBehaviorプロパティを持っていた理由です。 私たちがまだサポートしていなかった主なものの1つは、タブの配置でした。

素晴らしい会話をありがとうございました！ 振り返って...

コンテンツ領域へのドラッグとヘッダーへのドラッグを処理する方法については、ドラッグで興味深いです。どちらもターゲットですか？ アプリがタブ領域に何か他のもの（エクスプローラーからのファイルなど）をドロップできるようにしたい場合はどうなりますか？

興味深い質問です。 単純に、TabControlがタブストリップ領域とコンテンツ領域の両方をホストするので、両方とも同じ（大きな）ターゲットになると思います。 ただし、このモデルは、Edgeなどのアプリを検討すると崩壊します（例として）。 Edgeが最大化されていて、ユーザーがタブをタブストリップからドラッグしても、最大サイズであるためにコンテンツの上にある場合、ユーザーはタブが新しい​​ウィンドウを作成することを期待します。

したがって、ドラッグアンドドロップのターゲットはヘッダー領域/タブストリップのみにする必要があると思います。

「アプリはタブの位置/サイズを決定する可能性があります」はTabStripPlacementプロパティについて話しているのですか？

これは、TabStripPlacementではなく、「TabWidthBehavior」プロパティと列挙型を説明するためのものでした。 要件を更新し、タブ配置要件も追加しました（以下でもう少し説明します）。

XAMLバージョンのEdgeと同様に、セットはロードマップから削除されました。

現在、この作業の主な動機は、実際には新しいWindowsターミナルアプリです。 タブコントロールを使用するために他のアプリを拡張/探索し続けますが、私たちの主な焦点は、今のところそれらのシナリオを有効にすることです。

タブの配置は、移行シナリオのWPFパリティと一致するように、ある時点で優先順位リストの上位にある必要があります。 ただし、Toolkitの初期バージョンに追加する時間がなかったものです。

タブの配置は、特にWPFパリティに関連しているため、すばらしいアイデアです。 ただし、上記のとおり、ターミナルのニーズに基づいてスコープを設定しているため、これは「必要」というよりも「可能」になります。 そうは言っても、私はそれを上記の要件表に追加しました。

これらのシナリオは、TabViewコントロールに追加ボタンと閉じるボタンを非表示にする機能がある場合、UWPXAMLアプリで可能になる可能性があります。

TabControlは、タブ自体の閉じるボタンの非表示をサポートしています。 さらに、[追加]ボタンはアプリ自体（コントロールではなく）によって提供されるため、上記のようにコントロールを使用してプロパティスタイルのタブシナリオを作成できると期待しています。

[タブの追加]ボタンがコントロールの一部ではない場合は、ボタンのスタイルとXAMLコマンドをコントロールに含めて、コントロールが使用されている場所でボタンを一貫して実装しやすくすることをお勧めします。

ドラッグシナリオの@stmoyの場合、ヘッダーと領域にドラッグすると、領域が異なる場合や同じになる場合があると思います。 サンプルがティアアウェイのドラッグを示すことができれば良いでしょうが、たとえばメインコンテンツ領域にファイルをドロップし、それをキャッチする方法も示します（これはコントロール自体の範囲外かもしれませんが、便利ですその使用法に）。

ボタンスタイルとXAMLコマンド[新しいタブを追加するため]

@ mdtauk-素晴らしいアイデア。 スペックに追加します。

サンプルがティアアウェイのドラッグを示すことができれば良いでしょうが、たとえばメインコンテンツ領域にファイルをドロップし、それをキャッチする方法も示します

@ michael-hawker-同意しました、サンプルは価値があります。 ただし、ファイルのドラッグインはコンテンツ領域によって処理されるため、タブ固有である必要があるかどうかはわかりません。

みなさん、こんにちは。現在PR用にリリースされているタブの仕様を繰り返していることを簡単に説明したいと思います。 フィードバックがあればPRにコメントを追加してください！

指が交差したので、EdgeよりもChromeのタブのように感じます。

指が交差したので、EdgeよりもChromeのタブのように感じます。

インタラクションデザインが「正しく感じられる」ようにしたいので、出荷前にすぐに入手できるように、プレビューバージョンに対して特定のフィードバックを含む問題を確実に提出してください。

@chigyのような人がすでにTabViewControlのデザインコンプを作成しているかどうかはわかりませんが、私はすぐに試してみました。また、将来的に登場する可能性のあるサイドとボトムの配置オプションについても説明しました。

ボタンを閉じるホバー/押された状態がボタンの前景ではなく背景を変更するのは好きではありません。 背景を変更すると、ボタンが強調されすぎて（タブタイトルから離れて）、後者の方がはるかにエレガントになります。

たとえば、Edge UWPの閉じるボタン（フォアグラウンドの変更のみ）またはEdgeのタブオーディオミュートボタン（Chromium）を参照してください。

前景の変更に固執することを検討しましたが、背景の変更は他のコントロールやタイトルバーの動作と一致すると感じましたが、デフォルトでは前景にすぎない可能性があります。

@ mdtauk-あなたはロックします。 これらのデザインコンプを作成していただきありがとうございます。 コントロールの最初のドロップでサイドプレースメントを行うつもりはありませんが、それがどのように見えるかを確認するのは素晴らしいことです。

@chigyと私は協力して、Windowsの原則（丸みを帯びた角、標準の影など）に沿ったデザインコンプを作成していますが、提供されたデザインコンプは私たちを刺激するのに役立ちます。

ボタンを閉じるホバー/押された状態がボタンの前景ではなく背景を変更するのは好きではありません。 背景を変更すると、ボタンが強調されすぎて（タブタイトルから離れて）、後者の方がはるかにエレガントになります。

私たちの現在の考えは、ここで提案されているように、背景ではなく前景色を変更することです。 これには、検討している角の丸みに少しよくフィットするという追加の利点があります。

[エッジ]タブは、閉じたグリフの背後にある背景を使用しますが、私が提案したものよりも小さいです。ただし、[エッジ]タブはまだタッチモードをサポートしていません。

ツールキットのデザインのサイドタブを考えていたとき、 @ mdtaukが示すように、テキストを回転させて垂直に配置するか、水平に配置して、OneNoteのように左右のマージンを大きくするかで、途方に暮れました。最新の再設計の前で、WPFに似ています（互換性のために重要だと思います）。

したがって、WPFがワイドマージンと水平で行ったように維持することをお勧めしますが、ここに示すように両方をサポートすることも非常に簡単にします。これは、＃546をサポートするもう1つの理由です。

@ michael-hawker右側にタブの垂直リストをマージンを広くして、VisualStudioのように簡単に回転できるようにすることをお勧めします。

前後のタブスポットに影響しますが、月曜日に帰宅したらデザインモックアップを検討します

前後のタブスポットに影響しますが、月曜日に帰宅したらデザインモックアップを検討します

私は家にいます、そしてここにそのデザインがあります：

コントロールのデザインモックアップを改良しました。

_タブオーバーフローとタブサイズ変更を追加_

そのように、タブの概念はEdgeChromiumタブよりもEdgeUWPタブに非常によく似ています。 IMOのタブコントロールの外観は、EdgeUWPのタブコントロールにできるだけ近づける必要があります。 EdgeUWPのようなタブコントロールの背景としてのアクリルも非常に便利です。

それでも、Edge UWPのようにタブを閉じるボタンを作成できることを願っています。このボタンは、現在選択されているタブまたはタブのマウスホバーでのみ表示されます。

WinUIチームの場合： @stmoyどうやら、Windowsターミナルチームはタブコントロールの背景としてアクリルを使用できません（https://github.com/microsoft/terminal/issues/1375を参照）。 ターミナルチームは、これはアーキテクチャ上の制限によるものだと主張しています。 それはWinUIチームが支援できるものですか？ Edge UWPのように、タブコントロールのアクリル背景にはかなりの数のファンがいるようです。

@ Felix-Dev Edgeiumが移行すべき新しいデザインであることは知っていますが、UWP Edgeのデザインは少し優れていると思います。そのため、そのギャップを埋めることを試みたかったのです。

それでも、Edge UWPのようにタブを閉じるボタンを作成できることを願っています。このボタンは、現在選択されているタブまたはタブのマウスホバーでのみ表示されます。

CloseButtonOverlayは、私が思うにそれを行うプロパティです

@mdtauk
明確にするために、閉じるボタンがすべてのタブに常に表示されるのではなく、CloseButtonOverlay = OnHoverがタブコントロールのデフォルトになるようにしたい（タブタイトルimoから不必要にスペースを奪う）。

タッチユーザーには常に表示するのが最適なので、デフォルトは可能な限り包括的である必要があると思います

おそらく、閉じるボタンのオーバーレイモードは、ユーザーのディスプレイの機能に応じて作成できますか？

それがどういうわけか問題になる可能性があるかどうかはわかりません。表示の種類によって、タブコントロールにわずかな視覚的な違いが生じるためです。

おそらく、閉じるボタンのオーバーレイモードは、ユーザーのディスプレイの機能に応じて作成できますか？

それがどういうわけか問題になる可能性があるかどうかはわかりません。表示の種類によっては、タブコントロールにわずかな視覚的な違いが生じるからです。

これは、フライアウトのようなもので機能します。これは、フライアウトをトリガーした入力のタイプを検出でき、タッチ入力によって呼び出された場合に、より大きなタッチターゲットを提供するためです。

一部のタッチデバイスにはマウスも接続されているため、これは常に表示されているコントロールでは機能しません。

もちろん、開発者はデフォルトオプションを変更できます。アプリが、ホバー時にのみ表示するように閉じるボタンを求めるフィードバックをたくさん受け取った場合は、変更することを選択できます。

タブオーバーフローのアイデアを追加しました

これが大好き。

たった一つの小さなこと。 影と丸みを帯びた角がある場合、選択したタブ項目と背景の端の間に少し隙間が必要になることがあります。

これが大好き。

たった一つの小さなこと。 影と丸みを帯びた角がある場合、選択したタブ項目と背景の端の間に少し隙間が必要になることがあります。

なぜそれが必要になるのか不思議です...影はウィンドウフレームによってトリミングされませんか？ 影が上に見えるように、それは単なる美的選択ですか？

タブサイズ

@mdtauk ：私はこれらのデザインを見るのが大好きです！ いくつかの詳細な質問があります：

• 紫はアクセントカラーですか？
• オーバーフローのスクリーンショットの目的は、バンパーを表示することですか？ 写真を正しく読んでいることを確認したいだけです。
• タブの角の半径はいくつですか？
• タブの高さはどれくらいですか？
• どのフォントサイズが使用されましたか？

これらのデザインを使用して、ターミナルで友達と話し、彼らの考えを確認します。 これらのデザインには、現在の方向からのいくつかのデルタが含まれていますが、会話を促進するためにこれらを使用します。

@ Felix-Dev：フィードバックありがとうございます。 以下のいくつかのポイントに対処します。

そのように、タブの概念はEdgeChromiumタブよりもEdgeUWPタブに非常によく似ています。 IMOのタブコントロールの外観は、EdgeUWPのタブコントロールにできるだけ近づける必要があります。 EdgeUWPのようなタブコントロールの背景としてのアクリルも非常に便利です。

さまざまなチーム（ターミナルチームやエッジチームを含む）と積極的に反復して、これらのアプリエクスペリエンス全体でタブを調整しようとしています。 繰り返し（そして＃524のようなアイテムを実装し）続けると、タブコントロールのデザインは更新されたコントロールとより一貫性のあるものになります。

それでも、Edge UWPのようにタブを閉じるボタンを作成できることを願っています。このボタンは、現在選択されているタブまたはタブのマウスホバーでのみ表示されます。

短期的には、ターミナルが必要とするシナリオの実装と、必要に応じてAPIサーフェスのトリミングに重点を置いています。 v1では、Persistentのみをサポートします。 とは言うものの、私はもともとホバー動作も指定しました。それは素晴らしいアイデアだと思うからです。 コントロールの次の回転で再評価できるように、これらの種類の質問（x-on-hover、タブの配置など）を追跡しています。

WinUIチームの場合： @stmoyどうやら、Windowsターミナルチームはタブコントロールの背景としてアクリルを使用できません（microsoft / terminal＃1375を参照）。 ターミナルチームは、これはアーキテクチャ上の制限によるものだと主張しています。 それはWinUIチームが支援できるものですか？ Edge UWPのように、タブコントロールのアクリル背景にはかなりの数のファンがいるようです。

私たちはターミナルチームと積極的に協力しています。 残念ながら、このシナリオは、タブではなくXamlアイランドでの既知の制限の結果です。 アプリがTabControl.Backgroundをアクリルブラシに設定している場合、非終端記号アプリは「オプトイン」機能としてアクリル背景を使用できるはずです。

紫はアクセントカラーですか？

はい-自分のデザインを公式のデザインコンプと混同したくありませんでした

オーバーフローのスクリーンショットの目的は、バンパーを表示することですか？ 写真を正しく読んでいることを確認したいだけです。

はい、左右のボタンがどのように見えるか、タブがどのようにクリップされるかを示しています。

タブの角の半径はいくつですか？

4 epx-ガイダンスが2epxであることは知っていますが、選択したインジケーターの4epxの高さは4でより良く見えました

タブの高さはどれくらいですか？

40 epx

どのフォントサイズが使用されましたか？

タブタイトルテキストの場合は14、MDL2アイコンの場合は16

Edge Canaryには、新しいタブ読み込みアニメーションと呼ばれるフラグがあります-edge ：// flags＃new -tab-loading-animation

仕様の一部には、次のようなテーマや暗黙のアニメーションを含める必要があります。

• TabAddAnimation
• TabRemoveAnimation
• TabSwitchToAnimation
• TabSwitchFromAnimation
• TabSelectedSwitchToAnimation
• TabSelectedSwitchFromAnimation
• TabDragOutAnimation
• TabPlacedAnimation

@stmoy

私たちはターミナルチームと積極的に協力しています。 残念ながら、このシナリオは、タブではなくXamlアイランドでの既知の制限の結果です。

Xaml Islandの将来のバージョンでこの制限に対処することは可能ですか？ たとえば、Windowsターミナルアプリでは、背景のアクリルに対する強い欲求があるようです。 https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390、特にその投稿の最後の画像（タイトルバーに背景のアクリルが表示されている）を参照してください。 また、投稿が得た多くの賛成票にも注意してください😉。 ここに多くの賛成票がある別の投稿： https ：//github.com/microsoft/terminal/issues/1375#issuecomment -504644293

タブUIの設計についてより広義に話すと、EdgeUWPタブがEdgeChromiumタブの外観よりも優先されるユーザーコメントに対する支持的な反応にも注意してください： https ：//github.com/microsoft/terminal/issues/1375#issuecomment-504622788およびそのすぐ下に投稿してください。

Edge Chromiumタブが（最新の）Windowsタブの将来の外観を表すことを意図している場合、これらの圧倒的なユーザーの反応は、EdgeChromiumとWinUIの両方で使用されるタブの外観を再考する理由になる可能性があります。 （また、ここに@chigyを追加して、WindowsターミナルリポジトリでこれらのタブUIの反応に気付くようにします。）

編集：また、Windowsターミナルチームがこの問題を「修正できない」ことを再確認したため、このトピックに@ marb2000の注意を呼びかけました。 WinUIチームは、Windowsターミナルでアクリルタイトルバー（強く要求されています！）が発生する可能性をどのように見ていますか？ @stmoy

@ marb2000 @ stmoy以下の質問にコメントしてください。

また、Windowsターミナルチームがこの問題を「修正できない」ことを再確認したため、 @ marb2000の注意をこのトピックに呼びかけました[（ターミナルのアクリルタイトルバー）]。 WinUIチームは、Windowsターミナルでアクリルタイトルバー（強く要求されています！）が発生する可能性をどのように見ていますか？

@ marb2000 @SavoySchuler @jesbis @jevansaks

最近のコミュニティコールから皆さんにpingを送信しました😁
Xaml諸島（Windowsターミナル）での技術的なアクリルタイトルバーのサポートについては、上記の私の投稿を参照してください。 @ stmoyによってすでに部分的に回答されています。

これが私の投稿と上記の返信から得られた3つの主要なポイントです：

WinUIチームの場合：Windowsターミナルチームは、タブコントロールの背景としてアクリルを使用できないようです（microsoft / terminal＃1375を参照）。 ターミナルチームは、これはアーキテクチャ上の制限によるものだと主張しています。 それはWinUIチームが支援できるものですか？ Edge UWPのように、タブコントロールのアクリル背景にはかなりの数のファンがいるようです。

@stmoyによる返信：

私たちはターミナルチームと積極的に協力しています。 残念ながら、このシナリオは、タブではなくXamlアイランドでの既知の制限の結果です。 アプリがTabControl.Backgroundをアクリルブラシに設定している場合、非終端記号アプリは「オプトイン」機能としてアクリル背景を使用できるはずです。

私の質問：

また、Windowsターミナルチームがこの問題を「修正できない」ことを再確認したため、 @ marb2000の注意をこのトピックに呼びかけました[（ターミナルのアクリルタイトルバー）]。 WinUIチームは、Windowsターミナルでアクリルタイトルバー（強く要求されています！）が発生する可能性をどのように見ていますか？

答えてくれてありがとう😁