Eu estava no seu nível de frustração há alguns anos, quando comecei a portar aplicativos WPF. Portanto, certamente entendo seus sentimentos. Houve algum progresso desde então e, como você disse, a equipe WinUI está realmente tentando no seu fim.

Do meu ponto de vista, há um problema de design fundamental que não podemos contornar: o WinRT era tecnicamente deficiente porque precisa interoperar diretamente com C ++ e JavaScript ( aqui está um exemplo, e outro ). Realmente não combina bem com muitos dos conceitos de alto nível, como os genéricos. É claro que também há um grande benefício com essa arquitetura: agora, todo o Windows pode compartilhar as mesmas APIs do WinRT.

O WinRT também foi feito pela equipe do Windows sob Sinofsky, acredito, o que significa, sim, eles viviam em seu próprio mundo e não tinham experiência em trabalhar com o ecossistema de desenvolvedores de usuário final existente. Acabamos com uma API de 'mínimo denominador comum' com a qual desenvolvedores nativos e gerenciados não gostam de trabalhar. Esta é fundamentalmente uma das principais razões pelas quais o Windows Phone morreu - os desenvolvedores não podiam desenvolver / portar aplicativos facilmente. Sem Apps, não havia clientes. A Microsoft aprendeu essa lição.

Portanto, perdemos várias das vantagens do código gerenciado com as quais nos acostumamos ao longo dos anos. Definitivamente, ainda parece um passo atrás do WPF - encontro bugs e recursos incompletos o tempo todo. Eu acho que # 1830 nunca aconteceria na época do WPF. Ainda temos que avançar de alguma forma.

WinUI 3.0 é claramente um passo na direção certa para tentar consertar isso pelo menos no front-end. Porém, eu preferiria que a Microsoft implementasse um processo de desenvolvimento mais robusto e mais testes antes de lançar novos controles ... Eu sei que o desenvolvimento agora consiste em empurrar mudanças, consertar depois. Embora isso possa funcionar para aplicativos, não é um bom padrão para uma plataforma onde, uma vez que as coisas estão definidas, é muito difícil alterá-las mais tarde. (TreeView, NumberBox, etc ... tem tantos problemas no primeiro lançamento que nunca iria sair pela porta, muito menos estágios de planejamento, 15 anos atrás).

É triste para mim ver o que antes era a plataforma de IU mais poderosa do WPF evoluir para isso. Mas a Microsoft está agora, lenta mas seguramente, ouvindo feedback e consertando as coisas. Entende-se que há muito mais trabalho a fazer.

Você acha que os usuários farão o acima com prazer? Não, eles não vão - na verdade, 79,8% não o fazem (meus dados do AppCenter confirmam isso). Deixando-me com usuários que não usam meu aplicativo ou apenas fazendo com que meu aplicativo pareça inferior a outros aplicativos nativos.

Talvez você não esteja considerando o fato de que seus usuários estão realmente parando para pensar: "espere, eu realmente quero conceder a este aplicativo acesso a toda a minha unidade?" Esse é um aviso de luz vermelha para pessoas não familiarizadas com o aplicativo / desenvolvedor / empresa.

Você está culpando o processo pelo qual os usuários precisam passar para conceder ao seu aplicativo acesso a toda a unidade pela baixa taxa de retenção. Talvez você deva reconsiderar sua "necessidade" de broadFileSystemAccess em primeiro lugar e, em vez disso, peça aos usuários que selecionem manualmente as pastas às quais eles se sentem confortáveis ​​para fornecer acesso.

Para sua informação, se eu quisesse testar um aplicativo e depois da instalação fosse como "ei, me dê permissão para acessar tudo, em qualquer lugar", eu correria também.

Quando você solicita broadSystemAccess, seu aplicativo, por padrão, não tem esse acesso.

Obviamente ... Você apenas fez uma solicitação, seus usuários realmente têm que conceder acesso a você se eles se sentirem à vontade para fazê-lo.

Além disso, com base apenas no título desrespeitoso que quebra o Código de Conduta de Código Aberto da @jevansaks @jesbis

Uma última coisa a acrescentar. Acho que Rich Lander disse isso melhor no .NET Community Standup de 15 de janeiro (começando @ 1:12:40).

@verelpode Você

Quando você solicita broadSystemAccess, seu aplicativo, por padrão, não tem esse acesso.

Obviamente ... Você apenas fez uma solicitação, seus usuários realmente têm que conceder acesso a você se eles se sentirem à vontade para fazê-lo.

Esse não é o problema: pelo menos no Android / iOS, você recebe essas perguntas enquanto seu aplicativo tenta acessar o HDD, e ele não fecha , como no nosso caso.

Seu aplicativo não fecharia se você apresentasse seletor (es) de arquivo que permite ao usuário escolher a que deseja dar acesso ao seu aplicativo.

Em vez disso, você quer tudo, está reclamando de uma pequena etapa extra que os usuários precisam dar e está culpando sua taxa de retenção nessa etapa.

Além disso, com base apenas no título desrespeitoso que quebra o Código de Conduta de Código Aberto da @jevansaks @jesbis

É muito difícil ser respeitoso, quando estou quase enlouquecendo. Para não dizer - eu já disse isso antes, não há lugar para escrever sobre o WinRT. Eu ficaria feliz em usar um tom diferente, se eu realmente pudesse escrever, e alguém estaria ouvindo. Todos os clamores acima simplesmente não deveriam existir - o WinRT deve ser maduro o suficiente . Ainda não...

Onde a comunidade pode realmente falar com a equipe do WinRT? Tem alguém ouvindo?

Seu aplicativo não fecharia se você apresentasse seletor (es) de arquivo que permite ao usuário escolher a que deseja dar acesso ao seu aplicativo.

Em vez disso, você quer tudo, está reclamando de uma pequena etapa extra que os usuários precisam dar e está culpando sua taxa de retenção nessa etapa.

Meu aplicativo permite que os usuários editem fotos e vídeos, e quero que o usuário visualize facilmente o que quiser, sem usar um seletor de arquivos antigo. Então, sim, é muito importante que eu tenha acesso a todo o HDD. E não, essas pastas virtuais "Imagens" e "Vídeos" são o que a Microsoft acha que os usuários mantêm com suas fotos e vídeos. Isso não é realidade.

Já disse isso antes, não há lugar para escrever sobre o WinRT.

Como seus links indicam, você já está reclamando do WinRT nos fóruns de perguntas e respostas da UWP, que é para onde você foi direcionado.

Então, postando aqui, parece que você quer apenas um público maior, ao invés de realmente realizar qualquer coisa (já que a equipe WinUI não funciona no WinRT).

Como seus links indicam, você já está reclamando do WinRT nos fóruns de perguntas e respostas da UWP, que é para onde você foi direcionado.

No entanto, não há resolução para nenhum dos meus problemas. Em uma sessão de perguntas e respostas, você faz perguntas e recebe respostas. Mas você realmente não pode sugerir nada para mudar (infelizmente).

Meu aplicativo permite que os usuários editem fotos e vídeos, e quero que o usuário visualize facilmente o que quiser, sem usar um seletor de arquivos antigo. Então, sim, é muito importante que eu tenha acesso a todo o HDD.

Não, não é. Seus usuários não têm fotos e vídeos por toda a unidade, eles estão em locais específicos que podem não ser as pastas especiais.

Faça com que os usuários escolham essas pastas uma vez, então você sempre poderá ter acesso por meio da FutureAccessList . Não faça com que eles lhe dêem acesso a todos os seus arquivos, e então eles não fugirão.

@kmgallahan Claro, o tom pode ser

Acho que podemos manter esse tipo de discussão profissional, sabendo que se originam da frustração e de muito interesse investido no sucesso do ecossistema de desenvolvimento.

Claro, o tom pode ser desacelerado um pouco, mas todos nós já ficamos frustrados antes. É ainda mais frustrante pensar que questões óbvias não estão sendo tratadas.

Obrigado :)

Não, não é. Seus usuários não têm fotos e vídeos por toda a unidade, eles estão em locais específicos que podem não ser as pastas especiais.

Faça com que os usuários escolham essas pastas uma vez, então você sempre poderá ter acesso por meio da FutureAccessList . Não faça com que eles lhe dêem acesso a todos os seus arquivos, e então eles não fugirão.

Claramente, eles não estão nesses locais específicos ....

Claro, posso usar essa FutureAccessList e fazer com que os usuários se lembrem de onde guardam suas fotos / vídeos, porque todos nós sabemos onde guardamos todas as nossas fotos / vídeos, certo?

Em vez de (o que meu aplicativo faz) visualizar bem as pastas e mostrar as pastas onde você tem fotos / vídeos.

Algumas notas:

Obrigado @jtorjo por reservar um tempo para escrever sobre suas experiências e comentários, e também por seu tempo na página de perguntas e respostas .

Como @robloo e @kmgallahan mencionaram, a maior parte disso não está diretamente relacionado ao WinUI e você pode estar forçando um pouco o código de conduta 🙂

No entanto, também reconhecemos que o envolvimento no site de perguntas e respostas e no Hub de feedback pode ser melhor quando se trata de diferentes áreas da plataforma de desenvolvedor do Windows. Estamos realmente tentando melhorar isso, mas entendo que é frustrante encontrar um bom lugar para fornecer feedback e ver se algo está acontecendo.

Por exemplo, realmente vemos tudo o que vem por meio do Centro de Feedback, mas não há uma boa maneira de responder ou continuar uma discussão. Portanto, contanto que permaneça construtivo e esteja relacionado ao UX / desenvolvimento do aplicativo do Windows, então estamos bem em discutir alguns comentários gerais da plataforma aqui se um tópico não se encaixa bem em outro lugar.

Pelo que vale a pena, esses tópicos também recebem séria atenção interna. Entramos em contato com alguns especialistas em WinRT hoje para ver se há alguma atualização nessas áreas que possamos compartilhar, já que você resumiu ordenadamente alguns dos principais problemas com a plataforma geral e ferramentas.

Para desenvolvimento de aplicativos de desktop: WinUI 3 é uma grande parte de nosso esforço para separar a plataforma de desenvolvedor do Windows para remover essas barreiras de interoperabilidade e facilitar a adoção incremental de WinUI e UWP. Sabemos que precisamos habilitar melhor os aplicativos de desktop com UX moderna sem exigir todas as restrições atuais. Temos muitos especialistas, incluindo alguns dos principais criadores do WPF, trabalhando nisso.

Em particular, estamos gastando muito tempo nas ilhas Xaml e no WinUI para aplicativos de desktop e estamos ansiosos para a próxima etapa, que lançará uma prévia disso para as pessoas experimentarem ainda este ano. Estamos tentando ser mais orientados para o feedback e transparentes e isso deve ficar mais fácil à medida que movemos coisas como a plataforma Xaml completa (ou seja, WinUI 3) para o código aberto.

Se as pessoas estiverem interessadas no estado atual dos planos de desktop, também poderíamos entrar em mais detalhes em uma das ligações mensais da comunidade - sinta-se à vontade para sugerir tópicos aqui:

WinUI Community Call (22 de janeiro de 2020) # 1857

Olá @jesbis ,

Obrigado por olhar para os meus problemas!

Como @robloo e @kmgallahan mencionaram, a maior parte disso não está diretamente relacionado ao WinUI e você pode estar forçando um pouco o código de conduta 🙂

Sim, sinto muito por isso, só senti que estava ficando louco. As coisas que mencionei aqui são críticas - estou realmente apaixonado por isso, já que encontrei todas as opções acima. Todos eles cobram um preço enorme, muitas pessoas simplesmente desistem de tentar.

No entanto, também reconhecemos que o envolvimento no site de perguntas e respostas e no Hub de feedback pode ser melhor quando se trata de diferentes áreas da plataforma de desenvolvedor do Windows. Estamos realmente tentando melhorar isso, mas entendo que é frustrante encontrar um bom lugar para fornecer feedback e ver se algo está acontecendo.

Totalmente de acordo. Como uma observação lateral, eu na verdade tentei relatar o broadSystemAccess no Feedback Hub, e depois de fornecer todos os detalhes e gastar cerca de 15 minutos nele, acabei de alguma forma provavelmente pressionando uma tecla de atalho que era o equivalente a "Voltar" - portanto, Perdi todo o meu trabalho (sem desfazer, nenhum texto sendo copiado para a área de transferência, nada). Claramente, eu estava insanamente frustrado e simplesmente desisti.

Pelo que vale a pena, esses tópicos também recebem séria atenção interna. Entramos em contato com alguns especialistas em WinRT hoje para ver se há alguma atualização nessas áreas que possamos compartilhar, já que você resumiu ordenadamente alguns dos principais problemas com a plataforma geral e ferramentas.

Legal!

Para desenvolvimento de aplicativos de desktop: WinUI 3 é uma grande parte de nosso esforço para separar a plataforma de desenvolvedor do Windows para remover essas barreiras de interoperabilidade e facilitar a adoção incremental de WinUI e UWP. Sabemos que precisamos habilitar melhor os aplicativos de desktop com UX moderna sem exigir todas as restrições atuais. Temos muitos especialistas, incluindo alguns dos principais criadores do WPF, trabalhando nisso.

Fantástico! Estou definitivamente ansioso por isso. É muito provável que eu atualize meu aplicativo assim que isso for feito, mas até então estou preso com muitos problemas.

Se as pessoas estiverem interessadas no estado atual dos planos de desktop, também poderíamos entrar em mais detalhes em uma das ligações mensais da comunidade - sinta-se à vontade para sugerir tópicos aqui:

WinUI Community Call (22 de janeiro de 2020) # 1857

Posso sugerir os tópicos do WinRT que mencionei aqui?

Obrigado novamente!

Por exemplo, realmente vemos tudo o que vem por meio do Centro de Feedback, mas não há uma boa maneira de responder ou continuar uma discussão. Portanto, contanto que permaneça construtivo e esteja relacionado ao desenvolvimento de aplicativos, estamos bem em receber alguns comentários gerais da plataforma aqui se um tópico atualmente não se encaixa bem em outro lugar.

@jesbis
Esta é uma grande notícia! Muito obrigado à equipe do WinUI por mostrar essa flexibilidade e tentar mitigar os problemas (percebidos) do sistema de feedback do WinRT, embora não seja necessário!

@kmgallahan

Acho que Rich Lander disse isso melhor no .NET Community Standup de 15 de janeiro (começando @ 1:12:40).

Então Rich Lander diz que prefere pessoas com um pouco de agressividade, mas boas ao mesmo tempo. Acho que um dos maiores problemas da sociedade é que muitas pessoas são tão "educadas" que seu comportamento se torna extremista e passa a ser desrespeitoso e rude, enquanto superficialmente parece "educado". Pessoas muito "educadas" falam indiretamente e vagamente, e isso torna sua comunicação difícil de entender e fácil de interpretar mal. Pessoas muito "educadas" são desrespeitosas e rudes porque estão efetivamente dizendo o equivalente a:

"Eu acredito que você não pode lidar com a verdade direta, portanto, vou lidar com você com luvas grossas de algodão fofo e embalá-lo em plástico-bolha e falar com você muito educadamente, indiretamente e vagamente, porque se eu tratá-lo como um adulto maduro e expressar minhas opiniões honestas, você vai pirar e explodir e enlouquecer. Você é uma pessoa muito frágil, delicada e imatura, portanto, devo falar com você de forma extremamente educada e indireta, porque você pode não lidar com a verdade direta. "

Dessa forma, quando a chamada "polidez" é levada ao extremo (como muitas pessoas fazem), ela se torna desrespeitosa e rude, embora ainda pareça ser "educada". Em outras palavras, a incompreensão de polidez e respeito é um dos maiores problemas da sociedade. Muitas pessoas não percebem que a polidez excessiva é desrespeitosa e faz com que projetos falhem, etc. Este problema de polidez falsa causa mais uma falha de comunicação a cada segundo de cada hora de cada dia em algum lugar do mundo - isso acontece constantemente - e na sociedade sofre muito por causa disso.

@jtorjo
Aqui está a origem do problema:

Repetição do erro catastrófico da Nokia

O WinRT / UWP acidentalmente repetiu o mesmo erro que a Nokia, BlackBerry, Apple em um ponto e outras empresas. A história da Nokia: a Nokia era um gigante de muito sucesso, mas mais tarde a Nokia percebeu que havia ficado para trás na tecnologia de smartphones. Para resolver esse problema, eles precisavam priorizar a realização de uma série de versões aprimoradas de seu sistema preexistente. Em vez de fazer isso, eles tentaram mudar para um novo sistema e isso os matou. Literalmente os matou - o Nokia Mobile foi forçado a aceitar ser comprado pela Microsoft.

Então você esperaria que a Microsoft aprendesse com o erro da Nokia e não repetisse o mesmo problema. Infelizmente, a Microsoft repetiu o mesmo erro da Nokia. A Microsoft embarcou no WinRT / UWP em vez de produzir novas versões do WPF e do .NET Framework. Adivinha o que aconteceu? O mesmo desastre catastrófico da Nokia: ele os matou. O Windows Mobile está morto e foi cancelado por executivos da Microsoft. Assim, infelizmente, a Microsoft não aprendeu com o erro catastrófico da Nokia. Agora todos os smartphones estão executando Android ou Apple em vez de WinRT / UWP, portanto, WinRT / UWP foi uma falha catastrófica que fez a Microsoft perder completamente seu lugar em uma indústria de smartphones multibilionária. O WinRT / UWP causou perdas de bilhões de dólares para a Microsoft.

O BlackBerry cometeu o mesmo erro que a Nokia e a Microsoft. O BlackBerry foi muito bem-sucedido, mas depois o BlackBerry percebeu que havia ficado para trás na tecnologia de smartphones. Para resolver esse problema, eles precisavam priorizar a realização de uma série de versões aprimoradas de seu sistema preexistente. Em vez de fazer isso, eles tentaram mudar para um novo sistema. O BlackBerry usava originalmente o BlackBerry OS e, em seguida, por volta do ano de 2013, eles mudaram para o sistema QNX. O que aconteceu? O mesmo que WinRT e Nokia. Isso os matou. Em 2016, a BlackBerry anunciou que deixaria de projetar seus próprios telefones.

Isso também aconteceu com a Apple em um ponto no passado. A Apple quase entrou em colapso e teve muita sorte em sobreviver. Alguns anos depois, a Apple finalmente fez uma forte recuperação por meio de smartphones. Sorte de estar vivo após o erro catastrófico.

Quebrando mudanças

A Microsoft afirma que não poderia continuar o desenvolvimento do WPF; não poderia usar WPF para smartphones / tablets por causa de alterações significativas, mas esse é um caso de medo extremo de alterações significativas. Sim, é aconselhável ter muito cuidado em relação às mudanças bruscas, mas se for levado ao extremo, mata projetos e empresas. A realidade é que mudanças significativas podem de fato ser introduzidas. A Microsoft poderia ter lançado o "WPF 5" com suporte para smartphones / tablets / telas sensíveis ao toque, e anunciou que inclui mudanças importantes, mas nenhum desenvolvedor é forçado a atualizá-lo imediatamente. Os aplicativos preexistentes não quebram porque continuam a ser executados com o WPF 4 até que o desenvolvedor do aplicativo esteja confortável e pronto para mudar para o WPF 5. Assim, as alterações interrompidas não causam caos ou falhas.

É o mesmo princípio de uma nova versão de um pacote NuGet que inclui alterações significativas. Seu aplicativo não falha repentinamente quando a nova versão do pacote é lançada. Seus usuários continuam a usar seu aplicativo e não têm problemas porque seu aplicativo continua a usar a versão antiga do pacote até que você se sinta confortável e pronto para atualizar seu aplicativo para usar a versão mais recente do pacote NuGet. Assim, mudanças significativas podem ser introduzidas.

Reversão do ponto de vista sobre o código gerenciado

A Microsoft disse que o código gerenciado oferece vantagens excelentes, e isso é absolutamente verdadeiro em minha experiência com o uso de código gerenciado e não gerenciado. Comecei minha carreira escrevendo código não gerenciado. Posteriormente, testei as afirmações da Microsoft e mudei para o código gerenciado e experimentei melhorias excelentes em produtividade e confiabilidade. Mais tarde, a Microsoft estranhamente inverteu seu ponto de vista e produziu o WinRT com base em código não gerenciado e o antigo Component Object Model (COM) do ano de 1993, e o uso excessivo do Win16 (também conhecido como Win32). A base do WinRT é a tecnologia que está décadas desatualizada: código nativo, COM e Win16, também conhecido como Win32. Não deve ser surpresa que a maioria dos desenvolvedores de aplicativos relutou em mudar para WinRT / UWP.

O Android é agora o líder de mercado. A Microsoft pode aprender com o Android. Os aplicativos Android normalmente são escritos usando código gerenciado. Embora eu não goste de Java e prefira usar C #, devo dizer que Java é muito melhor do que Win16 e COM nativos.

Vários membros da equipe da Microsoft ainda continuam dizendo "nativos" como se isso fosse uma coisa boa. Comecei minha carreira com "nativo" e sei por anos de experiência que "nativo" é uma coisa ruim. Legiões de desenvolvedores Android também sabem que nativo é uma coisa ruim, mas muitos membros da equipe UWP dizem que é ótimo. Para usar as palavras de @jtorjo , a equipe do WinRT estava e está "fora de sintonia com a realidade". A equipe do WinRT continua a se comportar como se o WinRT fosse um sucesso, apesar do fato de ter falhado catastroficamente e do Windows Mobile já ter sido cancelado pelos executivos da Microsoft.

Tenho que repetir essas palavras continuamente: WinRT / UWP foi uma falha catastrófica. Fui forçado a repetir essas palavras porque a equipe do WinRT está "fora da realidade" no sentido de que se recusam a reconhecer que o WinRT / UWP foi uma falha catastrófica e que a Microsoft não deve continuar a repetir os mesmos erros de WinRT como se nada tivesse acontecido.

Por exemplo, atualmente DataGrid é escrito em código gerenciado moderno, mas as equipes do WinUI querem reescrever o DataGrid para usar código "nativo" e acredita que isso é um "upgrade" quando na realidade é um downgrade e regressão às práticas que estão décadas desatualizados. Em geral, o WinRT / UWP é atormentado por confusões entre práticas de engenharia de software modernas e obsoletas. Assim, o uso de @jtorjo das palavras _ "fora de contato com a realidade" _ poderia ser interpretado como indelicado, mas acredito que é uma descrição precisa, mesmo que não tenha sido a melhor escolha de palavras.

Para outro exemplo de _ "fora de contato com a realidade" _, olhe para o design de WebView2 - é como fazer uma viagem no tempo de volta ao início da minha carreira, décadas atrás, quando usamos conceitos obsoletos como HRESULT vez do tratamento moderno de exceções. É surpreendente ver o WebView2 sendo lançado como um novo projeto no ano de 2020, mas ainda usando técnicas antigas como HRESULT e LPCWSTR . O design do WebView2 está fora de sintonia com as práticas modernas de engenharia de software.

Então, seguindo as linhas do que Rich Lander disse, minha mensagem anterior demonstra meu respeito pela equipe WinUI, porque se eu desrespeitasse a equipe WinUI, sempre seria muito educado com a equipe ou não diria nada. Se eu desrespeitasse a equipe, descartaria e ignoraria o WinUI: não me incomodaria em escrever nenhuma mensagem - eu veria o WinUI como "sem esperança" e uma "causa perdida" e não daria nenhum feedback em tudo. O facto de dar um feedback detalhado demonstra que respeito a equipa. Muitas pessoas não dão feedback - isso é desrespeitoso para a equipe. É desrespeitoso ver a equipe como tão desesperada que não vale a pena escrever nenhum feedback para ela.

Se você estivesse no tribunal, diria educadamente "Meritíssimo" ao juiz, mesmo que o odeie. Polidez extrema é grosseria. Os juízes interpretam "Sua Excelência" como respeito, mas na verdade é desrespeito.

A Microsoft embarcou no WinRT / UWP em vez de produzir novas versões do WPF e do .NET Framework. ...

Concordou. Estou desenvolvendo UWP há alguns meses ... Existem algumas limitações, mas fiz o meu melhor para ser "zen" sobre isso e, mais ou menos, seguir em frente. Porém, quanto mais eu trabalhava, mais percebia - que as limitações eram, na verdade, WinRT, não UWP.

