Deve adicionar um link para a amostra de Van Arsdel

Acho que os controles mais genéricos do Toolkit devem sempre ser portados para C++ e disponíveis na Biblioteca de IU do Windows. O controle de guias quando está maduro e estável o suficiente também deve aparecer.

Aconteceu com o controle do Menu Principal :)

Link para a amostra de destaque de guia também mencionada na proposta.

Link para a amostra de destaque de guia também mencionada na proposta.

A remoção de uma guia gera um novo AppWindow, um novo CoreWindow e como você lida com o fallback onde as APIs da nova janela não estão presentes?

@mdtauk o exemplo usa a API ApplicationView de várias janelas mais antiga atualmente, a janela é criada em uma posição padrão em vez de onde arrastada. Estou testando com AppWindow e espero atualizar o exemplo para o novo SDK.

"Embora essas soluções alternativas tenham ajudado a preencher a lacuna da plataforma do WPF, elas têm várias limitações, incluindo:"

Você deve listar a digitação aqui também. Esta não é apenas a tecla tab ou as teclas de atalho. Arrowing era algo com o qual lutamos quando não tínhamos controle de tab e tínhamos que fazer com que todos fossem consistentes na falta dele.

Comentários sobre perguntas abertas do que ouvimos no kit de ferramentas:

1. O Tab Tearoff deve ser algo que o controle manipula ou que o aplicativo manipula?

Acho importante que o Tab Control lide com o arrastar e recombinar entre TabViews (hospedando o mesmo tipo de dados) e expondo um evento de arrastar, com a capacidade de inspecionar/interceptar.

Mas não sei se é importante que o TabView também gerencie diretamente o ciclo de vida da janela, pois isso fica mais complicado. Um desenvolvedor também pode querer personalizar o que acontece ao arrastar uma guia para fora, talvez apenas a remova ou crie uma janela especial apenas para esse conteúdo versus uma nova janela 'principal' com guias? Ou eles podem não querer lidar com o código para várias janelas.

Pode ser mais fácil expor o evento e ter auxiliares (ou aproveitar os existentes, como os do Windows Template Studio) para auxiliar na criação/gerenciamento do Windows. A parte mais complicada desse cenário é a "transferência de dados" entre threads, que pelo menos a nova API de janelas deve ajudar a aliviar.

1. Deve haver um botão "Adicionar nova guia" embutido? (Suspeito que provavelmente não, porque o controle não possui a coleção de guias.)

Acho que, desde que existam modelos e exemplos de cabeçalho adequados, ter um implementador adicionando um botão 'adicionar' é trivial, então não acho que precise ser embutido, pois o paradigma precisaria de outro evento. Isso é algo que originalmente pensamos também no kit de ferramentas. :)

1. TabItem.Icon deve ser IconElement ou IconElementSource?

Usamos IconElement para imitar a propriedade do NavigationViewItem. Além disso, IconElementSource é um IconElement então IconElement não é melhor por ser mais amplo? Seria bom se houvesse uma subclasse IconElement no WinUI que pudesse hospedar um Image direto (semelhante a BitmapIcon mas sem o mascaramento forçado). Dessa forma, a propriedade Icon pode hospedar qualquer coisa, seja um bom símbolo vetorial/ícone de fonte ou um arquivo ico/png (pense no favicon do cenário do tipo navegador).

1. Como um aplicativo pode personalizar a aparência da guia Selecionado (ou seja, no Edge)?

Você está falando sobre propriedades de estilo expostas que podem ser modificadas ou como um modelo completamente diferente para o item selecionado?

1. Atualmente, a API se inspira muito no Toolkit. Há alguma chance de iterar/melhorar?

Um item de feedback que recebemos foi sobre como personalizar o espaço no final das guias. Por exemplo, deve ser apenas uma única área de modelo que pode usar o alinhamento horizontal esquerdo/direito para colar as coisas nas bordas versus duas áreas separadas?

Outras perguntas:

• [ ] É interessante com arrastar sobre como lidar com arrastar para a área de conteúdo versus o cabeçalho, pois ambos são alvos? E se o aplicativo quiser permitir soltar outra coisa na área da guia (como um arquivo do explorer)?
• [ ] "O aplicativo pode decidir como posicionar/dimensionar as guias" está falando sobre a propriedade TabStripPlacement ?

