Sollte einen Link zum Van Arsdel-Beispiel hinzufügen

Ich denke, die allgemeineren Steuerelemente aus dem Toolkit sollten immer nach C++ portiert und in der Windows-UI-Bibliothek verfügbar sein. Tabs Control, wenn es ausgereift und stabil genug ist, sollte sich ebenfalls durchsetzen.

Es ist mit der Hauptmenüsteuerung passiert :)

Link zum Tab Tear-Off-Muster , das ebenfalls im Angebot genannt wird.

Link zum Tab Tear-Off-Muster , das ebenfalls im Angebot genannt wird.

Erzeugt das Abreißen eines Tabs ein neues AppWindow, ein neues CoreWindow, und wie gehen Sie mit dem Fallback um, wenn die neuen Fenster-APIs nicht vorhanden sind?

@mdtauk Das Beispiel verwendet derzeit die ältere ApplicationView-API für mehrere Fenster. Das Fenster wird in einer Standardposition erstellt, anstatt dorthin gezogen zu werden. Ich habe mit AppWindow getestet und hoffe, das Beispiel für das neue SDK aktualisieren zu können.

„Obwohl diese Problemumgehungen dazu beigetragen haben, die Plattformlücke von WPF zu schließen, weisen sie eine Reihe von Einschränkungen auf, darunter:“

Sie sollten hier auch die Tastatur auflisten. Dies ist nicht nur die Tabulatortaste oder die Tastenkombination. Arrowing war etwas, mit dem wir zu kämpfen hatten, als wir keine Tab-Kontrolle hatten und wir alle dazu bringen mussten, konsequent zu sein, wenn es keine gab.

Kommentare zu offenen Fragen aus dem, was wir im Toolkit gehört haben:

1. Sollte Tab Tearoff etwas sein, das das Steuerelement oder die App verarbeitet?

Ich denke, es ist wichtig, dass das Tab-Steuerelement das Ziehen und erneute Kombinieren zwischen TabViews (die denselben Datentyp hosten) und das Aufdecken eines Drag-out-Ereignisses mit der Fähigkeit zum Untersuchen/Abfangen handhaben.

Aber ich weiß nicht, ob es wichtig ist, dass TabView auch den Fensterlebenszyklus direkt verwaltet, da dies schwieriger wird. Ein Entwickler möchte möglicherweise auch anpassen, was passiert, wenn ein Tab herausgezogen wird, vielleicht wird er einfach entfernt oder ein spezielles Fenster nur für diesen Inhalt erstellt im Gegensatz zu einem neuen „Hauptfenster“ mit Tabs? Oder sie möchten vielleicht nicht damit umgehen, für mehrere Fenster codieren zu müssen.

Es kann einfacher sein, das Ereignis verfügbar zu machen und Helfer zu haben (oder vorhandene wie die in Windows Template Studio zu nutzen), um bei der Erstellung/Verwaltung von Windows zu helfen. Der schwierigste Teil dieses Szenarios ist die „Datenübertragung“ zwischen Threads, die zumindest durch die neue Windowing-API erleichtert werden sollte.

1. Sollte es eine eingebaute Schaltfläche "Neuen Tab hinzufügen" geben? (Ich vermute wahrscheinlich nicht, weil das Steuerelement die Sammlung von Registerkarten nicht besitzt.)

Ich denke, solange es angemessene Header-Vorlagen und Beispiele gibt, ist es trivial, einen Implementierer eine „Hinzufügen“-Schaltfläche hinzufügen zu lassen, also denke ich nicht, dass es eingebaut werden muss, da das Paradigma dann ein anderes Ereignis benötigen würde. Daran hatten wir ursprünglich auch im Toolkit gedacht. :)

1. Sollte TabItem.Icon IconElement oder IconElementSource sein?