A questão é que isso é o que temos e, claramente, precisamos seguir em frente com isso. Em minha opinião, isso deveria ser:

1. UWP precisa ocultar o máximo possível o fato de que usa WinRT e
2. O WinRT deve se esforçar para remover tantas limitações (desnecessárias) quanto possível
3. O foco principal deve ser Desktop e, em seguida, as outras plataformas (Hololens, xbox etc)

(ps O fato de que, para um arquivo, para obter suas propriedades, eu preciso chamar uma função assíncrona, ainda me faz estremecer)

Reversão do ponto de vista sobre o código gerenciado

Por que precisamos lidar com COM no WinRT está realmente além da minha compreensão. Parece que eles embrulharam algum código DCOM antigo ou algo assim, mas isso deve ser 100% escondido dos usuários do WinRT.
O fato de que precisamos estar cientes do COM é realmente muito ruim. Isso, mais uma vez, deve ficar o máximo possível, escondido de mim, usuário da (s) biblioteca (s).

[editar mais tarde] Agora, pensando bem, precisaríamos pelo menos do COM para lidar com o DirectX. Ainda assim, deve ser o mais escondido possível dos usuários das bibliotecas.

Vários membros da equipe da Microsoft ainda continuam dizendo "nativos" como se isso fosse uma coisa boa.

Native, no contexto de "compilar para .net nativo", acho que é uma coisa boa, no entanto, não gosto de suas limitações. Meu projeto falha ao compilar para .net nativo, porque ele usa outra lib que eu portei para UWP, e usa algumas APIs que os poderosos caras da Store acreditam ser "inaceitáveis". A biblioteca em questão é https://github.com/naudio/NAudio - uma biblioteca incrivelmente poderosa. Só por esse motivo, eu simplesmente disse - NÃO vou publicar meu aplicativo na loja da MS.

Para outro exemplo de _ "fora de contato com a realidade" _, olhe para o design de WebView2 - é como fazer uma viagem no tempo de volta ao início da minha carreira

Não tenho 100% de certeza, mas provavelmente você está certo. Eu sei que WebView é dito ser um invólucro sobre um controle Win32, e eu sei de um bug estranho, que os links do WebView não funcionavam quando o WebView estava em cima de outro controle.

Olá @robloo ,

Desculpe pelo atraso na resposta

Eu estava no seu nível de frustração há alguns anos, quando comecei a portar aplicativos WPF. Portanto, certamente entendo seus sentimentos. Houve algum progresso desde então e, como você disse, a equipe WinUI está realmente tentando no seu fim.

Sim, concordo totalmente. Em 2016-2017, eu nem tocaria no UWP.

Do meu ponto de vista, há um problema de design fundamental que não podemos contornar: o WinRT era tecnicamente deficiente porque precisa interagir diretamente com C ++ e JavaScript ( aqui

Isso é muito triste, para dizer o mínimo ... Por que razão queremos a interoperabilidade JS?

... é um exemplo e outro ). Realmente não combina bem com muitos dos conceitos de alto nível, como os genéricos. É claro que também há um grande benefício com essa arquitetura: agora, todo o Windows pode compartilhar as mesmas APIs do WinRT.

Há muitas coisas que eu odeio no WinRT - o que é mais uma na lista?

O fato de eu precisar saber disso é ruim. Na verdade, eu precisava criar esses 2 pequenos projetos, e foi tudo tentativa e erro, para entender o que eu realmente tenho permissão para usar.

Portanto, perdemos várias das vantagens do código gerenciado com as quais nos acostumamos ao longo dos anos. Definitivamente, ainda parece um passo atrás do WPF - encontro bugs e recursos incompletos o tempo todo. Eu acho que # 1830 nunca aconteceria na época do WPF. Ainda temos que avançar de alguma forma.

Sim, nós fazemos ...

WinUI 3.0 é claramente um passo na direção certa para tentar consertar isso pelo menos no front-end. Porém, eu preferiria que a Microsoft implementasse um processo de desenvolvimento mais robusto e mais testes antes de lançar novos controles ... [...]

100% aprovado.

É triste para mim ver o que antes era a plataforma de IU mais poderosa do WPF evoluir para isso. Mas a Microsoft está agora, lenta mas seguramente, ouvindo feedback e consertando as coisas. Entende-se que há muito mais trabalho a fazer.

Sim, há pessoas claramente incríveis no MS que estão ouvindo. Vamos torcer para que possamos reverter isso ...

A API de consulta de arquivos está além de lenta

Aparentemente, alguém encontrou uma solução alternativa para isso. Claramente, é realmente muito triste que tenha demorado tanto - e essa não é a maneira preferida de pesquisar arquivos, mas pelo menos funciona.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

Então, muito obrigado a @ duke7553 !

@jtorjo Fico feliz em ajudar!

Acho essa discussão muito interessante e, na verdade, muito relevante para o futuro da IU do Windows. Isso porque o WinUI não está sentado no vácuo. Todo esse repositório tem muito pouco valor, a menos que seja útil para a criação de aplicativos executados em algo diferente do WinRT / UWP. WinUI 3.0 não poderia vir em breve.

Temos uma visão e um roteiro para a IU no Windows, mas isso fica bem no topo da pilha e não há visão do que está sob a camada de superfície:
O WinUI está com boa aparência? SIM
Você pode fazer aplicativos modernos e bonitos no Windows agora (JAN2020)? NÃO
Você pode fazer um bom aplicativo com UWP? DE JEITO NENHUM!

Não podemos realmente seguir em frente sem abordar o elefante na sala: o fato mencionado anteriormente de que o WinRT e o UWP foram um fracasso total, não apenas em termos de negócios, mas também tecnologicamente. Estou pessoalmente entre a contagem de corpos. Parei de desenvolver meu projeto de hobby quando não conseguia descobrir como tocar um som quando meu aplicativo perdia o foco. Trivial. As coisas triviais têm que ser tão difíceis quanto no UWP? Você pode chamar uma plataforma de ótima quando coisas triviais são impossivelmente difíceis? WinUI é apenas parte de uma plataforma, não é?

Outro elefante na sala. Se alguém perguntar: Eu quero fazer um novo programa do Windows, qual é a melhor maneira de fazer isso? Não há uma resposta direta em JAN2020! Se você tentar colocar UWP na resposta, terá um péssimo momento. (Há um único comentário, postagem de blog, vídeo do YouTube em que alguém disse: Fiz um ótimo aplicativo com UWP e gostei do processo? Todos sabemos que não. Ninguém está escrevendo sobre como fazer aplicativos com UWP, literalmente não não existe na Internet). WPF? Sem controles modernos - tecnologia morta, não é uma boa ideia (ainda melhor do que UWP, no entanto). A resposta honesta seria: tentar o elétron, talvez? VSCode é feito com isso, então você sabe que pode fazer um bom aplicativo com ele.

E essa ideia de que você pode fazer um aplicativo para windows com qualquer idioma que quiser é apenas uma desculpa. Estamos em uma situação em que você pode fazer um aplicativo UWP muito ruim com qualquer idioma que desejar. Não há pelo menos UMA maneira excelente de fazer isso.

A coisa navie mencionada antes no tópico? Totalmente de acordo. Visual Studio - O próprio Juggernaut (UI) é feito com código gerenciado - WPF. É ótimo, até fantástico. Embora nem mesmo a Microsoft possa fazer aplicativos OK com esse suposto código nativo superion. Eu vejo um comportamento inesperado todos os dias com OneNote, Weather e até Iniciar / Pesquisar / Barra de tarefas. Parece instável e às vezes o foco não funciona como deveria.

Este é um tópico rico e importante. Muito relevante para WinUI e, infelizmente, não há lugar melhor para falar sobre isso. Esses tópicos precisam ser tratados de forma aberta pela Microsoft.

Temos uma visão e um roteiro para a IU no Windows, mas isso fica bem no topo da pilha e não há visão do que está sob a camada de superfície:
O WinUI está com boa aparência? SIM

Sim, ele é!

Você pode fazer aplicativos modernos e bonitos no Windows agora (JAN2020)? NÃO

Eu acredito que você pode - mas é realmente muito difícil. Coisas triviais são incrivelmente difíceis de fazer (sou a prova viva de que é possível, mas você precisa de nervos de aço com certeza):

• na interface do usuário, haverá problemas, mas geralmente você vai pegar o jeito
• na frente de "qualquer outra coisa", as coisas estão bem sombrias.
• lidar com arquivos em UWP é um inferno, devido à API StorageFile / Folder, que, para dizer o mínimo, odeio de todo o coração

Não podemos realmente seguir em frente sem abordar o elefante na sala: o fato mencionado anteriormente de que o WinRT e o UWP foram um fracasso total, não apenas em termos de negócios, mas também tecnologicamente. Estou pessoalmente entre a contagem de corpos. Parei de desenvolver meu projeto de hobby quando não conseguia descobrir como tocar um som quando meu aplicativo perdia o foco. Trivial. Fazer coisas triviais tem que ser tão difícil quanto

Concordou. Na verdade, a reprodução de sons do sistema, que no WPF é como SystemSounds.Beep.Play() , não está disponível no UWP.

Basicamente, não há biblioteca de som no UWP, devido às "ótimas" restrições do WinRT, o que basicamente significa - você não pode importar nenhuma função de DLLs que sejam win32. Basicamente, toda biblioteca decente não pode ser portada para UWP. Sem bibliotecas, sem aplicativos.

Na "biblioteca de som" no UWP, a naudio deu o seu melhor para trabalhar no UWP. Claramente, caiu plano. Eu fiz um fork, removi muitos #ifdefs e agora funciona para minhas necessidades. Nunca poderei publicar meu aplicativo na MS Store, nem quero fazer isso.

O melhor passo na direção certa, na minha opinião, é o MS

1. Finalmente, concentre-se no Windows Desktop PRIMEIRO . Pare de ir atrás de mil plataformas, como Hololens, Xbox e similares. Claro, haverá pessoas querendo desenvolver para essas plataformas, mas a porcentagem é minúscula.
2. Remova todas as restrições da API - para que as pessoas possam realmente compilar libs para UWP
3. Depois de solicitar broadSystemAccess, apenas dê e pare de ser tão superprotetor.
4. Depois de solicitar broadSystemAccess, permita System.IO em todo o HDD
5. Facilite a distribuição fora da loja MS (+ corrija o problema do "Novo Certificado")

Outro elefante na sala. Se alguém perguntar: Eu quero fazer um novo programa do Windows, qual é a melhor maneira de fazer isso? Não há uma resposta direta em JAN2020! Se você tentar colocar UWP na resposta, terá um péssimo momento. (Há um único comentário, postagem de blog, vídeo do YouTube em que alguém disse: Fiz um ótimo aplicativo com UWP e gostei do processo? Todos sabemos que não. Ninguém está escrevendo sobre como fazer aplicativos com UWP, literalmente não não existe na Internet). WPF? Sem controles modernos -

Sim, concordo - encontrar bons recursos no UWP é quase zero. Muitos problemas, você apenas terá que resolver e consertar por conta própria.

tecnologia morta, não é uma boa ideia (ainda melhor do que UWP, no entanto). A resposta honesta seria: tentar o elétron, talvez? VSCode é feito com isso, então você sabe que pode fazer um bom aplicativo com ele.

Sobre o WPF, só tenho palavras de elogio. Eu tenho desenvolvido por alguns anos. e embora a curva de aprendizado seja bastante íngreme, quando você pega o jeito, é incrível! Eu encontrei alguns bugs graves, que eu sabia que nunca seriam corrigidos, mas é isso.

Fui forçado a mudar para UWP, pois para tornar meu aplicativo rápido o suficiente, eu precisava usar o win2d. Há coisas que estão faltando no UWP quando se trata de IU (como, no momento em que comecei a portar, não havia uma maneira nativa de definir Cursor para um controle), mas no geral, sempre encontrei soluções alternativas .

A coisa navie mencionada antes no tópico? Totalmente de acordo. Visual Studio - O próprio Juggernaut (UI) é feito com código gerenciado - WPF. É ótimo, até fantástico. Embora nem mesmo a Microsoft

Claramente, eu aposto meu a **, que você não poderia criar Visual Studio em UWP por minha vida - e não estou falando sobre a interface do usuário, você poderia igualar e exceder a interface do Visual Studio, mas o resto. ...

Este é um tópico rico e importante. Muito relevante para WinUI e, infelizmente, não há lugar melhor para falar sobre isso. Esses tópicos precisam ser tratados de forma aberta pela Microsoft.

100% concordou!

Você pode fazer aplicativos modernos e bonitos no Windows agora (JAN2020)? NÃO

Eu acredito que você pode - mas é realmente muito difícil. Coisas triviais são incrivelmente difíceis de fazer (sou a prova viva de que é possível, mas você precisa de nervos de aço com certeza):

• na interface do usuário, haverá problemas, mas geralmente você vai pegar o jeito
• na frente de "qualquer outra coisa", as coisas estão bem sombrias.
• lidar com arquivos em UWP é um inferno, devido à API StorageFile / Folder, que, para dizer o mínimo, odeio de todo o coração

Somos como cães espancados aqui. Na verdade, é muito difícil fazer um novo aplicativo moderno para a área de trabalho do Windows! Não deveria haver pelo menos uma maneira excelente de fazer aplicativos? Ao acessar a Microsoft Store no Windows e tentar rolar a categoria de aplicativos, você não encontrará nenhum aplicativo decente feito com UWP. A propósito, eu não posso verificar sozinho porque ...

Sim, senhoras e senhores app "moderno", "nativo". Como o Windows agora é praticamente gratuito, a principal fonte de monetização não deveria ser o aplicativo mais sólido do sistema, mas estou divagando. Na verdade, você não precisa pesquisar o aplicativo para saber com que tecnologia ele foi feito. Basta uma olhada e você saberá se foi construído com UWP. Não há projetos comerciais sérios construídos com UWP, e o que é construído com ele é ... você sabe ...

E isso é porque é tããão difícil. Window10 é a maior plataforma depois da Internet e do Android !!! Mas ninguém está fazendo aplicativos para ele com as ferramentas que supostamente foram feitas para esse fim! Apenas contemple isso. É mais fácil construir um aplicativo Electron para 3 sistemas operacionais do que apenas para Windows com UWP!

Está tudo bem para nós, cães derrotados, que apenas queremos construir aplicativos de desktop do Windows para exigir ferramentas excelentes? Eu digo sem desculpas que sim! Mas tudo o que temos é o silêncio do rádio da Microsoft. Quem quer ouvir um conto de fadas de que seu aplicativo pode funcionar no Holo Lens, no Windows Phone ou no Xbox? Ninguém. Depois de 5 anos, nenhum aplicativo comercial funcionou em 2 dessas plataformas prometidas para UWP. (Principalmente porque essas plataformas não saem). Novamente, pondere isso! A melhor coisa que aconteceu conosco é que o WinUI está sendo portado de volta para o win32 antigo.

Eu amo a área de trabalho do Windows, aprendi a programar fazendo C # em WinForms e WPF. E foi fácil e excelente para um novato como eu. Hoje estou salivando olhando para aqueles controles suculentos no WinUI, mas alguém precisa esclarecer o quadro geral da plataforma. Precisamos de uma mensagem clara sobre liderança prática em tecnologia e não sobre as aspirações de mercado de alguns executivos de negócios da MS.

Oi,
Estou um pouco atrasado para essa discussão, mas queria dar minha humilde opinião de qualquer maneira.
Sobre aplicativos comerciais UWP: Um que me vem à mente é o Adobe XD. Este é UWP e parece muito maduro e completo.
Minhas próprias experiências com UWP, sendo um desenvolvedor .Net por 13 anos: é claro que você pode criar um aplicativo com boa aparência e desempenho com ele. Mas ... não é uma experiência bonita. Estamos no processo de criação de um aplicativo médico e muitas das coisas já mencionadas aqui e em outros lugares também foram encontradas por nós:

• API de arquivo lento inacreditável
• Muito lento "tempo F5". Portanto, iniciar a depuração para criar / iniciar o aplicativo para experimentar algo é pelo menos 10 vezes mais lento do que no WPF. (pense em aproximadamente 2 minutos em um livro de superfície 2)
• Em geral, sendo restringido pela sandbox.
  Estes são apenas os do topo da minha cabeça. No final, quando o XamlIslands foi lançado, optamos por hospedar nossa UI UWP completa em uma janela WPF, tendo um núcleo .net rápido por trás de tudo. Eu não acho que muitas pessoas usaram o XamlIsland nessa magnitude (concluindo a partir dos problemas do github / PRs que criamos). No entanto, essa tecnologia também tem algumas limitações muito sérias. Apenas como exemplo, o tempo de compilação aumenta ainda mais. Perdendo a capacidade de edição ao vivo do Xaml. Criando um instalador para um aplicativo WPF / XamlIsland / UWP sério? Isso dói. etc ...
  Então, para resumir, a criação de belos aplicativos UWP pode ser feita. Mas é tão improdutivo e lento. E restrito.
  Assim como muitos outros, estamos aguardando com entusiasmo o lançamento e o amadurecimento do WinUI 3, sendo capaz de ter um frontend "UWP" e um backend .net core (ou .net 5 ;-)) sem truques.

@jasonwurzel esses são alguns pontos muito bons

• A API do arquivo é lenta, mas por enquanto @ duke7553 postou uma solução alternativa em # 1465 (comentário)
  Isso é verdade, mas não sabíamos sobre isso naquela época. Redundante para dizer, é de alguma forma louco implementar esta solução alternativa apenas para obter I / O de arquivo rápido ...
• O tempo F5 torna as coisas mais lentas e acho que pode usar algumas melhorias
• Estou curioso para saber quais limitações você encontrou ao tentar desenvolver um aplicativo UWP regular em vez de seguir a rota das ilhas xaml? Estou trabalhando em alguns aplicativos agora e consegui resolver quaisquer limitações incluindo processos Win32, mas entendo que nem sempre é a maneira ideal de criar um aplicativo.
  Acho que no final foi a soma dos obstáculos que encontramos, sem dúvida alguns dos quais poderiam ter sido resolvidos com processos externos. Em nenhuma ordem particular:
• Observando a bandeja do CD / portas USB para a mídia inserida
• observar algum diretório escolhido pelo usuário em qualquer lugar do PC local e fazer com que o App / Windows se lembre do direito de acesso ao atualizar
• exigindo broadFileSystemAccess, obtendo a exceção, abrindo a página de configurações do Windows correspondente, o usuário verifica a alternância do aplicativo, boom App fecha sem aviso, sem chance de intervir.
• mesmo domínio: permitir que o usuário escolha um diretório sem ter que abrir um FolderPicker no estilo do Windows (não, não queremos estilizar nosso aplicativo de tela cheia de uma maneira agradável e simplificada e, em seguida, a caixa de diálogo do Windows salta na cara do usuário)
• Problema do ovo e da galinha: disponibilidade / suporte de pacotes de nuget (muito mais pessoas ainda estão usando WPF, então encontrar soluções para pequenos problemas é muito mais rápido)
• controlando o local de instalação

@AndrewPawlowski Estou surpreso que você diria isso quando há muitos aplicativos UWP excelentes que são modernos e bonitos, incluindo alguns que são de código aberto no GitHub.
Só porque você desistiu de criar um aplicativo porque não descobriu como fazer algo não significa que uma plataforma falhou, significa que seu aplicativo falhou. Se você olhar ao redor, verá muitos desenvolvedores que trabalharam duro e criaram alguns aplicativos realmente bons, incluindo aplicativos que continuam a reproduzir sons quando o aplicativo perde o foco.

Não estou dizendo que não seja possível, mas é muito, muito difícil. E não estou falando de um aplicativo simples do tipo "bloco de notas", estou falando de um aplicativo muito complexo que lida com interface do usuário / edição de vídeo / edição de som / carregamento / salvamento de muitas coisas no disco / (tentando e não conseguindo ) lançar coisas (e por favor não me fale sobre a API fullTrust). Estou falando de um aplicativo de mais de 50-100 mil linhas de código.

Isso é muuuuito mais difícil.

E o fato de que você pode reproduzir um som quando o aplicativo perde o foco - ninguém está dizendo que você não pode, mas deve ser muuuito mais fácil do que agora.

Você pergunta se há alguém que goste do processo de desenvolvimento de aplicativos UWP e a resposta é que existem muitos e nos últimos meses tenho recebido muitos pedidos de outros desenvolvedores para ajudar em seus aplicativos, a plataforma está claramente ganhando interesse.

Concordo, é por isso que realmente comecei a portar meu aplicativo para UWP. Mas tem sido uma estrada muito acidentada, e ainda é.

Você também afirma que não há ninguém escrevendo sobre o desenvolvimento de aplicativos UWP e devo dizer que isso é simplesmente falso, @rudyhuyn , Martin Zikmund são apenas dois exemplos de desenvolvedores que escrevem sobre UWP, mas existem muitos outros também.

Eu concordo totalmente, mas compare isso com as pessoas que escrevem sobre wpf. É uma gota na água.

Basta fazer uma pesquisa simples no github - "c # wpf" (3701 resultados) x "c # uwp" (337 resultados).
Tenho certeza que se você pesquisasse a mesma coisa e filtrasse por "número de commits> 500" (o que meio que significa - o usuário continuou com o projeto) -> você encontraria uma bela imagem do dimmer.

Isso mostra que você pode criar aplicativos bonitos em 2020 e também aplicativos UWP modernos, e que muitas de suas declarações não são precisas.

Eu imploro para discordar - para poder desenvolver um aplicativo UWP complexo e ficar feliz fazendo isso -> estamos muito longe disso.

• Estou curioso para saber quais limitações você encontrou ao tentar desenvolver um aplicativo UWP regular em vez de seguir a rota das ilhas xaml? Estou trabalhando em alguns aplicativos agora e consegui resolver quaisquer limitações incluindo processos Win32, mas entendo que nem sempre é a maneira ideal de criar um aplicativo.

No meu final, tentei usar win2d usando as ilhas Xaml em setembro - não funcionou nem um pouco. Tentei alguns dos exemplos do MS e eles também não funcionaram. Nesse ponto, percebi que realmente preciso portar meu aplicativo para UWP, caso contrário, isso nunca funcionará.

Quanto a um teste mais recente - https://github.com/microsoft/Win2D/issues/731

• Muito lento "tempo F5". Portanto, iniciar a depuração para criar / iniciar o aplicativo para experimentar algo é pelo menos 10 vezes mais lento do que no WPF. (pense em aproximadamente 2 minutos em um livro de superfície 2)

Ai sim! Eu nem mencionei isso, mas sim, é incrivelmente lento. Eu consegui contornar isso ajustando quais projetos eu compilo e quais não - e dependendo de qual parte do aplicativo estou trabalhando, isso é decente ou horrível (e por decente, quero dizer, cerca de 10-15 segundos na maioria das vezes)

• Em geral, sendo restringido pela sandbox.

Oh sim :)

• A API do arquivo é lenta, mas por enquanto @ duke7553 postou uma solução alternativa em # 1465 (comentário)

Concordo, mas pense em quanto tempo levou para alguém encontrar essa solução alternativa - que existia claramente, mas estava profundamente enterrada nos documentos. E agora, provavelmente muito poucas pessoas estão cientes disso (incluindo eu).

Se você fizer uma pesquisa no Google, não encontrará nenhuma postagem que mostre essa solução alternativa, então provavelmente levará alguns meses até que a maioria dos desenvolvedores perceba.

@jasonwurzel

Assim como muitos outros, estamos aguardando com entusiasmo o lançamento e o amadurecimento do WinUI 3, sendo capaz de ter um frontend "UWP" e um backend .net core (ou .net 5 ;-)) sem truques.

Só quero salientar que a MS disse que, assim que o .NET 5 for lançado, você poderá usá-lo em seus projetos UWP perfeitamente. Não há necessidade de nenhum "truque" ou uma situação como o .NET Core 3.x. Aqui está a postagem do anúncio do .NET 5 novamente: https://devblogs.microsoft.com/dotnet/introducing-net-5/

sim, é a isso que me referia 👍

