Flutter: ☂ Adicionar suporte para UWP

Provavelmente não por enquanto, veja #10881.

Gostaria de me incluir nesta solicitação de recurso, seria incrível que o Flutter suportasse o Windows 10 UWP.

Isso também deve abranger o Xbox One, que você pode segmentar no Xamarin/UWP

Sim por favor. O suporte ao Windows definitivamente seria um divisor de águas.

isso não é oficial, mas você pode conferir este projeto. https://github.com/google/flutter-desktop-embedding Acho que glfw também está disponível no Windows, então você pode tentar :wink:

Cara... eu quero xplat real :)

Eu estava digitando a mesma solicitação de recurso 😉... Espero que isso tenha alguma tração!

Como usuário com vários dispositivos Windows, MacOS e Chrome OS em minha casa... o modelo mais recente do Surface Pro acaba sendo meu driver diário todos os anos; desde o lançamento do SP4. Parece ser extremamente popular no campus e no trabalho agora também. No entanto, a escassa seleção de aplicativos UWP de alta qualidade continua sendo o maior ponto dolorido para mim.

Acredito que a elegância e facilidade do Flutter poderiam fornecer o incentivo que os desenvolvedores/corporações precisam para incluir o Win10 em sua estratégia multiplataforma... e, no processo, esperamos promover o Flutter para um status/popularidade semelhante ao Java; para consideração do executivo de TI, ao selecionar ferramentas e plataformas para desenvolvimento de produtos.

Xamarin, Ionic etc. incluem UWP, então por que Flutter?

Removendo a atribuição, já que este é um bug de guarda-chuva muito amplo. Subtarefas específicas são rastreadas em bugs individuais, que obterão responsáveis ​​e marcos específicos como de costume.

Removendo do projeto Window MVP. Ainda estamos avaliando a UWP como um destino e provavelmente daremos suporte a ela eventualmente, mas o foco inicial é habilitar o Win32 para limitar o escopo.

Eu acho que isso é um erro. Todas as plataformas que não suportam uwp não são suportadas a partir de 20 de janeiro de 2020. Ou seja, quando isso estiver pronto.

É inútil dar suporte a uma plataforma legada quando você não precisa porque a migração em massa está ocorrendo agora de forma agressiva.

O único foco deve ser uwp e wpf deve ser ignorado.

Todas as plataformas que não suportam uwp não são suportadas a partir de 20 de janeiro de 2020

A decisão de focar primeiro nas APIs do Win32 é técnica, não baseada em plataformas de destino.

wpf deve ser ignorado

No momento, não há planos para usar o WPF.

Desculpe, win32 deve ser ignorado.

Por quê?

Porque o win32 limita a vibração nas plataformas Windows. Uwp não porque, no momento em que você tiver isso, não haverá plataformas Windows suportadas que não suportam uwp, mas existem plataformas no Windows que não suportam win32 (arm64 que exigiria uma reconstrução completa)

Para ser claro, qualquer pessoa interessada em contribuir com o apoio da UWP ainda é bem-vinda e incentivada a fazê-lo.

ainda existem plataformas no Windows que não suportam win32 (arm64 que exigiria uma reconstrução completa)

O Windows 10 no ARM suporta Win32, você só precisa compilar o aplicativo em ARM64, como é o caso do UWP.

Todas as plataformas que não suportam uwp não são suportadas a partir de 20 de janeiro de 2020. Ou seja, quando isso estiver pronto.

O suporte para Windows 8.1 termina em 2023. Ele não suporta UWP.

@stuartmorgan Ei, estou interessado em trabalhar no suporte UWP.

Você mencionou acima "Ainda estamos avaliando a UWP como um alvo" - gostaria de saber o que você descobriu.

Obrigado,
-Jake

@ Kapranov98 Acabei de experimentar a portabilidade do flutter para o Windows 10 ARM. Win32/UWP é o menor dos problemas. O próprio Dart requer mudanças substanciais para rodar no WinARM. O código específico do ARM no dart nunca foi projetado para rodar em nada além de sistemas posix'ish (ios, android, linux, etc). Sem mencionar que o WinARM suporta apenas o conjunto de instruções Thumb-2 e, pelo que entendi, o dart jit usa o conjunto de instruções ARM (embora eu precise obter uma verificação oficial disso). Fazer o porto funcionar será um esforço bastante substancial.

@Jakesays você tentou habilitar /appcontainer como parte de sua experimentação?

Você mencionou acima "Ainda estamos avaliando a UWP como um alvo" - gostaria de saber o que você descobriu.

Vou iniciar um documento inicial para coletar informações em breve e vinculá-lo a partir daqui. Não há muitos detalhes neste momento (e uma vez que o documento inicial exista, coisas como os resultados de sua investigação ARM seriam muito bem-vindas como adições). Quando digo "ainda avaliando", quero dizer que ainda planejamos apoiá-lo no futuro e, como parte disso, avaliaremos o que tudo precisa ser feito. Como não é nosso foco para um MVP inicial, não há muita investigação atual ativa.

Parte disso envolverá a quebra de aspectos específicos, pois, como os comentários acima apontam, existem vários elementos diferentes, cada um com seus próprios desafios.