Wir haben IconElement verwendet, um die Eigenschaft von NavigationViewItem nachzuahmen. Außerdem ist IconElementSource ein IconElement , also ist IconElement nicht besser, da es breiter ist? Es wäre schön, wenn es eine IconElement -Unterklasse in WinUI gäbe, die nur ein einfaches Image hosten könnte (ähnlich wie BitmapIcon , aber ohne die erzwungene Maskierung). Auf diese Weise könnte die Icon-Eigenschaft alles hosten, sei es ein nettes Vektorsymbol/Font-Icon oder eine ico/png-Datei (denken Sie an Browsertyp-Szenario-Favicon).

1. Wie kann eine App anpassen, wie die Registerkarte „Ausgewählt“ aussieht (z. B. in Edge)?

Sprechen Sie von exponierten Stileigenschaften, die geändert werden können, oder möchten Sie eine völlig andere Vorlage für das ausgewählte Element?

1. Die API lässt sich derzeit stark vom Toolkit inspirieren. Gibt es Möglichkeiten zur Iteration/Verbesserung?

Ein Feedback-Element, das wir erhalten haben, betraf die Anpassung des Leerzeichens am Ende der Registerkarten. Soll es zB nur ein einzelner Vorlagenbereich sein, der dann die horizontale Links-/Rechtsausrichtung verwenden kann, um Dinge an den Rändern festzuhalten, anstatt zwei separate Bereiche?

Andere Fragen:

• [ ] Es ist interessant, wie man mit dem Ziehen in den Inhaltsbereich im Vergleich zum Header umgeht, sind beides Ziele? Was ist, wenn die App das Ablegen von etwas anderem im Registerkartenbereich zulassen möchte (z. B. eine Datei aus dem Explorer)?
• [ ] Spricht "Die App entscheidet möglicherweise über die Position/Größe der Tabs" von der Eigenschaft " TabStripPlacement "?

Wir haben auch vergessen, Anforderung 9 anzufordern, wir hatten ursprünglich eine Diskussion darüber, ob das Edge-Modell (wie sich das Toolkit-Steuerelement derzeit verhält) oder das NavigationView-Modell verwendet werden soll, wo es einen Dropdown-Chevron erstellt. Wir dachten, vielleicht würden wir in Zukunft beide unterstützen.

Wir haben uns schließlich für das Edge-Modell entschieden, da es einfacher zu implementieren war, da wir dann kein Objekt vom Typ SplitObservableCollection benötigten. Ich hatte als Test damit begonnen, an einem zu arbeiten, aber ich frage mich, ob es ein nützliches Konstrukt wäre, es aufzudecken?

@stmoy hast du die offenen Probleme/Feedbacks von oben, die wir von den Toolkit-Designs hatten, abgeschlossen?

Wie wirkt sich die Nachricht, dass Windows Sets das Edge-Tab-Modell aufgibt, auf die Entwicklung dieses Steuerelements aus?

Da Edge und seine Benutzeroberfläche jetzt zugunsten von ChromiumEdge (Edgium) so gut wie aufgegeben wurden, müssen/wollen wir das Erscheinungsbild oder Verhalten dieser Steuerung überdenken, damit sie besser für die Arten von Apps geeignet ist, die sie möglicherweise verwenden?

• Eigenschaftsdialoge;
• MDI (Multiple Document Interfaces) – wie Photoshop;
• Angedockte Werkzeugpaletten (Visual Studio/Blend/Adobe CC);

Ganz zu schweigen von ähnlichen Steuerelementen wie Pivot und der UWP-Multifunktionsleiste in der Entwicklung. Welche wird für welchen Anwendungsfall empfohlen und warum sollte jemand eine der anderen vorziehen? Anleitungen und Beispiele sollten klar sein, um diese Fragen zu beantworten, um Verwirrung zu vermeiden oder eine stärkere Steuerung anstelle einer leistungsfähigen und leichteren zu verwenden.

Erstanbieterkontrollen sollten die richtige Kontrolle für den richtigen Zweck verwenden, um zu versuchen, bei der konsistenten Verwendung den Weg zu weisen.

Auf #629 hatte @mdtauk einen Funktionsvorschlag:

Vielleicht eine Idee für die ToDo-Liste. Tab-Platzierung? Unten, links, rechts.

