Maui: UX de plataforma cruzada para .NET 5

Eu gosto desta ideia. No entanto, na prática, é algo com maior probabilidade de ser tratado pela equipe do Xamarin.Forms.
Talvez a equipe do Core contribua com algumas construções de baixo nível para tornar a estrutura de UX "melhor" (como o que o CoreFxLab faz).

Edit: O WebAssembly também pode se tornar uma plataforma com suporte?

Eu gosto da ideia. Já vi pessoas (inclusive eu) sofrendo com várias tecnologias de interface do usuário para vários ambientes.

Tenho certeza de que em um futuro próximo veremos o .net core portado para dispositivos Android e iOS usando o aplicativo Nativo como um substituto para corehost . Com isso dito, os recursos de interface do usuário serão necessários.

Para bibliotecas de desenho 2D xplat (incluindo desenho acelerado), temos o Skia, por exemplo.

Em todos os cenários, acredito que o XAML-Standard será uma boa opção para se obter uma maneira padrão de "descrever" a interface do usuário junto com as diretrizes do Fluent Design.

No entanto, estou cético de que existam planos da .Net Team para investir tempo nisso mais do que apenas trazer alguns primitivos xplat System.Drawing.X de volta ...

@4creators Talvez esta discussão seja do seu interesse

@vibeeshan025 WebAssembly não é um substituto para JavaScript, então a maior parte do seu comentário não faz sentido. Você ainda precisará do JavaScript para conectar um WebAssembly ao DOM. Então, não, você não pode simplesmente compilar algo no wasm e esperar que ele substitua o que você fez antes pelo JavaScript. Não é assim que funciona. Não será uma tecnologia de interface do usuário.