Essa conversa muda agora que o Windows 10 X é uma coisa? O Win32 poderá ser executado no Windows 10 X, mas acho que o UWP será um ajuste muito melhor. O Flutter planeja oferecer suporte a dispositivos de tela dupla? Surface Duo e Surface Neo?

@nerocui Pelo que entendi, o Duo é um dispositivo Android, então imagino que o Flutter funcionaria bem (pelo menos em uma tela). Não tenho certeza de qual CPU o Neo está executando, mas se for ARM, o Flutter está praticamente morto na água. Dart atualmente não gera código de montagem compatível para winarm (winarm usa instruções thumb-2 exclusivamente, e IIRC Dart usa instruções thumb-2 e arm). Seria um empreendimento não trivial fazê-lo funcionar.

@JakeSays Neo usa Intel Lakefield, então é x86. Estou mais preocupado com a parte UWP da história. Em um dispositivo móvel como o Neo, o ciclo de vida gerenciado do modelo de aplicativo UWP será útil. Win32 não será ideal para a duração da bateria. Além disso, os aplicativos win32 no Neo serão executados em um contêiner, o que é ruim para o desempenho. A segmentação de UWP é realmente uma jogada muito inteligente. Tanto o Android quanto o iOS executam o modelo de aplicativo gerenciado, o UWP deve trazer mais consistência. O Windows 8 pode ser praticamente ignorado, nenhuma das estatísticas mostra qualquer participação de mercado significativa.

@nerocui Ok, então obter a vibração para direcionar o UWP deve ser possível. O maior problema é a falta de suporte a OpenGL em UWP, mas isso deve ser resolvido usando ANGLE sob flutter.

Eu estava olhando para UWP, mas meu alvo era ARM/WinIOT.

@JakeSays UWP deve ser bom para a maioria dos dispositivos, mas é uma dor de cabeça para o Windows no ARM. Por mais irônico que seja, o flutter UWP (se vier) terá que permanecer emulado em dispositivos Windows baseados em ARM. Que nível de conclusão você alcançou para a porta flutter/uwp?

@nerocui Parei de trabalhar nisso quando descobri o problema do Dart.

Embora o UWP seja definitivamente desejado, o Win32 definitivamente não vai a lugar nenhum. A Microsoft anunciou recentemente que está adicionando suporte ao Win32 à Windows Store. Além disso, muitos jogos continuam a ser desenvolvidos na plataforma Win32.

Sim, a Microsoft aceita o aplicativo Win32 na loja e usa amplamente no mundo do que o UWP. O aplicativo Win32 tem o melhor desempenho, mas tem um limite no consumo de bateria. O Win32 tem apenas 2 estados Executando ou Não Respondendo (Congelar), mas o UWP tem mais estados (mais amigável com dispositivos móveis), como Executando em segundo plano, Suspenso.

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

A bateria é importante para dispositivos móveis como laptop ou dispositivo Windows 10x

Esta deve ser uma conversa simples:

A partir de 14 de janeiro, há 0 versões com suporte de Windows que não suportam UWP.

Existem versões principais do Windows que não suportam aplicativos win32 sendo implantados na loja ou de outra forma.

Win32 é uma plataforma legada. Se você estava mantendo um sistema mais antigo, com certeza, é o win32. Mas o flutter é um código novo. Há 0 motivo para escrevê-lo para uma API que é herdada e não suportada no braço, quando ela pode ser escrita para UWP e suportada em todos os lugares onde o Windows é suportado.

Mas o flutter é um código novo.

Este não é realmente o caso; Falei com pessoas interessadas em cenários de adição ao aplicativo para permitir a adoção do Flutter em aplicativos Win32 existentes.

Há 0 motivo para escrevê-lo para uma API que é herdada e não suportada no braço, quando ela pode ser escrita para UWP e suportada em todos os lugares onde o Windows é suportado.

Os comentários acima já explicaram que o suporte a esses dispositivos não é uma simples questão de Win32 vs UWP. Da mesma forma, as restrições de sandbox que são necessárias para algumas implantações ou modelos de distribuição se aplicariam ao mecanismo, que é uma grande base de código existente, não desenvolvimento de campo novo, portanto, também há complexidades.

Este argumento também ignora o fato de que existem muitas pessoas desenvolvendo novos códigos que se preocupam com a base de instalação, não com versões suportadas. A realidade é que o Windows 7 ainda é uma parte muito substancial da base de instalação, e é improvável que isso mude drasticamente no futuro imediato.

Há boas razões para oferecer suporte à UWP e, como já disse várias vezes, planejamos oferecer suporte a ela no futuro. No entanto, simplificar significativamente as compensações envolvidas para afirmar que a decisão é simples não acelerará esse processo. Novamente, qualquer pessoa que tenha uma opinião forte sobre o suporte UWP é certamente bem-vinda para contribuir com o desenvolvimento de uma incorporação de UWP.

@stuartmorgan você está ciente de alguma discussão sobre uma solução para o polegar 2 apenas restrições do winarm?

@stuartmorgan UWP pode ser usado em aplicativos win32/Winforms/WPF. As ilhas XAML são diretas e bem suportadas. O Win32 não funciona no winarm conforme descrito por @JakeSays. Portanto, seu argumento faz 0 sentido e não é justificativa para o flutter segmentar uma API herdada para o caso de incorporar o flutter em aplicativos herdados.