Ja, Tab Placement sollte irgendwann oben in der Prioritätenliste stehen, um der WPF-Parität für Migrationsszenarien zu entsprechen. Wir hatten jedoch auch keine Zeit, dies in der ursprünglichen Toolkit-Version hinzuzufügen.

Als wir dieses Feature ausweiteten, war es kein Ziel, das Szenario „Eigenschaftenblatt-Registerkarten“ zu unterstützen und sich auf das Szenario mit Browser-Registerkarten zu konzentrieren. Wir sehen einige Überschneidungen mit Eigenschaftsblättern, aber die Eigenschaftsblatt-Metapher ist nicht Teil des fließenden Designs, wir haben für dieses Szenario derzeit NavigationView (mit Links/Oben-Modi).

Die Navigationsansicht ist ein schweres Steuerelement und möchte den gesamten Bildschirm einnehmen. Auch Sets ist von der Roadmap verschwunden, ebenso wie die XAML-Version von Edge.

Es besteht also die Möglichkeit, TabView/Control zu überdenken, um es flexibler und nützlicher für die Zukunft zu machen.

Diese Szenarien könnten in UWP-XAML-Apps möglich sein, wenn das TabView-Steuerelement in der Lage wäre, die Schaltflächen „Hinzufügen“ und „Schließen“ auszublenden.

Aber es gibt auch Pivot-Steuerelemente, aber es unterstützt nur Pivot-Header oben, und Tabs können oben, unten, links oder rechts sein ...

In dem von uns unterstützten Toolkit, das keine Schließen-Schaltfläche hatte, war die Hinzufügen-Schaltfläche auch etwas, das der Implementierer selbst hinzufügen musste. Aus diesem Grund hatten wir die Eigenschaft TabWidthBehavior , um diese unterschiedlichen Modi zwischen Dokumenten und klassischen Registerkarten einzurichten. Eines der wichtigsten Dinge, die wir noch nicht unterstützt haben, war die Tab-Positionierung.

Danke für all die tollen Gespräche! Zurück im Kreis ...

Es ist interessant, wie man mit dem Ziehen in den Inhaltsbereich im Vergleich zum Header umgeht. Sind beides Ziele? Was ist, wenn die App das Ablegen von etwas anderem im Registerkartenbereich zulassen möchte (z. B. eine Datei aus dem Explorer)?

Interessante Frage. Naiverweise würde ich denken, dass sie beide dasselbe (große) Ziel wären, da das TabControl sowohl den Tab-Strip-Bereich als auch den Inhaltsbereich hostet. Dieses Modell fällt jedoch auseinander, wenn man Apps wie Edge (als Beispiel) betrachtet. Wenn Edge maximiert wurde und der Benutzer einen Tab aus der Tableiste zieht, aber immer noch über den Inhalt, weil er die maximale Größe hat, erwartet der Benutzer, dass der Tab ein neues Fenster erstellt.

Daher denke ich, dass wir nur den Header-Bereich/Tabstrip als Drag/Drop-Ziel haben sollten.

Spricht "Die App kann entscheiden, wie Position/Größe der Tabs ist" über die Eigenschaft TabStripPlacement?

Dies sollte die Eigenschaft „TabWidthBehavior“ und die Aufzählung und nicht TabStripPlacement beschreiben. Ich habe die Anforderung aktualisiert und auch eine Anforderung für die Platzierung von Tabs hinzugefügt (mehr dazu weiter unten).

Sets ist aus der Roadmap verschwunden, ebenso wie die XAML-Version von Edge.

Die Hauptmotivation für diese Arbeit ist im Moment eigentlich die neue Windows Terminal App . Wir werden weiterhin andere Apps erweitern/erkunden, um das Tab-Steuerelement zu verwenden, aber unser Hauptaugenmerk liegt im Moment darauf, ihre Szenarien zu aktivieren.

Die Registerkartenplatzierung sollte irgendwann oben in der Prioritätenliste stehen, um der WPF-Parität für Migrationsszenarien zu entsprechen. Wir hatten jedoch auch keine Zeit, dies in der ursprünglichen Toolkit-Version hinzuzufügen.