Ei pessoal, só quero colocar meu 5c aqui.
System.Drawing.X é essencial para o desenvolvimento do .NET Core. (acabei de vir aqui de https://github.com/dotnet/corefx/issues/20325)

A partir da interface do usuário - pergunte aos desenvolvedores da web (front-end). Eles usam muitos truques modernos, como recarga a quente.
Eu pessoalmente gosto de como as coisas estão progredindo em torno do React/ReactNative. Seria incrível usar C# para escrever React e depois usar vários mecanismos de renderização para diferentes plataformas.

FWIW, o Mono está adotando o WebAssembly , então se funciona no Mono, funciona (ou funcionará) no WebAssembly. Essa é a ideia/entendimento atual, pelo menos.

Além disso, tenho que ecoar o sentimento sobre a probabilidade de .NET/MSFT realizar essa tarefa. Todo o seu foco/QI foi colocado no núcleo/internos/estrutura/just-get-it-working e acho que será assim por mais um ano. Mas quem sabe, eu poderia ficar (agradavelmente) surpreso.

Minha opinião sobre isso é que algum esforço externo ganhará impulso e talvez seja comprado pelo MSFT, ala Xamarin, mas mais focado na interface do usuário (em oposição ao foco em estrutura/ferramentas, que é a força principal do Xamarin). Então, algo como Avalonia ou Noesis , que oferecem sua proposta de valor por meio de canais de código aberto e pagos, respectivamente. Aliás, ambos são Mono embutidos/suportados.

O Xaml Standard mudou um pouco com o lançamento do XAML Standard (Preview) para Xamarin.Forms e atualização há muito atrasada no andamento do projeto . Há uma discussão muito interessante em PR dotnet/designs#111 sobre os objetivos do projeto que parece estar indo na direção de beneficiar esta proposta

Silverilght é ótima solução o código já existe

1. Código Silverlight de código aberto
2. Faça com que seja executado em cima do tempo de execução do dotnet core
3. use moonlight para distribuição linux
4. crie uma alternativa do dotnet core para "Electron" que vai eath o mundo (menos uso de memória + grande melhoria de desempenho + bondade do xaml)
5. compliation nativa (se um dia o projeto correto ver a luz)

Achei relevante- http://platform.uno

@gulshan Interessante, ótimo projeto, ele suporta a maior parte do recurso UWP, como eles conseguiram implementar um conjunto tão rico de recursos em um tempo muito pequeno com apenas 4 contribuidores.

@vibeeshan025 eles têm uma empresa financiando IIRC...

Outro futuro que vale a pena explorar - HTML/CSS + .net (em vez de JS/TS). Já está sendo tentado aqui-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

Depois de pesquisar, parece que o tcl/tk pode ser uma opção de gui para todas as plataformas. Não tenho certeza se tcl/tk quando no Windows invoca o material real do gdiplus, mas pode ser uma opção para trazer WPF e Winforms para Linux, Mac, Windows, Android?, iOS?, E talvez webforms? Não tenho certeza se o tcl/tk suporta esses 3 últimos ainda. Se isso acontecer, o inferno da GUI será muito mais fácil de manter com uma única base de código.

Possíveis bibliotecas de GUI para usar:

• TclBridge (não parece ser gratuito ou de código aberto)
• o Mono (provavelmente o melhor talvez)
• Águia (não tenho certeza se é bom)
• Talvez outros também.

Eu tive a ideia de usar tcl/tk do módulo tkinner do cpython.

Também não tenho certeza se o .NET Core oferece suporte ao carregamento de recursos de *.resources(resx compilado) ou mesmo de *.resx ainda. Se isso acontecer, seria ótimo.

Microsoft.DesktopUI.App atualmente v3.0.0-alpha-26921-3 está disponível com compilações diárias do Windows .NET Core SDK . Estou curioso para saber o que seria necessário para colocá-lo em funcionamento no Linux sob algumas camadas de tradução para GDC e DirectX.

Precisa muito mais do que UX de plataforma cruzada, precisa ser uma estrutura de desenvolvimento de aplicativos de plataforma cruzada.
Limitá-lo apenas ao UX é um erro. Deve ter pelo menos todas as funcionalidades do SilverLight + RIA-Services.
Quando você escreve sistemas personalizados enormes para empresas maiores que viverão por décadas, você precisa manter todas as opções em aberto, pois não tem ideia de quais requisitos serão adicionados em um ano (ou em 10 anos), portanto, um ambiente fechado e limitado como UWP nunca será considerado, o mesmo com algo rodando dentro de um navegador. Deve haver acesso completo, ilimitado e nativo a cada recurso, API e serviço nas diferentes plataformas.
E quando você desenvolve um sistema onde você escreve tanto o servidor quanto o cliente, então você não quer usar REST ou algo assim (que deve ser usado quando você escreve o servidor e outra pessoa escreve o cliente), em vez disso, deve estar no espírito do RIA, onde você define a API do servidor e, em seguida, automaticamente apenas a chama do cliente usando as mesmas (===) classes e métodos que os do servidor. Tudo precisa ser fortemente tipado. A validação de dados começa com os limites rígidos obtidos de campos no servidor SQL (ou qualquer fonte de dados que você esteja usando) e estendido por DataAnnotations, que são propagados até o cliente automaticamente (levando em consideração a localização).

Isto é o que é necessário, nada menos é aceitável:
Criar um modelo de desenvolvimento de aplicativo cliente .NET onipresente

Já se passaram 20 anos desde que o Visual Basic 6 foi lançado e não estamos nem perto da produtividade que tínhamos em 1998.A Microsoft precisa apresentar sua visão de como um sistema personalizado maior deve ser feito em um "mundo da Microsoft" e como eles trarão de volta a produtividade que tínhamos 20 anos atrás.

A Microsoft precisa se recompor e assumir a responsabilidade que eles têm. A Microsoft precisa perceber que todos os seus clientes, parceiros e desenvolvedores que investiram pesadamente na tecnologia MS por décadas estão profundamente desapontados e sua confiança na MS é muito baixa. A MS precisa começar a respeitar seus clientes, parceiros e desenvolvedores e reconstruir sua reputação e respeito, mas vendo o que estão fazendo agora com o Skype e como tratam seus clientes e usuários do Skype, tenho poucas esperanças de que isso aconteça.

E esqueça o Xamarin, a Microsoft nem mesmo o usa , e opte por um único framework de encadeamento de memória como o framework ElectronJS (baseado em Chromium, Node.js, JavaScript e CSS), do que usar o Xamarin, que eles possuem e tem controle total e que produziria código nativo real para cada plataforma.

@Bartolomeus-649

Já se passaram 20 anos desde que o Visual Basic 6 foi lançado e não estamos nem perto da produtividade que tínhamos em 1998.

E a disseminação do uso de computadores e internet, bem como a diversidade de plataformas (SO/mobilidade/fatores de forma) não é nem de longe tão baixa quanto em 1998.

O que eu sinto que você está pedindo é que "alguém resolva todos os seus problemas". As razões pelas quais essa diversidade existe são múltiplas, ou estaríamos todos usando o mesmo dispositivo com o mesmo sistema operacional. Construir uma "abstração sobre tudo" é difícil e geralmente fornece apenas o menor conjunto de recursos possível. O Xamarin ainda tem a melhor abordagem aqui, permitindo que você use APIs específicas da plataforma sempre que possível. Mas mesmo boas abstrações para aplicativos móveis podem não ajudá-lo para aplicativos de desktop de alta produtividade.

Sobre os outros pontos que você está fazendo, acho que são principalmente opiniões ou observações pessoais que se aplicam ao seu trabalho específico e não declarações geralmente aplicáveis.

Espero que tenhamos melhores experiências multiplataforma, mas não acho que será fácil ou resistirá ao teste do tempo. Mesmo que shells do tipo WebAssembly e Electron, PWAs e amigos evoluam para a solução nos próximos 5 anos, podemos estar fazendo algo completamente diferente em 20 anos (e então reclamaríamos sobre como as coisas eram fáceis em 2018 😂 ).

A Microsoft atendeu às nossas expectativas e estruturas de UX de código aberto. Agora podemos iniciar projetos comunitários para transferi-los para outras plataformas. Infelizmente, a MSFT declarou explicitamente que eles não planejam trabalhar em nenhuma porta, então parece que esse trabalho é deixado para a comunidade.

@richlander @karelz @AdamYoblick @llongley @kmahone

Minha pergunta é se nós - a comunidade poderia trabalhar em portas Linux e macOS dentro de repositórios existentes, ou seja, em ramificações separadas ou devemos criar repositórios separados para oferecer suporte a esses projetos? Essa é uma decisão muito importante, pois o uso de repositórios existentes nos permitiria integrar portas à infraestrutura MSFT CI que, de outra forma, teriam que ser configuradas do zero pela comunidade.

Existe uma razão pela qual o Xamarin.Forms/Avalonia/Platform.Uno não atende às suas necessidades? Parece que uma nova tentativa de trazer XAML multiplataforma traz pouco valor para a comunidade como um todo.

Não 4creators, mas meus 2¢/impressões:

• O Xamarin.Forms parece se concentrar principalmente em cenários móveis.
• O mesmo para Platform.Uno
• Avalonia ainda não está pronto para o horário nobre. Demasiado buggy para eu querer confiar nele. (A última vez que fui verificar, o aplicativo de demonstração nem foi construído na versão estável atual, não inspira exatamente confiança.)

Não estou dizendo que uma porta multiplataforma do WPF ou Winforms é a solução aqui. (Uma porta de plataforma cruzada compatível com a API do Winforms não é nem uma boa idéia, IMO. Sem comentários sobre o WPF.) No entanto, também não acho que as soluções existentes sejam adequadas para o desenvolvimento de aplicativos de desktop.

Bons pontos. Ainda assim, devemos nos concentrar em melhorar as soluções existentes em vez de construir outra, que custa muito mais do que a anterior.

A propósito, algum ponto de dor sobre o NoesisGUI?

comunidade poderia trabalhar em portas Linux e macOS

@4creators Crie forks que você possui e sobre os quais tem controle total.

Infraestrutura de CI

A infraestrutura de CI do .NET Core está se movendo para usar um Azure DevOps regular em vez da solução personalizada atual baseada em Jenkins. O Azure DevOps tem uma oferta gratuita para projetos de código aberto que você pode aproveitar.

Falando apenas para dotnet/winforms:

O Winforms já está usando o AzureDevOps e qualquer PR no mestre executará a compilação do PR CI automaticamente.

No entanto, tenho certeza de que qualquer trabalho deve ser feito em um garfo. Não estamos planejando conceder acesso de gravação a dotnet/winforms apenas para que as pessoas possam criar suas próprias ramificações. Com todas as contribuições públicas, isso poluiria bastante nosso repositório. :)