Mais para todos os NOVOS desenvolvimentos:

A base de instalação do Windows 7 está caindo como uma pedra. WinARM está prestes a disparar massivamente no próximo ano. O Windows 7 será < 5% do mercado Windows (menos de 50 milhões de dispositivos e nenhum dos que pagam por software) até julho nas taxas atuais) e ali mesmo pulando no fundo com o Windows XP e Vista (quase exclusivamente devido a sistemas embarcados onde eles nunca lançariam um novo aplicativo baseado em Flutter sem substituir o sistema operacional por ele devido à falta de suporte.

Suas declarações e toda essa abordagem do Win32 demonstram uma falha em entender como as versões do Windows se expandem e depois caem (antes de revisões infinitas do Windows 10, todas com UWP, portanto, esse fluxo é irrelevante):

1. Nova versão lançada, adoção muito lenta apenas em novos dispositivos e apenas no espaço do consumidor.
2. (Win 7 => 10) Os dispositivos de consumo são atualizados mais rapidamente e a participação de mercado cresce.
3. O crescimento é limitado por geeks de tecnologia que não gostam de mudanças, alegando que a nova versão é pior que a antiga, embora não seja.
4. As empresas continuam a ficar de lado à medida que a nova versão ganha participação de mercado majoritária no espaço do consumidor.
5. A Microsoft anuncia a data de aposentadoria do suporte e patches para a versão antiga do Windows, à medida que os consumidores começam a ignorar os geeks da tecnologia e percebem que a nova versão é muito melhor que a antiga. A adoção chega a cerca de 50%.
6. Negócios por pressão de usuários que gostam muito mais da nova versão; software que funciona melhor na nova versão; e um prazo iminente para a obsolescência começar a implantar a nova versão no hardware de substituição. Adoção atinge cerca de 60-65%
7. Os gerentes de TI com visão de futuro começam a fazer lançamentos controlados de novas versões, grupo por grupo.
8. O prazo está chegando a meses de distância, e o resto dos gerentes de TI simplesmente detonam, reclamam dos problemas porque não planejaram adequadamente e fecham o Windows (esses são os geeks de tecnologia de cima) por seus problemas. A participação de mercado passa de 65% para 90% em 6-8 meses, à medida que o prazo para o suporte termina.
9. Os únicos sistemas restantes são os embarcados que pagam mais por patches de segurança devido ao alto custo de substituição desses sistemas que eram hardwares projetados para o sistema operacional anterior e geralmente exigem substituição de hardware.
10. Os sistemas incorporados começam a ser invadidos, então as empresas se beneficiam do custo e começam a substituir o hardware.
11. Apenas as pessoas que usam o sistema operacional são países do 3º mundo que não podem usar mais nada e ser hackeado não é um problema.

Estamos em #8 agora. Se os desenvolvedores estão visando o Windows 7 para novos softwares, eles ignoram a história. O lançamento do Windows 10 está exatamente seguindo o lançamento do Windows 7 antes dele. Não há motivo para direcionar o número 9 porque eles não lançam grandes atualizações de software, mesmo com oscilação incremental em aplicativos win32 entre versões de hardware.

Por isso:

1. As ilhas XAML abordam seus aplicativos win32 incrementais com o argumento de vibração dentro deles. E praticamente 0% das pessoas que realmente compram (e não roubam) software estarão usando uma plataforma que não pode usar a ilha XAML até setembro deste ano, quando o desktop flutter estiver estável o suficiente para produção.
2. Não há mercado lógico para direcionar o Windows 7 para um novo aplicativo. Absolutamente ninguém com qualquer compreensão da história e como o mercado de desktops funciona entre consumidores e empresas escreveria um novo aplicativo em win32 a menos que houvesse um bloqueador absoluto em uma API (o que é altamente duvidoso que as APIs sejam amplamente espelhadas agora). E mesmo que o fizessem, ele estaria sendo executado no Windows 10 e, portanto, não haveria razão para que eles não pudessem usar as ilhas XAML para flutter nesse aplicativo win32.

Assim, a decisão de usar o win32 é ridícula e mostra uma completa falha em entender o mercado Windows. (o que não é surpreendente sair do Google, infelizmente)

@ JohnGalt1717 Posso estar enganado, mas meu problema com o winarm não tinha nada a ver com o win32. Além disso, e isso é apenas uma sugestão, mas você pode recusar um pouco a retórica. Usar termos como ignorante e fazer afirmações amplas e infundadas realmente impedem que seu ponto de vista seja transmitido.

Fazer o Flutter rodar no winarm não é um esforço trivial, como já foi apontado várias vezes neste tópico. Fazer com que o Flutter seja executado no win32 é um esforço bastante trivial, pois requer pequenas alterações para que ele flutue. Faz sentido começar com frutas fáceis (win32), especialmente considerando que a maior parte do interesse que tenho visto em relação ao Flutter e ao Windows tem sido sobre a área de trabalho. Isso tem pouco a ver com win32 vs uwp e mais a ver com o fato de que a realidade é que existem MUITOS sistemas win32 por aí AGORA.

@JakeSays WinArm não permite que aplicativos win32 sejam publicados na loja no Arm. (exceto Office) Além dos problemas de compilação.

Que parte das minhas reivindicações não é fundamentada? Os dados 100% suportam minha posição. Quando o Flutter para desktop estiver pronto para lançamento no Windows, haverá 5% ou menos de máquinas Windows que não podem executar UWP e uma tonelada em que você não pode implantar um aplicativo win32. (ou seja, todos os dispositivos ARM, incluindo Duo ou Neo ou qualquer outro que execute o Windows, e todas as versões de terceiros que estão aumentando.)

Fazer o flutter rodar em UWP que funciona em WinArm e WinX64 e WinX86 não deve ser mais difícil do que win32. Ele também oferece verificação ortográfica em caixas de texto etc., dimensionamento adequado com base em DPI sem heroísmo e melhor suporte à cultura pronto para uso. (sem mencionar que a reprodução de mídia é muito melhor e mais fácil que o win32. Ou seja, eu posso reproduzir vídeo widevine, playready, AES criptografado trivialmente com 3 linhas de código em UWP. Fazer o mesmo no win32 é um esforço enorme. Sem falar nas legendas .

Não há "frutas fáceis" com win32 versus UWP. UWP é desktop. Todo o resto é desktop legado. (além do Silverlight, obviamente) Eles estão voltando a portar UWP e suas APIs para plataformas legadas para dar suporte a empresas que não reescrevem seus aplicativos. Eles adicionaram ilhas XAML exatamente para o caso de uso descrito de adicionar Flutter a aplicativos existentes (e qualquer outra coisa UWP).

"Existem MUITOS sistemas win32 por aí AGORA".

Veja como o diagrama fica em setembro: 5% das pessoas que executam o Windows seriam bloqueadas até setembro. Desses 5%, praticamente nenhum deles compra software com base em dados históricos. Em outubro, 5% dos usuários do Windows o usarão em algum tipo de ARM e serão bloqueados no Win32.

Então escolha seu veneno.

Observe, no entanto, quando você estiver fazendo isso, que o número de pessoas bloqueadas do UWP será continuamente menor, enquanto o número de pessoas bloqueadas do Win32 aumentará continuamente. Portanto, você está efetivamente garantindo uma reescrita em 12-24 meses se for win32 em vez de UWP, tudo para um mercado moribundo que você não pode suportar efetivamente de qualquer maneira, porque a Microsoft não corrigirá bugs no Windows 7, apenas segurança atualizações para aqueles que pagam por eles. (que não usará um aplicativo com vibração de qualquer maneira)

Ele também garante que a versão do Windows do player de vídeo sempre será massivamente limitada devido ao aumento maciço necessário para que o DRM funcione no Win32, não haverá um verificador ortográfico em linha ou correção automática para aqueles que usam um teclado de toque de software , e as coisas culturais serão muito mais difíceis de acertar.

Isso é chamado de pensamento para trás.

Se você não gosta da palavra ignorante, isso não é problema meu. Se você não conhece os fatos e a história, então, por definição, você é ignorante. Neste caso prejudicialmente assim. Se você quiser usar uma palavra socialmente correta que não tenha sido banida, que assim seja, me diga o que você gostaria que eu usasse e eu farei uma busca e substituição.

Diga-me onde estou realmente errado. E mesmo que minhas suposições e projeções estejam um pouco erradas, diga-me como minha afirmação ao longo do tempo não está correta e é menos prejudicial e menos trabalhosa do que a alternativa que é muito mais trabalhosa, muito mais bugs e muito mais difícil alcançar a paridade com outras plataformas ao longo do tempo para coisas como vídeo, verificação ortográfica, etc. Não importa como você o faça, no próximo ano praticamente ninguém estará usando o Windows 7. E isso significa que o Flutter estará 100% disponível para praticamente todos em todos os situação se for feito em UWP e não em win32. Versus win32, que atende a um sistema operacional morto e bloqueia os desenvolvedores de flutter do novo e crescente mercado do WinARM.

Como exemplo, posso, neste momento, em UWP criar um player de vídeo com todas as funcionalidades do player de vídeo atual, além de legendas mais DRM em UWP em poucos minutos com excelente documentação que pode ser consumida pelo Flutter como parte do biblioteca de vídeos de vibração. Eu sei que eles estão trabalhando em legendas e DRM para o player de vídeo flutter agora. E eu não preciso saber nada além de chamadas UWP. Isso significa que é trivial fornecer funcionalidade de vídeo completa no Flutter com UWP e quase qualquer C# pode fazê-lo, o que é um grande grupo de pessoas versus aqueles que sabem usar C++, criar superfícies DirectX e criar codificadores/decodificadores/transcodificadores de mídia e ligar tudo. (sim, no win32 você não pode reproduzir muitos formatos sem bibliotecas personalizadas que são suportadas imediatamente no UWP) O esforço para criar o mesmo produto entre UWP (mesmo se escrito em C++) versus win32 é cerca de 1/100 do quantidade de tempo.

O mesmo vale para comunicações seriais, bluetooth, rastreamento de localização, etc. etc. etc. 10, então você está confiando em todos que usam a versão mais recente do Windows 10 para ter acesso a essa funcionalidade, em comparação com 100% dos usuários no Windows 10 com acesso à funcionalidade UWP para essas APIs.) Nomeie sua funcionalidade que você considera garantida com plugins para flutter para Android/iOS e você verá a mesma coisa: implementá-los é trivial em UWP versus win32 e, portanto, é muito mais provável que você os implemente em UWP do que se escrever flutter para desktop em win32, além de todas as outras questões.

@JakeSays Ainda esperando que você demonstre algo desrespeitoso (ou errado) com o que eu disse. Pelo que posso dizer, você simplesmente não gosta de uma palavra, que usei corretamente. E, mais importante, usei-o de forma abstrata, não contra você ou qualquer outra pessoa pessoalmente. Não foi um ataque homônimo.

@stuartmorgan você está ciente de alguma discussão sobre uma solução para o polegar 2 apenas restrições do winarm?

@JakeSays Não tenho acompanhado discussões no nível do compilador Dart; Não estou ciente das discussões sobre o suporte ARM, mas isso não significa que elas não estejam acontecendo. Você definitivamente deve registrar uma solicitação de recurso do Dart, se ainda não o fez.

O maior problema é a falta de suporte a OpenGL em UWP, mas isso deve ser resolvido usando ANGLE sob flutter.

A incorporação atual do Windows já usa ANGLE, e James vem experimentando o suporte UWP desde os primeiros dias de seu trabalho nessa incorporação, então isso já está em andamento.

@stuartmorgan eu farei isso.
E sim, eu tinha esquecido que o Windows Embedder está usando ANGLE.

@JohnGalt1717 , revise nosso Código de conduta . Os padrões da comunidade do Flutter exigem um discurso profissional e respeitoso, e ativamente fazendo o nosso melhor para que as pessoas se sintam bem-vindas.

Há muitas pessoas apaixonadas e talentosas trabalhando no Flutter, e muitas boas razões para buscar ou não seguir uma linha específica de desenvolvimento. Posso dizer que você é apaixonado por ter o Flutter trabalhando na UWP. Assim são os outros. Alguns também são apaixonados por fazê-lo funcionar no win32. Este é um projeto de código aberto, tudo o que é preciso para que isso aconteça são contribuições. Enquanto isso, evite sugerir que os colaboradores que trabalham em caminhos alternativos são ignorantes, estão perdendo tempo ou engajados em pensamentos inversos.

Se você não consegue ver por que suas últimas postagens não alcançam o nível de respeito mútuo que aspiramos nesta comunidade, por favor, assuma um papel menos ativo.

/cc @timsneath @Hixie

@dnfield , dado que não fiz nenhuma dessas coisas, não consigo ver seu ponto. Delineei a história factual, e um caminho que está sendo trilhado que garante que isso terá que ser reescrito, e não chegará à paridade com outras plataformas.

Se você ler com atenção, em nenhum momento eu chamei alguém de ignorante (o que literalmente significa desconhecer os fatos e não é depreciativo, em si uma declaração de fato), nem acusei qualquer indivíduo de pensar retrógrado. (Ou seja, visando uma plataforma herdada que o separa do futuro enquanto abraça um passado morto e cada vez mais irrelevante a partir de 14 de janeiro)

Portanto, não consigo entender como alguém ficaria ofendido a menos que decidisse se identificar com a generalidade que usei e não posso controlar isso.

Se você se sente ofendido por declarações não feitas sobre você, sinto muito por se sentir assim. Talvez a solução seja levar minha posição a sério e pensar sobre isso logicamente e demonstrar que você realmente levou esses fatos em consideração e não os ignora e você tem algum plano de longo prazo de como o win32 funcionará no Windows que requer o store e essa loja não permite a publicação de aplicativos de braço win32. E que a sobrecarga de usar o win32 garantirá que o Windows esteja sempre atrás de outras plataformas, pois você está reduzindo seus possíveis contribuidores em mais de 90% com essa escolha. Então ficaria claro que você não é ignorante nem retrógrado e, portanto, o que eu disse não deveria ofendê-lo.

Em vez disso, recebo "Estou ofendido (por algo que não é dirigido a mim), então você está errado". O que não é argumento em nenhum debate.

Dado que nenhuma das minhas posições foi abordada, não importa como tenha sido formulada, é claro que o flutter provavelmente não será uma solução viável no Windows e permitirá a paridade de um aplicativo escrito para iOS, Android e Windows. O que garante que minha equipe não usará o flutter como planejado em nosso próximo projeto, pois você está nos forçando a usar pelo menos 2 frameworks (e, portanto, pelo menos 2 linguagens de programação) como resultado dessa decisão, então eu poderia escolher um caminho de excelência em vez de compromisso, mesmo que haja mais sobrecarga.

James vem experimentando o suporte UWP desde os primeiros dias de seu trabalho nessa incorporação, então isso já está em andamento.

@stuartmorgan @clarkezone Existe algum exemplo publicamente disponível de execução do Flutter no UWP? Eu adoraria experimentar isso, mesmo que seja em estágios muito iniciais.

Estou trabalhando em um protótipo de suporte UWP atualmente. Ainda é muito cedo (por exemplo, ainda não vi pixels), mas tenho um plano de como fazê-lo. Dependerá de uma pequena alteração em uma alteração anterior do Angle que fiz. Eu tenho isso codificado, mas ainda não enviado ao Angle. Isenção de responsabilidade: isso não constitui um compromisso de enviar algo, ainda é uma exploração do que é possível. Vou relatar aqui quando tiver feito um progresso um pouco mais interessante (por exemplo, pixels).

Obrigado pela pronta resposta @clarkezone

Eu encontrei em seu fork FDE um branch chamado uwptest . É o que você está experimentando? Eu adoraria acompanhar suas atualizações sobre esta rota.

NP, sim, esse é o ramo FDE. A curto prazo, haverá muitos hackers temporários para provar certas teorias.

Olá, @clarkezone! Posso perguntar, seu trabalho é apoiado pela Microsoft? Podemos esperar que a Microsoft dê suporte ao Flutter para criar aplicativos do Windows? Em caso afirmativo, existem planos de disponibilizar o UI Fabric para Flutter?

Acho que, recentemente, tem havido cada vez mais interesse em construir belos softwares corporativos para melhorar o engajamento/satisfação dos funcionários. Atualmente estou trabalhando em vários desses projetos. Recentemente, lançamos um aplicativo Android baseado em Flutter para uma das quatro grandes empresas financeiras. Embora essas empresas tendam a usar C# e Xamarin para seu software interno, elas esperam maior qualidade de interface do usuário para seus aplicativos móveis de experiência no local de trabalho - nesse caso, o Flutter prova ser uma opção melhor. Ao mesmo tempo, a Microsoft produz ótimos dispositivos usados ​​no ambiente corporativo que podem executar esses aplicativos Flutter, então seria ótimo ver mais suporte da Microsoft e/ou do Google para que isso acontecesse.

Olá Lucasz. Meu trabalho não é apoiado pela MS, é feito de forma pessoal no meu tempo livre. Concorde em seus outros pontos com certeza. FWIW Eu fiz um bom progresso, eu tenho o protótipo do Flutter runner trabalhando de ponta a ponta para saída/renderização (sem entrada ainda), a grande / próxima tarefa na qual estou trabalhando atualmente é fazer tudo linkar corretamente sem puxar em user32/gdi32 etc.. esta etapa é necessária para poder ver com sucesso o protótipo executado em dispositivos não desktop, como XBOX, emulador do Windows 10x e está provando ser (outro) yak shave :-)