Tab Placement ist eine großartige Idee, insbesondere in Bezug auf die WPF-Parität. Da wir den Umfang jedoch weitgehend auf der Grundlage dessen festlegen, was Terminal benötigt, ist dies nach dem oben Gesagten eher ein „könnte“ als ein „Bedarf“. Das heißt, ich habe es der obigen Anforderungstabelle hinzugefügt.

Diese Szenarien könnten in UWP-XAML-Apps möglich sein, wenn das TabView-Steuerelement in der Lage wäre, die Schaltflächen „Hinzufügen“ und „Schließen“ auszublenden.

Das TabControl unterstützt das Ausblenden der Schließen-Schaltfläche auf den Registerkarten selbst. Darüber hinaus wird die Schaltfläche „Hinzufügen“ von der App selbst (und nicht vom Steuerelement) bereitgestellt, sodass wir davon ausgehen, dass wir mithilfe des Steuerelements wie oben angegeben Registerkartenszenarien im Eigenschaftenstil erstellen können.

Wenn die Schaltfläche „Registerkarte hinzufügen“ nicht Teil des Steuerelements ist, könnte ich vorschlagen, dass ein Schaltflächenstil und ein XAML-Befehl in das Steuerelement eingeschlossen werden, um es den Benutzern zu erleichtern, eine Schaltfläche einheitlich überall dort zu implementieren, wo das Steuerelement verwendet wird.

@stmoy für das Drag-Szenario, ich denke, es wird Fälle geben, in denen das Ziehen auf die Kopfzeile und der Bereich unterschiedlich oder gleich sein können. Es wäre gut, wenn ein Beispiel das Ziehen für das Abreißen zeigen könnte, aber auch zum Beispiel das Ablegen einer Datei im Hauptinhaltsbereich und wie man das abfängt (das liegt vielleicht außerhalb des Bereichs des Steuerelements selbst, ist aber nützlich zu seiner Verwendung).

Schaltflächenstil und XAML-Befehl [zum Hinzufügen einer neuen Registerkarte]

@mdtauk - tolle Idee. Ich werde es der Spezifikation hinzufügen.

Es wäre gut, wenn ein Beispiel das Ziehen für das Abreißen zeigen könnte, aber auch zum Beispiel das Ablegen einer Datei im Hauptinhaltsbereich und wie man das abfängt

@michael-hawker - Stimmt, eine Probe würde sich lohnen. Ich weiß jedoch nicht, ob es tabspezifisch sein muss, da das Ziehen einer Datei vom Inhaltsbereich gehandhabt wird.

Hallo zusammen, ich wollte Ihnen nur kurz mitteilen, dass ich die Tabs -Spezifikation überarbeite, die derzeit für die PR verfügbar ist. Bitte fügen Sie Kommentare zur PR hinzu, wenn Sie Feedback haben!

Drücken Sie die Daumen, dass sie sich eher wie die Registerkarten von Chrome als die von Edge anfühlen.

Drücken Sie die Daumen, dass sie sich eher wie die Registerkarten von Chrome als die von Edge anfühlen.

Wir möchten, dass sich das Interaktionsdesign „richtig anfühlt“, also reichen Sie auf jeden Fall Probleme mit spezifischem Feedback gegen die Vorschauversion ein, damit wir es vor der Veröffentlichung richtig machen können!

Ich bin mir nicht sicher, ob jemand wie @chigy bereits eine Designkomposition für das TabView-Steuerelement erstellt hat, aber ich habe es schnell versucht und auch die Platzierungsoptionen für die Seite und die Unterseite demonstriert, die in Zukunft kommen könnten.

Ich mag es nicht, dass die Schwebe-/Gedrückt-Zustände der Schließen-Schaltfläche den Hintergrund der Schaltfläche und nicht ihren Vordergrund ändern. Durch das Ändern des Hintergrunds wird die Schaltfläche zu stark betont (und weg vom Registerkartentitel), und letzterer wäre auch viel eleganter.

Beispiele finden Sie unter der Schließen-Schaltfläche in Edge UWP (nur Vordergrund ändert sich) oder der Tab-Audio-Stummschaltfläche in Edge (Chromium).