A propósito, algum ponto de dor sobre o NoesisGUI?

De alguma forma, o NeosisGUI foi poupado das minhas anotações que mantenho em várias estruturas de interface do usuário, então tive que olhar para ele novamente.

Eu não usei, embora eu estivesse querendo experimentar. Minha impressão é que ele serve para suportar a interface do usuário no jogo, então pode não ser adequado para ferramentas. (Embora olhando para a lista de controles, isso pode ser uma suposição ruim.) Para a interface do usuário no jogo, nossas necessidades não justificam o custo futuro. Ele também não suporta o Nintendo Switch por qualquer motivo. (Embora aparentemente seja um trabalho em andamento .)

@4creators Eu acho que esse problema está mal intitulado, devido à confusão de dois problemas.

Primeiro, permitir que estruturas de .Net UI usem .Net Core em vez de outros runtimes .Net . O WPF pode rodar no .Net Core agora, e eles podem fazer o Xamarin.iOS/Android/Mac/GTK rodar no .Net Core também. Isso tem benefícios de desempenho e manutenção em comparação com o uso do Mono ou .Net Framework.

No entanto, fazer isso não cria uma nova estrutura de interface do usuário de plataforma cruzada . E os tópicos que você faz referência e a maioria das postagens aqui são sobre a criação de uma nova estrutura de interface do usuário multiplataforma. O tempo de execução não é o principal problema aqui. No entanto, esses threads são extremamente confusos porque não abordam as dificuldades reais de implementar a interface do usuário de plataforma cruzada, que as implementações reais (Xamarin.Forms usando amplamente controles nativos e Avalonia usando renderização comum) abordaram.