Por favor, adicione a Windows Store !!!!

@daniele777 é nisso que estou trabalhando;-) Atualização de status: de 84 erros de vinculador para 10

Posso ajudar ?? para melhorar o projeto ?? pode me fazer tarefa?

@daniele777 não neste momento, ainda fazendo o PoC básico funcionar. Os erros do vinculador são eliminados, mas há um problema de compilação na invocação do Dart entrando em um loop infinito no pipeline de compilação. Há também outras questões. Estarei de férias por algumas semanas, portanto, sem progresso por um pouco, quando voltar e passarmos pela fase de PoC, pode haver itens paralelizáveis ​​que relatarei aqui nessa eventualidade.

tudo bem tudo de bom!

Não vejo a hora disso chegar mais cedo. Eu tentei o flutter atual baseado em win32 no Windows. OMG, a renderização é tão pixelizada que parecia um design moderno, mas implementado usando uma estrutura de 10 anos. Não é algo que se esperaria ver em uma tela de 4k. Acostumado com as bordas suaves do texto em aplicativos UWP e aplicativos Web modernos, a renderização win32 parece extremamente datada.

@nerocui - se você estiver vendo renderização pixelizada no Windows, provavelmente é um bug diferente que não será corrigido apenas migrando para UWP. Você poderia registrar um novo problema sobre isso com etapas para reproduzir (e talvez uma captura de tela da pixelização)?