Ich habe überlegt, bei der Vordergrundänderung zu bleiben, aber ich hatte das Gefühl, dass die Hintergrundänderung mit den anderen Steuerelementen und dem Verhalten der Titelleiste übereinstimmen würde - aber als Standard könnte es nur der Vordergrund sein.

@mdtauk - du rockst. Vielen Dank für die Erstellung dieser Designkompositionen. Obwohl wir für den ersten Drop des Steuerelements keine seitliche Platzierung vornehmen werden, ist es großartig zu sehen, wie es aussehen könnte.

@chigy und ich arbeiten zusammen, um einige Designkompositionen zu entwickeln, die den Windows-Prinzipien entsprechen (einschließlich Dinge wie abgerundete Ecken, Standardschatten usw.), aber die von Ihnen bereitgestellten Designkompositionen werden uns dabei helfen, uns zu inspirieren.

Ich mag es nicht, dass die Schwebe-/Gedrückt-Zustände der Schließen-Schaltfläche den Hintergrund der Schaltfläche und nicht ihren Vordergrund ändern. Durch das Ändern des Hintergrunds wird die Schaltfläche zu stark betont (und weg vom Registerkartentitel), und letzterer wäre auch viel eleganter.

Unsere derzeitige Überlegung ist, nur die Vordergrundfarbe und nicht den Hintergrund zu ändern, wie hier vorgeschlagen wird. Dies hat den zusätzlichen Vorteil, dass es etwas besser zu den abgerundeten Ecken passt, die wir in Betracht ziehen.

Die Edge-Tabs verwenden einen Hintergrund hinter der Schließen-Glyphe, aber er ist kleiner als der von mir vorgeschlagene - aber die Edgium-Tabs unterstützen noch keine Touch-Modi.

Als wir an die seitlichen Registerkarten für das Design des Toolkits dachten, waren wir hin- und hergerissen, ob wir sie vertikal mit gedrehtem Text machen sollten, wie @mdtauk gezeigt hat, oder sie immer noch horizontal haben und einen größeren Rand auf der linken/rechten Seite einnehmen, wie es OneNote früher tat vor ihrer letzten Neugestaltung und ähnlich wie WPF (was unserer Meinung nach für die Kompatibilität wichtig wäre).

Also würde ich vorschlagen, es so zu belassen wie WPF es mit dem breiten Rand und horizontal gemacht hat, aber es auch super einfach zu machen, beide wie hier gezeigt zu unterstützen, was ein weiterer Grund ist, #546 zu unterstützen.

@michael-hawker Ich befürworte, die vertikale Liste der Registerkarten rechts mit dem breiten Rand zu haben und sie wie in Visual Studio einfach zu drehen.

Es wird sich auf die Vorher- und Nachher-Tab-Spots auswirken, aber ich werde versuchen, ein Design-Mock-Up zu erstellen, wenn ich am Montag nach Hause komme

Es wird sich auf die Vorher- und Nachher-Tab-Spots auswirken, aber ich werde versuchen, ein Design-Mock-Up zu erstellen, wenn ich am Montag nach Hause komme

Ich bin zu Hause, und hier ist das Design:

Ich habe ein Design-Mockup für die Steuerung verfeinert.

_Tab-Überlauf und Tab-Größe hinzugefügt_

So sieht Ihr Tab-Konzept den Edge-UWP-Tabs viel ähnlicher als den Edge-Chromium-Tabs. IMO sollte das Aussehen des Registerkartensteuerelements so nah wie möglich am Registerkartensteuerelement in Edge UWP sein. Acryl als Tab-Control-Hintergrund wie in Edge UWP wäre auch ganz nett.

Ich hoffe immer noch, dass die Schaltfläche zum Schließen der Registerkarte wie in Edge UWP erstellt werden kann, wo die Schaltfläche nur für die aktuell ausgewählte Registerkarte oder den Mauszeiger auf der Registerkarte angezeigt wird.

Für das WinUI-Team: @stmoy Anscheinend kann das Windows Terminal-Team kein Acryl als Hintergrund für das Tab-Steuerelement verwenden (siehe https://github.com/microsoft/terminal/issues/1375). Das Terminalteam behauptet, dass dies auf architektonische Einschränkungen zurückzuführen ist. Könnte das WinUI-Team dabei helfen? Es scheint einige Fans des Acrylhintergrunds für die Registerkartensteuerung wie in Edge UWP zu geben.

@Felix-Dev Ich weiß, dass Edgeium das neue Design ist, auf das man sich zubewegen sollte, aber ich denke, das UWP Edge-Design ist ein bisschen schöner - also wollte ich versuchen, diese Lücke zu schließen

Ich hoffe immer noch, dass die Schaltfläche zum Schließen der Registerkarte wie in Edge UWP erstellt werden kann, wo die Schaltfläche nur für die aktuell ausgewählte Registerkarte oder den Mauszeiger auf der Registerkarte angezeigt wird.

CloseButtonOverlay Ist die Eigenschaft, die das tun würde, denke ich

@mdtauk
Zur Verdeutlichung möchte ich, dass CloseButtonOverlay = OnHover zum Standard des Tab-Steuerelements wird, anstatt dass die Schaltfläche „Schließen“ ständig auf allen Registerkarten angezeigt wird (nimmt unnötigerweise Platz aus dem Registerkartentitel imo weg).

Immer sichtbar ist am besten für Touch-Benutzer, daher denke ich, dass die Standardeinstellung so umfassend wie möglich sein sollte

Vielleicht könnte man dann den Overlay-Modus des Schließen-Buttons von den Fähigkeiten des Benutzerdisplays abhängig machen?

Ich bin mir nicht sicher, ob das irgendwie ein Problem sein könnte, da es dann je nach Anzeigetyp einen leichten visuellen Unterschied in der Registerkartensteuerung geben würde.

Vielleicht könnte man dann den Overlay-Modus des Schließen-Buttons von den Fähigkeiten des Benutzerdisplays abhängig machen?

Ich bin mir nicht sicher, ob das irgendwie ein Problem sein könnte, da es dann je nach Anzeigetyp einen _leichten_ visuellen Unterschied in der Registerkartensteuerung geben würde.

Das funktioniert für Dinge wie Flyouts, da es die Art der Eingabe erkennen kann, die es ausgelöst hat, und größere Berührungsziele bereitstellt, wenn es durch eine Berührungseingabe aufgerufen wird.

Dies funktioniert nicht für immer sichtbare Steuerelemente, da an einigen Touch-Geräten auch eine Maus angeschlossen ist.

Entwickler können die Standardoption natürlich ändern, und wenn eine App viele Rückmeldungen erhält, in denen sie gefragt werden, ob die Schließen-Schaltfläche nur beim Hover angezeigt werden soll, können sie sie ändern.

Ich habe eine Idee für den Tab-Überlauf hinzugefügt

Liebe das.

Nur eine Kleinigkeit. Wenn Schatten und abgerundete Ecken vorhanden sind, möchten wir möglicherweise eine kleine Lücke zwischen dem ausgewählten Registerkartenelement und dem Rand des Hintergrunds.

Liebe das.

Nur eine Kleinigkeit. Wenn Schatten und abgerundete Ecken vorhanden sind, möchten wir möglicherweise eine kleine Lücke zwischen dem ausgewählten Registerkartenelement und dem Rand des Hintergrunds.

Neugierig, warum das nötig wäre ... Wird der Schatten nicht durch den Fensterrahmen abgeschnitten? Ist es nur eine ästhetische Wahl, damit der Schatten oben sichtbar ist?

Registerkartengröße

@mdtauk : Ich liebe es, diese Designs zu sehen! Ich habe ein paar bohrende Fragen:

• Ist Lila die Akzentfarbe?
• Ist der Zweck des Überlauf-Screenshots, die Stoßfänger zu zeigen? Ich möchte nur sicherstellen, dass ich das Bild richtig lese.
• Wie groß ist der Eckenradius der Laschen?
• Wie hoch sind die Tabs?
• Welche Schriftgröße wurde verwendet?

Ich werde diese Entwürfe verwenden, um mit unseren Freunden auf dem Terminal zu sprechen und zu sehen, was sie denken. Diese Entwürfe enthalten einige Abweichungen von unserer aktuellen Richtung, aber wir werden diese verwenden, um das Gespräch zu fördern.

@Felix-Dev: Vielen Dank für das Feedback; einige Ihrer Punkte unten ansprechen.

So sieht Ihr Tab-Konzept den Edge-UWP-Tabs viel ähnlicher als den Edge-Chromium-Tabs. IMO sollte das Aussehen des Registerkartensteuerelements so nah wie möglich am Registerkartensteuerelement in Edge UWP sein. Acryl als Tab-Control-Hintergrund wie in Edge UWP wäre auch ganz nett.

Wir iterieren aktiv mit verschiedenen Teams (einschließlich Terminal- und Edge-Teams), um zu versuchen, die Registerkarten über diese App-Erlebnisse hinweg auszurichten. Während wir weiter iterieren (und Elemente wie #524 implementieren), wird das Design des Tab-Steuerelements konsistenter mit den aktualisierten Steuerelementen aussehen.

Ich hoffe immer noch, dass die Schaltfläche zum Schließen der Registerkarte wie in Edge UWP erstellt werden kann, wo die Schaltfläche nur für die aktuell ausgewählte Registerkarte oder den Mauszeiger auf der Registerkarte angezeigt wird.

Kurzfristig konzentrieren wir uns darauf, die Szenarien zu implementieren, die Terminal benötigt, und gegebenenfalls die API-Oberfläche zu trimmen. Für v1 unterstützen wir nur Persistent. Allerdings habe ich ursprünglich auch das Hover-Verhalten spezifiziert, weil ich es für eine großartige Idee halte. Ich verfolge diese Art von Anfragen (wie X-on-Hover, Tab-Platzierung usw.), damit wir die nächste Version der Steuerung neu bewerten können.

Für das WinUI-Team: @stmoy Anscheinend kann das Windows Terminal-Team kein Acryl als Hintergrund für das Tab-Steuerelement verwenden (siehe microsoft/terminal#1375). Das Terminalteam behauptet, dass dies auf architektonische Einschränkungen zurückzuführen ist. Könnte das WinUI-Team dabei helfen? Es scheint einige Fans des Acrylhintergrunds für die Registerkartensteuerung wie in Edge UWP zu geben.

Wir arbeiten aktiv mit dem Terminal-Team zusammen. Leider ist dieses Szenario das Ergebnis einer bekannten Einschränkung bei Xaml Islands und nicht bei Tabs. Wir gehen davon aus, dass Nicht-Terminal-Apps in der Lage sein sollten, Acrylhintergrund als „Opt-in“-Funktion zu verwenden, wenn die App „TabControl.Background“ auf einen Acrylpinsel festlegt.

Ist Lila die Akzentfarbe?

Ja - ich wollte mein Design nicht mit einem offiziellen Design-Comp verwechseln

Ist der Zweck des Überlauf-Screenshots, die Stoßfänger zu zeigen? Ich möchte nur sicherstellen, dass ich das Bild richtig lese.

Ja, zeigt, wie die linke und rechte Schaltfläche aussehen würden und wie die Registerkarten beschnitten würden.

Wie groß ist der Eckenradius der Laschen?

4 epx - Ich weiß, dass die Anleitung 2epx ist, aber die 4epx-Höhe des ausgewählten Indikators sah mit 4 besser aus

Wie hoch sind die Tabs?

40 Folgen

Welche Schriftgröße wurde verwendet?

14 für den Tab-Titeltext, 16 für die MDL2-Symbole

In Edge Canary gibt es ein Flag namens New tab-loading animation - edge://flags#new -tab-loading-animation

Ein Teil der Spezifikation sollte Themen- und/oder implizite Animationen enthalten, wie zum Beispiel:

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

@stmoy

Wir arbeiten aktiv mit dem Terminal-Team zusammen. Leider ist dieses Szenario das Ergebnis einer bekannten Einschränkung bei Xaml Islands und nicht bei Tabs.

Kann diese Einschränkung in zukünftigen Versionen von Xaml Island behoben werden? Der Wunsch nach Hintergrund-Acryl scheint beispielsweise in der Windows-Terminal-App stark zu sein. Siehe https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390 und insbesondere das letzte Bild in diesem Beitrag (mit Hintergrundacryl in der Titelleiste). Beachten Sie auch die vielen Up-Votes, die dieser Beitrag erhalten hat 😉. Ein weiterer Beitrag mit vielen Upvotes hier: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

Um allgemeiner über das Design der Tabs-Benutzeroberfläche zu sprechen, beachten Sie auch die unterstützenden Reaktionen auf Benutzerkommentare, die das Aussehen der Edge-UWP-Tabs dem Aussehen der Edge-Chromium-Tabs vorziehen: https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 und the direkt darunter posten.

Wenn Edge Chromium-Tabs das zukünftige Aussehen von (modernen) Windows-Tabs darstellen sollen, könnten diese überwältigenden Benutzerreaktionen ein Grund sein, das Aussehen von Tabs zu überdenken, die sowohl in Edge Chromium als auch in WinUI verwendet werden. (Hier wird auch @chigy hinzugefügt, damit sie diese Reaktionen der Registerkarten-Benutzeroberfläche im Windows Terminal-Repo bemerken kann.)

Bearbeiten: Lenken Sie auch die Aufmerksamkeit von @marb2000 auf dieses Thema, da das Windows Terminal-Team gerade erneut bestätigt hat, dass sie dieses Problem "nicht beheben können". Wie sieht das WinUI-Team Chancen für die Titelleiste aus Acryl (stark nachgefragt!) für das Windows-Terminal? @stmoy

@marb2000 @stmoy Bitte kommentieren Sie die folgende Frage:

Auch die Aufmerksamkeit von @marb2000 auf dieses Thema lenken, da das Windows Terminal-Team gerade bekräftigt hat, dass sie dieses Problem „nicht beheben können“ [(Acryl-Titelleiste im Terminal)]. Wie sieht das WinUI-Team Chancen für die Titelleiste aus Acryl (stark nachgefragt!) für das Windows-Terminal?

@marb2000 @SavoySchuler @jesbis @jevansaks

Hat jeden von euch vom letzten Community-Call angepingt 😁
Informationen zur Unterstützung der technischen Acryltitelleiste in Xaml Islands (Windows Terminal) finden Sie in meinen Beiträgen oben, die teilweise bereits von @stmoy beantwortet wurden

Hier sind drei der wichtigsten Punkte aus meinen Beiträgen und den Antworten oben:

Für das WinUI-Team: Anscheinend kann das Windows-Terminal-Team kein Acryl als Hintergrund für das Tab-Steuerelement verwenden (siehe microsoft/terminal#1375). Das Terminalteam behauptet, dass dies auf architektonische Einschränkungen zurückzuführen ist. Könnte das WinUI-Team dabei helfen? Es scheint einige Fans des Acrylhintergrunds für die Registerkartensteuerung wie in Edge UWP zu geben.

Antwort von @stmoy :

Wir arbeiten aktiv mit dem Terminal-Team zusammen. Leider ist dieses Szenario das Ergebnis einer bekannten Einschränkung bei Xaml Islands und nicht bei Tabs. Wir gehen davon aus, dass Nicht-Terminal-Apps in der Lage sein sollten, Acrylhintergrund als „Opt-in“-Funktion zu verwenden, wenn die App „TabControl.Background“ auf einen Acrylpinsel festlegt.

Meine Frage:

Auch die Aufmerksamkeit von @marb2000 auf dieses Thema lenken, da das Windows Terminal-Team gerade bekräftigt hat, dass sie dieses Problem „nicht beheben können“ [(Acryl-Titelleiste im Terminal)]. Wie sieht das WinUI-Team Chancen für die Titelleiste aus Acryl (stark nachgefragt!) für das Windows-Terminal?

Danke für die Antwort 😁