Eu acho que a palavra "completamente" em _ "completamente fora de contato com a realidade" _ era injusta e imprecisa, mas @jtorjo estava muito frustrado por razões compreensíveis. Se a Microsoft estivesse completamente fora da realidade, a equipe do WinUI não estaria trabalhando para separar o WinUI do UWP. No geral, a equipe WinUI parece estar mais em contato do que outros departamentos da UWP / WinRT. Acho que uma descrição precisa seria a de que existe algum grau de ausência de contato em algumas equipes atualmente.

Significado de uma GUI de lista com colunas

Embora a equipe WinUI seja provavelmente a equipe com melhor desempenho de todas as equipes relacionadas ao UWP / WinRT, acho que alguns erros ainda foram cometidos no gerenciamento de projetos do WinUI. Uma GUI de lista com colunas (como DataGrid ) é um recurso mainstream essencial que todo cliente usa diariamente (como no Windows Explorer e vários outros exemplos, como Spotify etc). Desde o início do WinRT, já se passaram 8 anos sem suporte oficial para uma GUI de lista com colunas! Acho esta situação chocante. Por essa e outras razões, digo que o UWP ainda é uma versão alfa hoje (ainda não está completo em recursos, portanto, não é um verdadeiro beta). Não é surpreendente que a maioria dos desenvolvedores de aplicativos nunca levasse o UWP a sério e, portanto, o Windows Mobile acabou sendo cancelado.

Uma versão oficial do DataGrid do WinUI está atrasada nos últimos 8 anos. DataGrid ficou atrasado no minuto em que o WinRT 1.0 foi lançado porque a Microsoft nunca deveria ter iniciado um novo sistema (como expliquei em minha mensagem anterior sobre o Nokia etc). 8 anos sem fundamentos, 8 anos de atraso e agora a equipe WinUI quer deixar o DataGrid ainda mais atrasado, perdendo ainda mais tempo fazendo o downgrade para código nativo. Por vários motivos, é difícil levar a sério o UWP e confiar nele.

C ++ / CX foi recentemente substituído por C ++ / WinRT

Aqui está outro exemplo de estar "fora de contato com a realidade":
Obviamente, o software precisa ser escrito de maneira sã (quero dizer "sã" como terminologia, não um insulto como "Você está louco"). "Sano" como terminologia significa que você não deve usar magia negra complicada e obscura para realizar uma tarefa simples e direta.
C ++ / CX foi recentemente substituído por C ++ / WinRT. C ++ / WinRT usa o chamado _ "padrão de modelo curiosamente recorrente" _ para chamada de função via envio estático. Esse é um design realmente terrível porque não é um design lógico porque é um caso de usar magia negra complicada e obscura para realizar uma tarefa simples e direta. Além disso, o CLR / C # já resolveu esse problema décadas atrás, então por que a equipe do WinRT ainda está brincando e perdendo tempo com tópicos muito antigos e primitivos que já foram resolvidos décadas atrás? Por que a equipe do WinRT está reinventando a roda?

Eu naveguei pelo NOVO código-fonte do C ++ / WinRT e minha impressão dele é que é um software de qualidade terrivelmente baixa, mas a equipe do WinRT o vê como maravilhosamente avançado. Assim, "fora de contato com a realidade" é uma descrição precisa.

O sistema de arquivos UWP ainda é a versão alfa

@jtorjo e outras pessoas mencionaram os problemas de desempenho das APIs do sistema de arquivos da UWP. O desempenho está abaixo do nível necessário para descrevê-lo como uma versão beta com recursos completos. Outro motivo pelo qual a API UWP FS ainda é uma versão alfa é a falta de capacidade de mover uma pasta. 25 anos atrás, o Windows 95 tinha a capacidade de mover pastas, mas o UWP ainda não tem essa capacidade fundamental. De certa forma, o Windows 95 é mais poderoso que o UWP. De várias maneiras, o WPF e o .NET Framework ainda são mais poderosos do que o UWP. A Microsoft esperava que os desenvolvedores de aplicativos levassem o UWP a sério, mas isso era muito irracional (ou "fora da realidade") porque a Microsoft nunca progrediu o UWP do estágio alfa para o beta.

O Windows partiu do pressuposto de que dispositivos móveis como o "App Dev" eram o mercado em expansão e eram modernos porque tinham segurança e bateria em seu coração.

Eles foram expulsos do mercado de telefonia móvel devido às forças de mercado. Dispositivos como Hololens e Xbox estão tentando remover o suporte herdado do Win32 - para tornar o desenvolvimento mais simples para eles e uma base de código de sistema operacional mais enxuta e com melhor desempenho.

Essas apostas não valeram totalmente a pena, mas os ideais para um modelo moderno de entrega e segurança de aplicativos são objetivos louváveis.

Então, depois de um exame profundo, a Microsoft decidiu separar a estrutura de aplicativo moderna da estrutura de interface do usuário.

WinUI 3.0 deve ser o melhor dos dois mundos, permitindo acesso à maioria das APIs modernas que se beneficiam da projeção de linguagem, padrões de codificação modernos e familiaridade móvel. Mas também permitindo que os aplicativos usem os tempos de execução Win32 e .NET menos seguros, porém mais poderosos.

É claro que contar com o acesso Win32 irá restringir as plataformas em que eles serão executados - e quem sabe para onde o mercado se moverá nos próximos anos.

Eu sugeriria, em vez de criticar os mesmos velhos motivos e reclamações - esta comunidade seja usada para perguntar o que os desenvolvedores querem daqui para frente, e não para colocar a culpa ou reclamar de uma forma que não leve o projeto adiante.

@mdtauk escreveu:

Eles foram expulsos do mercado de telefonia móvel devido às forças de mercado.

Vários membros da equipe UWP / WinRT gostariam de acreditar muito nessa explicação, para se _sentir_ melhor sobre o que aconteceu. Não acredito nessa explicação. Acredito que o UWP falhou devido a:

1. Má gestão, e
2. Falha em resolver o problema de desenvolvedores de aplicativos adiarem perpetuamente as versões UWP de seus aplicativos devido à impressão de que UWP não estava pronto e ainda não está pronto para o horário nobre, e
3. Uso excessivo de técnicas antigas e improdutivas de engenharia de software e
4. Falha em ganhar a confiança da maioria dos desenvolvedores de aplicativos e
5. Coisas que faziam a UWP parecer boba, como promover o uso de JavaScript em vez de Java, significando a falha em reconhecer a diferença entre uma linguagem de script e uma linguagem de programação.

Infelizmente, considerando que o gerenciamento incorreto é o principal motivo da falha do UWP, é irônico que o UWP seja escrito em código não gerenciado porque a palavra "não gerenciado" realmente resume o motivo da falha: Gerenciamento incorreto do código-fonte e do gerenciamento do projeto.

@jtorjo escreveu:

Nativo, no contexto de "compilar para .net nativo", acho que é uma coisa boa

Eu concordo. A diferença está na geração automática versus manual de código nativo. Quando o código nativo é produzido automaticamente por um compilador ou ferramenta, geralmente é uma coisa boa, enquanto se o código-fonte nativo for escrito manualmente , a produtividade, o conjunto de recursos e a confiabilidade sofrem substancialmente.

Se você olhar para o período de desenvolvimento do WPF versus o período de desenvolvimento do WinUI, o desenvolvimento do WPF foi muito mais rápido (produtividade muito melhor), apesar do fato de que o WinUI deveria ter sido mais fácil / rápido de desenvolver do que o WPF porque o WinUI reutiliza muitos dos mesmos conceitos que já foram criados para o WPF. Infelizmente, a Microsoft optou por se envolver no uso excessivo de antigas técnicas de engenharia de software que contradiziam seu próprio ponto de vista anterior e sabotavam sua própria produtividade e levavam os desenvolvedores de aplicativos a adiar perpetuamente o desenvolvimento de aplicativos UWP.

O que pode ser feito agora para resolver os erros do passado? Pare de repetir os mesmos erros que levaram ao fracasso do UWP. Não continue como se nada de ruim tivesse acontecido. Usarei DataGrid como exemplo aqui: Adicione novos recursos a DataGrid vez de atrasar ainda mais o DataGrid. Não torne o DataGrid ainda mais atrasado do que 8 anos fazendo uma reescrita / conversão manual inútil para código nativo.

Os usuários finais não se importam se o DataGrid é escrito em código gerenciado ou não gerenciado, e eles não sabem o que esses termos significam, portanto, o que é muito mais importante e sensato é mantê-lo com o código gerenciado como está e melhorar o funcionalidade / recursos do DataGrid. A quantidade de código nativo escrito manualmente em UWP já é uma situação desastrosa, então por que tornar a situação ainda pior escrevendo ainda mais código nativo e ainda mais código obsoleto baseado em Win16 / 32 e COM?

Eu entendo que você não pode simplesmente jogar fora todo o código obsoleto, mas você PODE parar de tornar a situação pior do que já está. Ou seja, pare de escrever códigos nativos ainda mais antigos. Faça uma política de que, de agora em diante, todos os novos códigos / projetos sejam escritos usando técnicas modernas de engenharia de software. Não faça downgrade de código gerenciado preexistente, como DataGrid etc.

O sistema de arquivos UWP ainda é a versão alfa
@jtorjo e outras pessoas mencionaram os problemas de desempenho das APIs do sistema de arquivos da UWP. O desempenho está abaixo do nível necessário para descrevê-lo como uma versão beta com recursos completos. [...]

Eu mencionei isso antes e vou mencionar novamente - a API StorageFolder / StorageFile é uma das piores APIs que já vi. Estamos no meio do século 21, e eu preciso perguntar "oh, por favor, posso ter acesso a isso? E àquilo? E depois adicioná-los ao grande FuturesAccessList?"

E eu preciso pedir de forma assíncrona as propriedades básicas, como o tamanho do arquivo? Eu não me importo com o motivo que isso poderia ter, mas está muuuuito fora de contato com a realidade agora.

Essas apostas não valeram totalmente a pena, mas os ideais para um modelo moderno de entrega e segurança de aplicativos são objetivos louváveis.

Eu concordo totalmente...

[....] É claro que contar com o acesso Win32 irá restringir as plataformas em que eles rodarão - e quem sabe para onde o mercado se moverá nos próximos anos. [...]

Eu concordo plenamente, mas, pensar muito no futuro também pode ser uma dor ...
Com isso quero dizer - se você restringir o acesso ao Win32 desde o início, portar bibliotecas será praticamente um "impossível", então você não terá um presente, muito menos um futuro.

Ao permitir-nos também usar o código Win32, sim, podemos não ser capazes de portar para outra plataforma (futura), mas pelo menos teremos o código para hoje. E amanhã, será outro dia, e quando chegarmos lá, descobriremos uma maneira de portar nosso código se realmente quisermos.

Mas faço o que me é permitido escolher e entenderei os riscos.

Eu sugeriria, em vez de criticar os mesmos velhos motivos e reclamações - esta comunidade seja usada para perguntar o que os desenvolvedores querem daqui para frente, e não para colocar a culpa ou reclamar de uma forma que não leve o projeto adiante.

Não tenho certeza se isso foi direcionado a mim ou algo assim, eu não sou um falante nativo de inglês. Dito isso, eu definitivamente quero que esse projeto avance, mas acho que é importante abordarmos alguns problemas que nos impedem de implantar - hoje.

Eu sugeriria, em vez de criticar os mesmos velhos motivos e reclamações - esta comunidade seja usada para perguntar o que os desenvolvedores querem daqui para frente, e não para colocar a culpa ou reclamar de uma forma que não leve o projeto adiante.

Não tenho certeza se isso foi direcionado a mim ou algo assim, eu não sou um falante nativo de inglês. Dito isso, eu definitivamente quero que esse projeto avance, mas acho que é importante abordarmos alguns problemas que nos impedem de implantar - hoje.

Não estou almejando ninguém, mas o título da discussão é um pouco negativo e as pessoas não tendem a responder e abordar questões legítimas, se estiverem envoltas em insultos e acusações.

Além disso, agora sabemos que uma estrutura de aplicativo Win32 / .NET virá com o WinUI 3.0 - não faz muito sentido ainda criticá-los por serem WinRT apenas no passado. 😁

@jtorjo

Estamos no meio do século 21, e eu preciso perguntar "oh, por favor, posso ter acesso a isso? E àquilo? E depois adicioná-los ao grande FuturesAccessList?"

O fato de os aplicativos terem que perguntar ao usuário é, em minha opinião, um passo na direção certa. O fato de que, ao contrário dos aplicativos Winforms e WPF, o aplicativo não pode simplesmente escanear todos os meus arquivos e eu tenho o controle sobre quais pastas ele pode acessar é muito importante em termos de segurança. Se você acha que é ruim limitarmos os recursos que os aplicativos podem acessar para proteger o usuário, acho que essa é a sua opinião, mas não quero que todos os aplicativos façam o que querem com meus arquivos.

E eu preciso pedir de forma assíncrona as propriedades básicas, como o tamanho do arquivo? Eu não me importo com o motivo que isso poderia ter, mas está muuuuito fora de contato com a realidade agora.

Eu acho que o raciocínio era que ele não deveria bloquear o thread de interface do usuário, já que a pior coisa que pode acontecer de um ponto de UX é que o aplicativo não responde mais porque o desenvolvedor esquece que as operações do disco podem demorar um pouco. Usando o await, você pode contornar o problema e força você a desbloquear o thread de interface do usuário em algum ponto. (Pelo menos é assim que eu entendo async await).

Como @mdtauk corretamente apontou, o título da discussão é realmente um pouco negativo e, em vez de ficar repetindo as mesmas velhas reclamações, essas discussões devem ser usadas para apresentar ideias para resolver tais questões.

Acho que todos devemos ter em mente a adesão ao código de conduta de fonte aberta da Microsoft, manter uma discussão profissional e ser respeitoso com todos, independentemente de estarem presentes ou não.

https://opensource.microsoft.com/codeofconduct/

O fato de os aplicativos terem que perguntar ao usuário é, em minha opinião, um passo na direção certa. O fato de que, ao contrário dos aplicativos Winforms e WPF, o aplicativo não pode simplesmente escanear todos os meus arquivos e eu tenho o controle sobre quais pastas ele pode acessar é muito importante em termos de segurança. Se você acha que é ruim limitarmos os recursos que os aplicativos podem acessar para proteger o usuário, acho que essa é a sua opinião, mas não quero que todos os aplicativos façam o que querem com meus arquivos.

Portanto, começamos com uma grande desvantagem em relação aos aplicativos WPF. Isso é uma coisa - a outra coisa é

1. Já estou perguntando isso na instalação.
2. Mesmo que os usuários não prestem atenção, o Windows pode mostrar novamente ao usuário "Este aplicativo deseja acessar seus arquivos" e o usuário pode dizer Sim / Não. Eu ficaria totalmente bem com isso. No entanto, isso está muito longe do que está acontecendo.

E eu preciso pedir de forma assíncrona as propriedades básicas, como o tamanho do arquivo? Eu não me importo com o motivo que isso poderia ter, mas está muuuuito fora de contato com a realidade agora.

Eu acho que o raciocínio era que ele não deveria bloquear o thread de IU, já que a pior coisa que pode acontecer a partir de um ponto de UX é que o aplicativo não responde mais porque o desenvolvedor se esquece

O tamanho do arquivo deve ser pré-buscado (igual a data do último acesso / data da última gravação) - é tão importante que deve ser buscado previamente quando você faz uma consulta por arquivos.

Como @mdtauk corretamente apontou, o título da discussão é realmente um pouco negativo e, em vez de ficar repetindo as mesmas velhas reclamações, essas discussões devem ser usadas para apresentar ideias para resolver tais questões.

Eu quero totalmente que isso seja resolvido, nada mais.

Acho que todos devemos ter em mente a adesão ao código de conduta de fonte aberta da Microsoft, manter uma discussão profissional e ser respeitoso com todos, independentemente de estarem presentes ou não.

Essa discussão não teria acontecido aqui, se realmente tivéssemos um lugar para fazer essas perguntas e para que o WinRT pudesse ouvir o feedback em outro lugar.

Não estou almejando ninguém, mas o título da discussão é um pouco negativo e as pessoas não tendem a responder e abordar questões legítimas, se estiverem envoltas em insultos e acusações.

Concordo que é um pouco negativo, mais uma vez, isso não teria acontecido, se houvesse outro lugar para dar feedback sobre os problemas do WinRT.

Além disso, agora sabemos que uma estrutura de aplicativo Win32 / .NET virá com o WinUI 3.0 - não faz muito sentido ainda criticá-los por serem WinRT apenas no passado. 😁

Honestamente, eu realmente espero que seja o caso. Certamente vou esperar que esses problemas sejam resolvidos e, pessoalmente, mal posso esperar que essa plataforma que não seja sandbox esteja disponível. Mas até então, ainda estou trabalhando em um aplicativo e ainda enfrentando os problemas que descrevi em primeiro lugar.

Portanto, começamos com uma grande desvantagem em relação aos aplicativos WPF. Isso é uma coisa - a outra coisa é

Só para ficar claro, deixar o uso da opção de impedir que aplicativos acessem todos os arquivos é uma desvantagem na sua opinião?
Nós, como desenvolvedores, temos que desenvolver o software para os usuários, não contra eles. E não deixar que o usuário escolha quais dados seu aplicativo vê é uma desvantagem de segurança para os usuários, na minha opinião.

1. Já estou perguntando isso na instalação.

Você quer dizer o recurso "broadFileSystemAccess"? Na minha opinião, existem muito poucos aplicativos que têm um motivo legítimo para ter esse recurso. (como @kmgallahan já apontou)
Basta olhar para todos os aplicativos que você usa no dia a dia. Quantos deles precisam acessar todos os arquivos o tempo todo? Provavelmente não tantos, se houver algum.

Como você disse em seu comentário inicial:

Você acha que os usuários farão o acima com prazer? Não, eles não vão - na verdade, 79,8% não o fazem (meus dados do AppCenter confirmam isso).

Acho que provavelmente há um motivo pelo qual os usuários não gostam de fazer isso (além do fato de que essa é uma configuração de segurança que eles precisam alterar).

No entanto, posso não conhecer todos os casos de negócios que exigiriam acesso a todos os arquivos, portanto, se houver algum, fico feliz em ouvi-los. Afinal, não estamos aqui para lutar, mas para enriquecer os pontos de vista uns dos outros (espero) 😅

Editar:

O tamanho do arquivo deve ser pré-buscado (igual a data do último acesso / data da última gravação) - é tão importante que deve ser buscado previamente quando você faz uma consulta por arquivos.

Ah, certo, sim, alguns deles definitivamente devem ser buscados previamente. Eu concordo que isso é um tanto inconveniente para nós, desenvolvedores.

Essa discussão não teria acontecido aqui, se realmente tivéssemos um lugar para fazer essas perguntas e para que o WinRT pudesse ouvir o feedback em outro lugar.

Oficialmente, o centro de feedback é para isso (eu acho), mas sim, às vezes parece um pouco sem resposta. Esperançosamente, o centro de feedback melhora. Pelo que posso ver, eles já fizeram algumas alterações ao longo do tempo, então acho que espero que isso também mude.

@ Felix-Dev

Aqui está o post de anúncio do .NET 5 novamente

Obrigado por criar um link para isso. Eu particularmente achei esta parte interessante, e acredito que esta é uma notícia positiva:

"A interoperabilidade Java estará disponível em todas as plataformas.