@dnfield Não é como se as imagens fossem pixeladas. É apenas que o texto e a forma são renderizados (parece) sem aceleração de hardware para que as bordas não pareçam suaves. Isso acontece com muitos programas win32 que vejo. Não há etapas de reprodução, pois é apenas o texto e o botão na página do modelo padrão.

@nerocui É porque os aplicativos win32 não têm dimensionamento de DPI adequado em comparação com o UWP. É POSSÍVEL com muito trabalho fazer a renderização de texto win32 funcionar corretamente, mas é MUITO difícil.

@ JohnGalt1717 Obrigado, esse é exatamente o meu ponto. O Flutter deveria ser sobre a construção de belos aplicativos multiplataforma, mas o win32 é a única coisa que está tornando os aplicativos feios. Isso faz com que a implementação do flutter no Windows pareça inferior às outras plataformas.

win32 é a única coisa que está tornando os aplicativos feios

Como o @dnfield disse, é extremamente improvável que esse seja o caso. A renderização de texto flutuante está sendo feita inteiramente pela Skia, em um contexto GL (adequadamente dimensionado para DPI). A criação do contexto GL com APIs UWP não alterará a renderização.

Por favor, registre um bug com capturas de tela destacando os problemas que você está descrevendo.

Pode ser tão simples quanto a incorporação ignorando um sinalizador anti-alias em algum lugar, por exemplo. Mas sem passos para reproduzir não podemos dizer.

