Eu acho que é útil para as pessoas da comunidade se a equipe do Xamarin.Forms escrever mais documentos sobre a arquitetura do Xamarin.Forms, princípio de design e seu fluxo de trabalho no Github ou MS docs.
Do meu ponto de vista, eu uso o Xamarin.Forms para criar meus produtos, terei 2 opções quando encontrar os bugs, um é enviar o problema para o github e esperar que seja corrigido algum dia e o outro é enviar o problema para o github e consertei sozinho.
Depois de clonar o código-fonte e depurá-lo, é difícil entender como os recursos funcionam. Por exemplo https://github.com/xamarin/Xamarin.Forms/issues/8521
Outro exemplo é o recurso de navegação de página do Xamarin.Forms no lado do Android. É fácil entender o recurso de navegação entre as atividades no Android nativo. Mas no Xamarin.Forms parece que usa uma atividade principal para lidar com todas as páginas (talvez) (exceto os formulários nativos e a visualização nativa).

Eu acho isso ótimo.

Dividir a galeria e as vitrines para especificações / problemas etc. em projetos menores que podem ser trabalhados e exibidos com mais facilidade é uma grande vantagem no ciclo de desenvolvimento.

Uma das coisas mais problemáticas a fazer é ter várias versões diferentes nas quais bugs são corrigidos ou recursos são introduzidos e, em seguida, quando são aprimorados.
Ter várias instâncias menores ajuda muito com isso.

Outra coisa que estou pensando é em usar codespaces e, no futuro, github-codespaces, onde se pode anexar dotfiles para um problema (incluindo a versão correta do xamarin etc) e então poderíamos apenas usar codespaces ou verificar essa versão.

O melhor seria se as partes menores da galeria de controle pudessem estar disponíveis como projetos que estão disponíveis separadamente e podem apenas ser abertos em espaços de código. Posso ver muitos benefícios na combinação de aplicativos de controle menores e espaços de código.

Acho que o que estou tentando dizer é:

• Galeria de controle multiparte
• suporte para codespaces
• dotfiles em questão

Editar: adicionado terceiro ponto.

Eu concordo que tenho alguns problemas abertos por meses a fio. Eu clonei o XF, mas me perdi nele.
Portanto, um documento para vídeo apenas mostrando como a solução funciona seria ótimo.

Quanto mais .Netty isso pode ser, melhor.

1. Remova cordas mágicas e ligações não tipadas do núcleo. Não exija que ninguém contribuindo para o repo escreva uma vinculação sem tipo ou uma string sem verificação de tipo. Isso reduzirá drasticamente os bugs, tornará a correção de bugs muito mais fácil e tornará a refatoração mais fácil para que novos bugs não apareçam.
2. Não exija que os colaboradores lidem com nenhuma camada de marcação. Alguns desenvolvedores vão querer usar XAML ou CSS, mas os contribuidores que corrigem bugs não precisam se preocupar com isso. Apenas as pessoas que trabalham com linguagens de marcação, que devem ser uma camada sobre as classes .Net reais, devem se preocupar com essa camada.
3. A abordagem do renderizador deve ser estruturada de forma que a falha na implementação de uma alteração de propriedade (ou um erro de tipo ao fazer isso como acima) seja um erro de tipo.
4. Quando apropriado, deve haver uma tolerância para a implementação de alguns recursos sem vínculos específicos da plataforma, por exemplo, usando SkiaSharp ou Shapes ou objetos MAUI compostos, para implementações de plataforma cruzada confiáveis ​​que exibem o mesmo e não introduzem novos bugs.

Em um ponto, estávamos testando uma direção de ter um usuário SLN simplificado para contribuir assim

https://github.com/PureWeen/Xamarin.Forms.Sandbox

Basta fornecer um "Contributor.sln" bem direcionado, onde os contribuidores podem demonstrar uma correção ou uma API

Remova todas as galerias atuais e concentre-se apenas nas plataformas e em uma página principal

Um filtro de solução seria melhor? Você não precisa manter duas soluções.

Veremos o que tudo é desenvolvido com Filtros de Solução

AFAIK atualmente eles não funcionam no vsmac e eles são um pouco estranhos quando você tem projetos multi-direcionados. Uma vez que podemos ter suporte de primeira classe para multi-direcionamento e os projetos principais podem ser apenas no estilo SDK, então acho que a necessidade de filtros de solução não é tão alta.

A outra coisa irritante é que o VS para Windows atualmente cria todos os alvos quando você tem múltiplos alvos, enquanto o vsmac apenas cria aquele para o cabeçote da plataforma que você está executando.

A outra coisa irritante é que o VS para Windows atualmente cria todos os alvos quando você tem múltiplos alvos, enquanto o vsmac apenas cria aquele para o cabeçote da plataforma que você está executando.

Obter suporte para isso no VS para Windows seria incrível! Eu poderia me livrar de todas essas configurações extras que fiz para construir apenas a plataforma com a qual estou trabalhando no momento.

Concordo que a história atual de multi-segmentação no VS para mac é incrivelmente frustrante. Infelizmente, a segmentação múltipla é uma opção tão boa que ainda a escolho como minha abordagem e apenas sirvo como suporte técnico para outras pessoas da equipe que enfrentam problemas. É um fluxo interminável de frustração.