Também esqueci de chamar o Requisito 9, tivemos uma discussão originalmente sobre usar ou não o modelo Edge (como o controle do kit de ferramentas se comporta atualmente) ou o modelo NavigationView onde ele cria uma divisa suspensa. Pensamos que talvez no futuro apoiaríamos os dois.

Acabamos optando pelo modelo Edge por ser mais simples de implementar, pois não precisávamos de um objeto do tipo SplitObservableCollection . Eu comecei a trabalhar em um como teste, mas gostaria de saber se seria uma construção útil para expor?

@stmoy você fechou os problemas/feedback em aberto que tivemos dos designs do kit de ferramentas?

Como as notícias de Windows Sets abandonando o modelo Edge Tab afetam como esse controle pode ser desenvolvido?

Com o Edge e sua interface do usuário praticamente abandonada agora em favor do ChromiumEdge (Edgium), precisamos/queremos repensar a aparência ou o comportamento desse controle para ser mais adequado aos tipos de aplicativos que podem usá-lo?

• Diálogos de Propriedades;
• MDI (Multiple Document Interfaces) - como o Photoshop;
• Paletas de ferramentas encaixadas (Visual Studio/Blend/Adobe CC);

Sem mencionar controles semelhantes como Pivot e a Faixa de Opções UWP em desenvolvimento. Qual é recomendado para qual caso de uso e por que alguém escolheria um em vez do outro? A orientação e os exemplos devem ser claros para responder a essas perguntas para evitar confusão ou um controle mais pesado sendo usado em vez de um controle de alto desempenho e mais leve.

Os controles de primeira parte devem usar o controle certo para o propósito certo, para tentar liderar o uso consistente.

Em #629 @mdtauk tinha uma sugestão de recurso:

Talvez uma ideia para a lista de tarefas. Posicionamento da guia? Inferior, Esquerda, Direita.

Sim, o Tab Placement deve estar lá em cima na lista de prioridades em algum momento para corresponder à paridade do WPF para cenários de migração. É algo que também não tivemos tempo de adicionar na versão inicial do Toolkit.

Quando definimos esse recurso, tornou-se um não objetivo oferecer suporte ao cenário de "guias de planilha de propriedades" e focar no cenário de guias do navegador. Vemos alguma sobreposição com as folhas de propriedades, mas a metáfora da folha de propriedades não faz parte do design fluente, temos NavigationView (que tem modos Left/Top) para esse cenário agora.

A visualização de navegação é um controle pesado e deseja ocupar toda a tela. Também Sets foi retirado do roteiro, assim como a versão XAML do Edge.

Portanto, pode haver espaço para repensar o TabView/Control para torná-lo mais flexível e útil para o futuro.

Esses cenários podem ser possíveis em aplicativos UWP XAML, se o controle TabView tiver a capacidade de ocultar os botões adicionar e fechar.

Mas também há controles de pivô, no entanto, ele suporta apenas cabeçalhos de pivô na parte superior, e as guias podem ir na parte superior, inferior, esquerda ou direita ...

No kit de ferramentas, suportamos não ter o botão fechar, o botão adicionar também era algo que o implementador precisava adicionar. É por isso que tivemos a propriedade TabWidthBehavior para ajudar a configurar esses diferentes modos entre documentos e guias clássicas. Uma das principais coisas que ainda não suportamos foi o posicionamento das guias.

Obrigado por toda a grande conversa todos! Circulando de volta...

É interessante com arrastar sobre como lidar com arrastar para a área de conteúdo versus o cabeçalho também são ambos alvos? E se o aplicativo quiser permitir soltar outra coisa na área da guia (como um arquivo do explorer)?

Pergunta interessante. Ingenuamente, eu pensaria que ambos seriam o mesmo destino (grande) já que o TabControl hospeda a área da faixa de guias e a área de conteúdo. No entanto, esse modelo desmorona ao considerar aplicativos como o Edge (como exemplo). Se o Edge foi maximizado e o usuário arrastar uma guia para fora da faixa de guias, mas ainda sobre o conteúdo porque é o tamanho máximo, o usuário espera que a guia crie uma nova janela.