Também há um pouco de discussão sobre Java nos comentários no final dessa página da web, onde Rich Lander confirma a interoperabilidade bidirecional. Eu interpreto isso como um sinal positivo de que a Microsoft está voltando ao contato com a realidade. Não sou fã de Java (prefiro C #), mas, apesar disso, reconheço que a interoperabilidade de Java é altamente benéfica e deveria ter sido o foco em UWP / WinRT desde o início. Se UWP / WinRT tivesse dado prioridade máxima a Java e C # (código gerenciado) em vez de código nativo antigo desajeitado (C ++ / CX, Win16 / 32, COM), e se UWP não tivesse confundido o propósito de JavaScript com Java, então a UWP teria atraído muito mais desenvolvedores de aplicativos, e o Windows Mobile poderia estar vivo hoje.

Goste ou não, é preciso acordar e reconhecer a realidade da situação: o líder de mercado é o Android com foco no desenvolvimento de aplicativos Java. Java e C # significam código gerenciado. A Microsoft cometeu um erro extremamente caro ao reverter seu ponto de vista sobre o código gerenciado.

Embora eu realmente não goste de Java, está claro para mim que as técnicas de Java do Android são muito melhores do que a velha maneira desajeitada em que a Microsoft está desenvolvendo o WebView2 com o uso de técnicas de programação Win16 antigas, como ponteiros de 16 bits versus 32 bits e HRESULT vez de tratamento de exceção moderno, etc. WebView2 usa LPCWSTR e L significa "ponteiro longo", significando um ponteiro de 32 bits em oposição ao de 16 bits ponteiros "curtos" no Win16. O W significa "caracteres largos" significando Unicode (UTF-16) em oposição aos caracteres ASCII / ANSI de 8 bits. Em comparação, o uso de Java pelo Android é muito mais profissional, moderno e inspirador de confiança do que alguns departamentos da Microsoft estão fazendo.

Portanto, em uma nota positiva, é realmente uma ótima notícia saber que a Microsoft oferecerá suporte a Java (embora pessoalmente eu prefira C # em vez de Java). Os desenvolvedores de aplicativos Android aumentarão seu interesse no Windows assim que uma boa interoperabilidade Java confiável for lançada.

Além disso, agora sabemos que uma estrutura de aplicativo Win32 / .NET virá com o WinUI 3.0 - não faz muito sentido ainda criticá-los por serem WinRT apenas no passado. 😁

1. O futuro é brilhante, adoro o que vejo sendo desenvolvido no WinUI.
2. O passado foi bastante sombrio, para uma plataforma com 900 MILHÕES de dispositivos, a fraca prevalência de UWP é difícil de defender. EDITAR: o passado é o único lugar com o qual podemos aprender, por isso é importante discutir.
3. O presente é, creio eu, o ponto principal desta discussão e não está sendo abordado. Se alguém quiser começar hoje um aplicativo não trivial que levará de 1 a 1,5 anos para ser desenvolvido, que conselho honesto pode dar? Minha resposta seria: experimente o WinUI, crie suas libs no dotnet Core e espere que o WinUI3.0 saia para realmente começar a fazer seu aplicativo. Não se preocupe com UWP porque você vai querer jogá-lo fora de seu aplicativo de qualquer maneira, você provavelmente não quer plataformas diferentes, pois a de 900 milhões é muito grande. As questões sobre o presente não são triviais, as decisões de negócios precisam ser tomadas hoje.

O que não está sendo dito, mas o que realmente está acontecendo é que o UWP e a UI moderna não estão sendo estendidos para win32, mas, na verdade, o UWP está sendo refatorado fora da pilha . Por que alguém iria querer lidar com UWP quando eles poderiam usar o poder do dotnet standard 2 e dotnet core 3 e todas as bibliotecas disponíveis com isso?

Sobre sandbox e outras boas ideias apresentadas na UWP: eram boas ideias, mas poderiam ter sido executadas muito melhor. Espero que eles voltem e haja a possibilidade de OPT-IN em um sandbox ou OPT-IN em gerenciamento de estado semelhante ao UWP. Como desenvolvedores, queremos atender aos usuários, mas na UWP éramos ameaçados como o problema que a plataforma precisava conter.

Que conselho honesto pode ser dado? Esperar?

@AndrewPawlowski Se você determinou que o UWP e a sandbox não funcionam para você, acho que escrever um aplicativo WPF empacotado para MSIX é uma boa escolha até que o WinUI 3 chegue. Você já pode chamar APIs exclusivas do Windows 10, fornecer ao usuário uma experiência moderna de instalação / desinstalação e geralmente escolher na superfície da API do Windows 10 o que você gosta e o que não gosta (ou seja, você pode começar a usar as APIs Shell do Windows 10). Algumas APIs do WinRT são realmente divertidas de se trabalhar em comparação com as formas anteriores do win32 e alguns cenários, acredito, até mesmo feitos melhor no DesktopBridge, em vez de UWP puro. Caso em questão: registrando um aplicativo para início automático no login, consulte esta postagem para uma comparação do comportamento UWP vs DesktopBridge. No caso do DesktopBridge, você ainda, em última análise, deixa o usuário no controle, mas o usuário não será constantemente questionado duas vezes (primeiro, uma alternância no aplicativo e, em seguida, um prompt do sistema pedindo confirmação) ao habilitar start at log- no aplicativo.

Infelizmente, muitas partes das APIs WPF estão realmente mostrando sua idade agora, quando comparadas às APIs UI UWP, então você terá que conviver com isso por mais alguns meses (pelo menos). Os muitos kits de ferramentas WPF disponíveis atenuarão esse fato, mas se você realmente deseja uma aparência nativa para seu aplicativo de área de trabalho do Windows (e uma experiência de desenvolvimento XAML moderna!), Você realmente não será capaz de escapar das APIs de IU UWP (e mais tarde, as APIs WinUI 3). Isso significa que, mesmo se você puder reutilizar parte do código da IU do WPF para WinUI mais tarde, a modernização da IU ainda será um item de trabalho bastante grande, acredito.

Esse é o estado de desenvolvimento de aplicativos nativos do Windows que vejo atualmente para você, se você não puder esperar até que o WinUI 3 seja lançado e o UWP não seja uma opção para você.

@AndrewPawlowski

1. O futuro é brilhante, adoro o que vejo sendo desenvolvido no WinUI.

Concorrer

1. O passado foi bastante sombrio, para uma plataforma com 900 MILHÕES de dispositivos, a fraca prevalência de UWP é difícil de defender. EDITAR: o passado é o único lugar com o qual podemos aprender, por isso é importante discutir.
2. O presente é, creio eu, o ponto principal desta discussão e não está sendo abordado. Se alguém quiser começar hoje um aplicativo não trivial que levará de 1 a 1,5 anos para ser desenvolvido, que conselho honesto pode dar? Minha resposta seria: experimente o WinUI, crie suas libs no dotnet Core e espere que o WinUI3.0 saia para realmente começar a fazer seu aplicativo. Não se preocupe com UWP porque

Meu pensamento inicial foi o mesmo, mas não esperei ....

Sobre sandbox e outras boas ideias apresentadas na UWP: eram boas ideias, mas poderiam ter sido executadas muito melhor.

100% aprovado

No entanto, posso não conhecer todos os casos de negócios que exigiriam acesso a todos os arquivos, portanto, se houver algum, fico feliz em ouvi-los. Afinal, não estamos aqui para lutar, mas para enriquecer os pontos de vista uns dos outros (espero) 😅

Em qualquer lugar onde você deseja visualizar as coisas, você desejará acesso rápido aos arquivos. No meu caso, desejo visualizar pastas para mostrar visualmente ao usuário onde estão as fotos / vídeos e, para vídeos, quero que o usuário visualize o vídeo antes de selecioná-lo. A questão toda é: o seletor de arquivos oferece uma experiência bastante abaixo da média, e eu queria enriquecê-la.

Oficialmente, o centro de feedback é para isso (eu acho), mas sim, às vezes parece um pouco sem resposta. Esperançosamente, o centro de feedback melhora. Pelo que posso ver, eles já fizeram algumas alterações ao longo do tempo, então acho que espero que isso também mude (^ ∇ ^)

Pessoalmente, não gosto do centro de feedback - é muito inespecífico, entre outras questões.

@jtorjo @chingucoding hub de feedback para APIs do WinRT pode ser substituído / emparelhado com as perguntas e respostas da Microsoft em breve, verifique este commit: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Visto que a Chigusa foi mencionada lá: @chigy A plataforma de perguntas e respostas da Microsoft será a plataforma de feedback preferida para APIs WinRT não WinUI? Se não, como isso se relacionará com o hub de feedback (ou seja, arquivar bugs / perguntas em Q&A, solicitações de API no hub de feedback, ....)?

Esperançosamente, não acabaremos com três plataformas de feedback diferentes 😆

Como esta é uma discussão sobre UWP, posso promover uma solicitação de recurso: Permitir verbos do menu de contexto com integração do explorador de arquivos sem ter uma associação de tipo de arquivo https://aka.ms/AA71n2t btw. https://aka.ms/AA6rmrk (mas está na categoria errada - talvez alguém possa consertar isso?)

Uma boa fonte de solicitações de recursos é:
https://web.archive.org/web/20161221051552/https : //wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
Pena que o instantâneo desse uservoice seja bem antigo (2016). Lembro que havia coisas como:

• alinhe o comportamento da solicitação broadFileSystemAccess como se comportaria ao solicitar câmera, local, iniciando o aplicativo na inicialização ...
• auto. impressão (atualmente só é compatível com POS na IoT, até onde me lembro)
• tornar a impressão mais configurável

@jtorjo

Em qualquer lugar onde você deseja visualizar as coisas, você desejará acesso rápido aos arquivos. No meu caso, desejo visualizar pastas para mostrar visualmente ao usuário onde estão as fotos / vídeos e, para vídeos, quero que o usuário visualize o vídeo antes de selecioná-lo. A questão toda é: o seletor de arquivos oferece uma experiência bastante abaixo da média, e eu queria enriquecê-la.

Meu palpite é que, para isso, você primeiro permite que o usuário escolha uma pasta onde deseja usar seu aplicativo. Afinal, o usuário sabe melhor onde salvou seus vídeos.

Caso contrário, você pode querer dar uma olhada em:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

Mas, para ser honesto, não sei exatamente o que broadFileSystemAccess ajudaria nesse caso. Você não pode ter certeza de onde exatamente os arquivos estão (ao contrário do usuário). Mas talvez eu não entenda totalmente a ideia do seu aplicativo corretamente.

@ Felix-Dev
Obrigado pela informação, não sabia que o feedback do WinRT pode mover.

Esperançosamente, não acabaremos com três plataformas de feedback diferentes 😆

Haha sim, espero que não!

@jtorjo - Você já pensou em cancelar a portabilidade de seu aplicativo de WPF para UWP? Você pode cancelá-lo e esperar até que o WinUI 3 seja lançado, e então você não será forçado a usar a API problemática do sistema de arquivos UWP, broadFileSystemAccess, etc. Enquanto isso, enquanto espera pelo WinUI 3, você pode continuar a entregar novas versões de seu aplicativo para seus usuários, continuando a desenvolver a versão WPF de seu aplicativo.

Durante os 8 anos desde o início do WinRT, nunca fornecemos nenhum aplicativo WinRT ou UWP para nossos usuários. Em vez disso, fornecemos a eles muitas atualizações que continuam usando a versão WPF de nosso software. Nossos usuários não têm nenhuma reclamação sobre isso porque eles não se importam com detalhes técnicos como WPF, WinUI, UWP, em vez disso, eles se preocupam com o funcionamento do aplicativo e as funcionalidades que possui. Nossos usuários também não têm nenhuma reclamação sobre GUI antigo porque nossos aplicativos WPF incluem um monte de modernizações de GUI.

@AndrewPawlowski disse "experimente com WinUI". Sim, experimente. Escrevi um monte de código para UWP e WinUI ao longo dos anos, mas é todo código experimental, alfa ou beta. Nunca cheguei a um ponto em que me sentisse confortável o suficiente para lançar qualquer aplicativo UWP para os usuários.

A separação do WinUI 3 do UWP é uma grande ajuda, mas não acho que seja uma solução completa. O WinUI 3 não aborda a baixa produtividade / ritmo lento de desenvolvimento do WinUI: o WPF foi desenvolvido muito mais rápido do que o WinUI, embora o WPF fosse mais difícil do que o WinUI.

A equipe do WinUI diz que o ritmo vai acelerar quando o WinUI 3 for open source, e talvez vá, mas pessoalmente não vou escrever nenhuma contribuição C ++ / CX, C ++ / WinRT, Win16 / 32 ou COM para WinUI 3. I comecei minha carreira com o Win16 / Win32 décadas atrás, e o Win32 era um pesadelo, e não tenho intenção de voltar a usar essas técnicas de programação antigas e problemáticas. Ao longo dos anos, mantive minhas habilidades de engenharia de software atualizadas e mudei para C # e .NET Framework, e foi uma grande melhoria e benefício, e não vou voltar ao pesadelo do antigo Win16 / 32 dias e grandes quantidades de código nativo escrito manualmente.

@AndrewPawlowski escreveu:

Que conselho honesto pode ser dado? Esperar?

Essa é uma pergunta muito difícil de responder. Por um lado, sim, espere pelo WinUI 3, mas por outro lado, o WinUI 3 não é uma resolução completa do grande problema que foi iniciado pelo WinRT há 8 anos. WinUI 3 é uma resolução parcial útil.

Excelente vídeo do Ignite: https://youtu.be/Ul5JcdIJv5s

Acho que muito da discussão aqui questiona o propósito do WinRT. Desenvolvedores e usuários ainda se perguntam qual o papel que ele desempenhará, uma vez que o WinUI 3 e o .NET 5.0 permitirem uma fácil integração entre as diferentes tecnologias. Sem mencionar a eventual capacidade de escolher entre os modelos de aplicativos em sandbox e os clássicos.

Presumo que escrever novas APIs do WinRT seja mais fácil para a Microsoft fazer internamente, o que explica por que eles declararam muitas vezes antes que a maior parte da inovação da camada de API será feita dentro do WinRT. Isso significa que, para aplicativos novos e modernos do Windows, faz sentido usar o WinRT porque ele terá as mais recentes e melhores integrações com novas experiências que virão com os novos formatos. O WinRT destina-se apenas a ser um conjunto específico de APIs universais que aparecem em seu aplicativo .NET no Windows.

Dito isso, acho que todos concordamos que tornaria os aplicativos universais mais valiosos se o UWP Desktop Extension Pack tivesse melhores recursos de integração com o Windows Shell existente.

Quem sabe, a Microsoft pode ter planos de, eventualmente, substituir o Shell do Windows Explorer pelo novo Composable Shell (CShell) encontrado no Windows 10X, etc. Especialistas no Twitter também descobriram um novo UDK (Undocked Development Kit) encontrado no Windows que pode permitir melhor integração com este novo shell no futuro.

@AndrewPawlowski

você provavelmente não quer plataformas diferentes, pois a de 900 milhões é muito grande.

Embora eu entenda o que você quer dizer, você precisa perceber que UWP e .NET não são mais coisas mutuamente exclusivas, então, se faria sentido lançar seu aplicativo com recursos universais, deve-se investir no entendimento de partes do WinRT.

Eu divago. Como alguém que construiu um concorrente do Windows File Explorer com o modelo de aplicativo UWP puro, o WinUI 3 não chega rápido o suficiente. Em um futuro próximo, você não terá que escolher entre usar os recursos universais e os "900 milhões de usuários" 😀

@jtorjo Aconselho mudar o título para um que seja percebido de forma menos negativa, para que mais pessoas forneçam comentários aqui.
Talvez "Oportunidades para agregar valor ao WinRT"

@verelpode

@jtorjo - Você já pensou em cancelar a portabilidade de seu aplicativo de WPF para UWP? Você pode cancelá-lo e esperar até que o WinUI 3 seja lançado, e então você não será forçado a usar a API problemática do sistema de arquivos UWP, broadFileSystemAccess, etc. Enquanto isso, enquanto espera pelo WinUI 3, você pode continuar a entregar novas versões de seu aplicativo para seus usuários, continuando a desenvolver a versão WPF de seu aplicativo.

Eu pensei muito sobre isso - isso é o que eu queria fazer. Mas eu não posso deixar de fazer isso, porque eu realmente preciso do win2d (ou mais, um bom wrapper sobre o Direct2D). ShapDX (outro wrapper sobre Direct2D) parecia muito mais complicado, então escolhi usar win2d (que é UWP). Portanto, transfira tudo para UWP.

Meu palpite é que, para isso, você primeiro permite que o usuário escolha uma pasta onde deseja usar seu aplicativo. Afinal, o usuário sabe melhor onde salvou seus vídeos.

Você realmente aposta sua vida nisso? Eu não faria - claramente, se você for um usuário avançado, pode ser incrivelmente organizado e saber onde cada detalhe está. De outra forma....

E então, sempre que você (o usuário), de alguma forma copiar fotos / vídeos para uma nova pasta, você precisará se lembrar de dizer ao meu aplicativo para incluir isso também ...

Não quer dizer que a "ótima" FutureAccessList - não especifica realmente -> se eu adicionar uma pasta, todas as suas subpastas estarão acessíveis ao meu aplicativo?

Além disso, se eu adicionei algo a FutureAccessList, preciso recuperá-lo de lá ou posso obtê-lo com GetFolderFromPathAsync / GetFileFromPathAsync (é o primeiro, prefiro pular de um penhasco)?

E você sabia que se usar FutureAccessList.AddOrReplace e usar o caminho do arquivo como token, você obterá uma exceção? Que atencioso ... (não está em nenhum lugar da descrição)

WinUI 3 e .NET Core serão uma opção no futuro - presumo que a combinação, sem a sandbox do UWP, funcionará da mesma maneira que o WPF, mas com os controles XAML mais recentes, Visual Layer e acesso simples à API WinRT.

Meu palpite é que, para isso, você primeiro permite que o usuário escolha uma pasta onde deseja usar seu aplicativo. Afinal, o usuário sabe melhor onde salvou seus vídeos.

Você realmente aposta sua vida nisso? Eu não faria - claramente, se você for um usuário avançado, pode ser incrivelmente organizado e saber onde cada detalhe está. De outra forma....

Bem, se o usuário não sabe onde salvou seus vídeos, o que seu aplicativo deve fazer? Verificar todos os arquivos do sistema, o que mesmo com o software mais rápido pode levar horas? Pelo menos para mim não parece uma boa experiência. Afinal, se seu aplicativo é direcionado a usuários que querem fazer algo com vídeos, os usuários já estão um tanto "organizados" no sentido de saberem que têm vídeos em algum lugar. Mas, novamente, apenas meus pensamentos, sem realmente conhecer seu aplicativo e caso de negócios específico.

E então, sempre que você (o usuário), de alguma forma copiar fotos / vídeos para uma nova pasta, você precisará se lembrar de dizer ao meu aplicativo para incluir isso também ...

Acho que se você tiver acesso ao diretório pai, também poderá acessar futuras pastas filho (não tenho 100% de certeza).

E você sabia que se usar FutureAccessList.AddOrReplace e usar o caminho do arquivo como token, você obterá uma exceção? Que atencioso ... (não está em nenhum lugar da descrição)

Isso é estranho, isso é algo que definitivamente deveria ser documentado!

Pessoalmente, não sou muito fã de aplicativos que solicitam "broadFileSystemAccess", já que muitos deles não precisam disso. Talvez haja alguns casos em que faça sentido (escrever um explorador de arquivos, etc.), mas muitos casos que precisam de acesso a ALGUMAS pastas não devem prosseguir e dizer "por favor, permita-me acessar a todos os arquivos", já que você também pode solicitar essas pastas em particular.

Mas talvez eu não conheça casos de negócios suficientes para isso. Se houver mais, eu adoraria ouvi-los!

Mas talvez eu não conheça casos de negócios suficientes para isso. Se houver mais, eu adoraria ouvi-los!

• ferramentas e utilitários de software, como uma ferramenta de (des) compressão. Se você deseja extrair o arquivo compactado no mesmo diretório onde o arquivo atual está localizado e quando o aplicativo foi chamado pelo menu de contexto do Windows Explorer, você só teve acesso de gravação ao arquivo selecionado. Portanto, não será possível criar um novo arquivo ou diretório (para os arquivos descompactados).

  • Se o usuário arrastou o arquivo para o seu aplicativo uwp, você não tem acesso de gravação a esses arquivos!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

como uma ferramenta de (des) compressão. Se você deseja extrair o arquivo compactado no mesmo diretório onde o arquivo atual está localizado e quando o aplicativo foi chamado pelo menu de contexto do Windows Explorer, você só teve acesso de gravação ao arquivo selecionado. Portanto, não será possível criar um novo arquivo ou diretório (para os arquivos descompactados).

Acho que é muito discutível se você deve obter acesso a toda a pasta quando clica com o botão direito em um único arquivo ou não. Embora tbh eu geralmente especifique uma pasta diferente ao compactar / descompactar, já que normalmente preciso delas apenas para "troca", ou seja, backups ou downloads / uploads. Então, para mim, é quase necessário especificar onde exatamente salvar os arquivos. Mas este pode ser um caso de uso válido dependendo da escolha do usuário 😅

Se o usuário arrastou o arquivo para o seu aplicativo uwp, você não tem acesso de gravação a esses arquivos!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

Bem, isso parece um pouco complicado demais para usuários e desenvolvedores. Eu esperava que você tivesse pelo menos acesso de gravação aos arquivos descartados. Na minha opinião, esta é apenas uma restrição desnecessária para desenvolvedores.

Embora pelo menos no meu uso diário de aplicativos, eu apenas coloco arquivos nos comentários do GitHub. Para todos os outros casos, eu apenas clico duas vezes ou clico com o botão direito, mas concordamos que em alguns casos isso não é ótimo. Acho que há alguns casos, afinal, em que faria sentido ter acesso a todos os arquivos.

Bem, se o usuário não sabe onde salvou seus vídeos, o que seu aplicativo deve fazer? Verificar todos os arquivos do sistema, o que mesmo com o software mais rápido pode levar horas? ...

Existem claramente muitas possibilidades, uma delas é, quando o usuário expande uma pasta, visualizá-la para ele - para que ele veja facilmente quais pastas têm fotos / vídeos e quais não. Uma coisa que meu aplicativo faria, se o Windows me deixasse

Pessoalmente, não sou muito fã de aplicativos que solicitam "broadFileSystemAccess", já que muitos deles não precisam disso.

Eu não importa. O modelo de proteção do sistema de arquivos da sandbox do WinRT está além da realidade. É algo que alguém tirou do grande mantra "Mobile first", que simplesmente não se aplica ao desktop.

Na verdade, uma maneira muito mais inteligente de fazer a sandbox de arquivos / pastas é permitir que o usuário decida quais arquivos / pastas deseja proteger - deve haver uma maneira muito fácil de fazer isso (como, talvez, no File Explorer, com um comando de clique com o botão direito) .

Isso contrasta com o bloqueio de tudo por padrão e, em seguida, os usuários, inadvertidamente, dando a você acesso a arquivos confidenciais por engano.

Deixe-me ser franco aqui - qualquer aplicativo não trivial não vive no vácuo.

Existem claramente muitas possibilidades, uma delas é, quando o usuário expande uma pasta, visualizá-la para ele - para que ele veja facilmente quais pastas têm fotos / vídeos e quais não. Uma coisa que meu aplicativo faria, se o Windows me deixasse

Sim, é uma possibilidade. Mas quando você vai escanear a pasta? E quais pastas exatamente o usuário pode expandir em seu aplicativo?

Eu não importa.

O que exatamente você está tentando dizer aqui?

Na verdade, uma maneira muito mais inteligente de colocar arquivos / pastas na sandbox é permitir que o usuário decida quais arquivos / pastas deseja proteger - deve haver uma maneira muito fácil de fazer isso (como, talvez, no File Explorer, com um comando de clique com o botão direito) . Os usuários saberão claramente quais documentos / arquivos são confidenciais e os protegerão.

Acho que toda essa proteção de acesso não se trata apenas de arquivos "confidenciais", mas da privacidade em geral, por exemplo, arquivos de configuração (que normalmente estão ocultos em pastas que os usuários não veem) ou apenas quais programas estão instalados. Essas são informações que não quero que todos os programas tenham acesso, especialmente "aplicativos triviais", como você os chamou.

E também há uma analogia com o mundo real - pense apenas em seifs.

Sim, você pode procurar coisas em cofres. Mas isso não muda o fato de você ter a chave do seu apartamento ou casa. Mas dizer que todos os programas podem acessar tudo, exceto que estão em um cofre, é como dizer, você não precisa de uma porta para seu apartamento porque você tem um cofre para seus objetos de valor.

Isso contrasta com o bloqueio de tudo por padrão e, em seguida, os usuários, inadvertidamente, dando a você acesso a arquivos confidenciais por engano.

Esses erros podem acontecer em ambos os casos, mas acho que é mais provável que se esqueça de bloquear um arquivo confidencial do que dar acesso acidentalmente a um arquivo confidencial.

Deixe-me ser franco aqui - qualquer aplicativo não trivial não vive no vácuo. Será necessário obter dados de algum lugar (entrada) e gerá-los em algum lugar. A entrada e a saída geralmente são arquivos - você precisa interoperar com outros aplicativos e assim por diante. E o WinRT simplesmente torna isso impossível para mim projetar uma bela IU para oferecer aos meus usuários.

Dizer que é impossível é um exagero aqui, já que existem muitos aplicativos UWP excelentes (embora não muitos, infelizmente).

Sim, é uma possibilidade. Mas quando você vai escanear a pasta? E quais pastas exatamente o usuário pode expandir em seu aplicativo?

Você está familiarizado com o conceito do Windows Explorer? Você expande uma pasta ou unidade - é quando eu começaria a digitalizar

Acho que toda essa proteção de acesso não se trata apenas de arquivos "confidenciais", mas da privacidade em geral, por exemplo, arquivos de configuração (que normalmente estão ocultos em pastas que os usuários não veem) ou apenas quais programas estão instalados. Essas são informações que não quero que todos os programas tenham acesso, especialmente "aplicativos triviais", como você os chamou.

Isso não seria um problema, se o aplicativo mantivesse seus arquivos em sua própria pasta "apenas este aplicativo pode acessá-lo".

Isso contrasta com o bloqueio de tudo por padrão e, em seguida, os usuários, inadvertidamente, dando a você acesso a arquivos confidenciais por engano.

Esses erros podem acontecer em ambos os casos, mas acho que é mais provável que se esqueça de bloquear um arquivo confidencial do que dar acesso acidentalmente a um arquivo confidencial.

Eu discordo totalmente - toda a questão de "confidencial" deve fazer você querer bloquear esse arquivo.

Dizer que é impossível é um exagero aqui, já que existem muitos aplicativos UWP excelentes (embora não muitos, infelizmente).

Você está se contradizendo aqui. Mas vamos nos aprofundar na vastidão de ótimos aplicativos UWP:

Observe a "abundância" de curtidas, que deve dizer quantas pessoas estão usando. Queria fazer um contraste com a apple store, mas não posso porque não tenho uma maçã. Mas vamos ver o Android - o Facebook tem mais de 70 milhões de avaliações (em comparação com 1353 no Windows). O Instagram tem mais de 93 milhões de avaliações (em comparação com 1578 aqui). E tenho quase certeza de que o Fb e o Instagram são, na verdade, aplicativos de elétrons, não UWP.

Você está familiarizado com o conceito do Windows Explorer? Você expande uma pasta ou unidade - é quando eu começaria a digitalizar

Então você está construindo algo semelhante ao Windows Explorer que irá visualizar arquivos de vídeo em pastas?

Isso não seria um problema, se o aplicativo mantivesse seus arquivos em sua própria pasta "apenas este aplicativo pode acessá-lo".

Por outro lado, os aplicativos geralmente devem ter acesso a todos os arquivos, mas, por outro lado, alguns arquivos e pastas serão bloqueados pelo usuário (já que ele só terá arquivos "confidenciais" e todo o resto é automaticamente não confidencial) e algumas pastas são bloqueado pelos temas de aplicativos? E se eu quiser programar um aplicativo que lide com arquivos gerados por programas? Todos os programas de backup falhariam porque não seriam capazes de fazer backup de programas? Não tenho certeza de como isso funcionaria e lamento se entendi mal sua ideia aqui.

Eu discordo totalmente - toda a questão de "confidencial" deve fazer você querer bloquear esse arquivo.

Então, o que exatamente eu não escolheria como confidencial? Não quero que todos os aplicativos vejam as fotos das minhas férias, mas o Photoshop deve conseguir vê-las. Então, eles são confidenciais ou não? Ou este "sinalizador" confidencial é uma lista de programas e alguns arquivos não são confidenciais para alguns aplicativos?

Você está se contradizendo aqui.

Sim, meu fraseado era uma porcaria lá. Desculpe por isso. Eu queria indicar que definitivamente existem ótimos aplicativos não "triviais" que funcionam bem.

Observe a "abundância" de curtidas, que deve dizer quantas pessoas estão usando. Queria fazer um contraste com a apple store, mas não posso porque não tenho uma maçã. Mas vamos ver o Android - o Facebook tem mais de 70 milhões de avaliações (em comparação com 1353 no Windows). O Instagram tem mais de 93 milhões de avaliações (em comparação com 1578 aqui). E tenho quase certeza de que o Fb e o Instagram são, na verdade, aplicativos de elétrons, não UWP.

Este não é um problema com UWP, mas sim com o fato de que:

1. As pessoas geralmente não tendem a escrever comentários
2. A iTunes store / Google Play Store é muito mais antiga que a Microsoft Store
3. A Microsoft Store não foi bem recebida pelos usuários e não começou bem
4. A maioria das empresas prefere desenvolver sites em vez de aplicativos de plataforma limitada

E tenho quase certeza de que o Fb e o Instagram são, na verdade, aplicativos de elétrons, não UWP.

É difícil dizer se eles são elétrons ou não, já que o site e o aplicativo são muito diferentes. Com base no fato de que os diálogos se parecem quase exatamente com os padrões, eles podem ser aplicativos UWP.

Então você está construindo algo semelhante ao Windows Explorer que irá visualizar arquivos de vídeo em pastas?

Isso é parte de um assistente do meu aplicativo.

Por outro lado, os aplicativos geralmente devem ter acesso a todos os arquivos, mas, por outro lado, alguns arquivos e pastas serão bloqueados pelo usuário (já que ele só terá arquivos "confidenciais" e todo o resto é automaticamente não confidencial) e algumas pastas são bloqueado pelos temas de aplicativos? E se eu quiser programar um aplicativo que lide com arquivos gerados por programas?

Minha ideia era o oposto do que temos agora. Não estou dizendo que seja perfeito, longe disso - mas tudo é melhor do que o que está acontecendo agora. Portanto, por padrão, você teria acesso a todos os arquivos não confidenciais. Se você precisar acessar arquivos confidenciais, será necessário perguntar primeiro.

Então, o que exatamente eu não escolheria como confidencial? Não quero que todos os aplicativos vejam as fotos das minhas férias, mas o Photoshop deve conseguir vê-las. Então, eles são confidenciais ou não? Ou este "sinalizador" confidencial é uma lista de programas e alguns arquivos não são confidenciais para alguns aplicativos?

A meu ver, esse "sinalizador" tornaria um arquivo ou pasta como "Acesso negado". Se você realmente quisesse acessá-lo, poderia pedir permissão e o usuário poderia optar por dar a você ou não (e a permissão poderia ser - apenas desta vez, ou para sempre).

Sim, meu fraseado era uma porcaria lá. Desculpe por isso. Eu queria indicar que definitivamente existem ótimos aplicativos não "triviais" que funcionam bem.

Não estou dizendo que não. Estou dizendo que é extremamente difícil fazer um, em comparação com o WPF.
Estou dizendo que estou perdendo dias lidando com questões que simplesmente não deveriam existir.

Por exemplo, às vezes, recebo uma exceção (uma exceção COM, para ser específico) e, em vez de obtê-la no ponto de falha, na verdade a obtenho em outro thread e, na maioria das vezes, até mesmo o rastreamento de pilha é perdido. Descobrir o que aconteceu é muito doloroso.

Outro problema é todo o mantra "vamos obter informações assíncronas" - que eu odeio muito. Estou lidando com a renderização que precisa ser imediata, mas o carregamento de bitmaps é assíncrono. Então, eu tive que construir um mecanismo de cache realmente complicado só para isso.

E não vamos entrar em tempos de compilação. E, ultimamente, às vezes, ao compilar, recebo um "... dll é integrado no modo de lançamento" (o que basicamente não pode ser, porque estou compilando o debug). A solução alternativa é simplesmente limpar toda a solução e reconstruir (o que leva mais de 1 minuto).

E sim, trava. O VS trava a cada 10-20 execuções, me perguntando o porquê.

E esses são os problemas que me vieram à cabeça agora há pouco. Existem incontáveis ​​mais.

Este não é um problema com UWP, mas sim com o fato de que:

1. As pessoas geralmente não tendem a escrever comentários
2. A iTunes store / Google Play Store é muito mais antiga que a Microsoft Store
3. A Microsoft Store não foi bem recebida pelos usuários e não começou bem
4. A maioria das empresas prefere desenvolver sites em vez de aplicativos de plataforma limitada

Bem, eu gostaria de ter feito uma comparação com a loja da Apple - tenho certeza que seus principais aplicativos têm milhões de avaliações. A ideia é que a loja da MS nunca pegou - porque as pessoas simplesmente desistem do UWP / WinRT. Se eu não precisasse do win2d, teria desistido pelo menos 20 vezes.

Basta pensar nisso - preciso pedir ao Windows para ir para tela inteira, como um aplicativo UWP. Isso está além da loucura. E para torná-lo ainda mais estúpido, isso só se aplicará na próxima execução .

Eu estava olhando para a API "Faça uma captura de tela da tela" - simplesmente desisti, é inútil. Eu basicamente queria ter uma maneira legal de iniciar o aplicativo, com base na tela atual (tipo, fazer uma transição para o meu aplicativo) -> não é possível, porque requer interação do usuário (ou seja, o usuário tem que dizer - sim , Quero permitir a captura de uma captura de tela, o que estraga tudo)

Não vou começar com a área de transferência - que funciona apenas quando seu aplicativo está em primeiro plano. E para torná-lo ainda mais engraçado, a Microsoft pensou "nós daremos a você acesso à área de transferência em todos os momentos, quando estiver em depuração", mas no lançamento, você receberá uma bela exceção "Acesso negado". Você sabe quantas horas levei para finalmente descobrir por que meu aplicativo não iniciava na versão (enquanto tudo estava ótimo em Debug)

A lista continua - acho que poderia escrever um livro. Claro, UWP / WinRT são legais em teoria. Mas quando você começar a usar então, tudo bem ..

É difícil dizer se eles são elétrons ou não, já que o site e o aplicativo são muito diferentes. Com base no fato de que os diálogos se parecem quase exatamente com os padrões, eles podem ser aplicativos UWP.

Certo, meu ponto é - as pessoas desistem de aplicativos UWP - os benefícios são superados pelos muitos problemas que vêm com eles.

@jtorjo
(Apenas para ter certeza de que você está ciente disso.)

Não vou começar com a área de transferência - que funciona apenas quando seu aplicativo está em primeiro plano.

Eu cheguei ao mesmo (ou semelhante) problema durante o desenvolvimento de um dos meus aplicativos UWP, onde tive que colocar dados na área de transferência e no final resolvi isso por meio de um processo win32 de confiança total (que apenas chama SetClipboardData do Win32). Se o conceito de acompanhar o processo win32 de confiança total para seu aplicativo UWP for novidade, você encontrará uma boa introdução aqui (o autor trabalhou anteriormente no UWP na Microsoft).

@ Felix-Dev

Eu cheguei ao mesmo (ou semelhante) problema durante o desenvolvimento de um dos meus aplicativos UWP, onde tive que colocar dados na área de transferência e no final resolvi isso por meio de um processo win32 de confiança total (que apenas chama SetClipboardData do Win32). Se o conceito de acompanhar o processo win32 de confiança total para seu aplicativo UWP for novidade, você encontrará uma boa introdução aqui (o autor trabalhou anteriormente no UWP na Microsoft).

Obrigado pelo ponteiro! Eu sabia sobre o processo win32 de confiança total. Provavelmente li esses artigos várias vezes :) Na verdade, pensei várias vezes em ter um aplicativo complementar de processo de confiança total win32. Decidi não fazê-lo, devido à complexidade adicional - já estou lutando para gerar kits de configuração que realmente funcionem sem a loja MS. Eu só não queria incluir isso na equação também.

Então você está construindo algo semelhante ao Windows Explorer que irá visualizar arquivos de vídeo em pastas?

Isso é parte de um assistente do meu aplicativo.

Isso soa como um explorador de arquivos com etapas extras (⊙ˍ⊙)

Minha ideia era o oposto do que temos agora. Não estou dizendo que seja perfeito, longe disso - mas tudo é melhor do que o que está acontecendo agora. Portanto, por padrão, você teria acesso a todos os arquivos não confidenciais. Se você precisar acessar arquivos confidenciais, será necessário perguntar primeiro.

Então, basicamente, no final, seu aplicativo provavelmente terá o mesmo problema de agora, porque você nunca saberia se os arquivos são confidenciais. E os usuários que marcarão tudo como confidencial? Então você acabou de criar o mesmo sistema de agora, apenas com mais variação no qual você pode acessar.

Por exemplo, às vezes, recebo uma exceção (uma exceção COM, para ser específico) e, em vez de obtê-la no ponto de falha, na verdade a obtenho em outro thread e, na maioria das vezes, até mesmo o rastreamento de pilha é perdido. Descobrir o que aconteceu é muito doloroso.

Se isso acontece com frequência com você, é muito chato. Para mim, no entanto, quase todas as exceções que ocorreram para mim (por exemplo, no XCG) tinham um StackTrace associado e às vezes até mensagens de exceção úteis. Portanto, não posso dizer nada sobre isso porque nunca foi realmente um problema para mim.

Outro problema é todo o mantra "vamos obter informações assíncronas" - que eu odeio muito. Estou lidando com a renderização que precisa ser imediata, mas o carregamento de bitmaps é assíncrono. Então, eu tive que construir um mecanismo de cache realmente complicado só para isso.

Às vezes, o assíncrono é um pouco chato, no entanto, na maioria dos casos, os métodos assíncronos têm um motivo para serem assíncronos, já que você não deseja bloquear a IU em operações como operações de rede ou arquivo. Dito isso, você pode usar os seguintes métodos para executar seu método assíncrono de forma síncrona:

`` `c #
// Bloqueará o thread até que MyAsyncMethod termine
var myResult = MyAsyncMethod (). Result;

// Isso também terminará quando o método terminar a execução.
// Observe que ConfigureAwait pode resultar na chamada do método em um contexto diferente
var myResult2 = MyAsyncMethod (). ConfigureAwait (false);
`` For ConfigureAwait` você pode dar uma olhada no seguinte artigo: https://devblogs.microsoft.com/dotnet/configureawait-faq/

E não vamos entrar em tempos de compilação. E, ultimamente, às vezes, ao compilar, recebo um "... dll é integrado no modo de lançamento" (o que basicamente não pode ser, porque estou compilando o debug). A solução alternativa é simplesmente limpar toda a solução e reconstruir (o que leva mais de 1 minuto).

O "... dll" é construído no modo de liberação é estranho. Talvez verifique se os arquivos do projeto são incoerentes? Em relação ao tempo de compilação, sim, isso é um pouco chato, embora ~ 1 minuto ainda seja ok, WinUI leva cerca de 5 a 10 minutos 😅

E sim, trava. O VS trava a cada 10-20 execuções, me perguntando o porquê.

Sim, isso é muito chato, embora eu não ache que isso dependa realmente do UWP, mas apenas do Visual Studio em geral (ainda é um processo de 32 bits por um motivo!).

Bem, eu gostaria de ter feito uma comparação com a loja da Apple - tenho certeza que seus principais aplicativos têm milhões de avaliações. A ideia é que a loja da MS nunca pegou - porque as pessoas simplesmente desistem do UWP / WinRT. Se eu não precisasse do win2d, teria desistido pelo menos 20 vezes.

Parece que você pode usar Win2D com WPF: https://github.com/Microsoft/Win2D/issues/660

Basta pensar nisso - preciso pedir ao Windows para ir para tela inteira, como um aplicativo UWP. Isso está além da loucura. E para torná-lo ainda mais estúpido, isso só se aplicará na próxima execução.

Parece possível colocar seu aplicativo UWP no modo de tela cheia, mesmo na inicialização: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(Embora eu não tenha tentado enviar um aplicativo com isso)

Eu estava olhando para a API "Faça uma captura de tela da tela" - simplesmente desisti, é inútil. Eu basicamente queria ter uma maneira legal de iniciar o aplicativo, com base na tela atual (tipo, fazer uma transição para o meu aplicativo) -> não é possível, porque requer interação do usuário (ou seja, o usuário tem que dizer - sim , Quero permitir a captura de uma captura de tela, o que estraga tudo)

A maioria dos usuários não quer que os aplicativos tirem fotos arbitrariamente de suas telas sem sua permissão. Você pode não ter problemas com isso, mas eu certamente tenho e muitos outros também.

Não vou começar com a área de transferência - que funciona apenas quando seu aplicativo está em primeiro plano. E para torná-lo ainda mais engraçado, a Microsoft pensou "nós daremos a você acesso à área de transferência em todos os momentos, quando estiver em depuração", mas no lançamento, você receberá uma bela exceção "Acesso negado". Você sabe quantas horas levei para finalmente descobrir por que meu aplicativo não iniciava na versão (enquanto tudo estava ótimo em Debug)

Sim, você recebe uma exceção, no entanto, o fato de que seu aplicativo não pode acessá-lo quando não está em foco é mencionado na documentação:

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Mas por que você precisa acessar a área de transferência quando o usuário não está usando seu aplicativo? Se você tentar definir a área de transferência quando o usuário não estiver usando seu aplicativo, o usuário ficará irritado quando você interferir na cópia / colagem. E se você lê a área de transferência quando o usuário não está pedindo que seu aplicativo faça isso, você o está espionando. A menos que esse seja o seu objetivo (nesse caso, você definitivamente não deve usar UWP), há muito poucos motivos para ler a área de transferência enquanto seu aplicativo não está em foco (se houver algum).

Certo, meu ponto é - as pessoas desistem de aplicativos UWP - os benefícios são superados pelos muitos problemas que vêm com eles.

Talvez, mas também pelo fato de que é mais fácil escrever um site e empacotá-lo dentro do Electron e enviá-lo para Mac, Linux e Windows em vez de escrever aplicativos separados para todas as plataformas.

Isso soa como um explorador de arquivos com etapas extras (⊙ˍ⊙)

Não é. Longe disso.

Então, basicamente, no final, seu aplicativo provavelmente terá o mesmo problema de agora, porque você nunca saberia se os arquivos são confidenciais. E os usuários que marcarão tudo como confidencial? Então você acabou de criar o mesmo sistema de agora, apenas com mais variação no qual você pode acessar.

Não estou dizendo que minha solução seja a certa. Obviamente, eu preferiria não estar em um sandbox, só estou dizendo que a implementação atual é muito ruim.

Às vezes, o assíncrono é um pouco chato, no entanto, na maioria dos casos, os métodos assíncronos têm um motivo para serem assíncronos, já que você não deseja bloquear a IU em operações como operações de rede ou arquivo. Dito isso, você pode usar os seguintes métodos para executar seu método assíncrono de forma síncrona:

Isto está errado. Isso simplesmente pressupõe que sempre estarei chamando a partir do thread de interface do usuário. Tenho certeza de que isso é bom para coisas simples, mas posso criar meus próprios threads e também posso criar minhas próprias tarefas e fazer coisas lá.

Ter tudo assíncrono me força a sempre chamar o await e marcar as funções como assíncronas.

[...] Por ConfigureAwait você pode dar uma olhada no seguinte artigo: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Obrigado, eu sei sobre isso. Outro problema que encontrei foi ao carregar um bitmap (assíncrono) exatamente como você sugeriu. De vez em quando, eu encontrava tempos de espera insanos, como 5 a 6 segundos para carregar um bitmap.
Acabei fazendo soluções alternativas.

O "... dll" é construído no modo de liberação é estranho. Talvez verifique se os arquivos do projeto são incoerentes? Em relação ao tempo de compilação, sim, isso é um pouco chato, embora ~ 1 minuto ainda seja ok, WinUI leva cerca de 5 a 10 minutos 😅

Sim, eu nem quero pensar sobre isso :) Não tenho certeza do que você quis dizer sobre arquivos de projeto serem incoerentes.

E sim, trava. O VS trava a cada 10-20 execuções, me perguntando o porquê.

Sim, isso é muito chato, embora eu não ache que isso dependa realmente do UWP, mas apenas do Visual Studio em geral (ainda é um processo de 32 bits por um motivo!).

Eu acredito que seja relacionado ao UWP. Isso nunca aconteceu comigo quando lidava com o WPF - eu tinha 28 projetos e nunca travou. Na UWP, tenho 15 projetos (que transferi do WPF) e ele trava. E se eu olhar no Visualizador de eventos, há algo sobre o travamento da sandbox - não me lembro exatamente.

Parece que você pode usar Win2D com WPF: microsoft / Win2D # 660

Essa foi minha primeira tentativa. É um impedimento completo. Eu me deparei com tantos problemas, que acabei desistindo. O código que lida com win2d é bastante complexo, então concluí que demoraria muito mais para escrevê-lo sobre o WPF do que para usar UWP diretamente.

Por mais que eu odeie a configuração UWP, eu estava certo. Eu nunca teria sido capaz de fazer funcionar corretamente. E suponho que você esteja ciente de https://github.com/microsoft/Win2D/issues/731

Basta pensar nisso - preciso pedir ao Windows para ir para tela inteira, como um aplicativo UWP. Isso está além da loucura. E para torná-lo ainda mais estúpido, isso só se aplicará na próxima execução.

Parece possível colocar seu aplicativo UWP no modo de tela cheia, mesmo na inicialização: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

Desculpe, eu quis dizer "ir ao máximo" - desculpe por isso.

Sim, você recebe uma exceção, no entanto, o fato de que seu aplicativo não pode acessá-lo quando não está em foco é mencionado na documentação:

O problema é que temos um comportamento diferente em Debug e em Release. Deve ser consistente.

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Mas por que você precisa acessar a área de transferência quando o usuário não está usando seu aplicativo? [...]

O engraçado é o seguinte - eu queria copiar algo para a área de transferência na inicialização. No entanto, isso estava no construtor do MainPage, então, aparentemente, eu ainda não estava em primeiro plano. Funcionou bem no Debug, travou no Release - e com isso, quero dizer exatamente na inicialização, sem logar sem nada.

Certo, meu ponto é - as pessoas desistem de aplicativos UWP - os benefícios são superados pelos muitos problemas que vêm com eles.

Talvez, mas também pelo fato de que é mais fácil escrever um site e empacotá-lo dentro do Electron e enviá-lo para Mac, Linux e Windows em vez de escrever aplicativos separados para todas as plataformas.

Quando se trata de independência de plataforma, esse é um tópico totalmente novo - o que eu estava me referindo é o fato de que muitos problemas que as pessoas encontram ao desenvolver aplicativos UWP simplesmente não deveriam existir. Mudar de WPF para UWP tem sido uma experiência muito ruim.

@chingucoding

Mas por que você precisa acessar a área de transferência quando o usuário não está usando seu aplicativo? Se você tentar definir a área de transferência quando o usuário não estiver usando seu aplicativo, o usuário ficará irritado quando você interferir na cópia / colagem. E se você lê a área de transferência quando o usuário não está pedindo que seu aplicativo faça isso, você o está espionando. A menos que esse seja o seu objetivo (nesse caso, você definitivamente não deve usar UWP), há muito poucos motivos para ler a área de transferência enquanto seu aplicativo não está em foco (se houver algum).

No meu caso, meu aplicativo exibe de tempos em tempos uma notificação quando ocorre um evento que o aplicativo está aguardando. A notificação do sistema pode conter informações que o usuário deseja processar posteriormente / usar em outro contexto, portanto, forneço um botão de ação [copiar para a área de transferência] que copia algumas das informações mostradas. Como uma notificação pode chegar a qualquer momento e o aplicativo pode muito bem estar em segundo plano nesse ponto, tenho que usar um processo auxiliar Win32 nesse caso.

Usar o Win32 fora da área restrita UWP nem sempre ocorre porque o desenvolvedor deseja alcançar algo sem que o usuário saiba. Portanto, embora de modo geral o sandbox forneça valor para nós, usuários, você ainda precisa lidar com ele como um desenvolvedor em qualquer caso, mesmo se você não for um desenvolvedor mal-intencionado que não se importa em espionar o usuário ou não tem a intenção de pedir por o consentimento do usuário antes de alterar algo em seu sistema.

O fato de você poder usar um processo de confiança total do Win32 junto com seu aplicativo indica que a MS está ciente desse dilema e nos dá os desenvolvedores de ferramentas para usar UWP e ainda poder desfrutar da liberdade do Win32 em boa medida.

Não é. Longe disso.

Pode-se baixar o aplicativo agora? Se sim, onde posso encontrá-lo? 😅

Obviamente, eu preferiria não estar em um sandbox, só estou dizendo que a implementação atual é muito ruim.

Eu acho que, se você não gosta do sandbox, talvez mudar para uma alternativa WPF possa ser a melhor escolha, em vez de apenas tentar desenvolver seus aplicativos em UWP, que você deixou claro, você acha que é "impossível" ou "insanamente difícil" de desenvolver aplicativos para. Não acho que as alternativas do WPF sejam tão ruins em comparação com o Win2D, isso justificaria você passar por todas as suas lutas. Mas esse é apenas meu ponto de vista sobre isso.

Além disso, a implementação atual é "ruim" para as pessoas acostumadas a não ter limitações em relação aos arquivos. Vindo de um histórico de desenvolvimento da Web, estou muito bem com isso. Eu posso ver o lugar deles, especialmente porque a Web também tem limitações cujo objetivo é proteger os usuários.

Não tenho certeza do que você quis dizer sobre os arquivos de projeto serem incoerentes.

Talvez os arquivos do projeto para depuração estejam errados e alguma dll esteja sendo gerada no lançamento, embora eu duvide que isso aconteceria se você apenas deixasse o Visual Studio lidar com isso.

Eu acredito que seja relacionado ao UWP. Isso nunca aconteceu comigo quando lidava com o WPF - eu tinha 28 projetos e nunca travou. Na UWP, tenho 15 projetos (que transferi do WPF) e ele trava. E se eu olhar no Visualizador de eventos, há algo sobre o travamento da sandbox - não me lembro exatamente.

A confiabilidade do Visual Studio depende muito do tamanho do projeto para mim. UWP / NetCore / NetFramework pequeno / médio sempre funcionam bem. Projetos grandes fazem com que o Visual Studio pare de responder, trava ou simplesmente trava de vez. Mas essa é apenas minha experiência.

Desculpe, eu quis dizer "ir ao máximo" - desculpe por isso.

Nesse caso, sim, a mudança só será aplicada na próxima inicialização, desde que você defina o valor para ela APÓS o seu aplicativo ter iniciado. Eu não sei o que você quer dizer com "Eu tenho que perguntar ao Windows". Você está se referindo ao fato de que deve configurá-lo no código?

Também existe uma maneira de definir o tamanho preferido, o que deve resultar no aplicativo ocupando todo o espaço da tela em que está (semelhante ao maximizado), embora não seja tão bom quanto o real maximizado:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Isto está errado. Isso simplesmente pressupõe que sempre estarei chamando a partir do thread de interface do usuário. Tenho certeza de que isso é bom para coisas simples, mas posso criar meus próprios threads e também posso criar minhas próprias tarefas e fazer coisas lá.

Se você já está usando seus próprios threads, o uso de await não deve ser um problema para você. Mesmo se você usar threads separados, o manipulador de eventos sempre é executado no thread de IU, portanto, se você fizer cálculos extensivos lá, o aplicativo não responderá.

Por mais que eu odeie a configuração UWP, eu estava certo. Eu nunca teria sido capaz de fazer funcionar corretamente. E presumo que você conheça microsoft / Win2D # 731

Eu não sabia disso, pensei que, sendo o problema que mencionei em 2018, já estaria resolvido bem.

O problema é que temos um comportamento diferente em Debug e em Release. Deve ser consistente.

Hmm, isso é muito estranho. O comportamento deve ser consistente.

O engraçado é o seguinte - eu queria copiar algo para a área de transferência na inicialização.

Eles também mencionam esse caso de uso na documentação e você deve esperar que CoreWindow.Activated copie. Por que exatamente você copiaria algo para a área de transferência, quando o usuário acabou de iniciar seu aplicativo? Algo semelhante ao que @Felix-Dev deseja alcançar / alcançar?

@ Felix-Dev Obrigado por responder. Eu não pensei sobre esse cenário. Nesse caso, sim, você precisa acessar a área de transferência e isso definitivamente melhora a experiência dos usuários. Meu palpite seria que, desde que você torrou "tem foco", isso teria funcionado. Mas acho que não é o caso.

Portanto, embora de modo geral o sandbox forneça valor para nós, usuários, você ainda precisa lidar com ele como um desenvolvedor em qualquer caso, mesmo se você não for um desenvolvedor mal-intencionado que não se importa em espionar o usuário ou não tem a intenção de pedir por o consentimento do usuário antes de alterar algo em seu sistema.

Sim, temos que lidar com isso, no entanto, muitos aplicativos não estão sendo limitados pela sandbox de tal forma que seria muito difícil encontrar uma solução alternativa. E uma coisa a não esquecer é que se o UWP não estiver funcionando para você, ainda existem 2 outras opções.

Em relação ao seu último ponto, sim, o fato de você poder usar processos Win32 é uma indicação de que há casos em que a UWP está limitando você.
Talvez essa seja a solução alternativa mais fácil / rápida disponível, ou talvez seja por design.

Não é. Longe disso.

Pode-se baixar o aplicativo agora? Se sim, onde posso encontrá-lo? 😅

Aqui -> https://phot-awe.com

Eu acho que, se você não gosta do sandbox, talvez mudar para uma alternativa WPF possa ser a melhor escolha, em vez de apenas tentar desenvolver seus aplicativos em UWP, que você deixou claro, você acha que é "impossível" ou "insanamente difícil" de desenvolver aplicativos para. Não acho que as alternativas do WPF sejam tão ruins em comparação com o Win2D, isso justificaria você passar por todas as suas lutas. Mas esse é apenas meu ponto de vista sobre isso.

Este era um aplicativo WPF. No entanto, devido à natureza da edição de vídeo, há muito tempo atingi os limites do WPF em termos de velocidade (basicamente, lidando com DrawingVisual ). Acredite em mim, eu não teria feito isso, se tivesse escolha.

Além disso, a implementação atual é "ruim" para as pessoas acostumadas a não ter limitações em relação aos arquivos. Vindo de um histórico de desenvolvimento da Web, estou muito bem com isso. Eu posso ver o lugar deles, especialmente porque a Web também tem limitações cujo objetivo é proteger os usuários.

Eu poderia jurar que você vinha de um background da Web :)

Talvez os arquivos do projeto para depuração estejam errados e alguma dll esteja sendo gerada no lançamento, embora eu duvide que isso aconteceria se você apenas deixasse o Visual Studio lidar com isso.

Esse não é o caso, mas eu verifiquei duas vezes - não é o caso.

A confiabilidade do Visual Studio depende muito do tamanho do projeto para mim. UWP / NetCore / NetFramework pequeno / médio sempre funcionam bem. Projetos grandes fazem com que o Visual Studio pare de responder, trava ou simplesmente trava de vez. Mas essa é apenas minha experiência.

Sim, já lidei com isso no passado. Não parece ser o caso com as versões mais recentes do VS (2017,2019). Enfim, para encurtar a história, isso acabou de acontecer no UWP para mim. Pode ter a ver com o fato de que estou usando o win2d e tenho a sensação de que é uma besta bastante complicada.

Nesse caso, sim, a mudança só será aplicada na próxima inicialização, desde que você defina o valor para ela APÓS o seu aplicativo ter iniciado. Eu não sei o que você quer dizer com "Eu tenho que perguntar ao Windows". Você está se referindo ao fato de que deve configurá-lo no código?

No WPF, eu simplesmente defino o tamanho da janela para onde eu quero. Aqui, há uma API que você precisa chamar -> ApplicationView.PreferredLaunchViewSize - que, como dizem os documentos, "funciona, exceto nos casos em que o sistema gerencia o tamanho da janela diretamente." - e sim, só funciona para a próxima inicialização do aplicativo.

Também existe uma maneira de definir o tamanho preferido, o que deve resultar no aplicativo ocupando todo o espaço da tela em que está (semelhante ao maximizado), embora não seja tão bom quanto o real maximizado:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Estou usando outro código, que realmente funciona corretamente

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

Se você já está usando seus próprios threads, o uso de await não deve ser um problema para você. Mesmo se você usar threads separados, o manipulador de eventos sempre é executado no thread de IU, portanto, se você fizer cálculos extensivos lá, o aplicativo não responderá.

Claramente, os manipuladores de eventos são executados no thread de interface do usuário. Eu meio que me acostumei com isso, tive que modificar um pouco do meu aplicativo - apenas adicionando assíncrono às funções ... O que ainda realmente me incomoda é que, para mim, parece que algumas APIs tomaram isso ao extremo, ter apenas versões Async (), onde não faz sentido.

Eu não sabia disso, pensei que, sendo o problema que mencionei em 2018, já estaria resolvido bem.

Não tem - pelo menos da última vez que verifiquei.

O problema é que temos um comportamento diferente em Debug e em Release. Deve ser consistente.

Hmm, isso é muito estranho. O comportamento deve ser consistente.

Sim, isso é o que realmente me irritou. E claramente, trabalhando com a área de transferência por um tempo absurdamente longo em aplicativos não UWP, não pensei que teríamos essas limitações, então sim, não li sobre ter que esperar por CoreWindow.Activated. Dito isso, é incrivelmente complicado ter que aprender todos esses detalhes. É como se eu precisasse aprender um idioma totalmente novo. Em vez de ser um processo contínuo, parece que toda semana aprendo sobre algo que simplesmente me surpreende.

Eles também mencionam esse caso de uso na documentação e você deve esperar que CoreWindow.Activated copie. Por que exatamente você copiaria algo para a área de transferência, quando o usuário acabou de iniciar seu aplicativo? Algo semelhante ao que @Felix-Dev deseja alcançar / alcançar?

Isso foi quando eu estava testando meu aplicativo no início e só queria dá-lo a um colega para mais alguns testes internos. No entanto, ele precisaria ajustar algumas configurações. E as configurações foram mantidas no LocalFolder do aplicativo. Isso é diferente para cada usuário, então minha opinião foi - deixe-me manter isso simples e copiá-lo para a área de transferência. Então, quando ele iniciar o aplicativo, ele irá para "Este PC", colará o local e editará um arquivo de configurações lá (agora, eu sei como poderia ter simplesmente aberto o aplicativo no Explorer, mas naquele momento, eu nao fiz). O que acabou quebrando, e eu investigando e xingando por algumas boas horas.

Aqui -> https://phot-awe.com

Obrigado!

Este era um aplicativo WPF. No entanto, devido à natureza da edição de vídeo, há muito tempo atingi os limites do WPF em termos de velocidade (basicamente, lidando com o DrawingVisual). Acredite em mim, eu não teria feito isso, se tivesse escolha.

Não sabia que o WPF tinha uma desvantagem de desempenho tão grande em comparação com o UWP.

Esse não é o caso, mas eu verifiquei duas vezes - não é o caso.

Isso é estranho. Eu esperava que houvesse algo errado. Por que o VS falaria sobre o release dll quando você está executando o debug?

No WPF, eu simplesmente defino o tamanho da janela para onde eu quero. Aqui, há uma API que você precisa chamar - ApplicationView.PreferredLaunchViewSize - que, como dizem os documentos, "funciona, exceto nos casos em que o sistema gerencia o tamanho da janela diretamente."

Mas o código que você está usando não é também uma API para definir o tamanho da janela?

• e sim, só funciona para a próxima inicialização do aplicativo.

Não é surpreendente quando é chamado de "PreferredLaunchViewSize" 😅
É um pouco inconveniente que não haja como configurar isso após o lançamento.

Sim, já lidei com isso no passado. Não parece ser o caso com as versões mais recentes do VS (2017,2019). Enfim, para encurtar a história, isso acabou de acontecer no UWP para mim.

Fico feliz em saber que não é tão ruim quanto nas versões anteriores do VS.

Pode ter a ver com o fato de que estou usando o win2d e tenho a sensação de que é uma besta bastante complicada.

Não confio muito no designer, já que ele começa a falhar nas ligações de modelo. Você já experimentou o Blend for Visual Studio? Isso é mais confiável em relação ao designer?

Sim, isso é o que realmente me irritou. E claramente, trabalhando com a área de transferência por um tempo absurdamente longo em aplicativos não UWP, não pensei que teríamos essas limitações, então sim, não li sobre ter que esperar por CoreWindow.Activated. Dito isso, é incrivelmente complicado ter que aprender todos esses detalhes. É como se eu precisasse aprender um idioma totalmente novo. Em vez de ser um processo contínuo, parece que toda semana aprendo sobre algo que simplesmente me surpreende.

Sim, posso imaginar isso. Algo que pode ser bom é um guia de transição de WPF para UWP. Se isso existisse, isso definitivamente economizaria muito tempo para novos desenvolvedores UWP e antigos WPFs. E esta não seria a primeira vez que existe um guia de transição. Já existe um guia de Java para C #, o que ajuda muito para desenvolvedores de Java.

Isso foi quando eu estava testando meu aplicativo no início e só queria dá-lo a um colega para mais alguns testes internos. No entanto, ele precisaria ajustar algumas configurações. E as configurações foram mantidas no LocalFolder do aplicativo. Isso é diferente para cada usuário, então minha opinião foi - deixe-me manter isso simples e copiá-lo para a área de transferência. Então, quando ele iniciar o aplicativo, ele irá para "Este PC", colará o local e editará um arquivo de configurações lá (agora, eu sei como poderia ter simplesmente aberto o aplicativo no Explorer, mas naquele momento, eu nao fiz). O que acabou quebrando, e eu investigando e xingando por algumas boas horas.

Oh, eu vejo. Se alguém não pensar em abrir a pasta, copiar o caminho da pasta para a área de transferência é uma solução. Para fins de teste, isso é bastante inteligente.

Não sabia que o WPF tinha uma desvantagem de desempenho tão grande em comparação com o UWP.

O WPF não foi otimizado para DirectX - quando pixel shaders e máscaras entram em ação, ele acaba sendo muito lento. A portabilidade para UWP / win2d tornou o aplicativo 3-4 vezes mais rápido. Isso é incrivelmente perceptível.

Isso é estranho. Eu esperava que houvesse algo errado. Por que o VS falaria sobre o release dll quando você está executando o debug?

Sim, exatamente meu ponto.

Mas o código que você está usando não é também uma API para definir o tamanho da janela?

O que quero dizer é que você usa Preferred ... Size, mas não tem certeza de que isso vai acontecer. Como ao usar o WPF, você tem a garantia de que, ao definir a posição / tamanho, isso realmente acontecerá.

Não é surpreendente quando é chamado de "PreferredLaunchViewSize" 😅
É um pouco inconveniente que não haja como configurar isso após o lançamento.

Isso é além de inconveniente - é extremamente inconveniente. Basicamente, não consigo redimensionar meu aplicativo depois de iniciado. E sim, eu gostaria que meu aplicativo tivesse diferentes "modos" de operação (como Básico / Avançado) - com base nisso, eu gostaria de ocupar mais ou menos espaço - não posso fazer isso. Você acha que o usuário concordará com "As alterações acontecerão somente após a reinicialização"?

Não confio muito no designer, já que ele começa a falhar nas ligações de modelo. Você já experimentou o Blend for Visual Studio? Isso é mais confiável em relação ao designer?

Eu deveria ter sido mais específico - o VS não trava ao editar xaml - trava ao iniciar o aplicativo; basicamente, suponho que isso aconteça exatamente na implantação, já que você apenas vê o grande "x" no aplicativo (uwp) por cerca de 10 segundos e, nesse ponto, eu sei que ele trava. Nesse ponto, posso esperar mais 45-60 segundos e ver se o VS irá travar ou apenas fechar o VS no Gerenciador de Tarefas.

Sim, posso imaginar isso. Algo que pode ser bom é um guia de transição de WPF para UWP.

Sim, isso seria muito útil.

Oh, eu vejo. Se alguém não pensar em abrir a pasta, copiar o caminho da pasta para a área de transferência é uma solução. Para fins de teste, isso é bastante inteligente.

Obrigado;) Bem, teria sido inteligente, se tivesse realmente funcionado :)

@chingucoding

Às vezes, o assíncrono é um pouco chato, no entanto, na maioria dos casos, os métodos assíncronos têm um motivo para serem assíncronos, já que você não deseja bloquear a IU em operações como operações de rede ou arquivo. Dito isso, você pode usar os seguintes métodos para executar seu método assíncrono de forma síncrona

Deixe-me dar mais um motivo pelo qual odeio o assíncrono - isso aconteceu comigo agora (basicamente, é um relatório de bug de um usuário). Inicialmente, eu não conseguia descobrir por nada.

Resumindo a história - com um clique de botão, abro um seletor de arquivos. O que, você adivinhou, é assíncrono.

Então, o usuário clicou duas vezes nele (com uma pausa de cerca de 100 ms entre os cliques). Certamente, isso abriu 2 seletores de arquivo.

Agora, claramente posso consertar isso, mas isso nunca aconteceria se a função inicial fosse síncrona (e é claro, isso nunca acontecerá no WPF).

Isso é além de inconveniente - é extremamente inconveniente. Basicamente, não consigo redimensionar meu aplicativo depois de iniciado. E sim, eu gostaria que meu aplicativo tivesse diferentes "modos" de operação (como Básico / Avançado) - com base nisso, eu gostaria de ocupar mais ou menos espaço - não posso fazer isso. Você acha que o usuário concordará com "As alterações acontecerão somente após a reinicialização"?

Bem, "absurdamente inconveniente" pode ser para aplicativos que precisam aplicar certos tamanhos, mas na maioria dos casos os aplicativos não precisam ser redimensionados. Como um aplicativo deve escolher qual tamanho é atualmente apropriado para o caso de uso do usuário? Se o usuário tem necessidade de torná-lo menor ou maior, então o usuário é o primeiro a perceber isso. Especialmente porque ele sabe melhor onde estão as outras janelas abertas e onde haveria espaço disponível para não bloquear a visibilidade de outras janelas.

Se você tiver um modo básico e avançado, pode alterar o tamanho mínimo preferido se o aplicativo definitivamente não funcionar quando for muito pequeno. Mas, na minha opinião, seria muito irritante para mim se os programas começassem a se redimensionar (e felizmente nenhum programa faz isso até agora).

Eu não consigo fazer isso. Você acha que o usuário concordará com "As alterações acontecerão somente após a reinicialização"?

Se o redimensionamento for tão importante, o usuário pode fazer isso sozinho. No entanto, essa "mudança só acontecerá após a reinicialização" não é incomum, portanto, é parcialmente aceitável em minha opinião.

Então, o usuário clicou duas vezes nele (com uma pausa de cerca de 100 ms entre os cliques). Certamente, isso abriu 2 seletores de arquivo.

Por que exatamente ele abriu o seletor de arquivos duas vezes? O manipulador de eventos disparou duas vezes? Então, isso não é um problema causado por assíncrono, mas pelo fato de que o manipulador de eventos não bloqueou a IU de receber eventos adicionais do respectivo botão.

Resumindo a história - com um clique de botão, abro um seletor de arquivos. O que, você adivinhou, é assíncrono.

Sim, é assíncrono porque você não deseja bloquear todo o seu segmento enquanto o usuário está navegando em sua unidade e escolhendo a pasta. A chamada é finalizada quando o usuário termina de escolher um arquivo / pasta e você obtém o arquivo escolhido como resultado.

Em minha opinião, é melhor não bloquear o encadeamento nessas operações, pois você nunca sabe quanto tempo elas realmente levarão. Se você bloquear o thread de IU por causa disso, seu aplicativo deixará de responder enquanto um seletor de arquivo estiver aberto, o que IMO não é um bom UX.

Deixe-me começar dizendo respeitosamente o seguinte: nunca chegaremos a um acordo sobre nada .

É claro que você está pensando de uma perspectiva da web e simplesmente não vê nada como "área de trabalho". Eu sei que você tem boas intenções, mas você não está pensando em "área de trabalho" até que tenha desenvolvido algo complicado - quando se trata de área de trabalho. E eu acredito que você não tem.

Bem, "absurdamente inconveniente" pode ser para aplicativos que precisam aplicar certos tamanhos, mas na maioria dos casos os aplicativos não precisam ser redimensionados. Como um aplicativo deve escolher qual tamanho é atualmente apropriado para o caso de uso do usuário? Se o usuário precisar torná-lo menor ou maior, do que o usuário

Você está perguntando isso seriamente? Um aplicativo não deveria ajudar o usuário? E então, se o usuário não concordar com o tamanho do aplicativo, ele pode redimensionar. Mas o aplicativo deve ser capaz de dizer, com base no que deve realizar, este é o tamanho que eu deveria estar executando. Digamos que o Photoshop - sempre preferirá rodar em tela cheia, porque tem muitas informações para mostrar ao usuário.

Se você tiver um modo básico e avançado, pode alterar o tamanho mínimo preferido se o aplicativo definitivamente não funcionar quando for muito pequeno. Mas, na minha opinião, seria muito irritante para mim se os programas começassem a se redimensionar (e felizmente nenhum programa faz isso até agora).

Se sim, você nem pensou nisso. Os assistentes às vezes são executados em tamanhos menores e, quando o assistente termina, o aplicativo pode entrar em tela inteira.

Eu não consigo fazer isso. Você acha que o usuário concordará com "As alterações acontecerão somente após a reinicialização"?

Se o redimensionamento for tão importante, o usuário pode fazer isso sozinho. No entanto, essa "mudança só acontecerá após a reinicialização" não é incomum, portanto, é parcialmente aceitável em minha opinião.

E tenho uma experiência de inicialização ruim, porque mostro uma janela que parece boa apenas em um determinado tamanho - e o Windows apenas diz "Oh, mas mostrarei o aplicativo como desejo".

Por que exatamente ele abriu o seletor de arquivos duas vezes? O manipulador de eventos disparou duas vezes? Então, isso não é um problema causado por assíncrono, mas pelo fato de que o manipulador de eventos não bloqueou a IU de receber eventos adicionais do respectivo botão.

Você está honestamente fazendo isso? Mostre-me como um código foi cortado onde você fez isso conscientemente.

Em minha opinião, é melhor não bloquear o encadeamento nessas operações, pois você nunca sabe quanto tempo elas realmente levarão. Se você bloquear o thread de IU por causa disso, seu aplicativo deixará de responder enquanto um seletor de arquivo estiver aberto, o que IMO não é um bom UX.

Como o WPF lida com isso? Ele lida com isso corretamente. A IU não bloqueia, mas o aplicativo bloqueia nessa chamada - portanto, o acima nunca aconteceria no WPF

Deixe-me começar dizendo respeitosamente o seguinte: nunca chegaremos a um acordo sobre nada.

Se esta é sua opinião sobre esta discussão, sinto muito por isso.

É claro que você está pensando de uma perspectiva da web e simplesmente não vê nada como "área de trabalho". Eu sei que você tem boas intenções, mas você não está pensando em "área de trabalho" até que tenha desenvolvido algo complicado - quando se trata de área de trabalho. E eu acredito que você não tem.

Acho que uma descrição mais precisa seria: Eu venho de um background onde os desenvolvedores não têm acesso a nada e você vem de um background onde os desenvolvedores têm acesso a todos os recursos do sistema operacional.

Se sim, você nem pensou nisso. Os assistentes às vezes são executados em tamanhos menores e, quando o assistente termina, o aplicativo pode entrar em tela inteira.

Sim, os assistentes são executados em tamanhos menores, MAS a maioria dos assistentes (incluindo o "Assistente" de inicialização do Visual Studio 2019) fecha-se e inicia o programa real. Eles não se "transformam" no aplicativo real.

É importante notar que alguns assistentes também não são novas janelas, mas apenas pop-ups, com o aplicativo real em segundo plano.

E tenho uma experiência de inicialização ruim, porque mostro uma janela que parece boa apenas em um determinado tamanho - e o Windows apenas diz "Oh, mas mostrarei o aplicativo como desejo".

Você faz com que pareça que o Windows está apenas ignorando seu código o tempo todo, enquanto é claro quando ele irá ignorar isso (tirado da documentação de "PreferredLaunchViewSize"):

Esta propriedade só tem efeito quando o aplicativo é iniciado em um dispositivo desktop que não está no modo Tablet.

Portanto, ele só funciona no desktop em modo não tablet. Mas faz sentido em outros dispositivos solicitar tamanhos? Você espera que seu aplicativo seja executado no X-Box ou Holo Lens, e você otimizou para esses dispositivos? Do contrário, essa limitação não deveria incomodá-lo muito.

Você está honestamente fazendo isso? Mostre-me como um código foi cortado onde você fez isso conscientemente.

Não, não estou, só estava tentando apontar o fato de que você culpa "async" por algo que não está relacionado a isso. Se o usuário clicar em um botão duas vezes, o evento clicado será acionado duas vezes.

Como o WPF lida com isso? Ele lida com isso corretamente. A IU não bloqueia, mas o aplicativo bloqueia nessa chamada - portanto, o acima nunca aconteceria no WPF

Tenho quase certeza de que se você executar o código no UI thread e demorar para ser concluído, você estará bloqueando o UI thread no WPF.

Olá, sou o líder de desenvolvimento da infraestrutura do Windows SDK e do Windows Runtime na equipe do sistema operacional do Windows.

Esta é uma ótima discussão com muitos detalhes e conversas. Alguém trouxe esta conversa há alguns dias e estou ansioso para lê-la, mas ainda pode demorar alguns dias antes de eu começar a entendê-la. Vou ler tudo, porém, e tentar dar-lhe algumas respostas mais detalhadas ou fazer o acompanhamento da melhor maneira possível.

Este provavelmente não é o melhor lugar para questões gerais de winrt. Você pode levantar problemas nos fóruns de desenvolvedores da Microsoft ou, especificamente, para problemas do Windows Runtime, pode abrir um problema em https://github.com/microsoft/xlang. Nossa equipe analisa os problemas que chegam lá regularmente. Problemas arquivados no github chegarão à minha equipe mais rápido, mas terão menos rastreamento. Se o seu feedback exigir mudanças no sistema operacional, manter o trabalho do sistema operacional sincronizado com um problema arquivado no github é um processo manual. Por outro lado, o feedback do fórum segue o trabalho entre as equipes e a organização, e é menos provável que se desconecte do trabalho real feito com base no feedback.

Obrigado novamente pela discussão animada. Vou postar novamente sobre esse problema em breve.

Ben Kuhn
Microsoft

Olá ben,

Olá, sou o líder de desenvolvimento da infraestrutura do Windows SDK e do Windows Runtime na equipe do sistema operacional do Windows.

Esta é uma ótima discussão com muitos detalhes e conversas. Alguém trouxe esta conversa há alguns dias e estou ansioso para lê-la, mas ainda pode demorar alguns dias antes de eu começar a entendê-la. Vou ler tudo, porém, e tentar dar-lhe algumas respostas mais detalhadas ou fazer o acompanhamento da melhor maneira possível.

Incrível - aguardamos sua (s) resposta (s)!

Como sou o autor da postagem original, se você tiver alguma dúvida / algo não esteja claro, entre em contato e farei o possível para esclarecer.

Este provavelmente não é o melhor lugar para questões gerais de winrt. Você pode levantar problemas nos fóruns de desenvolvedores da Microsoft ou, especificamente, para problemas do Windows Runtime, pode abrir um problema em https://github.com/microsoft/xlang.

Concordo que não é o melhor lugar, o problema é que as pessoas não sabem onde postar.

Se você diz que devemos postar em https://github.com/microsoft/xlang , com certeza postarei lá de agora em diante.

Melhor,
João

Primeiro, deixe-me destacar algumas coisas que não vou abordar.

• Há uma grande discussão sobre janela, posição da janela, etc. perto da parte inferior do tópico. Isso provavelmente ainda está um pouco fora do assunto para WinUI, mas mais perto de casa. Eu gostaria de deixar o pessoal do WinUI analisar o feedback sobre a posição da janela, tela inteira, etc. e ajudar no redirecionamento. @StephenLPeters , você pode ajudar com isso?

• Não vou tocar no feedback do VS. Há um fórum saudável para discutir a qualidade e o desempenho do VS. Embora eu tenha anotado a discussão de que a história do desenvolvimento de aplicativos do Windows a partir do Visual Studio se tornou um pouco mais complexa e confusa.

• WPF. Eu tenho uma relação de amor e ódio com a WPF. É útil e principalmente bom. Mas quando li o comentário sobre cliques aninhados no seletor de arquivos, isso me fez rir. Porque existem algumas peculiaridades no WPF que me deram verdadeiras dores de cabeça. Como o fato de que, quando você arrasta no WPF, as mensagens de arrastar despacham duas vezes em uma mensagem aninhada, de modo que você está realmente fazendo um arrasto modal dentro de um arrasto modal. Você geralmente nunca percebe. Usualmente. Mas ainda gosto do WPF. 😉

Em segundo lugar, @verelpode : Isso me fez rir. Importa-se se eu continuar com este?
"Eu acredito que você não pode lidar com a verdade direta, portanto, vou lidar com você com luvas grossas de algodão macio e embalá-lo em plástico-bolha"

Ok, agora vamos aos tópicos reais.

WinRT vs. UWP vs. .NET - alguns antecedentes

O Tempo de Execução do Windows é, na verdade, duas coisas agrupadas em uma, agrupadas em outra e realmente mal compreendidas.

O sistema do tipo Windows Runtime é realmente, em certo sentido, COM V2. É a próxima etapa espiritual na progressão do disparo de interrupções para a chamada do Win32 e para a chamada de APIs COM. O sistema de tipos é em alguns aspectos um pouco menos expressivo em COM, mas em muitos aspectos um superconjunto substancial. Ele foi projetado originalmente para resolver exatamente um problema: como tornamos mais fácil para os desenvolvedores que usam .NET ou outras linguagens chamar APIs do WinRT sem ter que esperar que o VS faça bons wrappers no .NET framework.

Depois, há a biblioteca de API. Fizemos algumas coisas ótimas aqui e algumas coisas bobas. Podemos ter nos empolgado um pouco com algumas das coisas assíncronas. Se você programa com C ++ / WinRT, você pode mitigar isso significativamente. Se você não estiver no thread de interface do usuário, apenas pegue o resultado e ele será bloqueado e concluído de forma síncrona. O .NET também pode tornar isso mais fácil agora, mas escrevo menos código .NET atualmente e tenho menos certeza sobre o estado atual das coisas. Fizemos algumas outras coisas que também não funcionaram conforme planejado. Não vou listar todos eles. No entanto, fizemos algumas melhorias.

O modelo de aplicativo UWP saltou para o winrt com os dois pés. Isso significava que poderíamos escrever APIs do sistema operacional uma vez e torná-los fáceis de acessar a partir de aplicativos baseados em JS, aplicativos .NET e aplicativos nativos. Isso por si só já era bom. Tirar todas as outras APIs do Win32 não foi tão bom. Ainda temos algum trabalho de documentação a fazer, mas agora existem muito mais APIs Win32 clássicas que podem ser usadas em aplicativos de loja. Resumindo, criamos uma plataforma de aplicativo totalmente nova com uma pequena base de usuários em novos dispositivos, não permitimos que você trouxesse seu código existente e muitas pessoas não apareceram. Nós sabemos. É por isso que estamos consertando, pouco a pouco. Nós acertamos muito também e estamos trabalhando lenta, mas firmemente, em direção a uma abordagem do melhor dos dois mundos. Um sistema de instalação declarativo é, em muitos aspectos, uma coisa maravilhosa.

A portabilidade de código entre aplicativos UWP e aplicativos de desktop também foi abordada neste tópico. Como o modelo UWP divergia muito, há vários pontos problemáticos. Estamos lidando com eles o mais rápido possível. Alguns demoram ou exigem “grandes pausas”. Por exemplo, usamos nomes diferentes para as DLLs CRT. Reunimos uma atenuação, o pacote de encaminhadores de VC, mas a correção real será, eventualmente, remover a distinção em uma versão futura do CRT, o que inerentemente requer renomear os arquivos e uma grande alteração significativa. Fazemos isso com pouca frequência intencionalmente porque é perturbador.

O próprio WinRT está movendo cada vez mais seu código-fonte aberto de ferramentas e, embora não seja muito conhecido, a maior parte do WinRT está disponível para aplicativos de desktop. XAML era a grande lacuna. As ilhas XAML foram um passo na direção certa, mas estou muito mais animado com o WinUI.

Feedback para APIs específicas

Para vários deles, vou pedir que você envie um feedback se este for o seu problema. Ajudarei a divulgar o problema para a equipe certa. Cada equipe diferente no Windows é responsável por suas próprias APIs, e será mais eficaz se você registrar no hub de feedback. Isso conecta o feedback com um ser humano e uma história reais. Ele também permite que você acompanhe o feedback. Vocês podem se ajudar um pouco adicionando comentários que outras pessoas arquivam, conforme apropriado. Tente escolher uma categoria apropriada. Se não estiver claro, você pode usar “feedback do desenvolvedor” -> Feedback da API

APIs de sistema de arquivos para aplicativos modernos são dolorosamente e inesperadamente lentos

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Ouvimos esse feedback, tanto de clientes quanto de nossas próprias equipes de criação de aplicativos. Eu gostaria de ter mais para compartilhar neste momento. Por enquanto, tudo o que posso dizer, infelizmente, é “nós sabemos”.

A API / capacidade BroadSystemAccess não é prática quando implementada.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Envie um item do hub de feedback e me envie o link. Vou promovê-lo pessoalmente e entregá-lo ao proprietário certo. Uma taxa de redução de 80% não é boa. Eu entendo a questão de ser um sinal de alerta para os usuários também. SE, as APIs de arquivo foram rápidas o suficiente, parece que a lista de acesso futura mitigaria pelo menos um pouco da dor, mas pode não ser tão 'lisa' como a que você tem agora. Mas então, você está entre uma rocha e um lugar duro. Para ser mágico do jeito que você está fazendo agora, você precisa que o usuário deixe você ver tudo. A planilha de senha, a pasta de e-mail, o cache do navegador, etc. Você pode ser confiável, mas seu aplicativo deve fazer os usuários pausar e pensar sobre o quanto eles confiam em você antes de entregar o mundo deles.

Eu entendo que a ideia de fechar o aplicativo e reiniciá-lo é uma etapa estranha. Este parece ser o tipo de coisa que deve ser resolvida pelo menos no primeiro lançamento. Envie um item de feedback separado. A mesma oferta. Vou promover e entregar.

Com relação à possibilidade de futuras listas de acesso acessar subpastas, fui em frente e criei um problema de documentação para a página. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. É importante notar que, como as páginas de documentos estão no github, você pode arquivar problemas em documentos ou propor alterações no conteúdo também.

Arrastar o arquivo para os aplicativos não permite acesso de gravação: a mesma oferta sobre o hub de feedback. Por favor, arquive e eu encaminharei de acordo.

Criação de aplicativos para sideload fora da loja MS

A conclusão que peguei aqui é que a maior parte do problema é um problema de doc, mas toca em outro aspecto-chave. Como algumas de nossas ferramentas mudaram para projetos github e código-fonte aberto, a documentação mudou com isso, e isso torna mais difícil usar a documentação do Windows como um balcão único para tudo. Levantarei esse problema internamente com relação ao problema específico em torno do arquivo .appinstaller e discutirei de maneira mais geral com nossa equipe de conteúdo sobre como lidar melhor com isso.

Você também observou um problema específico sobre a necessidade de rotear pelo servidor para depurar. Que você deve arquivar como um problema contra o projeto github existente.

Emissão de novo certificado e distribuição privada

Isso é um pouco mais perto de mim (minha equipe maior também lida com os aspectos da instalação do aplicativo. Ainda gostaria de ter um problema com o hub de feedback para que eu possa trabalhar.

O sistema de tipo WinRT afeta a capacidade de fornecer ótimas APIs e bibliotecas

A incapacidade de sobrecarregar no nome do tipo é por design. Até que repensemos como os aplicativos javscript (que tal Node / V8? Isso seria interessante?) Acessam APIs do WinRT, não estaremos prontos para revisitar isso. A outra questão sobre propriedades e NaN está em uma questão separada que tem uma boa discussão, então não vou me aprofundar nela nesta resposta.

A central de feedback deve avisar ao abandonar para evitar a exclusão acidental de conteúdo

Sim, vou marcar isso com +1. Por favor, arquive. Há uma categoria no hub de feedback em aplicativos para ... hub de feedback. Isso é tão meta.

As APIs assíncronas ainda estão fora de controle e parecem estranhas para coisas que não deveriam ser assíncronas

Sim. Isso continua a ser um tópico de debate interno também. Há um equilíbrio tênue entre babá e incentivo ao bom comportamento que ainda não atingimos. Continue a enviar comentários sobre APIs específicas que você adoraria ver serem síncronas.

Não há boas APIs de áudio no WinRT

Não sou um especialista em áudio. Sinta-se à vontade para arquivar no centro de feedback, mas também irei ligar para um salva-vidas aqui e fazer algumas perguntas.

Dores na área de transferência

Tenho que começar com uma Mae Culpa aqui. Nosso modelo de acesso à área de transferência foi projetado na era Win8, quando éramos superprotetores com o usuário. Eu codifiquei a maior parte. Existem boas razões para proteger a área de transferência. Os usuários colocam todos os tipos de dados confidenciais na área de transferência, enquanto um aplicativo que pode sobrescrever a área de transferência também pode causar danos ao tentar explorar pontos fracos em outros aplicativos que podem ter mais acesso. As APIs da área de transferência do Win32 também permitem alguns comportamentos bastante poderosos que podem ser abusados. Portanto, a área de transferência limita o acesso, a menos que seu aplicativo esteja em primeiro plano ou conectado a um depurador, e restringe um pouco o que você pode colocar na área de transferência (de maneiras que você nunca deve notar, a menos que esteja realmente tentando).

Dito isso, uma notificação com a qual está havendo interação parece que deveria ter acesso à área de transferência. Isso exigiria tratamento especial devido à forma como o Windows e o primeiro plano são contados, eu acho, mas não parece além do razoável. Envie comentários da API e promoverei esse problema no banco de dados de bugs também.

Empacotando

Espero que seja útil. Vou rastrear o tópico e acompanhar os problemas acima, conforme observado, se você os enviar.

Por respeito à equipe WinUI, que já tem muito em suas mãos, deixe este tópico terminar e se concentrar apenas nos aspectos de WinUI e Janelas levantados neste tópico. Como este é tão longo e sinuoso, pode ser útil separá-los em questões menores e separadas. Vou deixar isso aberto por alguns dias para que todos vocês enviem comentários e deixem comentários com links, depois fecharei este tópico.

Se você quiser mergulhar mais nas discussões do sistema de tipo WinRT, o projeto xlang é um bom lugar para começar. Para comportamentos específicos da API do Windows, o hub de feedback é uma escolha melhor. Ele também tem um sistema de comentários agora, então espero que isso ajude.

Obrigado novamente por uma ótima discussão e todos os comentários detalhados sobre tantos tópicos.

Ben Kuhn
Microsoft

Seu aplicativo não fecharia se você apresentasse seletor (es) de arquivo que permite ao usuário escolher a que deseja dar acesso ao seu aplicativo.

Eu não posso enfatizar o suficiente o quão importante isso é como um usuário. Não quero dar a nenhum aplicativo acesso a tudo, mas se você pedir uma localização estranha _e faz_ sentido, vou conceder acesso.

@BenJKuhn Obrigado pela resposta detalhada. Muito, muito apreciado!

• WPF. Eu tenho uma relação de amor e ódio com a WPF. É útil e principalmente bom. Mas quando li o comentário sobre cliques aninhados no seletor de arquivos, isso me fez rir. Porque existem algumas peculiaridades no WPF que me deram verdadeiras dores de cabeça. Como o fato de que, quando você arrasta no WPF, as mensagens de arrastar despacham duas vezes em uma mensagem aninhada, de modo que você está realmente fazendo um arrasto modal dentro de um arrasto modal. Você geralmente nunca percebe. Usualmente. Mas ainda gosto do WPF. 😉

Eu concordo totalmente. Não sou um defensor do WPF, já cheguei aos limites do WPF há muito tempo. Essa é a razão pela qual me mudei para a UWP. Em termos de estabilidade, o WPF parece muito mais estável.

WinRT vs. UWP vs. .NET - alguns antecedentes

Depois, há a biblioteca de API. Fizemos algumas coisas ótimas aqui e algumas coisas bobas. Podemos ter nos empolgado um pouco com algumas das coisas assíncronas.

Você pode dizer isso de novo :)

A portabilidade de código entre aplicativos UWP e aplicativos de desktop também foi abordada neste tópico [...], mas a correção real será, eventualmente, remover a distinção em uma versão futura do CRT, que inerentemente requer renomear os arquivos e uma grande mudança significativa .

Qualquer hora prevista de chegada? .Net 5?

APIs de sistema de arquivos para aplicativos modernos são dolorosamente e inesperadamente lentos

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Ouvimos esse feedback, tanto de clientes quanto de nossas próprias equipes de criação de aplicativos. Eu gostaria de ter mais para compartilhar neste momento. Por enquanto, tudo o que posso dizer, infelizmente, é “nós sabemos”.

Até agora, tenho uma solução alternativa - longe do ideal, mas por enquanto estou bem - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

A API / capacidade BroadSystemAccess não é prática quando implementada.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Envie um item do hub de feedback e me envie o link. Vou promovê-lo pessoalmente e entregá-lo ao proprietário certo. Uma taxa de redução de 80% não é boa. eu entendo

Vou servir, espero chegar lá no fim de semana.

o fato de ser uma bandeira vermelha para os usuários também. SE, as APIs de arquivo forem rápidas o suficiente, parece que a lista de acesso futura mitigaria pelo menos alguns dos

Sim, se a API StorageFile / Folder fosse tão rápida quanto System.IO (ou pelo menos comparável), isso o atenuaria. Não é por falta de tentativa - fiz tudo o que está descrito na documentação.

dor, mas pode não ser tão 'liso' como o que você tem agora. Mas então, você está entre uma rocha e um lugar duro. Para ser mágico do jeito que você está fazendo agora, você precisa que o usuário deixe você ver tudo. A planilha de senha, a pasta de e-mail, o cache do navegador, etc. Você pode ser confiável, mas seu aplicativo deve fazer os usuários pausar e pensar sobre o quanto eles confiam em você antes de entregar o mundo deles.

Eu entendo totalmente tudo isso. E eu concordo com você. Meu ponto de dor é a implementação atual de tudo isso. Já reescrevi a maior parte da interface do usuário que lida com isso (várias vezes).

Dito isso, aqui estão minhas idéias para melhorias:

• "Selecionar pasta" poderia ser um pouco mais útil - eu poderia especificar os arquivos nos quais estou interessado e destacar para o usuário as pastas que os contêm
• Área de transferência - se o usuário colocar alguns arquivos / pastas na área de transferência e, em seguida, voltar ao meu aplicativo, terei acesso a eles automaticamente (talvez você possa adicionar um recurso "ClipboardFilesAndFolders")
• arrastar e soltar arquivos / pastas - isso deve me dar automaticamente acesso a esses arquivos (por que o usuário os soltaria em meu aplicativo de outra forma?)

Eu entendo que a ideia de fechar o aplicativo e reiniciá-lo é uma etapa estranha. Este parece ser o tipo de coisa que deve ser resolvida pelo menos no primeiro lançamento. Envie um item de feedback separado. A mesma oferta. Vou promover e entregar.

Compreendi, obrigado - no fim de semana.

Arrastar o arquivo para os aplicativos não permite acesso de gravação: a mesma oferta sobre o hub de feedback. Por favor, arquive e eu encaminharei de acordo.

Certo, vou servir - a coisa sobre arrastar arquivos para aplicativos. Na verdade, ainda não tentei:

1. funciona com arquivos e pastas?
2. obtenho acesso ao .Path?
3. É persistente (presumo que não)?
4. Preciso manter o StorageFile / Folder, ou recriá-lo mais tarde a partir de .Path funcionará (presumindo que a resposta de 2. seja SIM)?

Criação de aplicativos para sideload fora da loja MS

A conclusão que peguei aqui é que a maior parte do problema é um problema de doc, mas toca em outro aspecto-chave. Como algumas de nossas ferramentas mudaram para projetos github e código-fonte aberto, a documentação mudou com isso, e isso torna mais difícil usar a documentação do Windows como um balcão único para tudo. Levantarei esse problema internamente com relação ao problema específico em torno do arquivo .appinstaller e discutirei de maneira mais geral com nossa equipe de conteúdo sobre como lidar melhor com isso.

Sim, isso seria incrível!

Pessoalmente, descobri isso para meu aplicativo. Isso está me impedindo de fazer outras coisas avançadas que eu gostaria de fazer (como ter um aplicativo win32 para iniciar, já que tenho medo de como todo o arquivo .appinstaller precisaria ser alterado).

Mas, para mim, isso deve fazer parte do processo de "Publicação" do Visual Studio. Você deve criar um .appinstaller para mim (já que obter todos os nomes de dependências corretos está longe de ser trivial, e quaisquer atualizações nas dependências -> lá vamos nós de novo). Ele também deve criar um arquivo readme.txt, no qual deve explicar o que eu preciso fazer upload para o meu servidor, e também me dizer que não posso usar o .appinstaller localmente, ele precisa ser baixado do servidor (durante o teste )

Você também observou um problema específico sobre a necessidade de rotear pelo servidor para depurar. Que você deve arquivar como um problema contra o projeto github existente.

Não me lembro qual era o problema :)

A central de feedback deve avisar ao abandonar para evitar a exclusão acidental de conteúdo

Sim, vou marcar isso com +1. Por favor, arquive. Há uma categoria no hub de feedback em aplicativos para ... hub de feedback. Isso é tão meta.

Direito :)

As APIs assíncronas ainda estão fora de controle e parecem estranhas para coisas que não deveriam ser assíncronas

Sim. Isso continua a ser um tópico de debate interno também. Há um equilíbrio tênue entre babá e incentivo ao bom comportamento que ainda não atingimos. Continue a enviar comentários sobre APIs específicas que você adoraria ver serem síncronas.

Hehe, essa é uma lista longa;)

1. Ele começa com propriedades básicas em StorageFolder / File; StorageFile.GetFileFromPathAsync (+ semelhante para pasta).
2. Carregando miniaturas (StorageFile.GetThumbnailAsync
3. Carregando bitmaps. Isso é especialmente doloroso, já que foi levado para outras bibliotecas (como win2d), e eu atingi limites insanos - como carregar um bitmap simples (que deve levar <20ms), para durar 5 segundos ou mais. É claro que há algum bloqueio nos bastidores, mas ninguém sabe o quê / por quê / quando. E sim, meu laptop é um foguete.

Eu não acompanhei muitas outras APIs, uma pesquisa rápida em meu projeto mostra 326 usos - eu reduzi muito isso, já que muitas coisas do meu lado precisam ser síncronas.

Acima são minhas principais dores, do topo da minha cabeça. A partir de agora, vou criar um documento e adicioná-lo :)

Não há boas APIs de áudio no WinRT

Não sou um especialista em áudio. Sinta-se à vontade para arquivar no centro de feedback, mas também irei ligar para um salva-vidas aqui e fazer algumas perguntas.

Não tenho certeza se / como isso será resolvido. O mais fácil seria afrouxar os requisitos ou algo assim, para que o naudio (https://github.com/naudio/NAudio) possa ser portado corretamente para UWP. Para ser claro, ele pode ser compilado para UWP fora da caixa, mas é inútil porque a maior parte do material de uso é # ifdef-ed.

Para ser claro, não estou reclamando da API de som no UWP - o que é totalmente bom, mas preciso de mais. Ou seja, a capacidade de interpretar ondas sonoras e similares (que o naudio permite).

Eu fiz um port do naudio, onde quase removi todos os #ifdefs - funciona, mas meu aplicativo nunca vai chegar à loja MS - e estou bem com isso.

Dores na área de transferência

[...] Dito isso, uma notificação que está sendo interagida parece que deveria ter acesso à área de transferência. Isso exigiria tratamento especial devido à forma como o Windows e o primeiro plano são contados, eu acho, mas não parece além do razoável. Envie comentários da API e promoverei esse problema no banco de dados de bugs também.

Parece bom, vai servir.

Obrigado!

@jtorjo Você faria a gentileza de incluir também o problema # 1893 (Proposta: Acesso ao sistema de arquivos: fornecer uma maneira amigável de solicitar permissão para acessar locais específicos de arquivos) em seus itens do Centro de Feedback sobre o sistema de arquivos (caso você não tenha feito isso) não planeje isso já, acho que você listou o problema subjacente acima). Infelizmente, já tenho um monte de outros itens para arquivar, então se você pudesse cobrir este quando lidar com o Sistema de Arquivos, seria ótimo :)

Claro, eu ainda o arquivaria se adicioná-lo ao Centro de Feedback fosse inconveniente para você!

@ Felix-Dev farei o meu melhor! Manteremos você informado!

Arrastar o arquivo para os aplicativos não permite acesso de gravação: a mesma oferta sobre o hub de feedback. Por favor, arquive e eu encaminharei de acordo.

Certo, vou servir - a coisa sobre arrastar arquivos para aplicativos.

Esta deveria ser a nota sobre como abrir a partir de um menu de contexto do shell. Desculpe pela confusão.

@BenJKuhn Tendo em vista que este

@Felix-Dev Para propostas específicas, honestamente acho que é melhor começar a enviá-las ao Centro de Feedback com a tag "Plataforma do Desenvolvedor> Feedback da API".

Olhando os comentários recentes arquivados sob esse filtro, parece que não foram adicionados comentários muito específicos. Eu vi apenas 30 itens (no máximo) arquivados sob esse filtro. No entanto, os engenheiros responderam aos comentários lá recentemente.

Estou convocando a comunidade para enviar seus comentários sobre a API por meio do Centro de Feedback, conforme marcado acima, e começaremos a ver isso florescer como uma opção para enviar comentários sobre a API assim que as propostas ficarem melhores.

Acho que @BenJKuhn vai concordar comigo.

Acabei de notar que minha resposta se tornou bastante longa, então tome isso como um aviso 😅

@ duke7553 Temos uma situação aqui em que a comunidade deve usar duas plataformas diferentes para seus comentários sobre a plataforma UWP. Solicitações de API específicas como (adicione o parâmetro x ao método y ou adicione um método para fazer z) devem ser arquivadas no Centro de Feedback pelo menos (embora provavelmente também devam ser postadas em um local adicional). No entanto, questões / propostas mais complexas do que essa (até chegar ao âmago da plataforma UWP) devem definitivamente ser postadas em outro lugar que não o Centro de Feedback em sua forma atual. É bom postar um breve resumo no Hub de Feedback, mas para qualquer outra coisa, o Hub de Feedback não é a plataforma no momento. Leia abaixo para mais detalhes sobre o porquê.

Em seu estado atual, o Centro de Feedback simplesmente não é visto de forma positiva pelos muitos membros ativos da comunidade de desenvolvimento com base em seus sentimentos expressos neste mesmo repositório e em outros lugares como o Twitter repetidas vezes . Os problemas destacados aqui, por exemplo, são:

• A (percebida) falta de envolvimento das equipes de desenvolvimento do Windows (acabei de olhar para os comentários recentes da API arquivados também e muitos problemas aparecem com 0 comentários e nenhuma resposta oficial no momento, especialmente em relação aos problemas de 2 meses e Mais velho).
• O envolvimento da comunidade em questões / propostas específicas é bastante baixo (votos positivos, comentários).
• A UI / UX geral do Centro de Feedback, que realmente torna muito difícil ter discussões de feedback envolventes com a equipe e a comunidade. Sobre isso, algumas pessoas da equipe WinUI afirmaram que também concordam com a comunidade aqui .
• Finalmente, é muito mais fácil no Github agora adicionar arquivos de mídia de suporte, como imagens ou GIFs, a uma proposta para ajudar a visualizá-la. Vou apenas deixar esta imagem aqui tirada diretamente do Centro de Feedback ao preencher um problema:
  

Eu não usei o Feedback Hub antes para registrar problemas específicos da plataforma de desenvolvimento e estou olhando para eles agora, vendo como os problemas são recebidos pela comunidade (quase zero envolvimento da comunidade!), As equipes de desenvolvimento do Windows e sua estrutura geral, devo dizer este único repositório WinUI é superior ao Centro de Feedback em basicamente todos os aspectos (facilidade de criação de propostas / envolvimento da comunidade / disponibilidade de desenvolvedores MS / ...).

Não é nem perto, honestamente.

Especialmente quando se trata de envolvimento da comunidade. Não posso deixar de enfatizar o quão excepcional a contribuição da comunidade foi neste repo aqui e tem impulsionado maciçamente e melhorado tantos problemas / propostas. Todas essas ótimas contribuições da comunidade desapareceriam se fossem arquivadas apenas no Centro de Feedback atual.

E sobre as respostas da equipe de desenvolvimento aos meus problemas de modelo de aplicativo UWP criados aqui, direi apenas o seguinte: Em muitos casos como este , recebi feedback oportuno com a observação de que um item de trabalho foi criado internamente. O que mais posso pedir? Compare isso com o sentimento de muitos desenvolvedores, que acham que seus problemas não levarão a lugar nenhum se forem arquivados no Centro de Feedback. E posso ver de onde estão vindo apenas olhando para o Centro de Feedback agora.

@BenJKuhn
As equipes da MS precisam intensificar seriamente sua plataforma de feedback UWP e até que eu tenha visto essas melhorias, sempre usarei este repositório aqui também, desde que permitido pela equipe WinUI. O Centro de Feedback atualmente é o ponto mais baixo aos olhos de muitos desenvolvedores do Windows e uma postagem durante a noite não mudará repentinamente essa situação. É um começo, mas muito mais é necessário para reverter fundamentalmente as impressões negativas que muitos desenvolvedores receberão ao falar sobre o Hub de Feedback (ou outras plataformas de feedback de desenvolvedor específicas da MS, como o UserVoice for UWP desativado anteriormente). Dadas as muitas experiências decepcionantes que muitos desenvolvedores de UWP / Windows tiveram ao lidar com o Hub de Feedback ou outras plataformas de feedback anteriores, eu - sobre este assunto - acredito fortemente que as equipes de desenvolvimento e feedback do Windows precisam dar um passo à frente, em vez de implorar aos desenvolvedores para retorno (sem muitas - se houver - melhorias visíveis para mostrar). Eu reconheço que essa é uma visão bastante dura, mas se você realmente olhar as muitas respostas dos desenvolvedores fornecidas neste repo e em muitas outras plataformas de feedback ao longo dos anos, verá facilmente que há uma frustração real na comunidade de desenvolvimento.

Não quero ser apenas duro aqui, pois os dois lados precisarão um do outro para criar uma plataforma de feedback vibrante e frutífera, fornecendo altos valores de satisfação para a Microsoft e para a comunidade de desenvolvedores. Como um compromisso, estive sugerindo em minha postagem acima para postar problemas UWP aqui neste repositório, onde eles podem ser ativamente discutidos com a comunidade e postar um breve resumo com um link para o tópico do github incluído no Centro de Feedback. Além de todas as vantagens que isso teria para a comunidade que listei acima, o link adicionado também dará às equipes de desenvolvimento do Windows uma olhada nas muitas visualizações diferentes presentes nesta comunidade e até mesmo capturará muitas pequenas ideias que provavelmente nunca serão arquivadas no Centro de Feedback, mas pode ser encontrado em muitos dos comentários aqui .

Vou terminar este post com uma captura de tela tirada da plataforma do desenvolvedor do Centro de Feedback -> seção Feedback da API:

PS: Usarei esta postagem para agradecer sinceramente à equipe do WinUI novamente por concordarem em abrir seu repositório para hospedar problemas que não estão relacionados ao WinUI, mas em vez disso, visam abordar problemas fundamentais que os desenvolvedores estão vendo no UWP . Obrigado, equipe WinUI!

@BenJKuhn

Aqui estão os problemas do hub de feedback que criei

A API / capacidade BroadSystemAccess não é prática quando implementada. https://aka.ms/AA804aq

API BroadSystemAccess / não deve reiniciar o aplicativo quando o usuário permite amplo acesso ao sistema https://aka.ms/AA7zpe3

A área de transferência deve funcionar o tempo todo. https://aka.ms/AA804ce

Acesso ao sistema de arquivos: fornece uma maneira amigável de solicitar permissão para acessar locais de arquivos específicos https://aka.ms/AA804cp (para @ Felix-Dev)

Não há boas APIs de áudio no WinRT https://aka.ms/AA804d0

As APIs assíncronas ainda estão fora de controle e parecem estranhas para coisas que não deveriam ser assíncronas https://aka.ms/AA804d3

Outras coisas que criei

Mais detalhes - deve permitir mais caracteres https://aka.ms/AA7zws5

Escolha uma categoria - torne isso mais fácil https://aka.ms/AA804cd

Coisas sobre as quais não tenho certeza

Arrastar e soltar arquivos / pastas - eu não testei pessoalmente. Ou seja, não estou curioso sobre a parte de arrastar e soltar, que não é muito difícil de implementar. Estou curioso para saber se realmente funciona quando o usuário descarta arquivos / pastas em um controle UWP. Eu tenho acesso somente leitura (o que seria suficiente para mim)? Posso adicionar esses arquivos / pastas a FutureAccessList?

Estou curioso para saber se alguém testou / usou isso com sucesso, uma vez que não há muitas informações online.

Centro de feedback

O centro de feedback não é uma experiência agradável. Por um lado, os problemas que adiciono não aparecem em "Meus comentários" por um tempo - preciso fechar e reiniciar o aplicativo. Não se lembra da minha última seleção. Não consigo escrever muito texto, não há como descartar um arquivo e / ou imagens da área de transferência. Portanto, estou totalmente de acordo com @Felix-Dev - é realmente difícil entender onde postar problemas (exceto, de agora em diante postarei no xlang).

@BenJKuhn Aqui está o link da https://aka.ms/AA7zx69

Obrigado a todos pela ótima discussão. Eu encaminhei cada um dos problemas de plataforma que você arquivou para as equipes apropriadas. Para definir as expectativas de acordo, deixe-me fazer uma analogia com a procura de emprego: é um pouco como passar pela triagem e ir direto para a entrevista no processo de contratação. A partir daqui, cada problema está nas mãos da equipe certa para investigar e priorizar.

Agradeço o esforço que você fez para relatar esses problemas e continuarei a rastreá-los à medida que as equipes os analisam. Espero que cada um de vocês continue a se envolver conosco nos problemas que encontrar e farei o meu melhor para apoiá-los no aprimoramento da experiência do desenvolvedor de aplicativos no Windows.

Obrigado,

Ben Kuhn

@jtorjo, você poderia compartilhar o relatório WACK para a porta UWP do NAudio que você construiu?

Esses dados nos ajudariam a avaliar quais restrições precisaríamos relaxar para que o NAudio pudesse passar pela certificação da Loja.

@mikebattista Anexei o WACK. Por favor, leve em consideração apenas os problemas de áudio.

Claramente, os problemas do log4net também seriam legais de resolver, embora eu presuma que, ao bifurcar o log4net e remover essas chamadas, eu ficaria bem. No entanto, é estranho que eles apareçam, já que tenho quase certeza de que nunca fomos realmente chamados. Qualquer forma...

FindFirstFileExFromApp - isso deve (e de fato existe) - definitivamente não deve ser sinalizado.

Você pode ignorar o EnumChildWindows / EnumWindows - eu posso #ifdef-los.

ValidationResult.zip

Obrigado! Avaliaremos as falhas de API com suporte. Entrei em contato com a equipe de áudio para obter sua opinião sobre o possível relaxamento de quaisquer restrições aqui.

@mikebattista incrível, obrigado! Estou ansioso por isso :)

@jtorjo em relação ao cenário de arrastar e soltar:

1. funciona com arquivos e pastas?
   Deve e funciona para muitos aplicativos e testes; se você descobrir o contrário, registre um bug sobre isso.
2. obtenho acesso ao .Path?
   Talvez - se houver um caminho real do sistema de arquivos para fazer o backup do item de armazenamento, então sim. (coisas como as bibliotecas de shell não têm um caminho real do sistema de arquivos)
3. É persistente (presumo que não)?
   Não, o aplicativo pode torná-lo persistente adicionando-o à lista de Acesso futuro.
4. Preciso manter o StorageFile / Folder, ou recriá-lo mais tarde a partir de .Path funcionará (presumindo que a resposta de 2. seja SIM)?
   Você precisa adicioná-lo à Lista de Acesso Futuro ou às Listas de Usados ​​Mais Recentemente, caso contrário, o ÚNICO acesso que você tem é por meio dessa instância de um objeto. Quando você libera essa instância, o acesso desaparecerá.

Com relação à adição de arquivos de vídeo de locais arbitrários - o sistema deliberadamente não permite acesso arbitrário, no entanto, ainda é possível para um aplicativo lidar com o caso comum de arquivos colocados em locais alternativos e os usuários não atualizaram a biblioteca para incluí-los. O indexador e os serviços de detecção de armazenamento contêm código para verificar periodicamente a unidade em busca de detalhes (tamanhos de arquivos, etc.) e são aproveitados para localizar arquivos de foto e vídeo. Um aplicativo pode usar as APIs StorageLibrary para determinar se algum desses locais que ainda não estão na biblioteca foram encontrados e, em caso afirmativo, solicitar ao usuário que os adicione. (Isso mantém o usuário no comando e permite um cenário de caso comum) Nada adicionará automaticamente todos os locais que contêm arquivos, pois não há como determinar se isso é a coisa certa a fazer. [Eu uso várias ferramentas de construção e renderização de modelos 3D e tenho literalmente milhares de imagens de textura que não gostaria de mostrar na minha biblioteca de fotos, por exemplo]

'FindFirstFileExFromApp - isso deve (e de fato existe) - definitivamente não deve ser sinalizado.'
Concordo totalmente que todas as * APIs FromApp são projetadas e destinadas ao uso em aplicativos de contêiner de aplicativos. Portanto, se as ferramentas sinalizam algum deles, esse é um bug que precisamos resolver.

@ smaillet-ms Obrigado por responder aqui. Está sendo feito um trabalho para melhorar a velocidade das APIs Windows.Storage? Há muito tempo que esperamos por uma resposta. Eu estaria disposto a assinar um NDA para usar as APIs aprimoradas em meu cenário de aplicativo.

Atualmente, uso a implementação FromApp de FindFirstFile, mas é impossível obter miniaturas de itens usando uma API FromApp.

Esse nível de sigilo sobre o trabalho que está sendo feito para melhorar o Tempo de Execução do Windows contrasta com o que foi compartilhado anteriormente pelos engenheiros da Microsoft no thread.

Link de feedback ignorado relevante: https://aka.ms/AA6dgqz

Apenas para adicionar aqui, detalhes específicos podem ser protegidos por trás de um NDA, mas se houver trabalho sendo feito neste tópico internamente, muitos desenvolvedores UWP se sentiriam mais seguros se a MS declarasse isso publicamente (junto com uma visão geral de quando podemos esperar ver / ouvir mais).

Muito trabalho foi feito para melhorar o desempenho das APIs de armazenamento em várias versões do sistema operacional. O desafio neste ponto para os desenvolvedores é principalmente saber quais APIs usar e quando.

Existem muitas maneiras de fazer as coisas e muitas delas são totalmente erradas para uma determinada aplicação. Infelizmente, não existe nenhum tipo de "uma resposta certa e verdadeira", pois realmente depende do aplicativo e do que ele fará com as informações que obtém do sistema de arquivos. As APIs * FromApp fornecerão atualmente o melhor desempenho em relação às suas contrapartes Win32 padrão. Embora, conforme apontado aqui, ele não tenha todos os dados extras do shell, como miniaturas, etc. (que são caros para adquirir se não estiverem disponíveis em um cache). Portanto, se seu aplicativo precisar encontrar arquivos de interesse com base no nome / caminho ou extensão, ele pode fazer isso usando as APIs * FromApp e, em seguida, criar um StorageFile com base no nome para recuperar mais detalhes. Embora haja sobrecarga duplicada nisso, já que as verificações de acesso são realizadas duas vezes neste caso. Se você está tentando encontrar apenas um arquivo, isso geralmente não é um problema, mas a redundância em uma escala maior pode custar. Se você usar o Storage WinRT Apis com o Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties, você pode obter uma enumeração REALMENTE rápida, que retorna a um item de armazenamento totalmente realizado sob demanda, que tem um hit de desempenho, mas é inferior à criação de um item de um caminho, pois isso precisa incluir verificações de acesso adicionais. A desvantagem é que não funciona se o usuário desabilitou o indexador para o local em questão.

Se você estiver preenchendo uma IU, como um aplicativo de fotos / mídia, então as classes BulkAccess são provavelmente sua melhor aposta, pois são voltadas para cenários de uso na IU com virtualização etc. para que possam fornecer dados à IU rapidamente e alimentar mais dados conforme necessário, à medida que o usuário rola pelo conteúdo.

Como eu disse, muitos trade offs. Obviamente, temos trabalho a fazer para descobrir como documentar o processo de avaliação de qual será a melhor opção para um determinado aplicativo. Também continuamos a avaliar os locais onde podemos alcançar as maiores melhorias gerais sem quebrar os aplicativos existentes.

O WinRT é uma grande superfície e não pertence a uma única equipe da MS. Cada equipe avalia suas prioridades para cada versão e pode ou não publicar seus planos com antecedência. Pessoalmente, adoraria ver as coisas chegarem onde temos Zero Overhead em relação às APIs Win32 dentro ou fora do contêiner do aplicativo. Obviamente, não estamos nesse ponto agora e não posso fazer nenhuma promessa de que chegaremos lá, prioridades de negócios e planos em um projeto tão grande como o Windows com tantos usuários finais quanto nós é um processo complexo envolvendo difícil / difícil escolhas em todos os níveis. (Sem mencionar vários desafios técnicos que podem atrapalhar ...)

@ smaillet-ms

@jtorjo em relação ao cenário de arrastar e soltar:

1. funciona com arquivos e pastas?
   Deve e funciona para muitos aplicativos e testes; se você descobrir o contrário, registre um bug sobre isso.
2. obtenho acesso ao .Path?
   Talvez - se houver um caminho real do sistema de arquivos para fazer o backup do item de armazenamento, então sim. (coisas como as bibliotecas de shell não têm um caminho real do sistema de arquivos)
3. É persistente (presumo que não)?
   Não, o aplicativo pode torná-lo persistente adicionando-o à lista de Acesso futuro.
4. Preciso manter o StorageFile / Folder, ou recriá-lo mais tarde a partir de .Path funcionará (presumindo que a resposta de 2. seja SIM)?
   Você precisa adicioná-lo à Lista de Acesso Futuro ou às Listas de Usados ​​Mais Recentemente, caso contrário, o ÚNICO acesso que você tem é por meio dessa instância de um objeto. Quando você libera essa instância, o acesso desaparecerá.

Soa bem. Implementarei isso em meu aplicativo em algum momento.

[...] O indexador e os serviços de sensor de armazenamento contêm código para verificar periodicamente a unidade em busca de detalhes (tamanhos de arquivos etc.) e são aproveitados para localizar arquivos de foto e vídeo. Um aplicativo pode usar as APIs StorageLibrary para determinar se algum desses locais que ainda não estão na biblioteca foram encontrados e, em caso afirmativo, solicitar ao usuário que os adicione.

Não tenho nada contra isso, mas parece uma complicação a mais para meu aplicativo. Você já ouviu falar de alguém realmente usando isso?

No momento, preciso descobrir mil maneiras de lidar com todos os tipos de problemas quando se trata de StorageFolder / File, e esta é apenas mais uma. Isso simplesmente coloca o fardo, mais uma vez, em mim, o desenvolvedor.

'FindFirstFileExFromApp - isso deve (e de fato existe) - definitivamente não deve ser sinalizado.'
Concordo totalmente que todas as * APIs FromApp são projetadas e destinadas ao uso em aplicativos de contêiner de aplicativos. Portanto, se as ferramentas sinalizam algum deles, esse é um bug que precisamos resolver.

Concordou.

@ smaillet-ms

Muito trabalho foi feito para melhorar o desempenho das APIs de armazenamento em várias versões do sistema operacional. O desafio neste ponto para os desenvolvedores é principalmente saber quais APIs usar e quando.

Lamento dizer, mas isso não parece muito reconfortante.

Na época do WPF, eu simplesmente usaria System.IO, faria qualquer consulta de arquivo / pasta que eu quisesse, de uma maneira insanamente fácil, e não me preocuparia com velocidade. Eu só saberia - funciona. 4.000 arquivos, 10.000 arquivos - simplesmente funciona.

Existem muitas maneiras de fazer as coisas e muitas delas são totalmente erradas para uma determinada aplicação.

Isso basicamente diz - as APIs nem deveriam existir em primeiro lugar.

Infelizmente, não existe nenhum tipo de "uma resposta certa e verdadeira", pois realmente depende do aplicativo e do que ele fará com as informações que obtém do sistema de arquivos. As APIs * FromApp fornecerão atualmente o melhor desempenho em relação às suas contrapartes Win32 padrão.

Isso é verdade com certeza. Embora eu já tenha empacotado a * FromApp API em uma classe agradável de usar (para meu próprio cenário), isso é o que o MS também deve fazer - apresentar isso em uma API agradável e fácil de usar - um empacotador C # simples que muito provavelmente, cobre 98% dos casos de uso.

Eu mesma faria, mas não tenho tempo. Posso compartilhar minha aula simples com alegria e alguém pode continuar a partir daí.

Embora, conforme apontado aqui, ele não tenha todos os dados extras do shell, como miniaturas, etc. (que são caros para adquirir se não estiverem disponíveis em um cache).

Concordo - já estou fazendo isso separadamente (pedindo miniaturas em um segmento diferente) - Uma API de consulta para isso faria maravilhas. Basicamente, eu pediria miniaturas em massa. E eu poderia obter um IAsyncEnumerable.

Mais uma vez, o MS pode criar uma API simples para isso e, por enquanto, basta fazer um .GetThumbnailAsync em cada arquivo. Em seguida, forneça-nos a API e, posteriormente, você poderá melhorar sua (s) velocidade (s).

Portanto, se seu aplicativo precisar encontrar arquivos de interesse com base no nome / caminho ou extensão, ele pode fazer isso usando as APIs * FromApp e, em seguida, criar um StorageFile com base no nome para recuperar mais detalhes. Embora haja sobrecarga duplicada nisso, já que as verificações de acesso são realizadas duas vezes neste caso.

No lado positivo, muitas informações já estão presentes na API * FromApp - hora de criação, hora do último acesso, hora da última gravação, tamanho do arquivo.

Se você está tentando encontrar apenas um arquivo, isso geralmente não é um problema, mas a redundância em uma escala maior pode custar. Se você usar o Storage WinRT Apis com o Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties, você pode obter uma enumeração REALMENTE rápida, que retorna a um item de armazenamento totalmente realizado sob demanda, que tem um hit de desempenho, mas é inferior à criação de um item de um caminho, pois isso precisa incluir verificações de acesso adicionais. A desvantagem é que não funciona se o usuário desabilitou o indexador para o local em questão.

Isso tem várias desvantagens - em primeiro lugar, em meus testes, era mais rápido do que os arquivos não indexados, mas não tão rápido. Acho que foi 3x-5x mais rápido, mas ainda é cerca de 10x-50x mais lento que * FromApp. Isso é INSANAMENTE LENTO. Além disso, eu realmente não posso dizer aos meus usuários para verificar a opção "Todos os arquivos têm contexto indexado, além das propriedades do arquivo", é simplesmente a opção dele. E provavelmente muitos usuários simplesmente deixam isso desmarcado.

Na verdade, o Windows deve descobrir automaticamente os arquivos usados ​​e indexar essas pastas - é muito provável que importe muito para arquivos de mídia (vídeo / foto / música) e para documentos.

Se você estiver preenchendo uma IU, como um aplicativo de fotos / mídia, então as classes BulkAccess são provavelmente sua melhor aposta, pois são voltadas para cenários de uso na IU com virtualização etc. para que possam fornecer dados à IU rapidamente e alimentar mais dados conforme necessário, à medida que o usuário rola pelo conteúdo.

Honestamente, eu nem sabia que isso existia - estou olhando para isso enquanto conversamos.
No entanto, se bem entendi, isso é apenas um pouco de açúcar sintático, pois vai sofrer dos mesmos problemas de desempenho que IStorageQuery.

E esses problemas de desempenho são enormes. Eles são tão grandes que, basicamente, para cerca de 1000 arquivos, o primeiro arquivo é recuperado após 9 a 10 segundos. Em outras palavras, assim que você começar a enumerar o resultado, ele será bloqueado por 9 a 10 segundos antes de fazer qualquer coisa. Estou assumindo que o mesmo ocorreria com o FileInformationFactory, apenas que a IU responderá durante esse tempo.

O WinRT é uma grande superfície e não pertence a uma única equipe da MS. Cada equipe avalia suas prioridades para cada versão e pode ou não publicar seus planos com antecedência. Pessoalmente, adoraria ver as coisas chegarem onde temos Zero Overhead em relação às APIs Win32 dentro ou fora do contêiner do aplicativo.

Bem, muitos de nós também;) Eu entendo que o WinRT é uma grande parte do Windows e que diferentes partes estão espalhadas por equipes diferentes.

Não é muito reconfortante para nós não ver publicamente a visão que a MS tem para o WinRT. Não ter uma linha do tempo sobre o que / quando / se acontece.

Para mim, a velocidade de lidar com arquivos / pastas é simplesmente fundamental. Como alguém pode confiar no WinRT / UWP se fazer algo tão simples como enumerar os arquivos em uma pasta pode demorar tanto? E descobrir como melhorar isso se resume a "terei a sorte de minha pesquisa no Google funcionar na * API FromApp"?

Não quero parecer ingrato - realmente aprecio o seu tempo e nos explicando tudo isso. Obrigado!

@BenJKuhn Alguém (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297) preencheu outro tíquete sobre o Problema de "Novo certificado" aqui -> https://aka.ms/AA8bw9v

O lado realmente ruim - eu tentei acessar isso, mas ele me diz que não tenho acesso para visualizar este tíquete. Isso realmente não ajuda com a credibilidade do "Centro de Feedback".

Por que você permite o sideload fora da loja MS, mas torna quase impossível fazê-lo de fato?

Na verdade, isso não é verdade. Você não pode fazer upload de seu aplicativo para a Loja da MS e usar o instalador do aplicativo como forma alternativa de instalar o aplicativo. Meu aplicativo foi banido por causa disso durante a certificação.
Políticas da MS Store:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function - valor-representação precisa

10.1.5
Seu aplicativo pode promover ou distribuir software apenas por meio da Microsoft Store.

Depois de remover o arquivo appinstaller do meu servidor, os usuários podem usar o MS Store novamente para instalar meu aplicativo. Eu entendo - regras são regras, mesmo eu não consigo encontrar uma razão para elas. Mas é realmente decepcionante, quando conheço muitos aplicativos, que são distribuídos através de store e appinstaller (Unigram) ou chocolatey (novo MS Terminal).

Por que você permite o sideload fora da loja MS, mas torna quase impossível fazê-lo de fato?

Na verdade, isso não é verdade. Você não pode fazer upload de seu aplicativo para a Loja da MS e usar o instalador do aplicativo como forma alternativa de instalar o aplicativo. Meu aplicativo foi banido por causa disso durante a certificação.
Políticas da MS Store:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function - valor-representação precisa

Não tenho certeza se estamos falando da mesma coisa aqui - nos dias de hoje, simplesmente não consigo encontrar um único motivo para precisar ou querer a MS Store. Minha queixa é que é extremamente difícil desenvolver um aplicativo e, em seguida, implantá-lo fora da loja da MS.