É melhor trabalhar para melhorar os recursos da área de trabalho do Xamarin.Forms adicionando os controles de área de trabalho relevantes (não difíceis) ou contribuir para tornar o Avalonia estável, se você preferir. Qualquer nova plataforma (mesmo que seja baseada em uma plataforma única existente) levará anos de trabalho para obter a qualidade alfa, e a única justificativa para refazer o Xamarin.Forms & Avalonia em vez de contribuir com eles é que ambos estão fazendo isso errado.

Concordo com a última parte. No entanto, a equipe do Xamarin disse explicitamente que substituir o Mono pelo .NET Core é inviável, pois eles são otimizados para diferentes cargas de trabalho e um trabalho significativo de integração não trivial precisará ser feito.

Acho que esta questão está mal intitulada, por causa da confusão de duas questões.

@charlesroddie IMO, não realmente. A questão não é ter algum framework UX disponível na plataforma .NET Core, mas sim o UX que faz parte do ecossistema DotNet criado e mantido em conjunto com outras partes. Os planos futuros da MSFT para o ecossistema .NET são baseados em .NET Core com .NET Framework preterido por ser um componente herdado do Windows não recomendado para o desenvolvimento de novos aplicativos. Atualmente, não há planos para portar Xamarin.Forms para .NET Core com alguns motivos indicados acima por @Happypig375 e o outro motivo é a falta de decisão de como proceder com o suporte xplat em dispositivos móveis. No entanto, presumo que devido ao esforço de desenvolvimento investido no .NET Core, a futura plataforma xplat usada pela MSFT será baseada no .NET Core.

O Mono não é otimizado o suficiente para muitas cargas de trabalho, mesmo no Linux, e não há mais novos recursos importantes desenvolvidos em cima desse tempo de execução. Atualmente, a BCL é compartilhada entre Mono e .NET Core. Isso aponta para uma alta probabilidade de depreciação do Mono no futuro.

Com base nessas suposições, acho que vale a pena ter uma única plataforma UX baseada em .NET Core como parte de seu ecossistema. Portanto, o título do problema é exatamente como deveria ser, pois não peço uma estrutura UX que é xplat e padrão CLI baseado, mas uma estrutura UX que faz parte do ecossistema .NET Core projetado e suportado pela equipe DotNet.

O .Net Standard garante que diferentes tempos de execução da interface do usuário possam fazer parte do mesmo ecossistema sem problemas. Embora o .Net Core tenha vantagens em relação a outros tempos de execução, que podem eventualmente ser depreciados, não é necessário vincular o tempo de execução para encontrar a abordagem correta para a interface do usuário de plataforma cruzada. Só complica demais a questão.

É ir longe demais dizer que uma plataforma UX é "baseada" em um tempo de execução específico. @Happypig375 Atualmente não está nos planos do Xamarin mudar para o .Net Core (os planos são, em vez disso, deixar o Mono se tornar mais semelhante ao .Net Core compartilhando código). Mas não deve ser mais difícil do que mover o WPF para o .Net Core.

(BTW, não é verdade que o Mono não tenha novos recursos, pois está sendo atualizado para suportar .Net Standard 2.1, e o trabalho atual em webassembly está sendo feito em Mono em vez de .Net Core. Mas isso é um aparte, pois este trabalho pode ser portado para .Net Core.)

Roteiro do WinUI 3.0 - precisamos da sua opinião!

Parece que esta proposta de desenvolvimento pode abrir novas possibilidades de xplat uma vez que todos os componentes necessários são de código aberto.

Eles deveriam considerar chamar de MicrosoftUI 1.0 se for esse o caso, @4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

Acredito que esse problema seja resolvido por este repositório.