https://github.com/flutter/flutter/issues/53308
Questão arquivada. Por favor, veja se são informações precisas/suficientes.

Eu acho que se você definir seu DPI para 150% ou pior 175% e carregar algum texto, você o verá.

Por favor, pare de postar aqui sobre detalhes de renderização; não está relacionado a esse problema, de acordo com minha explicação acima, e, portanto, fora do tópico.

pronto para publicação na loja do Windows? alguma novidade?

Não, não está pronto para publicar na loja. Pixels e entrada estão funcionando no XBOX e Windows 10x. Ainda iterando na API. Ainda resta muito trabalho.

Eu tenho pensado em uma abordagem um pouco diferente - ainda não tentei, mas posso fazer se encontrar algum tempo livre - que tal usar o Flutter para Web com o Skia WASM na área de trabalho (que pode ser apoiado pelo Blazor)? Eu posso pensar em um acesso limitado à E/S sendo uma desvantagem, mas a renderização real da interface do usuário e a manipulação de eventos devem funcionar conforme o esperado. O Windows parece ter um bom suporte para PWAs (assim como o Chrome OS), e essa abordagem pode ser mais fácil de implementar e ainda obter um bom desempenho.

@lukaszciastko não, isso será mais um Electron. Flutter deve ser renderizado em uma janela nativa do Windows (HWND), que por sua vez pode ser incorporada a qualquer tipo de aplicativo nativo do Windows (win32, Winforms, wpf).
IMHO uwp não deve ser considerado como um tipo principal de aplicativo do Windows. Mesmo MS não fez isso.