Portanto, acho que devemos ter apenas a área de cabeçalho/tira de guia como alvo de arrastar/soltar.

"O aplicativo pode decidir como posicionar/dimensionar as guias" está falando sobre a propriedade TabStripPlacement?

Isso foi feito para descrever a propriedade e enum "TabWidthBehavior" e não TabStripPlacement. Atualizei o requisito e também adicionei um requisito de posicionamento de guia (discutido um pouco mais abaixo).

Os conjuntos foram retirados do roteiro, assim como a versão XAML do Edge.

O principal motivador para este trabalho agora é, na verdade, o novo aplicativo Windows Terminal . Continuaremos a expandir/explorar outros aplicativos para usar o controle Tab, mas nosso foco principal é habilitar seus cenários no momento.

O posicionamento da guia deve estar lá em cima na lista de prioridades em algum momento para corresponder à paridade do WPF para cenários de migração. É algo que também não tivemos tempo de adicionar na versão inicial do Toolkit.

O Tab Placement é uma ideia incrível, principalmente no que se refere à paridade do WPF. De acordo com o que foi dito acima, no entanto, como estamos definindo o escopo com base no que o Terminal precisa, isso acaba sendo mais um "poderia" do que uma "necessidade". Dito isso, adicionei-o à tabela de requisitos acima.

Esses cenários podem ser possíveis em aplicativos UWP XAML, se o controle TabView tiver a capacidade de ocultar os botões adicionar e fechar.

O TabControl suporta ocultar o botão fechar nas próprias guias. Além disso, o botão "Adicionar" será fornecido pelo próprio aplicativo (e não pelo controle), portanto, esperamos poder criar cenários de guia de estilo de propriedade usando o controle conforme especificado acima.

Se o botão Adicionar guia não fizer parte do controle, sugiro que um estilo de botão e um Comando XAML sejam incluídos no controle, para facilitar a implementação de um botão de forma consistente onde quer que o controle seja usado.

@stmoy para o cenário de arrastar, acho que haverá casos em que arrastar para o cabeçalho e a área podem ser diferentes ou iguais. Seria bom se uma amostra pudesse mostrar o arrastar para a remoção, mas também, por exemplo, soltar um arquivo na área de conteúdo principal e como pegá-lo (isso pode estar fora do alcance do próprio controle, mas é útil ao seu uso).

estilo de botão e comando XAML [para adicionar uma nova guia]

@mdtauk - ótima ideia. Vou adicioná-lo à especificação.

Seria bom se uma amostra pudesse mostrar o arrastar para o tear-away, mas também, por exemplo, soltar um arquivo na área de conteúdo principal e como pegá-lo

@michael-hawker - Concordo, uma amostra valeria a pena. No entanto, não sei se precisa ser específico da guia, pois arrastar um arquivo seria tratado pela área de conteúdo.

Olá a todos, só queria dar um aviso rápido de que estou iterando na especificação Tabs que está atualmente disponível para PR . Por favor, adicione comentários ao PR se você tiver algum feedback!

Cruzam os dedos para que pareçam mais as guias do Chrome do que as do Edge.

Cruzam os dedos para que pareçam mais as guias do Chrome do que as do Edge.

Queremos que o design de interação "pareça certo", então definitivamente registre problemas com feedback específico em relação à versão de visualização para que possamos acertar antes de enviar!

Não tenho certeza se alguém como @chigy já fez uma composição de design para o TabView Control, mas eu tentei rapidamente, demonstrando também as opções de posicionamento Lateral e Inferior que poderiam vir no futuro.

Não gosto que os estados de foco/pressionado do botão fechar mudem o plano de fundo do botão e não o primeiro plano. Alterar o plano de fundo adiciona muita ênfase ao botão (e longe do título da guia) e o último também seria muito mais elegante.

Por exemplo, veja o botão fechar no Edge UWP (somente alterações em primeiro plano) ou o botão de aba-áudio mudo no Edge (Chromium).

Eu considerei manter a mudança de primeiro plano, mas senti que a mudança de plano de fundo estaria alinhada com os outros controles e comportamento da barra de título - mas como padrão, poderia ser apenas o primeiro plano.

@mdtauk - você arrasa. Obrigado por criar essas composições de design. Embora não façamos o posicionamento lateral para a primeira queda do controle, é ótimo ver como poderia ser.

@chigy e eu estamos trabalhando juntos para construir algumas composições de design que se alinham com os princípios do Windows (incluindo coisas como cantos arredondados, sombra padrão etc.), mas as composições de design que você forneceu ajudarão a nos inspirar.

Não gosto que os estados de foco/pressionado do botão fechar mudem o plano de fundo do botão e não o primeiro plano. Alterar o plano de fundo adiciona muita ênfase ao botão (e longe do título da guia) e o último também seria muito mais elegante.

Nosso pensamento atual é apenas mudar a cor do primeiro plano e não do plano de fundo, como está sendo sugerido aqui. Isso tem o benefício adicional de encaixar um pouco melhor com os cantos arredondados que estamos considerando.

As guias Edge usam um plano de fundo atrás do glifo próximo, mas é menor do que o que propus - mas as guias Edgium ainda não suportam nenhum modo Touch.

Quando estávamos pensando nas guias laterais para o design do kit de ferramentas, estávamos divididos entre fazê-las verticalmente com texto girado como @mdtauk mostrava ou ainda tê-las na horizontal e ocupar uma margem maior para o lado esquerdo/direito como o OneNote costumava antes de seu mais recente redesenho e semelhante ao WPF (que achamos que seria importante para a compatibilidade).

Portanto, sugiro mantê-lo como o WPF fez com a margem ampla e a horizontal, mas também torná-lo super simples para oferecer suporte a ambos , como mostrado aqui , que é outro motivo para oferecer suporte a #546.

@michael-hawker Eu endosso ter a lista vertical de guias à direita com a margem larga e facilitar a rotação delas como no Visual Studio.

Isso afetará os pontos de guia antes e depois, mas vou tentar fazer uma maquete de design quando voltar para casa na segunda-feira

Isso afetará os pontos de guia antes e depois, mas vou tentar fazer uma maquete de design quando voltar para casa na segunda-feira

Estou em casa, e aqui está esse design:

Eu refinei uma maquete de design para o controle.

_adicionado Tab Overflow e Tab Sizing_

Assim, seu conceito de guia se parece muito mais com as guias do Edge UWP do que com as guias do Edge Chromium. IMO, a aparência do controle de guia deve ser o mais próximo possível do controle de guia no Edge UWP. Acrílico como um plano de fundo de controle de guia, como no Edge UWP, também seria muito bom.

Ainda espero que o botão de fechamento da guia possa ser feito como no Edge UWP, onde o botão é exibido apenas para a guia selecionada no momento ou na guia do mouse.

Para a equipe WinUI: @stmoy Aparentemente, a equipe do Windows Terminal não pode usar acrílico como plano de fundo para o controle de guias (consulte https://github.com/microsoft/terminal/issues/1375). A equipe do terminal afirma que isso se deve a limitações arquitetônicas. Isso é algo que a equipe do WinUI poderia ajudar? Parece haver alguns fãs do fundo acrílico para o controle de guias como no Edge UWP.

@Felix-Dev Eu sei que o Edgeium é o novo design a ser seguido, mas acho que o design do UWP Edge é um pouco melhor - então eu queria tentar preencher essa lacuna

Ainda espero que o botão de fechamento da guia possa ser feito como no Edge UWP, onde o botão é exibido apenas para a guia selecionada no momento ou na guia do mouse.

CloseButtonOverlay É a propriedade que faria isso, eu acho

@mdtauk
Para esclarecer, gostaria de ver CloseButtonOverlay = OnHover para se tornar o padrão do Tab Control, em vez do botão Fechar ser mostrado constantemente em todas as guias (desnecessariamente tira espaço do título da guia imo).

Sempre visível é melhor para usuários de toque, então acho que o padrão deve ser o mais inclusivo possível

Talvez o modo de sobreposição do botão Fechar possa ser dependente dos recursos da tela do usuário?

Não tenho certeza se isso poderia de alguma forma ser um problema, pois haveria uma pequena diferença visual no controle de guias, dependendo do tipo de exibição.

Talvez o modo de sobreposição do botão Fechar possa ser dependente dos recursos da tela do usuário?

Não tenho certeza se isso poderia de alguma forma ser um problema, pois haveria uma _leve_ diferença visual no controle de guias, dependendo do tipo de exibição.

Isso funciona para coisas como flyouts porque pode detectar o tipo de entrada que o acionou, fornecendo alvos de toque maiores se convocados por uma entrada de toque.

Isso não funciona para controles sempre visíveis, pois alguns dispositivos de toque também terão um mouse conectado.

Os desenvolvedores poderão alterar a opção padrão, é claro, e se um aplicativo receber muitos comentários solicitando que o botão Fechar seja exibido apenas ao passar o mouse - eles podem optar por alterá-lo.

Eu adicionei uma ideia para estouro de guias

Amo isso.

Apenas uma pequena coisa. Quando há sombra e cantos arredondados, podemos querer um pequeno espaço entre o item de guia selecionado e a borda do plano de fundo.

Amo isso.

Apenas uma pequena coisa. Quando há sombra e cantos arredondados, podemos querer um pequeno espaço entre o item de guia selecionado e a borda do plano de fundo.

Curioso por que isso seria necessário... A sombra não é cortada pela moldura da janela? É apenas uma escolha estética para que a sombra fique visível acima?

Dimensionamento da guia

@mdtauk : Adoro ver esses designs! Tenho algumas perguntas de sondagem:

• O roxo é a cor de destaque?
• O objetivo da captura de tela de estouro é mostrar os bumpers? Eu só quero garantir que estou lendo a imagem corretamente.
• Qual é o raio do canto das abas?
• Qual a altura das abas?
• Que tamanho de fonte foi usado?

Vou usar esses designs para conversar com nossos amigos no Terminal e ver o que eles acham. Esses designs incluem alguns deltas de nossa direção atual, mas os usaremos para ajudar a promover a conversa.

@Felix-Dev: Obrigado pelo feedback; abordando alguns de seus pontos abaixo.

Assim, seu conceito de guia se parece muito mais com as guias do Edge UWP do que com as guias do Edge Chromium. IMO, a aparência do controle de guia deve ser o mais próximo possível do controle de guia no Edge UWP. Acrílico como um plano de fundo de controle de guia, como no Edge UWP, também seria muito bom.

Estamos interagindo ativamente com várias equipes (incluindo equipes de Terminal e Edge) para tentar alinhar as guias nessas experiências de aplicativos. À medida que continuamos a iterar (e implementar itens como #524), o design do controle Tab ficará mais consistente com os controles atualizados.

Ainda espero que o botão de fechamento da guia possa ser feito como no Edge UWP, onde o botão é exibido apenas para a guia selecionada no momento ou na guia do mouse.

No curto prazo, estamos nos concentrando na implementação dos cenários que o Terminal precisa e no corte da superfície da API quando apropriado. Para v1, daremos suporte apenas a Persistente. Dito isso, eu originalmente especifiquei o comportamento do hover também porque acho que é uma ótima ideia. Estou acompanhando esses tipos de perguntas (como x-on-hover, posicionamento de guias, etc.) para que possamos reavaliar na próxima rotação do controle.

Para a equipe do WinUI: @stmoy Aparentemente, a equipe do Windows Terminal não pode usar acrílico como plano de fundo para o controle de guias (consulte microsoft/terminal#1375). A equipe do terminal afirma que isso se deve a limitações arquitetônicas. Isso é algo que a equipe do WinUI poderia ajudar? Parece haver alguns fãs do fundo acrílico para o controle de guias como no Edge UWP.

Estamos trabalhando ativamente com a equipe do Terminal. Infelizmente, este cenário é resultado de uma limitação conhecida com Xaml Islands e não com Tabs. Esperamos que os aplicativos não-Terminal possam usar o plano de fundo acrílico como um recurso "opt-in" se o aplicativo definir o TabControl.Background como um pincel acrílico.

O roxo é a cor de destaque?

Sim - eu não queria confundir meu design com uma composição de design oficial

O objetivo da captura de tela de estouro é mostrar os bumpers? Eu só quero garantir que estou lendo a imagem corretamente.

Sim, está mostrando como os botões esquerdo e direito ficariam e como as guias seriam cortadas.

Qual é o raio do canto das abas?

4 epx - Eu sei que a orientação é 2epx, mas a altura 4epx do indicador selecionado ficou melhor com 4

Qual a altura das abas?

40 pixels

Que tamanho de fonte foi usado?

14 para o texto do título da guia, 16 para os ícones MDL2

No Edge Canary existe um sinalizador chamado New tab-loading animation - edge://flags#new -tab-loading-animation

Parte da especificação deve incluir o tema e/ou animações implícitas, como:

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

@stmoy

Estamos trabalhando ativamente com a equipe do Terminal. Infelizmente, este cenário é resultado de uma limitação conhecida com Xaml Islands e não com Tabs.

É possível resolver essa limitação em versões futuras do Xaml Island? Parece haver um forte desejo de acrílico de fundo no aplicativo Windows Terminal, por exemplo. Veja https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390 e principalmente a última imagem desse post (com fundo acrílico na barra de título). Observe também os muitos votos positivos que o post recebeu 😉. Outro post com muitos votos positivos aqui: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

Falando mais amplamente sobre o design da interface do usuário do Tabs, observe também as reações de apoio aos comentários dos usuários, preferindo as guias Edge UWP à aparência da guia Edge Chromium: https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 e o poste logo abaixo dele.

Se as guias do Edge Chromium devem representar a aparência futura das guias do Windows (modernas), essas reações esmagadoras do usuário podem ser um motivo para repensar a aparência das guias usadas no Edge Chromium e no WinUI. (Também adicionando @chigy aqui para que ela possa notar as reações da interface do usuário da guia no repositório do Windows Terminal.)

Edit: Também chamando a atenção do @marb2000 para este tópico, pois a equipe do Windows Terminal acabou de reafirmar que "não poderão corrigir" esse problema. Como a equipe do WinUI está vendo as chances de uma barra de título em acrílico (altamente solicitada!) acontecer no Windows Terminal? @stmoy

@marb2000 @stmoy Por favor, comente a pergunta abaixo:

Também chamando a atenção de @marb2000 para este tópico, pois a equipe do Windows Terminal acabou de reafirmar que "não será capaz de corrigir" esse problema [(barra de título acrílica no terminal)]. Como a equipe do WinUI está vendo as chances de uma barra de título em acrílico (altamente solicitada!) acontecer no Windows Terminal?

@marb2000 @SavoySchuler @jesbis @jevansaks

Pingou a todos um de vocês da recente chamada da comunidade 😁
Sobre suporte técnico à barra de título em acrílico nas Ilhas Xaml (Windows Terminal), veja minhas postagens acima e que já foram parcialmente respondidas por @stmoy

Aqui estão três dos principais pontos retirados dos meus posts e das respostas acima:

Para a equipe WinUI: Aparentemente, a equipe do Windows Terminal não pode usar acrílico como plano de fundo para o controle de guias (consulte microsoft/terminal#1375). A equipe do terminal afirma que isso se deve a limitações arquitetônicas. Isso é algo que a equipe do WinUI poderia ajudar? Parece haver alguns fãs do fundo acrílico para o controle de guias como no Edge UWP.

Resposta de @stmoy :

Estamos trabalhando ativamente com a equipe do Terminal. Infelizmente, este cenário é resultado de uma limitação conhecida com Xaml Islands e não com Tabs. Esperamos que os aplicativos não-Terminal possam usar o plano de fundo acrílico como um recurso "opt-in" se o aplicativo definir o TabControl.Background como um pincel acrílico.

Minha pergunta:

Também chamando a atenção de @marb2000 para este tópico, pois a equipe do Windows Terminal acabou de reafirmar que "não será capaz de corrigir" esse problema [(barra de título acrílica no terminal)]. Como a equipe do WinUI está vendo as chances de uma barra de título em acrílico (altamente solicitada!) acontecer no Windows Terminal?

Obrigado por responder 😁