@clarkezone Mal posso esperar para ver seu trabalho no projeto para que possamos aplicativos executados no Windows

para que possamos aplicativos executados no Windows

Já é possível executar aplicativos Flutter no Windows , e já faz algum tempo. Este problema agora é especificamente sobre UWP.

Vou atualizar o título para deixar isso mais claro.

para que possamos aplicativos executados no Windows

Já é possível rodar aplicativos Flutter no Windows, e já faz algum tempo. Este problema agora é especificamente sobre UWP.

Vou atualizar o título para deixar isso mais claro.

Stuart, não vi nenhum lugar na documentação sobre como criar e executar aplicativos Flutter no Windows. Por favor, pode me dizer onde posso encontrar essa informação?

@teskalja Você tem algum documento aqui https://github.com/flutter/flutter/wiki/Desktop-shells#create
No currículo, você precisa estar no branch master e executar:
flutter config --enable-windows-desktop

No projeto você quer tentar:
flutter create . // Irá adicionar a pasta windows, cuidado com as alterações nas pastas android e ios,
flutter run -d windows

Mais especificamente, meu pensamento em torno deste dev. é esperar que haja alguma relação com o Project Union. Eu amo flutter e estou tão feliz que este SDK é uma coisa. Estou preocupado com o futuro dos aplicativos Win32 no sistema operacional Windows.

Qual é a base de conhecimento que a equipe de flutter possui?

Quando você terminar isso, isso significa que podemos implementar plug-ins Flutter em C# e usar de plug-ins quaisquer APIs, SDKs e pacotes NuGet disponíveis para aplicativos UWP?

@kinex Estou curioso para saber por que você acha que os dois estão relacionados. Adicionar suporte .net para plugins seria relativamente simples e não exigiria UWP. É meio que fora do escopo para flutter embora.

@JakeSays Do meu entendimento, o ambiente de execução (UWP neste caso) define como os plugins são criados e o que está disponível para os plugins. Então, talvez a resposta para minha pergunta seja "claro", mas não tenho certeza.

Nos plugins do Android, você pode usar Kotlin (ou Java) e quaisquer APIs, SDKs e pacotes do Android. Nos plugins do iOS, você pode usar o Swift (ou Objective-C) e quaisquer APIs, SDKs e Pods do iOS. Eu esperaria o mesmo com o UWP e isso tornaria isso realmente incrível.

Facilitar o uso de C# em plugins é algo que pretendemos fazer, mas é ortogonal ao suporte UWP.

Um executor de UWP significaria poder usar APIs específicas de UWP em plug-ins, mas meu entendimento é que muito poucas APIs são realmente específicas de UWP (por exemplo, de acordo com esta documentação "A regra geral é que um aplicativo de desktop pode chamar uma Plataforma Universal do Windows (UWP) API.")

@stuartmorgan Isso não é verdade. Eventualmente, com a reunião do projeto, isso será verdade, mas não é agora e, mesmo assim, é para software legado, não para novos aplicativos, como seria o caso do flutter. Há uma quantidade enorme de coisas que você não pode fazer sem UWP (ou seja, acessar os plugins para vários codecs de vídeo, o player de vídeo DRM, etc.) . Existem 0 sistemas operacionais suportados pela Microsoft (e, portanto, seguros) que não podem executar UWP no mercado (ou seja, direcionar o Windows 7 é ridículo e não deve ser um objetivo do Flutter, apenas o Windows 10 deve ser um alvo). Portanto, há 0 razões pelas quais isso não deve ser UWP nativa desde o primeiro dia.

Pior, todos os Windows 10 S e variantes NÃO PODEM executar aplicativos win32, então o flutter será bloqueado deles. Eles também serão bloqueados de dispositivos ARM/ARM64, a menos que sejam executados em UWP e Windows X que executa aplicativos win32 em um contêiner docker usando a Área de Trabalho Remota, terá uma experiência significativamente pior do que aplicativos UWP nativos como resultado, especialmente quando se trata de desempenho gráfico.

Portanto, se o google/flutter estivesse pensando no futuro com o suporte do Windows, seria inteiramente UWP desde o primeiro dia, o que permite C++ e .NET (a grande maioria dos desenvolvedores do Windows usa .net, não C++) E suporta todos os dispositivos Windows atuais e futuros com o melhor possível interatividade. A abordagem atual do win32 é míope e mal pesquisada (o que indica um ponto cego realmente enorme no Google, o que é preocupante, considerando os bilhões de dispositivos que executam o Windows).

Dado que o Skia já está rodando em UWP, há muito pouca razão para que este não seja o ambiente de fato e o foco de 100% dos esforços do Google no Windows. (e realmente, trabalhando com a Microsoft para obter todos os simuladores remotos Xamarin e implantação direta em dispositivos iOS no Windows funcionando também)

@JohnGalt1717 Você já fez esse argumento várias vezes nesta edição; repeti-lo não é construtivo. Se você deseja acelerar o desenvolvimento do suporte UWP, pode contribuir com ele.

@stuartmorgan Eu ficaria curioso para saber sua opinião sobre o uso de c#. Tenho algumas ideias de como fazer isso funcionar.

@kinex , na verdade, os plugins de flutter são essencialmente apenas código C que interage com o flutter por meio de uma API simples. Para escrevê-los em C# seria necessário basicamente um "plugin .net" escrito em C que hospedaria o CLR e faria a ponte entre o mundo flutter e o c#. Teoricamente, seria possível escrever plugins de flutter em java no Windows ou em qualquer idioma, desde que o ambiente de linguagem possa ser executado no sistema operacional de destino.

@JakeSays Eu arquivei https://github.com/flutter/flutter/issues/64958 com meus pensamentos atuais sobre C #, já que aparentemente nunca o arquivei aqui. Qualquer pessoa interessada em C# especificamente deve seguir esse problema.

@JakeSays Ok, obrigado pelo esclarecimento. Sem um conhecimento melhor, eu assumi algo assim: plugins C# (talvez implementados como bibliotecas .NET?) seriam carregados pelo executor UWP e o código Dart poderia chamá-los através do processo runner UWP. Nessa arquitetura imaginária, esses plug-ins C# podem acessar as mesmas APIs, SDKs e pacotes NuGet que qualquer biblioteca .NET hospedada por um aplicativo UWP.

De qualquer forma, é bom saber que existem planos em relação ao suporte a C#. Acredito que haverá mais autores de plugins (= mais plugins mais rápidos) e plugins mais estáveis ​​se C# puder ser usado em vez de C++.

@kinex você está certo em que os plugins c# teriam acesso ao conjunto completo de bibliotecas .net, bem como pacotes nuget. Quando o código c# é executado, ele está sendo executado em um ambiente .net completo (ou .net core, conforme o caso).

FFI é uma solução muito mais leve para plugins. Veja https://pub.dev/packages/win32 , por exemplo. Mas isso está muito fora do tópico para um problema que é ostensivamente sobre a construção de um runner baseado em UWP.

@timsneath Acho que ffi e plugins resolvem dois problemas diferentes. iirc existem muitas limitações com o que você pode fazer com ffi (por exemplo, é síncrono).

Novamente, arquivei #64958 para plugins C#; por favor, continue qualquer discussão sobre C#, mas não sobre UWP.

coisas legais acontecendo
alguém deveria dizer à Microsoft para contribuir aqui também

@airbus5717 o que você quer dizer? A Microsoft contribui para a discussão aqui o tempo todo.

Achei que valeria a pena compartilhar uma atualização de setembro de 2020 sobre o estado do experimento Flutter UWP em que estou trabalhando. O progresso tem sido mais lento do que eu gostaria, pois este é um projeto de tempo livre / melhor esforço no qual tenho trabalhado apenas à noite e nos fins de semana. No entanto, consegui fazer um progresso decente nos últimos seis meses e fazer alguns cenários funcionarem, a saber:

• um embedder WinRT Flutter de prova de conceito usando CoreWindow em conjunto com APIs de entrada WinRT em execução na sandbox do AppContainer: https://github.com/clarkezone/engine
• um corredor de teste Flutter UWP correspondente (apenas 115 linhas de c++!)
• usando isso, consegui publicar uma versão do pacote MSIX do Flutter Gallery com sucesso na Microsoft Store, passando nas verificações da API WAC para certificação da loja (finalmente :-))

Ainda há muito a fazer para chegar a algo pronto para produção e não tenho ideia de quanto tempo isso levará, mas certamente mostra que o Flutter UWP é viável.

Existem alguns grandes problemas restantes a serem resolvidos, como como fazer a integração de ferramentas com flutter create , como fazer o hot reload e o suporte do observatório funcionar e muito mais. Mais detalhes aqui .

No exemplo abaixo, consegui pegar a fonte do relógio Flutter Particle de https://github.com/miickel/flutter_particle_clock construí-lo no modo de lançamento visando o Windows, pegar o binário app.so resultante, empacotá-lo para UWP usando o mesmo Flutter Runner usado acima para o Flutter Gallery, publique na Microsoft Store e instale no meu XBOX: