I was at your frustration level a few years ago when I first started porting over WPF apps. So I certainly understand your sentiments. There has been some progress since then and as you said the WinUI team is really trying on their end.

From my viewpoint there is a fundamental design issue we can't work around: WinRT was technically handicapped because it has to interop directly with C++ and JavaScript (here is an example, and another). It really doesn't play nice with a lot of the high-level concepts either such as generics. Of course there is one big benefit with this architecture as well: All of Windows can now share the same WinRT API's.

WinRT was also done by the Windows team under Sinofsky I believe which means, yes, they lived in their own world and had no experience working with the existing end-user developer ecosystem. We ended up with a 'least common denominator' API that both native and managed developers don't enjoy working with. This is fundamentally one of the main reasons Windows Phone died -- developers couldn't develop/port apps easily. Without Apps there were no customers. Microsoft did learn this lesson.

So we have lost several of the perks of managed code that we've grown accustomed to over the years. It definitely still seems like a step back from WPF -- I find bugs and incomplete features all the time. I think #1830 would never happen in the WPF days. We still have to move forward somehow.

WinUI 3.0 is clearly a step in the right direction to try to fix this on the frontend at least. Though, I would prefer Microsoft implements a more robust development process and more testing before releasing new controls... I know development is now push changes, fix later. While that may work for apps, it's not a good pattern for a platform where once things are set it's very hard to change them later. (TreeView, NumberBox, etc... have so many issues on first release that never would get out the door, let alone planning stages, 15 years ago).

It is sad for me to see what was once the most powerful UI platform WPF evolve into this. But Microsoft is now, slowly but surely, listening to feedback and fixing things. It is understood there is a lot more work to do.

Do you think users will happily do the above? No they won't - in fact, 79.8% don't do it (my AppCenter data backs this up). Leaving me with either users not using my app, or just having my app look subpar to other native apps.

Perhaps you aren't considering the fact that your users are actually stopping to think: "wait, do I really want to grant this app access to my entire drive?" That is a red-light warning for people not familiar with the app/developer/company.

You're blaming the process users need to go through to grant your app access to their entire drive for the low retention rate. Perhaps you should reconsider your "need" for broadFileSystemAccess in the first place, and rather just have users manually select the folders they feel comfortable giving you access to.

FYI, if I wanted to try an app out and after installation it was like "hey, give me permission to access everything, everywhere", I'd run too.

When you request broadSystemAccess, your application, by default, does not have that access.

Obviously... You only made a request, your users actually have to grant you access if they feel comfortable doing so.

Also, based on the disrespectful title alone that breaks the Microsoft Open Source Code of Conduct, and the content not being about WinUI, this issue should be closed. @jevansaks @jesbis

One last thing to add. I think Rich Lander said it best at the Jan 15th .NET Community Standup (starting @ 1:12:40).

@verelpode You ride the line mentioned in the above video, but you stay constructive and on-topic for the most part, so I value your contributions to the WinUI repo - even if you feel they are fruitless sometimes, as I saw in your recent comment(s).

When you request broadSystemAccess, your application, by default, does not have that access.

Obviously... You only made a request, your users actually have to grant you access if they feel comfortable doing so.

That's not the issue: at least on Android/iOS, you get asked that stuff while your app tries to access the HDD, and it does not get closed, as is in our case.

Your app wouldn't close if you presented file picker(s) that let the user choose what they want to give your app access to.

Instead you want it all, are complaining about a minor one-time extra step users have to take, and are blaming your retention rate on this step.

Also, based on the disrespectful title alone that breaks the Microsoft Open Source Code of Conduct, and the content not being about WinUI, this issue should be closed. @jevansaks @jesbis

It's really hard to be respectful, when I'm almost going out of my mind. Not to say - I've said this before, there's no place to write about the WinRT. I'd happily use a different tone, if I actually could write, and someone would be listening. All the above cries should simply not exist - WinRT should be mature enough. Yet... no...

Where can the community actually talk to the WinRT team? Is there anyone listening?

Your app wouldn't close if you presented file picker(s) that let the user choose what they want to give your app access to.

Instead you want it all, are complaining about a minor one-time extra step users have to take, and are blaming your retention rate on this step.

My app is allowing users to edit photos and videos, and I want the user to easily preview as he chooses, not use an old style file picker. So yeah, it's really important that I get access to all the HDD. And no, those "Pictures" and "Videos" virtual folders are what Microsoft thinks users keep their photos and videos. That's not reality.

I've said this before, there's no place to write about the WinRT.

As your links indicate, you've already been ranting about WinRT on the UWP Q&A forums, which is where you've been directed to go.

So by posting here it seems you just want a larger audience, rather than to actually accomplish anything (since the WinUI team doesn't work on WinRT).

As your links indicate, you've already been ranting about WinRT on the UWP Q&A forums, which is where you've been directed to go.

Yet, there's no resolution to any of my issues. On a Q & A, you ask questions, and receive answers. But you can't really suggest anything to change (unfortunately).

My app is allowing users to edit photos and videos, and I want the user to easily preview as he chooses, not use an old style file picker. So yeah, it's really important that I get access to all the HDD.

No its not. Your users don't have photos and videos all over the drive, they are in specific locations that might not be the special folders.

Have the users pick those folders once, then you can always have access via the FutureAccessList. Don't make them give you access to all of their files, and then they won't run away.

@kmgallahan Sure, the tone can be dialed back a bit, but we've all been frustrated before. It's even more frustrating to think that obvious issues aren't being addressed. I think it's sometimes constructive to vent those frustrations in a forum where people can validate them and also offer potential solutions. His technical points are valid, it's just for WinRT and a bit UWP -- both not WinUI XAML controls which this repo represents. For that reason, this probably should be closed as off topic.

I think we can keep these types of discussions professional knowing they originate from frustration and a lot of vested interest in the success of the development ecosystem.

Sure, the tone can be dialed back a bit, but we've all been frustrated before. It's even more frustrating to think that obvious issues aren't being addressed.

Thanks :)

No its not. Your users don't have photos and videos all over the drive, they are in specific locations that might not be the special folders.

Have the users pick those folders once, then you can always have access via the FutureAccessList. Don't make them give you access to all of their files, and then they won't run away.

Clearly, they are not in those specific locations....

Sure, I can use that FutureAccessList and have users remember where they keep their photos/videos, because we all know where we keep all of our photos/videos, right?

Instead of (what my app does) nicely previewing folders and showing you the folders where you have photos/videos.

A few notes:

Thanks @jtorjo for taking the time to write about your experiences and feedback, and also for your time on the Q&A page too.

As @robloo and @kmgallahan mentioned most of this isn't directly related to WinUI and you may be pushing the code of conduct a little 🙂

However we also recognize that engagement on the Q&A site and Feedback Hub could be better when it comes to different areas of the Windows developer platform. We really are actively trying to improve that but I get that it's frustrating to find a good place to provide feedback and see whether anything's happening.

For example we really do see everything that comes through Feedback Hub but there isn't a good way to respond or continue a discussion. So, as long as it stays constructive and is related to Windows app UX/development then we're okay with discussing some general platform feedback here if a topic doesn't currently fit well elsewhere.

For what it's worth, these topics also get serious internal attention. We reached out to some WinRT experts today to see if there's any update on these areas that we can share since you neatly summarized some of the top issues with the overall platform and tools.

For desktop app development: WinUI 3 is a big part of our effort to decouple the Windows developer platform to remove those interoperability barriers and make it easier to incrementally adopt WinUI and UWP. We know we need to better enable desktop apps with modern UX without requiring all the current restrictions. We have lots of experts including some of the main creators of WPF working on it.

In particular, we're spending a lot of time on Xaml islands and on WinUI for desktop apps and we're looking forward to the next step which will be releasing a preview of that for people to try later this year. We're trying to be more feedback-driven and transparent and that should get easier as we move things like the full Xaml platform (i.e. WinUI 3) to open source.

If people are interested in the current state of the desktop plans then we could also go into a bit more detail in one of the monthly Community Calls - feel free to suggest topics here:

WinUI Community Call (January 22, 2020) #1857

Hi @jesbis,

Thanks for looking at my issues!

As @robloo and @kmgallahan mentioned most of this isn't directly related to WinUI and you may be pushing the code of conduct a little 🙂

Yeah, really sorry about that, I just felt I was going out of my mind. The things I mentioned here are critical - I'm really passionate about this, since all of the above I ran into. They all take a huge toll, a lot of people simply just give up even trying.

However we also recognize that engagement on the Q&A site and Feedback Hub could be better when it comes to different areas of the Windows developer platform. We really are actively trying to improve that but I get that it's frustrating to find a good place to provide feedback and see whether anything's happening.

Totally agreed. As a side note, I actually tried to report the broadSystemAccess on Feedback Hub, and after providing all the details, and spending about 15 minutes on it, I ended up somehow probably pressing a hotkey that was the equivalent of "Back" - thus, I lost all my work (no undo, no text being copied to clipboard, nothing). Clearly, I was insanely frustrated and just gave up.

For what it's worth, these topics also get serious internal attention. We reached out to some WinRT experts today to see if there's any update on these areas that we can share since you neatly summarized some of the top issues with the overall platform and tools.

Cool!

For desktop app development: WinUI 3 is a big part of our effort to decouple the Windows developer platform to remove those interoperability barriers and make it easier to incrementally adopt WinUI and UWP. We know we need to better enable desktop apps with modern UX without requiring all the current restrictions. We have lots of experts including some of the main creators of WPF working on it.

That's awesome! I'm definitely looking more that forward to it. It's very likely that I'll update my app once this is done, but until then I'm stuck with a lot of issues.

If people are interested in the current state of the desktop plans then we could also go into a bit more detail in one of the monthly Community Calls - feel free to suggest topics here:

WinUI Community Call (January 22, 2020) #1857

Can I suggest the WinRT topics I mentioned here?

Thanks again!

For example we really do see everything that comes through Feedback Hub but there isn't a good way to respond or continue a discussion. So, as long as it stays constructive and is related to app development then we're okay with taking some general platform feedback here if a topic doesn't currently fit well elsewhere.

@jesbis
This is great news! Many thanks to the WinUI team to show this flexibility and trying to mitigate the (perceived) WinRT-feedback-system issues even though they don't have to!

@kmgallahan

I think Rich Lander said it best at the Jan 15th .NET Community Standup (starting @ 1:12:40).

So Rich Lander says there that he prefers people with a little bit of aggression but nice at the same time. I think one of the biggest problems in society is that many people are so very "polite" that their behavior becomes extremist and flips over to disrespect and rudeness while superficially appearing "polite". Very "polite" people speak indirectly and vaguely, and this makes their communication difficult to understand and easy to misinterpret. Very "polite" people are disrespectful and rude because they're effectively saying the equivalent of:

"I believe that you can't handle the direct truth, therefore I'll handle you with thick fluffy cotton gloves, and pack you in bubble wrap, and speak to you very politely, indirectly, and vaguely, because if I treat you as a mature adult and express my honest opinions, you'll flip out and explode and go nuts. You're a very fragile, delicate person, and you're immature, thus I must speak extremely politely and indirectly to you, because you can't handle the direct truth."

In that way, when so-called "politeness" is taken to an extreme (as many people do), it becomes disrespectful and rude while still appearing to be "polite". In other words, misunderstanding of politeness and respect is one of the biggest problems in society. Many people do not realize that excessive politeness is disrespectful, and causes projects to fail, etc. This problem of false politeness causes yet another communication failure every second of every hour of every day somewhere in the world -- it happens constantly -- and society suffers greatly because of it.

@jtorjo
Here's the origin of the problem:

Repetition of Nokia's catastrophic mistake

WinRT/UWP accidentally repeated the same mistake as Nokia, BlackBerry, Apple at one point, and other companies. The Nokia story: Nokia was a very successful giant, but later Nokia realized that they had fallen behind in smartphone tech. In order to solve this problem, they needed to make it top priority to realize a series of improved versions of their preexisting system. Instead of doing that, they tried to switch to a new system, and it killed them. Literally killed them -- Nokia Mobile was forced to accept being bought-out by Microsoft.

So then you'd expect that Microsoft would learn from Nokia's mistake and not repeat the same problem. Unfortunately Microsoft did repeat the same mistake as Nokia. Microsoft embarked on WinRT/UWP instead of producing new versions of WPF and .NET Framework. Guess what happened? The same catastrophic disaster as Nokia: It killed them. Windows Mobile is dead and was cancelled by Microsoft executives. Thus unfortunately Microsoft didn't learn from Nokia's catastrophic mistake. Now all the smartphones are running either Android or Apple instead of WinRT/UWP, thus WinRT/UWP was a catastrophic failure that caused Microsoft to completely lose their place in a multi-billion dollar smartphone industry. WinRT/UWP caused multi-billion dollar losses for Microsoft.

BlackBerry made the same mistake as Nokia and Microsoft. BlackBerry was very successful, but later BlackBerry realized that they had fallen behind in smartphone tech. In order to solve this problem, they needed to make it top priority to realize a series of improved versions of their preexisting system. Instead of doing that, they tried to switch to a new system. BlackBerry originally used BlackBerry OS, and then around the year 2013, they switched to the QNX system. What happened? The same as WinRT and Nokia. It killed them. In 2016, BlackBerry announced it would cease designing its own phones.

It also happened with Apple at one point in the past. Apple nearly collapsed and was very lucky to survive. A number of years later, Apple eventually made a strong recovery via smartphones. Lucky to be alive after the catastrophic mistake.

Breaking Changes

Microsoft claims they couldn't continue WPF development; couldn't use WPF for smartphones/tablets because of breaking changes, but that's a case of extreme fear of breaking changes. Yes it's wise to be very careful in regards to breaking changes, but if it's taken to an extreme, then it kills projects and companies. The reality is that breaking changes can in fact be introduced. Microsoft could have released "WPF 5" with support for smartphones/tablets/touchscreens, and announced that it includes breaking changes but no developer is forced to upgrade to it immediately. Preexisting apps don't break because they continue to run with WPF 4 until the app developer is comfortable and ready to switch to WPF 5. Thus the breaking changes don't cause chaos or failures.

It's the same principle as a new version of a NuGet package that includes breaking changes. Your app doesn't suddenly break when the new version of the package is released. Your users continue to use your app and don't experience any problems because your app continues to use the old version of the package until you're comfortable and ready to upgrade your app to use the latest version of the NuGet package. Thus breaking changes can be introduced.

Reversal of standpoint on managed code

Microsoft said managed code provides excellent advantages, and it was absolutely true in my experience using both managed and unmanaged code. I began my career writing unmanaged code. Later I tested Microsoft's claims and I switched to managed code and I experienced excellent improvements in productivity and reliability. Later, Microsoft bizarrely reversed their standpoint and produced WinRT with a basis on unmanaged code, and the ancient Component Object Model (COM) from the year 1993, and excessive use of Win16 (also known as Win32). The basis of WinRT is tech that is decades out-of-date: Native code, COM, and Win16 AKA Win32. It shouldn't be surprising that most app developers were reluctant to switch to WinRT/UWP.

Android is now the market leader. Microsoft can learn from Android. Android apps are typically written using managed code. Although I dislike Java and prefer to use C#, I have to say that Java is much better than native Win16 and COM.

Multiple Microsoft staff members still continue saying "native" as if that's a good thing. I began my career with "native" and I know from years of experience that "native" is a bad thing. Legions of Android developers also know that native is a bad thing, but too many UWP staff members say it as if it's great. To use the words of @jtorjo, the WinRT team was and is "out of touch with reality". The WinRT team continues to behave as if WinRT was a success, despite the fact that it failed catastrophically and Windows Mobile was already cancelled by Microsoft executives.

I have to keep repeating those words again and again: WinRT/UWP was a catastrophic failure. I've forced to keep repeating those words because the WinRT team is "out of touch with reality" in the sense that they refuse to acknowledge that WinRT/UWP was a catastrophic failure and that Microsoft shouldn't continue to repeat the same mistakes of WinRT as if nothing happened.

For example, currently DataGrid is written in modern managed code, but the WinUI teams wants to rewrite DataGrid to use "native" code and believes this is an "upgrade" when in reality it is a downgrade and regression to practices that are decades out-of-date. In general, WinRT/UWP is plagued with mix-ups between modern and obsolete software engineering practices. Thus @jtorjo's use of the words _"out of touch with reality"_ could be interpreted as impolite, but I believe it is an accurate description, even if it wasn't the best choice of words.

For another example of _"out of touch with reality"_, look at the design of WebView2 -- it is like taking a time travel back to the start of my career, decades ago, when we used obsolete concepts such as HRESULT instead of modern exception handling. It is astonishing to see WebView2 being released as a new project in the year 2020 yet still using ancient techniques such as HRESULT and LPCWSTR. The design of WebView2 is out of touch with modern software engineering practices.

So, along the lines of what Rich Lander said, my previous message demonstrates my respect for the WinUI team, because if I disrespected the WinUI team, then I would always be very polite to the team, or say nothing at all. If I disrespected the team, I'd write off and ignore WinUI: I wouldn't bother writing any messages at all -- I would view WinUI as "hopeless" and a "lost cause" and I wouldn't give any feedback at all. The fact that I give detailed feedback demonstrates that I respect the team. Many people don't give any feedback -- that's disrespectful to the team. It's disrespectful to view the team as being so hopeless that it's not worthwhile writing any feedback for them.

If you were in court, you'd very politely say "Your Honor" to the judge even if you hate his guts. Extreme politeness is rudeness. Judges interpret "Your Honor" as respect but it's actually disrespect.

Microsoft embarked on WinRT/UWP instead of producing new versions of WPF and .NET Framework. ...

Agreed. I've been developing UWP for quite a few months now... There are quite a few limitations, but I've done my best to be "zen" about it, and more or less, move on. But the more I would work, the more I realized - that the limitations were in fact WinRT, not UWP.

The thing is, this is what we have, and clearly, we need to move forward with it. In my mind, this should be:

1. UWP needs to hide as much as possible the fact that it uses WinRT and
2. WinRT should strive to remove as many (unneeded) limitations as possible
3. The main focus should be Desktop, and then the other platforms (Hololens, xbox etc)

(p.s. The fact that, for a file, to get its properties, I need to call an async function, still makes me twitch)

Reversal of standpoint on managed code

Why we'd need to deal with COM in WinRT is indeed beyond my understanding. Seems they wrapped some old DCOM code or something, but that should be 100% hidden from users of WinRT.
The fact that we need to be aware of COM is really really bad. That, once again, should be as much as possible, hidden from me, the user of the library(ies).

[later edit] Now come to think of it, we'd at least need COM to deal with DirectX. Still, it should be as hidden as possible from the users of libraries.

Multiple Microsoft staff members still continue saying "native" as if that's a good thing.

Native, in the context of "compile to .net native", I do think is a good thing, however, I don't like its limitations. My project fails to compile to .net native, because it uses another lib that I ported to UWP, and uses some APIs, that the powerful Store guys believe is "unacceptable". The lib in question is https://github.com/naudio/NAudio - an awesomely powerful library. For this reason alone, I simply said - I will NOT publish my app to MS store.

For another example of _"out of touch with reality"_, look at the design of WebView2 -- it is like taking a time travel back to the start of my career

I'm not 100% sure, but you're probably right. I do know that WebView is said to be a wrapper over a Win32 control, and I know of a weird bug, that WebView links would not work when the WebView was on top of another control.

Hi @robloo ,

Sorry for the late reply

I was at your frustration level a few years ago when I first started porting over WPF apps. So I certainly understand your sentiments. There has been some progress since then and as you said the WinUI team is really trying on their end.

Yes, totally agree. Back in 2016-2017, I wouldn't even touch UWP.

From my viewpoint there is a fundamental design issue we can't work around: WinRT was technically handicapped because it has to interop directly with C++ and JavaScript (here

That is beyond sad, to say the least ... Why of why would we want JS interoperability?

... is an example, and another). It really doesn't play nice with a lot of the high-level concepts either such as generics. Of course there is one big benefit with this architecture as well: All of Windows can now share the same WinRT API's.

There are many things I hate about WinRT - what's one more to the list?

The fact that I even need to know about this, is bad. In fact, I needed to create such 2 small projects, and it was all trial and error, to understand what I'm actually allowed to use.

So we have lost several of the perks of managed code that we've grown accustomed to over the years. It definitely still seems like a step back from WPF -- I find bugs and incomplete features all the time. I think #1830 would never happen in the WPF days. We still have to move forward somehow.

Yup, we do...

WinUI 3.0 is clearly a step in the right direction to try to fix this on the frontend at least. Though, I would prefer Microsoft implements a more robust development process and more testing before releasing new controls... [...]

Agreed 100%.

It is sad for me to see what was once the most powerful UI platform WPF evolve into this. But Microsoft is now, slowly but surely, listening to feedback and fixing things. It is understood there is a lot more work to do.

Yes, there are clearly awesome people at MS that are listening. Lets hope we can turn this around...

The Querying for files API Is Beyond slow

Apparently, someone did find a workaround to this. Clearly, it's really really sad this took so long - and this is not preferred way I would like to deal with searching for files, but at least it actually works.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment-575987737

So, many thanks to @duke7553 !

@jtorjo Happy to help!

I find this discussion very interesting and actually very relevant to the future of Windows UI. That's because WinUI is not sitting in a vacuum. This whole repo has very little value unless it's useful for creating apps that run on something other than WinRT/UWP. WinUI 3.0 could not come soon enough.

We have a vision and a roadmap for the UI on windows, but that sits on the very top of the stack and there is no vision for what's under that surface layer:
Is WinUI looking good? YES
Can you make modern, good looking apps on Windows now (JAN2020)? NO
Can you make a good app with UWP? HELL NO!

We can't really move forward without addressing the elephant in the room: mentioned earlier fact that WinRT and UWP were total failures, not only business-wise but also technologically. I'm personally among the body count. I stopped developing my hobby project when I couldn't figure out how to play a sound when my app lost focus. Trivial. Do trivial things has to be as hard as they are in UWP? Can you call a platform great when trivial things are impossibly difficult? WinUI is just part of a platform, isn't it?

Another elephant in the room. If someone asks: I want to make a new Windows program, what's the best way to do it? There is no straight answer in JAN2020! If you try putting UWP into the answer - you WILL have a bad time. (Is there a single comment, blog post, YouTube video where somebody said: I made a great app with UWP and I liked the process? We all know there isn't. No one is writing about making app with UWP, it literally doesn't exist on the Internet). WPF? No modern controls - dead tech, not a good idea (still better than UWP, though). The honest answer would have to be: try electron, maybe? VSCode is made with that, so you know you can make a good app with it.

And this idea that you can make an app for windows with any language you like is just a cop-out. We are in a situation where you can make a very bad UWP app with any language you want. Bot not at least ONE excellent way of doing it.

The navie thing mentioned before in the thread? Completely agree. Visual Studio - The Juggernaut itself (UI) is made with managed code - WPF. It's great, fantastic even. While even Microsoft can't make OK apps with this supposed superion native code. I see unexpected behavior every single day with OneNote, Weather, and even Start/Search/Taskbar. It feels wonky and sometimes focus doesn't work as it should.

This is a rich and important topic. Very much relevant to WinUI, and sadly there is no better place to talk about it. These topics need to be handled in an open way by Microsoft.

We have a vision and a roadmap for the UI on windows, but that sits on the very top of the stack and there is no vision for what's under that surface layer:
Is WinUI looking good? YES

Yes it is!

Can you make modern, good looking apps on Windows now (JAN2020)? NO

I do believe you can - but it's really really hard. Trivial things are insanely hard to do (I'm living proof it's possible, but you need nerves of steel for sure):

• on the UI front, there will be issues, but usually you'll get the hang of it
• on the "anything else" front, things are pretty dim.
• dealing with files on UWP is complete hell, due to the StorageFile/Folder API, which, to put it midly, I hate with all my heart

We can't really move forward without addressing the elephant in the room: mentioned earlier fact that WinRT and UWP were total failures, not only business-wise but also technologically. I'm personally among the body count. I stopped developing my hobby project when I couldn't figure out how to play a sound when my app lost focus. Trivial. Do trivial things has to be as hard as they are in

Agreed. Indeed, playing system sounds, which in WPF is like SystemSounds.Beep.Play(), it's not available on UWP.

Basically, there's no sound library on UWP, due to the "great" WinRT restrictions, which basically means - you can't import any functions from DLLs that are win32. So pretty much, every decent library can't be ported to UWP. No libraries, no apps.

On the "sound library" on UWP, naudio has tried its best to work on UWP. Clearly, it fell flat. I did a fork, removed a lot of #ifdefs, and it now works for my needs. I will never be able to publish my app to MS Store, nor do I ever want to.

The best step in the right direction, on my mind, is for MS to

1. Finally focus on Windows Desktop FIRST. Stop going after a thousand platforms, like Hololens, Xbox and the like. Sure, there will be people wanting to develop for those platforms, but the percentage is minuscule.
2. Remove all restrictions API wise - so people can actually compile libs to UWP
3. Once you request broadSystemAccess, just give it and stop being so overprotective.
4. Once you request broadSystemAccess, allow System.IO over all HDD
5. Make it easy to distribute outside the MS store (+ fix the "New Certificate" issue)

Another elephant in the room. If someone asks: I want to make a new Windows program, what's the best way to do it? There is no straight answer in JAN2020! If you try putting UWP into the answer - you WILL have a bad time. (Is there a single comment, blog post, YouTube video where somebody said: I made a great app with UWP and I liked the process? We all know there isn't. No one is writing about making app with UWP, it literally doesn't exist on the Internet). WPF? No modern controls -

Yes, I concur - finding good resources on UWP is close to zero. A lot of issues, you'll just have to tackle and fix on your own.

dead tech, not a good idea (still better than UWP, though). The honest answer would have to be: try electron, maybe? VSCode is made with that, so you know you can make a good app with it.

About WPF I only have words of praise. I've developed for quite a few years. and while the learning curve is quite steep, once you get the hang of it, it's amazing! I did find a few hardcore bugs, which I knew would never get fixed, but that's that.

I was forced to move to UWP, since in order to make my app fast enough, I had to use win2d. There are things that are missing from UWP when it comes to UI (like, at the time I began porting, there's no native way to define the Cursor for a control), but all in all, I always found workarounds.

The navie thing mentioned before in the thread? Completely agree. Visual Studio - The Juggernaut itself (UI) is made with managed code - WPF. It's great, fantastic even. While even Microsoft can't

Clearly, I bet my a**, that you could not create Visual Studio in UWP for the life of me -- and I'm not talking about the UI, you could match and exceed the UI of Visual Studio, but the rest....

This is a rich and important topic. Very much relevant to WinUI, and sadly there is no better place to talk about it. These topics need to be handled in an open way by Microsoft.

100% agreed!

Can you make modern, good looking apps on Windows now (JAN2020)? NO

I do believe you can - but it's really really hard. Trivial things are insanely hard to do (I'm living proof it's possible, but you need nerves of steel for sure):

• on the UI front, there will be issues, but usually you'll get the hang of it
• on the "anything else" front, things are pretty dim.
• dealing with files on UWP is complete hell, due to the StorageFile/Folder API, which, to put it midly, I hate with all my heart

We are like beaten dogs here. It is actually soo hard to make a new modern app for Windows desktop! Shouldn't there be at least one excellent way of doing apps? When you go to Microsoft Store on windows and try to scroll apps category you won't find any decent app made with UWP. Btw I can't check it myself because ...

Yep, "modern", "native" app ladies and gentlemen. Since Windows is now practically free shouldn't the main source of monetization be the most solid app on the system, but I digress. You actually don't need to research the app to know what tech it was made with. Just one look and you can tell if it was built with UWP. There are no serious commercial projects build with UWP, and what is built with it is ... you know ...

And that is because it IS soooo hard. Window10 is the biggest platform after The Internet and Android!!! But No One is making apps for it with the tools that were supposedly made for that purpose! Just contemplate on that. It's easier to build an Electron app for 3 operating systems than just for Windows with UWP!

Is it OK for us, beaten dogs, that just want to build Windows desktop apps to demand excellent tools? I say unapologetically yes! But all we have is radio silence from Microsoft. Who wants to hear a fairy tale that your app might work on Holo Lens or a Windows Phone or Xbox? Nobody. After 5 years there has been no commercial app that works on 2 fo those platforms promised for UWP. (Mostly because those platforms don't exit). Again, ponder that! The best thing that has happened to us is WinUI is being ported BACK to old win32.

I love Windows desktop, I learned to program doing C# on WinForms and WPF. And it was easy and excellent for a noob like I was. Today I am salivating looking at those juicy controls in WinUI, but somebody has to come clear on the big picture for the platform. We need a clear message about practical technology leadership and not about the market aspirations of some MS business execs.

Hi,
I'm a bit late to this discussion but wanted to give my humble opinion anyway.
Concerning commercial UWP Apps: One that comes to my mind is Adobe XD. This one is UWP and feels very mature and complete.
My own experiences with UWP, being a .Net developer for 13 years: Of course you can create a good looking, performant app with it. But... it is not a beatiful experience. We're in the process of creating a medical application and many of the things already mentioned here and elsewhere were encountered by us also:

• Unbelievable slow file API
• Very slow "F5 time". So going into debug to build/start the application to try out something is at least 10 x slower than in WPF. (think approx. 2 minutes on a Surface Book 2)
• In general, being restricted by the sandbox.
  These are just the ones from the top of my head. In the end when XamlIslands was released we chose to host our complete UWP UI in a WPF Window, having fast .net core behind everything. I don't think many people used XamlIsland in this magnitude (concluding from the github issues/PRs we created). Yet this technology also has some very serious limitations. Just as an example, compile time goes up even higher. Losing the ability for live editing Xaml. Creating an installer for a serious WPF/XamlIsland/UWP app? It hurts. etc...
  So to sum it up, creating beautiful UWP apps can of course be done. But it is so unproductive and slow. And restricted.
  So as many others we are excitedly awaiting the release and maturing of WinUI 3, being able to have "UWP" frontend and .net core (or .net 5 ;-) ) backend without tricks.

@jasonwurzel those are some very good points

• The file API is slow but for the meantime @duke7553 posted a workaround in #1465 (comment)
  That is true, yet we didn't know about it back then. Redundant to say, it is somehow crazy to implement this workaround just to get fast file I/O...
• F5 time does slow things down and I think that can use some improvements
• I am curious what limitations you ran in to by trying to develop a regular UWP app as opposed to going the xaml islands route? I am working on a few apps right now and I was able to solve any limitations by including Win32 processes, but I understand that it isn't always the ideal way to create an app.
  I guess in the end it was the sum of the obstacles we met, no doubt some of which could have been solved with external processes. In no particular order:
• Observing the CD tray/USB ports for inserted media
• observing some user-chosen directory anywhere on the local PC and having the App/Windows remember the access right when updating
• demanding broadFileSystemAccess, getting the exception, opening the corresponding Windows Settings Page, user checks the App's toggle, boom App closes without warning, no chance to intervene.
• same domain: letting the user choose a directory without having to open a Windows-style FolderPicker (no we do not want to style our fullscreen app in a nice and streamlined manner and then the Windows Dialog jumps into the user's face)
• chicken-and-egg problem: availability/support of nuget packages (many more people are still using WPF, so finding solutions to small problems is just much more quicker)
• controlling the install location

@AndrewPawlowski I am surprised you would say that when there are plenty of great UWP apps that are both modern and good looking, including a handful that are open source on GitHub.
Just because you gave up on creating an app because you didn't figure out how to do something does not mean a platform failed, it means your app failed. If you look around you can see many developers who worked hard and created some really good apps including apps that continue playing sound when the app loses focus.

I'm not saying it's not possible, but it's very very hard. And I'm not talking about a simple "Notepad-like" app, I'm talking about a very complex app which deals with UI / video editing / sound editing / loading/saving lots of stuff to disk / (trying and not succeeding) launch stuff (and please don't tell me about the fullTrust API). I'm talking about a 50-100K+ lines-of-code app.

That is waaaay harder.

And the fact that you can play a sound when the app loses focus - no one is saying that you can't, but it should be waaay easier than is now.

You ask if there is anyone who enjoys the process of developing UWP apps and the answer is that there are many and in recent months I have been getting lots of requests from other developers for help on their apps, the platform is clearly gaining interest.

I agree, that's why I actually embarked on porting my app to UWP. But it's been a very bumpy road, and still is.

You also claim that there is nobody writing about developing UWP apps and I have to say that is just false, @rudyhuyn, Martin Zikmund are just two examples of developers writing about UWP but there are many others as well.

I totally agree, but compare that with people writing about wpf. It's a drop in the water.

Just do a simple github search - "c# wpf" (3701 results) vs "c# uwp" (337 results).
I'm sure if you would search for the same thing, and filter by "number of commits > 500" (which kinda' means - user stuck with the project) -> you would find a waaay dimmer picture.

This pretty much shows that you can create both good looking apps in 2020 as well as modern UWP apps and that many of your statements are not accurate.

I beg to disagree - in order to be able to develop a UWP complex app and be happy doing it -> we're a long way from that.

• I am curious what limitations you ran in to by trying to develop a regular UWP app as opposed to going the xaml islands route? I am working on a few apps right now and I was able to solve any limitations by including Win32 processes, but I understand that it isn't always the ideal way to create an app.

On my end, I tried to use win2d using Xaml Islands back in Sept - did not work one bit. I tried some of MS's examples and they didn't work either. At that point, I realized I really need to port my app to UWP or otherwise this will never work.

As for a more recent test - https://github.com/microsoft/Win2D/issues/731

• Very slow "F5 time". So going into debug to build/start the application to try out something is at least 10 x slower than in WPF. (think approx. 2 minutes on a Surface Book 2)

Oh yes! I didn't even mention this, but yeah, it's insanely slow. I've gotten around it by tweaking what projects I compile and which I don't - and depending on which part of the app I'm working on, this is decent or horrible (and by decent, I mean, roughly 10-15 seconds most of the time)

• In general, being restricted by the sandbox.

Oh yeah :)

• The file API is slow but for the meantime @duke7553 posted a workaround in #1465 (comment)

Agreed, but just think of how long it took for someone to find that workaround -- that clearly existed, but was deeply buried in the docs. And right now, probably a very few people are aware of it (including myself).

If you do a google search, you won't find any of the posts that show that workaround, so it will probably be a few months before most developers will be aware of it.

@jasonwurzel

So as many others we are excitedly awaiting the release and maturing of WinUI 3, being able to have "UWP" frontend and .net core (or .net 5 ;-) ) backend without tricks.

Just want to point out that MS said that once .NET 5 lands, you will be able to use it for your UWP projects just fine. No need for any "tricks" or a situation like .NET Core 3.x. Here is the .NET 5 announcement post again: https://devblogs.microsoft.com/dotnet/introducing-net-5/

yeah, that's what I was refering to 👍

I think the word "completely" in _"completely out of touch with reality"_ was unfair and inaccurate, but @jtorjo was very frustrated for understandable reasons. If Microsoft was completely out of touch with reality, then the WinUI team would not be working on separating WinUI from UWP. Overall the WinUI team seems to be more in-touch than other departments of UWP/WinRT. I think an accurate description would be that some degree of out-of-touch exists in some teams at the current time.

Significance of a list-with-columns GUI

Although the WinUI team is probably the best-performing team out of all teams related to UWP/WinRT, I think some mistakes were still made in the project management of WinUI. A list-with-columns GUI (such as DataGrid) is an essential mainstream feature that every customer uses on a daily basis (such as in Windows Explorer and various other examples such as Spotify etc). Since the start of WinRT, it has been 8 years without official support for a list-with-columns GUI! I find this situation to be shocking. For that reason and others, I say that UWP is still an alpha version today (it's not yet feature-complete thus not a true beta). It's unsurprising that most app developers never took UWP seriously, and hence Windows Mobile ended up being cancelled.

An official version of WinUI's DataGrid has been overdue for the last 8 years. DataGrid became overdue the minute when WinRT 1.0 was released because Microsoft should have never started a new system (as I explained in my previous message re Nokia etc). 8 years with missing fundamentals, 8 years overdue, and now the WinUI team wants to make DataGrid even more overdue by wasting even more time by downgrading it to native code. For multiple reasons, it's difficult to take UWP seriously and difficult to trust it.

C++/CX was recently replaced by C++/WinRT

Here's another example of being "out of touch with reality":
Obviously software needs to be written in a sane manner (I mean "sane" as terminology, not an insult such as "You're insane"). "Sane" as terminology means you shouldn't use obscure convoluted black magic to accomplish a simple straightforward task.
C++/CX was recently replaced by C++/WinRT. C++/WinRT uses the so-called _"curiously recurring template pattern"_ for function-calling via static dispatch. That's a really terrible design because it's not a sane design because it's a case of using obscure convoluted black magic to accomplish a simple straightforward task. Furthermore, the CLR/C# already solved this issue decades ago, therefore why is the WinRT team still messing around and wasting time with very old and primitive topics that were already solved decades ago? Why is the WinRT team re-inventing the wheel?

I browsed the NEW source code of C++/WinRT and my impression of it is that it's a terribly low-quality piece of software, but the WinRT team views it as wonderfully advanced. Thus "out of touch with reality" is an accurate description.

UWP file system is still alpha version

@jtorjo and other people have mentioned the performance problems of UWP's file system API's. The performance is below the level necessary to describe it as a feature-complete beta version. Another reason why the UWP FS API is still an alpha version is the lack of the ability to move a folder. 25 years ago, Windows 95 had the ability to move folders, but UWP is still missing this fundamental ability. In some ways, Windows 95 is more powerful than UWP. In various ways, WPF and .NET Framework are still more powerful than UWP. Microsoft expected app developers to take UWP seriously but this was very unreasonable (or "out of touch with reality") because Microsoft never progressed UWP from alpha to beta stage.

Windows made the assumption that mobile like "App Dev" was the booming market, and was modern in that it had security and battery life at it's heart.

They were pushed out of the Mobile market due to market forces. Devices like Hololens and Xbox are trying to remove Win32 legacy support - to make development simpler for them, and a leaner more performant OS codebase.

These bets have not totally paid off, but the ideals for a modern app delivery and security model, are laudable goals.

So after some soul searching Microsoft have decided to disentangle the modern app framework, from the UI framework.

WinUI 3.0 should be the best of both worlds, allowing access to most modern APIs which benefit from language projection, modern coding standards, and mobile familiarity. But also allowing apps to use the less secure but more powerful Win32 and .NET runtimes.

Of course relying on Win32 access, will restrict what platforms they will run on - and who knows where the market will move to in the years to come.

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

@mdtauk wrote:

They were pushed out of the Mobile market due to market forces.

Various UWP/WinRT staff members would like to believe that explanation very much, in order to _feel_ better about what happened. I don't believe that explanation. I believe that UWP failed because of:

1. Mismanagement, and
2. Failure to address the problem of app developers perpetually postponing the UWP versions of their apps because of the impression that UWP wasn't ready and still isn't ready for prime time, and
3. Excessive usage of unproductive old software engineering techniques, and
4. Failure to win the trust of the majority of app developers, and
5. Things that made UWP look silly such as promoting use of JavaScript instead of Java, meaning the failure to recognize the difference between a scripting language versus a programming language.

Sadly, considering that mismanagement is the main reason for UWP's failure, it's ironic that UWP is written in unmanaged code because the word "unmanaged" really sums up the reason for the failure: Mismanagement of both the source code and the project management.

@jtorjo wrote:

Native, in the context of "compile to .net native", I do think is a good thing

I agree. The difference is in automatic versus manual generation of native code. When native code is produced automatically by a compiler or tool, then it's usually a good thing, whereas if native source code is manually written source code, then productivity, feature-set, and reliability suffers substantially.

If you look at the timeframe of WPF development versus the timeframe of WinUI development, then WPF's development was much faster (much better productivity), despite the fact that WinUI should have been easier/faster to develop than WPF because WinUI reuses many of the same concepts that were _already_ created for WPF. Unfortunately, Microsoft chose to engage in excessive use of old software engineering techniques that contradicted their own prior standpoint and sabotaged their own productivity and led to app developers perpetually postponing UWP app development.

What can be done now to solve the past mistakes? Stop repeating the same mistakes that led to failure of UWP. Don't continue as if nothing bad happened. I'll use DataGrid as an example here: Add new features to DataGrid instead of delaying DataGrid even further. Don't make DataGrid even more than 8 years overdue by doing a useless manual rewrite/conversion to native code.

End-users couldn't care less whether DataGrid is written in managed or unmanaged code, and they don't know what those terms mean, thus what is far more important and sensible is to keep it with managed code as-is and improve the functionality/features of DataGrid. The amount of manually-written native code in UWP is already a disasterous situation, so why make the situation even worse by writing even more native code and even more obsolete code based on Win16/32 and COM?

I understand that you cannot just throw away all of the obsolete code, but you CAN stop making the situation worse than it already is. Meaning, cease writing even more antique native code. Make a policy that from now on, all new code/projects will be written using modern software engineering techniques. Don't downgrade preexisting managed code such as DataGrid etc.

UWP file system is still alpha version
@jtorjo and other people have mentioned the performance problems of UWP's file system API's. The performance is below the level necessary to describe it as a feature-complete beta version. [...]

I mentioned this before and I'll mention is again - the StorageFolder/StorageFile API is one of the worst APIs I've seen. We're way in the 21st century, and I need to ask "oh please please, can I have access to this? and to that? and then add them to the great FuturesAccessList?"

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

These bets have not totally paid off, but the ideals for a modern app delivery and security model, are laudable goals.

I totally agree...

[....] Of course relying on Win32 access, will restrict what platforms they will run on - and who knows where the market will move to in the years to come. [...]

I completely agree, but, thinking too much into the future can also be a pain...
By that I mean - if you restrict Win32 access from the get go, porting libraries will be pretty much a "no-go", so you won't have a present, let alone a future.

By allowing us to also use Win32 code, yes we may not be able to port to another (upcoming) platform, but at least we'll have code for today. And tomorrow, that will be another day, and when we get there, we'll figure a way to port our code if we really want to.

But I do what to be given to choice, and I will understand the risks.

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

Not sure if this was targeted at me or anything, I'm not a native english speaker. Having said that, I definitely want this project going forward, but I do think it's important we address some issues that stop us from deploying - today.

I would suggest instead of belabouring the same old grounds and complaints - this community be used to ask for what developers want going forward, and not to lay blame or ranting in a way that doesn't move the project forward.

Not sure if this was targeted at me or anything, I'm not a native english speaker. Having said that, I definitely want this project going forward, but I do think it's important we address some issues that stop us from deploying - today.

I am not targeting anyone, but the discussion title is a little negative and people don't tend to respond and address legitimate issues, if they are wrapped around insults and accusations.

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

@jtorjo

We're way in the 21st century, and I need to ask "oh please please, can I have access to this? and to that? and then add them to the great FuturesAccessList?"

The fact that apps have to ask the user is in my opinion a step in the right direction. The fact that unlike Winforms and WPF apps, the app can not simply scan all of my files and I have the control over which folders it can access is very important security wise. If you think that it is bad that we limit the resources apps can access to protect the user, than I guess that's your view, but I do not want every app to do what it wants with my files.

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

I guess the rationale was that it should not block the UI thread since the worst thing that can happen from a UX point is that the app does not respond anymore because the developer forget that disc operations may take a bit. Using await you can get around the problem and it forces you to unblock the UI thread at some point. (At least that is how I understand async await).

As @mdtauk correctly pointed out, the discussion title is indeed a little negative, and instead of keeping repeating the same old complains, such discussions should be used to come up with ideas to solve such issues.

I think we all should keep in mind to adhere the Microsoft open source code of conduct, keep a professional discussion and be respectful to everyone regardless if they are present or not.

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

The fact that apps have to ask the user is in my opinion a step in the right direction. The fact that unlike Winforms and WPF apps, the app can not simply scan all of my files and I have the control over which folders it can access is very important security wise. If you think that it is bad that we limit the resources apps can access to protect the user, than I guess that's your view, but I do not want every app to do what it wants with my files.

So we start with a huge disadvantage compared to WPF apps. That's one thing - the other thing is

1. I'm already asking that at installation.
2. Even if users may not pay attention, Windows could once again show the user "This app wants access to your files" and the user could say Yes/No. I would be totally fine with that. However, this is FAR from what is happening.

And I need to asynchronously ask for basic properties, such as file's size? I don't care what rationale this might have had, but it's waaay out of touch with reality right now.

I guess the rationale was that it should not block the UI thread since the worst thing that can happen from a UX point is that the app does not respond anymore because the developer forget

The file size should be pre-fetched (same as, last access date/ last write date) - it is so important, that it should be pre-fetched when you do a query for files.

As @mdtauk correctly pointed out, the discussion title is indeed a little negative, and instead of keeping repeating the same old complains, such discussions should be used to come up with ideas to solve such issues.

I totally want these to be solved, nothing else.

I think we all should keep in mind to adhere the Microsoft open source code of conduct, keep a professional discussion and be respectful to everyone regardless if they are present or not.

This discussion would not have happened here, had we actually had a place to ask these questions, and for WinRT to listen for feedback elsewhere.

I am not targeting anyone, but the discussion title is a little negative and people don't tend to respond and address legitimate issues, if they are wrapped around insults and accusations.

I agree it's a little negative, once again, this would not have happened, had there been somewhere else to give feedback on WinRT issues.

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

Honestly, I really hope this is the case. I will certainly wait for these issues to be resolved, and personally can't wait for that non-sandbox platform to be available. But until then, I am still working on an app, and still facing the issues I outlined in the first place.

So we start with a huge disadvantage compared to WPF apps. That's one thing - the other thing is

Just to be clear, leaving the use a choice to deny apps from accessing all file is a disadvantage in your opinion?
We as developers have to develop the software for the users not against them. And leaving the user no choice on what data your app sees is a security disadvantage for users, in my opinion.

1. I'm already asking that at installation.

Do you mean the "broadFileSystemAccess" capability? In my opinion there are very very few apps that have a legitimate reason to have this capability. (as @kmgallahan already pointed out)
Just look at all the apps you use on a day to day basis. How many of those need access to all files all the time? Probably not so many, if there are even any.

As you said in your initial comment:

Do you think users will happily do the above? No they won't - in fact, 79.8% don't do it (my AppCenter data backs this up).

I think there probably is a reason users are not happy to do this (beside the fact that this is a security setting that they have to change).

However I may not know all business cases that would require access to all files, so if there are any I am happy to hear them. At the end of the day we are not here to fight but to enrich each others points of view (hopefully) 😅

Edit:

The file size should be pre-fetched (same as, last access date/ last write date) - it is so important, that it should be pre-fetched when you do a query for files.

Oh right, yes some of those should definitely be pre fetched. I agree that this is somewhat inconvenient for us developers.

This discussion would not have happened here, had we actually had a place to ask these questions, and for WinRT to listen for feedback elsewhere.

Officially the feedback hub is for that (I think) but yes it feels a bit unresponsive sometime. Hopefully the feedback hub improves. From what I can see, they already made some changes to it over the course of time, so I think that this will hopefully change too.

@Felix-Dev

Here is the .NET 5 announcement post again

Thanks for linking to that. I especially found this part interesting, and I believe this is positive news:

"Java interoperability will be available on all platforms.

There's also a bit of Java discussion in the comments at the end of that webpage, where Rich Lander confirms two-way interop. I interpret this as a positive sign that Microsoft is getting back in touch with reality. I'm no fan of Java (I prefer C#), but nevertheless I acknowledge that Java interoperability is highly beneficial and should have been the focus in UWP/WinRT from the beginning. If UWP/WinRT had given top priority to Java and C# (managed code) instead of clunky old native code (C++/CX, Win16/32, COM), and if UWP hadn't mixed-up the purpose of JavaScript versus Java, then UWP would have attracted many more app developers, and Windows Mobile might well be alive today.

Like it or not, it's necessary to wake up and acknowledge the reality of the situation: The market leader is Android with its focus on Java app development. Java and C# mean managed code. Microsoft made a hugely costly mistake when it reversed its standpoint on managed code.

Even though I don't really like Java, it's clear to me that Android's Java techniques are much better than the clunky old way in which Microsoft is developing WebView2 with its use of antique Win16 programming techniques such as 16-bit versus 32-bit pointers, and HRESULT instead of modern exception handling, etc. WebView2 uses LPCWSTR and the L means "long pointer" meaning a 32-bit pointer as opposed to the 16-bit "short" pointers in Win16. The W means "wide characters" meaning Unicode (UTF-16) as opposed to 8-bit ASCII/ANSI characters. In comparison, Android's use of Java is far more professional, modern, and trust-inspiring than what some departments of Microsoft are doing.

So on a positive note, it's really great news to hear that Microsoft will support Java (even though personally I prefer C# over Java). Android app developers will increase their interest in Windows as soon as good reliable Java interop is released.

Also now we know that a Win32/.NET app framework will be coming with WinUI 3.0 - there is little point in still criticising them for being WinRT only in the past. 😁

1. The future is bright, I love what I see is being developed in WinUI.
2. The past was pretty bleak, for a platform with 900 MILLION devices the poor prevalence of UWP is hard to defend. EDIT: the past is the only place we can learn from, so it is important to discuss.
3. The present is, I think, is the main point of this thread and it is not being addressed. If someone wants to start today a nontrivial app that will take 1-1.5 years to develop, what honest advice can be given? My answer would be: experiment with WinUI, make your libs in dotnet Core, and wait for WinUI3.0 to come out to really start making your app. Don't bother with UWP because you will want to throw it out of your app anyways, you probably don't want different platforms as the 900milion one is plenty big. The questions about the present are not trivial, business decisions need to be made today.

What is not being said, but what is really happening is that UWP and modern UI are not being extended to win32, but actually UWP is being refactored OUT of the stack. Why anyone would want to deal with UWP when they could use the power of dotnet standard 2 and dotnet core 3 and all the libs that are available with that?

About sandboxing and other good ideas introduced in UWP: they were good ideas, but could have been executed much better. I hope they will come back and there will be a possibility of OPT-IN into a sandbox or OPT-IN into state management similar to UWP. As developers we want to serve the users but in UWP we were threated as the problem that the platform needed to contain.

What honest advice can be given? Wait?

@AndrewPawlowski If you've determined that UWP and the sandbox doesn't work for you, I think writing a MSIX-packaged WPF app is a good choice until WinUI 3 lands. You can already call Windows 10 exclusive APIs, provide the user with a modern install/uninstall experience and generally pick from the Windows 10 API surface what you like and what not (i.e. you can start using Windows 10 Shell APIs). Some WinRT APIs are really a joy to work with compared to past win32 ways and some scenarios I believe are even done best on DesktopBridge rather than pure UWP. Case in point: Registering an app for automatic start at log-in, see this post for a comparison of UWP vs DesktopBridge behavior. In the case of DesktopBridge, you still, ultimately, leave the user in control, but the user won't constantly be asked twice (first, a toggle in the app, then a system prompt asking for confirmation) when enabling start at log-in in the app.

Unfortunately, many parts of the WPF APIs are really showing their age now when compared to UWP UI APIs so you will just have to live with that a few more months (at least). The many available WPF toolkits will mitigate this fact, but if you truly want a native look and feel for your Windows desktop app (and a modern XAML development experience!), you really won't be able to escape the UWP UI APIs (and later the WinUI 3 APIs). That means, even if you can re-use some of the WPF UI code for WinUI later, modernizing the UI will still be a rather big work item I believe.

That's the state of native windows app development I currently see for you if you cannot wait until WinUI 3 ships and UWP is not an option for you.

@AndrewPawlowski

1. The future is bright, I love what I see is being developed in WinUI.

Concur

1. The past was pretty bleak, for a platform with 900 MILLION devices the poor prevalence of UWP is hard to defend. EDIT: the past is the only place we can learn from, so it is important to discuss.
2. The present is, I think, is the main point of this thread and it is not being addressed. If someone wants to start today a nontrivial app that will take 1-1.5 years to develop, what honest advice can be given? My answer would be: experiment with WinUI, make your libs in dotnet Core, and wait for WinUI3.0 to come out to really start making your app. Don't bother with UWP because

My initial thought was the same, but I did not wait....

About sandboxing and other good ideas introduced in UWP: they were good ideas, but could have been executed much better.

Agreed 100%

However I may not know all business cases that would require access to all files, so if there are any I am happy to hear them. At the end of the day we are not here to fight but to enrich each others points of view (hopefully) 😅

Anywhere where you want to preview stuff, you'll want fast access to files. In my case, I want to preview folders to visually show the user where the photos/videos are at, and for videos, I want the user to preview the video before selecting it. The whole point is: the file picker offers a pretty sub-par experience, and I wanted to enrich that.

Officially the feedback hub is for that (I think) but yes it feels a bit unresponsive sometime. Hopefully the feedback hub improves. From what I can see, they already made some changes to it over the course of time, so I think that this will hopefully change too (^∇^)

Personally I don't like the feedback hub - it's too unspecific, among other issues.

@jtorjo @chingucoding feedback hub for WinRT APIs might be replaced/paired with Microsoft Q&A soon, check out this commit: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Seeing as Chigusa has been mentioned there: @chigy Will the Microsoft Q&A platform be the preferred feedback platform for non WinUI WinRT APIs? If not, how will it relate to feedback hub (i.e. file bugs/questions on Q&A, API requests on feedback hub,....)?

Hopefully we won't end up with three different feedback platforms 😆

Since this is a discussion about UWP I can promote a feature request: Allow context menu verbs with file explorer integration without having a file type association https://aka.ms/AA71n2t btw. https://aka.ms/AA6rmrk ( but its in the wrong category - maybe someone can fix this?)

A good source of feature requests is:
https://web.archive.org/web/20161221051552/https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
Too bad the snapshot of this uservoice is quite old (2016). I can remember there was stuff like:

• align the behavior of the broadFileSystemAccess request like it would behave when requesting camera, location, starting app on startup...
• auto. printing (is currently only supported for POS on IoT as far I remember)
• make printing more configurable

@jtorjo

Anywhere where you want to preview stuff, you'll want fast access to files. In my case, I want to preview folders to visually show the user where the photos/videos are at, and for videos, I want the user to preview the video before selecting it. The whole point is: the file picker offers a pretty sub-par experience, and I wanted to enrich that.

My guess would that for that you first let the user pick a folder where he wants to use your app. After all, the user knows best where he saved his videos.

Otherwise you might want to take a look at:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

But to be honest, I don't know what exactly would broadFileSystemAccess would help you in that case. You can't be sure where exactly the files are (unlike the user). But maybe I don't fully understand the idea of your app correctly.

@Felix-Dev
Thanks for the information, didn't know that WinRT feedback might move.

Hopefully we won't end up with three different feedback platforms 😆

Haha yes hopefully not!

@jtorjo -- Have you considered cancelling the porting of your app from WPF to UWP? You could cancel it and wait until WinUI 3 is released, and then you won't be forced to use the problematic UWP file system API, broadFileSystemAccess, etc. In the meantime, while you're waiting for WinUI 3, you could continue to deliver new versions of your app to your users by continuing to develop the WPF version of your app.

During the 8 years since the beginning of WinRT, we've never actually given any WinRT nor UWP app to our users. Instead we've given them many updates that continue to use the WPF version of our software. Our users have zero complaints about this because they don't care about tech details such as WPF, WinUI, UWP, rather they care about how well the app works and what functionality it has. Our users also don't have any complaints about old GUI because our WPF apps include a bunch of GUI modernizations.

@AndrewPawlowski said "experiment with WinUI". Yes, experiment. I've written a bunch of code for UWP and WinUI over the years, but it's all experimental, alpha, or beta code. I never reached a point where I was comfortable enough to release any UWP apps to users.

WinUI 3's separation from UWP is a big help, but I don't think it's a full solution. WinUI 3 doesn't address the low productivity / slow pace of development of WinUI: WPF was developed much faster than WinUI, even though WPF was more difficult than WinUI.

The WinUI team says the pace will speed up when WinUI 3 is open source, and maybe it will, but personally I won't be writing any C++/CX, C++/WinRT, Win16/32, or COM contributions for WinUI 3. I began my career with Win16/Win32 decades ago, and Win32 was a nightmare, and I have no intention of ever reverting to such old and problematic programming techniques. Over the years, I kept my software engineering skills up-to-date and I switched to C# and .NET Framework, and it was a major improvement and benefit, and I won't go back to the nightmare of the old Win16/32 days and large amounts of manually-written native code.

@AndrewPawlowski wrote:

What honest advice can be given? Wait?

That's a really difficult question to answer. On one hand, yes wait for WinUI 3, but on the other hand, WinUI 3 isn't a full resolution of the big problem that was initiated by WinRT 8 years ago. WinUI 3 is a helpful partial resolution.

Great Video from Ignite: https://youtu.be/Ul5JcdIJv5s

I think a lot of the discussion here questions the purpose of WinRT. Developers and users alike still wonder what role it will play once WinUI 3 and .NET 5.0 allow for easy inter-op between the different technologies. Not to mention, the eventual ability to pick between the sandboxed vs classic app models.

I assume writing new WinRT APIs is easier for Microsoft to do internally, which explains why they've stated many times before that most of the API-layer innovation will be done within WinRT. This means that for new, modern Windows applications, it makes sense to use WinRT because it will have the latest and greatest integrations with new experiences that will come with the new form factors. WinRT is only intended to be a specific set of Universal APIs that light up in your .NET app on Windows.

With that said, I think we all agree that it would make Universal apps more valuable if the UWP Desktop Extension Pack had better integration capabilities with the existing Windows Shell.

Who knows, Microsoft may have plans to eventually replace the Windows Explorer Shell with the newer Composable Shell (CShell) found in Windows 10X, etc. Experts on Twitter have also discovered a new UDK (Undocked Development Kit) found in Windows that might allow for better integration with this new shell in the future.

@AndrewPawlowski

you probably don't want different platforms as the 900milion one is plenty big.

While I see what you mean, you have to realize that UWP and .NET are no longer these mutually-exclusive things, so if it made sense to launch your app with Universal features, one should invest in understanding parts of WinRT.

I digress. As one who built a Windows File Explorer competitor with pure-UWP app model, WinUI 3 can't come fast enough. In the near future, you won't have to choose between using Universal features and the "900 million users" 😀

@jtorjo I would advise changing the title to one that will be perceived less negatively, so more people will provide input here.
Perhaps "Opportunities to add value to WinRT"

@verelpode

@jtorjo -- Have you considered cancelling the porting of your app from WPF to UWP? You could cancel it and wait until WinUI 3 is released, and then you won't be forced to use the problematic UWP file system API, broadFileSystemAccess, etc. In the meantime, while you're waiting for WinUI 3, you could continue to deliver new versions of your app to your users by continuing to develop the WPF version of your app.

I thought long and hard about this - this is what I wanted to do. But I can't not do it, because I really need win2d (or more to the point, a good wrapper over Direct2D). ShapDX (another wrapper over Direct2D) seemed much more complicated, so I chose to use win2d (which is UWP). Therefore, port everything to UWP.

My guess would that for that you first let the user pick a folder where he wants to use your app. After all, the user knows best where he saved his videos.

Do you truly really bet your life on that? I wouldn't - clearly, if you're an advanced user, you may be insanely organized, and know where every bit of thing is. Otherwise....

And then, whenever you (the user), somehow copy photos/videos to a new folder, you'll need to remember to tell my app to include that as well...

Not to say that the "great" FutureAccessList - doesn't really specify -> if I add a folder, will all its subfolders be accessible to my app?

Also, if I've added something to FutureAccessList, do I need to retrieve it from there or can I get with GetFolderFromPathAsync/GetFileFromPathAsync (it's the former, I'd rather jump off a cliff)?

And did you know, that if use FutureAccessList.AddOrReplace, and use the file's path as token, you get an exception? How thoughtful... (it's nowhere in the description)

WinUI 3 and .NET Core will be an option in the future - I assume that combination, without UWP's sandbox will work in the same way as WPF, but with the newer XAML controls, Visual Layer, and simple WinRT API access.

My guess would that for that you first let the user pick a folder where he wants to use your app. After all, the user knows best where he saved his videos.

Do you truly really bet your life on that? I wouldn't - clearly, if you're an advanced user, you may be insanely organized, and know where every bit of thing is. Otherwise....

Well if the User does not know where he saved his videos, what should your app do? Scan all files in the system, which even with the fastest software might take hours? At least for me this does not seem like a good experience. After all, if your app is targeted towards users that want to do something with videos, the users are already somewhat "organized" in the snese that they know they have videos somewhere. But again, just my thoughts without really knowing your app and specific business case.

And then, whenever you (the user), somehow copy photos/videos to a new folder, you'll need to remember to tell my app to include that as well...

I think if you have the access to the parent directory, you can also access future child folders (I am not 100% sure though).

And did you know, that if use FutureAccessList.AddOrReplace, and use the file's path as token, you get an exception? How thoughtful... (it's nowhere in the description)

Thats weird, this is something that should definitely be documented!

Personally I am not really a fan of apps requesting "broadFileSystemAccess" since a lot of them don't need it. Maybe there are some cases where it makes sense (writing a file explorer etc) but a lot of cases which need access to SOME folders shouldn't go ahead and say "please allow me access to all files", since you could also ask for that folders in particular.

But maybe I don't know enough business cases for such. If there are more I would love to hear them!

But maybe I don't know enough business cases for such. If there are more I would love to hear them!

• tools and utilities software, like a (de)compression tool. If you want to extract the compressed file in the same directory where the current file is located and when the app was called by the windows explorer context menu you only got write access to the selected file. So wont be able to create a new file or directory (for the uncompressed file(s)).

  • If the user dragged the file into your uwp app you don't have write access to those file!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

like a (de)compression tool. If you want to extract the compressed file in the same directory where the current file is located and when the app was called by the windows explorer context menu you only got write access to the selected file. So wont be able to create a new file or directory (for the uncompressed file(s)).

I think it is very debatable wether you should get access to the whole folder when you right click a single file or not. Though tbh I usually specify a different folder when compressing/uncompressing since I usually need them only for "exchange" i.e. backups or downloads/uploads. So for me it is almost necessary to specify where exactly to save the files to. But this may be a valid use case depending on the users choice 😅

If the user dragged the file into your uwp app you don't have write access to those file!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

Well that just seems a bit overcomplicated for users and developers. I would have expected that you get at least write access to the files dropped. In my opinion this is just a unnecessary constraint for devs.

Though at least in my day to day use of apps, I only drop files into GitHub comments. For every other case I just double click or right click, but agreed in some cases that's just not great. I guess there are a few cases after all where it would make sense to have access to all files.

Well if the User does not know where he saved his videos, what should your app do? Scan all files in the system, which even with the fastest software might take hours? ...

There are clearly a lot of possibilities, one of them is, when user expands a folder, to preview it for him - so he easily sees which folders have photos/videos, and which not. One thing my app would actually do, if Windows would let me

Personally I am not really a fan of apps requesting "broadFileSystemAccess" since a lot of them don't need it.

I doesn't matter. WinRT's sandbox's file system protection model is beyond out of touch with reality. It's something that someone took from the great "Mobile first" mantra, which simply doesn't apply to desktop.

In fact, a much smarter way to sandbox files/folders is to let the user decide which files/folders he wants protecting - there should be a very easy way to do that (like, maybe in File Explorer, with a right click command). Users will clearly know what documents/files are confindential, and protect those. And there's also a real-world analogy - just think of seifs.

This goes in contrast to blocking everything by default, and then users inadvertently giving you access to confidential files by mistake.

Let me be blunt here - any non trivial app doesn't live in a vacuum. It will need to get data from somewhere (input) and output it somewhere. The input and output are often files - you need to interoperate with other apps and so on. And WinRT just makes that it to impossible to me to design a nice UI to give to my users.

There are clearly a lot of possibilities, one of them is, when user expands a folder, to preview it for him - so he easily sees which folders have photos/videos, and which not. One thing my app would actually do, if Windows would let me

Yes that is a possibility. But when are you going to scan the folder? And which folders exactly can the user expand in your app?

I doesn't matter.

What exactly are you trying to say here?

In fact, a much smarter way to sandbox files/folders is to let the user decide which files/folders he wants protecting - there should be a very easy way to do that (like, maybe in File Explorer, with a right click command). Users will clearly know what documents/files are confindential, and protect those.

I think this whole access protection is not just about "confidental" files but privacy in general, e.g. config files (which are commonly hidden in folders users don't see) or just which programs are installed. These are information I do not want every program to be able to access, especially "trivial apps" as you called them.

And there's also a real-world analogy - just think of seifs.

Yes, you can look stuff away in safes. But this does not change the fact that you have a key to your flat or home. But saying every program can access everything except its in a safe is like saying, you don't need a door for your flat because you have a safe for your valuables.

This goes in contrast to blocking everything by default, and then users inadvertently giving you access to confidential files by mistake.

This mistakes can happen in both cases, but I think it is more likely to forget locking a confidential file than accidently giving access to a confidential file.

Let me be blunt here - any non trivial app doesn't live in a vacuum. It will need to get data from somewhere (input) and output it somewhere. The input and output are often files - you need to interoperate with other apps and so on. And WinRT just makes that it to impossible to me to design a nice UI to give to my users.

Saying it is impossible is a stretch here since there are a lot of great UWP apps (though not many unfortunately).

Yes that is a possibility. But when are you going to scan the folder? And which folders exactly can the user expand in your app?

Are you familiar with the concept of Windows Explorer? You expand a folder or drive - that's when I would start scanning

I think this whole access protection is not just about "confidental" files but privacy in general, e.g. config files (which are commonly hidden in folders users don't see) or just which programs are installed. These are information I do not want every program to be able to access, especially "trivial apps" as you called them.

This is a non-issue, if the app would keep its files in its own "only this app can access it" folder.

This goes in contrast to blocking everything by default, and then users inadvertently giving you access to confidential files by mistake.

This mistakes can happen in both cases, but I think it is more likely to forget locking a confidential file than accidently giving access to a confidential file.

I completely disagree - the whole point of "confidential" should make you want to lock that file.

Saying it is impossible is a stretch here since there are a lot of great UWP apps (though not many unfortunately).

You are contradicting yourself here. But lets delve into the vastness of great UWP apps:

Notice the "abundance" of likes, which should tell you just how many people are using it. I wanted to give a contrast to apple store, but i can't since I don't have an apple. But lets see Android - Facebook has 70+ Million reviews (compared to 1353 on Windows). Instagram has 93+ Million reviews (compared to 1578 here). And I'm almost certain both Fb and Instagram are actually electron apps, not UWP.

Are you familiar with the concept of Windows Explorer? You expand a folder or drive - that's when I would start scanning

So you are building something similiar to Windows Explorer that will preview video files in folders?

This is a non-issue, if the app would keep its files in its own "only this app can access it" folder.

So on the hand, apps should generally have access to all files, but on the other hand some files and folders will be locked by the user (as he will only have "confidential" files and everything else is automatically unconfidential) and some folders are blocked by apps themeselves? And what if I want to program an app that will deal with files that have been generated by programs? Would every backup program fail as it wouldn't be able to backup programs? I am not quite sure how that would work out, and I am sorry if I misunderstood your idea here.

I completely disagree - the whole point of "confidential" should make you want to lock that file.

So what exactly would I not pick as confidential? I don't want every app to see my holiday pictures, but Photoshop should be able to see them. So are they confidential or not? Or is this confidential "flag" a list of programs and some files are not confidential for some apps?

You are contradicting yourself here.

Yeah my phrasing was rubbish there. Sorry about that. I wanted to indicate that there definitely exist great non "trivial" apps that just work fine.

Notice the "abundance" of likes, which should tell you just how many people are using it. I wanted to give a contrast to apple store, but i can't since I don't have an apple. But lets see Android - Facebook has 70+ Million reviews (compared to 1353 on Windows). Instagram has 93+ Million reviews (compared to 1578 here). And I'm almost certain both Fb and Instagram are actually electron apps, not UWP.

This is not a problem with UWP but rather with the fact that:

1. People usually do not tend to write comments
2. The iTunes store/Google Play Store is way older than the Microsoft Store
3. The Microsoft Store was not well received among users and didn't start of well
4. Most companies preferring developing Websites instead of platform limited apps

And I'm almost certain both Fb and Instagram are actually electron apps, not UWP.

It's hard to tell if they are electron or not since the website and the app look vastly different. Based on the fact that the dialogs look almost exactly like the default ones they may be UWP apps.

So you are building something similiar to Windows Explorer that will preview video files in folders?

That is a part of a wizard from my app.

So on the hand, apps should generally have access to all files, but on the other hand some files and folders will be locked by the user (as he will only have "confidential" files and everything else is automatically unconfidential) and some folders are blocked by apps themeselves? And what if I want to program an app that will deal with files that have been generated by programs?

My idea was the opposite of what we have now. I'm not saying it's perfect, far from it - but anything is better than what's happening now. So, by default, you would have access to all non-confidential files. If you would need access to confidential files, you would need to ask first.

So what exactly would I not pick as confidential? I don't want every app to see my holiday pictures, but Photoshop should be able to see them. So are they confidential or not? Or is this confidential "flag" a list of programs and some files are not confidential for some apps?

The way I see it, this "flag" would turn a file or folder as "Access denied". Had you really wanted to access it, you could ask permission and the user could choose to give to you or not (and the permission could be - just this one time, or forever).

Yeah my phrasing was rubbish there. Sorry about that. I wanted to indicate that there definitely exist great non "trivial" apps that just work fine.

I'm not saying there aren't. I'm saying it's insanely hard to make one, compared to WPF.
I'm saying I'm wasting days dealing with issues that simply shouldn't exist.

Like for instance, sometimes, I get an exception (a COM exception, to be specific), and instead of getting it at the point of failure, I actually get it in another thread, and most of the time, even the stack trace is lost. Figuring out what happened is very very painful.

Another issue is the whole "lets get info async" mantra - which I very much hate. I'm dealing with rendering that needs to be immediate, but loading of bitmaps is async. So I had to build a really complicated caching mechanism just for that.

And lets not get into compile times. And lately sometimes when building, I get a "...dll is built in release mode" (which basically can't be, because i'm building debug). The workaround is to simply clean all solution and rebuild (which takes 1+ minute).

And yes, crashes. VS crashes every 10-20 runs, beats me why.

And these are the issues that came to my head just now. There are countless more.

This is not a problem with UWP but rather with the fact that:

1. People usually do not tend to write comments
2. The iTunes store/Google Play Store is way older than the Microsoft Store
3. The Microsoft Store was not well received among users and didn't start of well
4. Most companies preferring developing Websites instead of platform limited apps

Well, i wish i could have had an Apple store comparison - I'm pretty sure their top apps have millions of reviews. The idea is MS store never caught on - because people simply give up on UWP/WinRT. Had I not needed win2d, I would have given up at least 20 times.

Just think about that - I need to ask Windows to go full screen, as a UWP app. That's beyond insane. And to make it even stupider, that will only apply on the next run.

I was looking at the "Grab a screenshot of the screen" API - I simply gave up on it, it's useless. I basically wanted to have a cool way to start the app, based on the current screen (sort of, have a transition into my app) -> it's not possible, because it requires user interaction (namely, the user has to say - yes, I want to allow grabbing a screenshot, which ruins the whole thing)

Let me not start with the clipboard -- which works only when your app is in the foreground. And to make it even funnier, Microsoft thought "we'll give you access to the clipboard at all times, when in debug", but in release, you'll get a nice "Access denied" exception. Do you know how many hours it took me to finally figure out that's why my app wouldn't start in Release (while everything was just dandy in Debug)

The list goes on -- I think I could write a book. Sure, UWP/WinRT are cool in theory. But when you start to use then, oh well..

It's hard to tell if they are electron or not since the website and the app look vastly different. Based on the fact that the dialogs look almost exactly like the default ones they may be UWP apps.

Right, my point is - people give up on UWP apps -- the benefits are outweighed by the many many problems that come with it.

@jtorjo
(Just to make sure you are aware of it.)

Let me not start with the clipboard -- which works only when your app is in the foreground.

I reached that same (or similar) issue during development of one of my UWP apps where I had to place data on the clipboard and in the end I solved it via an accompanying win32 full-trust process (which just calls Win32's SetClipboardData). If the concept of having an accompanying win32 full-trust process for your UWP app is news to you, you'll fine a good introduction here (the author previously worked on the UWP at Microsoft).

@Felix-Dev

I reached that same (or similar) issue during development of one of my UWP apps where I had to place data on the clipboard and in the end I solved it via an accompanying win32 full-trust process (which just calls Win32's SetClipboardData). If the concept of having an accompanying win32 full-trust process for your UWP app is news to you, you'll fine a good introduction here (the author previously worked on the UWP at Microsoft).

Thanks for the pointer! I did know about the win32 full-trust process. I've probably read those articles several times :) I've actually thought about have a win32 full trust process companion app several times. I chose not to, because of the added complexity - I'm already struggling to generate setup kits that actually work without the MS store. I just did not want to bring this into the equation as well.

So you are building something similiar to Windows Explorer that will preview video files in folders?

That is a part of a wizard from my app.

That sort of sounds like a file explorer with extra steps (⊙ˍ⊙)

My idea was the opposite of what we have now. I'm not saying it's perfect, far from it - but anything is better than what's happening now. So, by default, you would have access to all non-confidential files. If you would need access to confidential files, you would need to ask first.

So basically, in the end, your app will likely run into the same problem as now because you would never know if files are confidential. What about the users that will mark everything as confidential? So you just created the same system as now just with more variation in which you can access.

Like for instance, sometimes, I get an exception (a COM exception, to be specific), and instead of getting it at the point of failure, I actually get it in another thread, and most of the time, even the stack trace is lost. Figuring out what happened is very very painful.

If that happens often for you, that is very annoying. For me however, almost every exception that occurred for me (e.g. in the XCG) had a StackTrace associated and sometimes even useful exception messages. So I can't really say anything about that because it was never really an issue for me.

Another issue is the whole "lets get info async" mantra - which I very much hate. I'm dealing with rendering that needs to be immediate, but loading of bitmaps is async. So I had to build a really complicated caching mechanism just for that.

Sometimes async is a bit annoying, however in most cases async methods have a reason to be async, since you do not want to block the UI on operations such as network or file operations. Having said that, you can use the following methods to run your async method synchronously:

```c#
// Will block thread until MyAsyncMethod has finished
var myResult = MyAsyncMethod().Result;

// This will also also finish when the method has finished execution.
// Note that ConfigureAwait may result in the method being called on a different context
var myResult2 = MyAsyncMethod().ConfigureAwait(false);
`` ForConfigureAwait` you can take a look at the following article: https://devblogs.microsoft.com/dotnet/configureawait-faq/

And lets not get into compile times. And lately sometimes when building, I get a "...dll is built in release mode" (which basically can't be, because i'm building debug). The workaround is to simply clean all solution and rebuild (which takes 1+ minute).

The "...dll" is built in release mode is weird. Maybe check if the project files are incoherent? Regarding compile time, yes that is a bit annoying, though ~1 Minute is still okayish, WinUI takes around 5-10 minutes 😅

And yes, crashes. VS crashes every 10-20 runs, beats me why.

Yeah thats pretty annoying, though I don't think that this is really dependent on UWP but just Visual Studio in general (it is still a 32 bit process for a reason!).

Well, i wish i could have had an Apple store comparison - I'm pretty sure their top apps have millions of reviews. The idea is MS store never caught on - because people simply give up on UWP/WinRT. Had I not needed win2d, I would have given up at least 20 times.

It seems like that you can use Win2D with WPF: https://github.com/Microsoft/Win2D/issues/660

Just think about that - I need to ask Windows to go full screen, as a UWP app. That's beyond insane. And to make it even stupider, that will only apply on the next run.

It seems possible to get your UWP App in fullscreen mode, even at startup: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(Though I have not tried submitting an app with that)

I was looking at the "Grab a screenshot of the screen" API - I simply gave up on it, it's useless. I basically wanted to have a cool way to start the app, based on the current screen (sort of, have a transition into my app) -> it's not possible, because it requires user interaction (namely, the user has to say - yes, I want to allow grabbing a screenshot, which ruins the whole thing)

Most users do not want apps to just arbitrarily take pictures of their screen without their permission. You may not have a problem with that, but I certainly do and so do many others.

Let me not start with the clipboard -- which works only when your app is in the foreground. And to make it even funnier, Microsoft thought "we'll give you access to the clipboard at all times, when in debug", but in release, you'll get a nice "Access denied" exception. Do you know how many hours it took me to finally figure out that's why my app wouldn't start in Release (while everything was just dandy in Debug)

Yes you get an exception, however the fact that your app can not access it when it is not in focus is mentioned in the documentation:

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

But why do you need access to the clipboard when the user is not using your app? If you try to set the clipboard when the user is not using your app, the user will get irritated when you interfere with his copy/pasting. And if you read the clipboard when the user is not asking your app to do it, you are spying on him. Unless that's your goal (in which case you should definitely not use UWP), there are very few reasons to read out the clipboard while your app is not in focus (if there are any at all).

Right, my point is - people give up on UWP apps -- the benefits are outweighed by the many many problems that come with it.

Maybe, but also by the fact that its easier to write a Website and pack it inside Electron and ship it to Mac, Linux and Windows instead of writing separate apps for all platforms.

That sort of sounds like a file explorer with extra steps (⊙ˍ⊙)

It's not. Far from it.

So basically, in the end, your app will likely run into the same problem as now because you would never know if files are confidential. What about the users that will mark everything as confidential? So you just created the same system as now just with more variation in which you can access.

I'm not saying my solution is the right one. Clearly I would prefer not be in a sandbox at all, I'm just saying the current implementation is very bad.

Sometimes async is a bit annoying, however in most cases async methods have a reason to be async, since you do not want to block the UI on operations such as network or file operations. Having said that, you can use the following methods to run your async method synchronously:

This is wrong. This simply assumes I will always be calling from the UI thread. I mean sure this is fine for simple stuff, but I can create my own threads, and I can also create my own Tasks, and do stuff there.

Having everything async just forces me to always call await and mark functions async.

[...] For ConfigureAwait you can take a look at the following article: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Thanks, I know about this. Another issue I ran into was loading a bitmap (async) exactly as you suggested. Every now and then, I would run into insane wait times, like 5-6 seconds to load a bitmap.
I ended up doing workarounds.

The "...dll" is built in release mode is weird. Maybe check if the project files are incoherent? Regarding compile time, yes that is a bit annoying, though ~1 Minute is still okayish, WinUI takes around 5-10 minutes 😅

Yeah, I don't even want to think about that :) I'm not sure what you mean about project files being incoherent.

And yes, crashes. VS crashes every 10-20 runs, beats me why.

Yeah thats pretty annoying, though I don't think that this is really dependent on UWP but just Visual Studio in general (it is still a 32 bit process for a reason!).

I do believe it is UWP related. This never happened to me when dealing with WPF - I had 28 projects, and it never crashed. In UWP I have 15 projects (which I ported from WPF), and it crashes. And if I look in Event Viewer, there's something about the sandbox crashing - I don't remember exactly.

It seems like that you can use Win2D with WPF: microsoft/Win2D#660

That was my first attempt. It's a complete no-go. I ran into so many issues, that I ended giving up. The code that deals with win2d is quite complex, so I reasoned it would take me much longer to write it on top of WPF than to use UWP directly.

As much as I hate the UWP setup as is, I was correct. I would have never been able to properly make it work. And I assume you're aware of https://github.com/microsoft/Win2D/issues/731

Just think about that - I need to ask Windows to go full screen, as a UWP app. That's beyond insane. And to make it even stupider, that will only apply on the next run.

It seems possible to get your UWP App in fullscreen mode, even at startup: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

I'm sorry, I meant "to go maximized" - sorry for that.

Yes you get an exception, however the fact that your app can not access it when it is not in focus is mentioned in the documentation:

The issue is - we have different behavior in Debug than in Release. It should be consistent.

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

But why do you need access to the clipboard when the user is not using your app? [...]

The funny thing is this - I wanted to copy something into the clipboard at startup. However, this was in MainPage's constructor, so apparently, I was not in the foreground yet. Worked peachy in Debug, crashed in Release -- and by that, I mean exactly at startup, no logging no nothing.

Right, my point is - people give up on UWP apps -- the benefits are outweighed by the many many problems that come with it.

Maybe, but also by the fact that its easier to write a Website and pack it inside Electron and ship it to Mac, Linux and Windows instead of writing separate apps for all platforms.

When it comes to platform independence, that's a whole new topic - what I was referring to is the fact that a lot of issues people encounter when developing UWP apps should simply not exist. Switching from WPF to UWP has been a very bad experience.

@chingucoding

But why do you need access to the clipboard when the user is not using your app? If you try to set the clipboard when the user is not using your app, the user will get irritated when you interfere with his copy/pasting. And if you read the clipboard when the user is not asking your app to do it, you are spying on him. Unless that's your goal (in which case you should definitely not use UWP), there are very few reasons to read out the clipboard while your app is not in focus (if there are any at all).

In my case my app from time to time displays a notification when an event happens the app is watching for. The toast notification might contain information the user wants to process further/use in another context so I provide a [copy to clipboard] action button which copies some of the shown information. Since a notification might arrive at any time and the app might very well be in the background at that point I have to use a Win32 helper process in that case.

Using Win32 outside of the UWP sandbox is not always because the developer wants to achieve something without having the user know about it. So while generally speaking the sandbox provides value to us users, you still have to deal with it as a dev in any case, even if you aren't a malicious dev who doesn't mind spying on the user or has no intention asking for the user's consent before changing something on their system.

The fact that you can use a Win32 full-trust process alongside your app indicates that MS is aware of this dilemma and does give us devs the tools to use UWP and still be able to enjoy the freedom of Win32 to a good extent.

It's not. Far from it.

Can one download the app now? If so where can I find it? 😅

Clearly I would prefer not be in a sandbox at all, I'm just saying the current implementation is very bad.

I guess, if you dislike the sandbox, than maybe switching to an WPF alternative might be the better choice, instead of just trying to develop your apps in UWP, which you made clear, you think is "impossible" or "insanely hard" to develop apps for. I don't think that the WPF alternatives are so bad compared to Win2D, that would justify you going through all your struggles. But that's just my point of view on that.

Also, the current implementation is "bad" for people being used to having no limitations regarding to files. Coming from a Web development background, I am very fine with that. I can see their place, especially since the Web also has limitations whose purpose is to protect users.

I'm not sure what you mean about project files being incoherent.

Maybe the project files for debug are wrong and some dll is being generated in release, though I doubt that would happen if you are just letting Visual Studio handle that.

I do believe it is UWP related. This never happened to me when dealing with WPF - I had 28 projects, and it never crashed. In UWP I have 15 projects (which I ported from WPF), and it crashes. And if I look in Event Viewer, there's something about the sandbox crashing - I don't remember exactly.

Visual Studio's reliability vastly depends on the project size for me. Small/medium UWP/NetCore/NetFramework always work fine. Large projects result in Visual Studio getting unresponsive, hang or simply crashes at time. But that's just my experience.

I'm sorry, I meant "to go maximized" - sorry for that.

In that case, yes the change will only applied on next startup, since you set the value for it AFTER your app has started. I do not know what you mean by "I have to ask Windows". Are you referring to the fact that you have to set it in code?

Also there is a way to set the preferred size, which should result in the app taking all of space on the screen it is on (similar to maximized) though it is not quite as good as real maximized:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

This is wrong. This simply assumes I will always be calling from the UI thread. I mean sure this is fine for simple stuff, but I can create my own threads, and I can also create my own Tasks, and do stuff there.

If you are already using your own threads, using await should not be a problem for you. Even if you use separate threads, event handler are always run in the UI thread, so if you do extensive computation there, the app gets unresponsive.

As much as I hate the UWP setup as is, I was correct. I would have never been able to properly make it work. And I assume you're aware of microsoft/Win2D#731

I was not aware of that, I thought that being the issue I mentioned from 2018, it would be resolved fine by now.

The issue is - we have different behavior in Debug than in Release. It should be consistent.

Hmm that is very weird. The behavior should be consistent.

The funny thing is this - I wanted to copy something into the clipboard at startup.

They also mention that use case in the documentation, and you should wait for CoreWindow.Activated to copy. Why exactly would you copy something into clipboard though, when the user just started your app? Something similar to what @Felix-Dev wants to achieve/achieved?

@Felix-Dev Thank you for respond. I didn't think about that scenario. In that case, yes you need to access the clipboard and this definitely improves the experience for users. My guess would have been that since you toast "has focus" this would have worked. But I guess it's not the case.

So while generally speaking the sandbox provides value to us users, you still have to deal with it as a dev in any case, even if you aren't a malicious dev who doesn't mind spying on the user or has no intention asking for the user's consent before changing something on their system.

Yes we have to deal with it, however a lot of apps are not being limited by the sandbox in such a way it would be very hard to find a workaround. And one thing to not forget is that if UWP is not working for you, there are still 2 other options.

Regarding your last point, yes the fact that you can use Win32 processes is an indication that there are cases where UWP is limiting you.
Maybe this was the easiest/fastest workaround at hand, or maybe it actually is by design.

It's not. Far from it.

Can one download the app now? If so where can I find it? 😅

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

I guess, if you dislike the sandbox, than maybe switching to an WPF alternative might be the better choice, instead of just trying to develop your apps in UWP, which you made clear, you think is "impossible" or "insanely hard" to develop apps for. I don't think that the WPF alternatives are so bad compared to Win2D, that would justify you going through all your struggles. But that's just my point of view on that.

This was a WPF application. However, due to the nature of video editing, I've long hit the limits of WPF in terms of speed (basically, dealing with DrawingVisual). Trust me, I would have not done this, if I would have had a choice.

Also, the current implementation is "bad" for people being used to having no limitations regarding to files. Coming from a Web development background, I am very fine with that. I can see their place, especially since the Web also has limitations whose purpose is to protect users.

I could have sworn you were coming from a Web background :)

Maybe the project files for debug are wrong and some dll is being generated in release, though I doubt that would happen if you are just letting Visual Studio handle that.

That is not the case, but I did double check - not the case.

Visual Studio's reliability vastly depends on the project size for me. Small/medium UWP/NetCore/NetFramework always work fine. Large projects result in Visual Studio getting unresponsive, hang or simply crashes at time. But that's just my experience.

Yes, I've dealt with that in the past. Doesn't seem to be the case with the latest versions of VS (2017,2019). Anyway, long story short, this just happened on UWP for me. It may have to do with the fact that I'm using win2d, and I have a feeling that is quite a complicated beast.

In that case, yes the change will only applied on next startup, since you set the value for it AFTER your app has started. I do not know what you mean by "I have to ask Windows". Are you referring to the fact that you have to set it in code?

In WPF, I simply set the window size to where I want it to be. Here, there's an API you need to call -> ApplicationView.PreferredLaunchViewSize - which, as the docs say "it works, except in cases where the system manages the window size directly." - and yeah, it only works for the next app start.

Also there is a way to set the preferred size, which should result in the app taking all of space on the screen it is on (similar to maximized) though it is not quite as good as real maximized:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

I'm using another code, which actually works correctly

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;

If you are already using your own threads, using await should not be a problem for you. Even if you use separate threads, event handler are always run in the UI thread, so if you do extensive computation there, the app gets unresponsive.

Clearly, the event handlers run in the UI thread. I've kinda' got accustomed to it, I did have to modify quite a bit of my app - just adding async to functions... What still truly bothers me is that to me, it looks like quite a few APIs have taken this to the extreme, just having Async() only versions, where it makes no sense.

I was not aware of that, I thought that being the issue I mentioned from 2018, it would be resolved fine by now.

It has not - at least last time I checked.

The issue is - we have different behavior in Debug than in Release. It should be consistent.

Hmm that is very weird. The behavior should be consistent.

Yeah, that's what really pissed me off. And clearly, working with clipboard for an insanely long time on non-UWP apps, I didn't think we'd have these limitations, so yeah, I didn't read about having to wait for CoreWindow.Activated. Having said that, it's incredibly cumbersome to have to learn all these details. It's like I need to learn a whole new language altogether. Instead of being a seamless process, it seems every week I learn of something that just blows my mind.

They also mention that use case in the documentation, and you should wait for CoreWindow.Activated to copy. Why exactly would you copy something into clipboard though, when the user just started your app? Something similar to what @Felix-Dev wants to achieve/achieved?

This was when I was early testing my app, and I just wanted to give it to a colleague for some more internal testing. However, he would need to tweak some settings. And the settings were kept in the Application's LocalFolder. This is different for every user, so my take was -- let me just keep this simple and copy it to the clipboard. Then when he starts the app, he'll then go to "This PC", paste the location, and edit a settings file there (now, I know how I could have simply opened the app in Explorer, but at that time, I did not). Which ended up crashing, and me investigating and cursing for a few good hours.

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

Thanks!

This was a WPF application. However, due to the nature of video editing, I've long hit the limits of WPF in terms of speed (basically, dealing with DrawingVisual). Trust me, I would have not done this, if I would have had a choice.

Didn't knew that WPF had such a big performance draw back compared to UWP.

That is not the case, but I did double check - not the case.

That's weird. I would have expected there to be something wrong. Why would VS talk about release dll's when you are running debug.

In WPF, I simply set the window size to where I want it to be. Here, there's an API you need to call - ApplicationView.PreferredLaunchViewSize - which, as the docs say "it works, except in cases where the system manages the window size directly."

But isn't the code you are using also an API to set the window size?

• and yeah, it only works for the next app start.

Not surprising when it's called "PreferredLaunchViewSize" 😅
Just a bit inconvenient that there is no way to set this after launch.

Yes, I've dealt with that in the past. Doesn't seem to be the case with the latest versions of VS (2017,2019). Anyway, long story short, this just happened on UWP for me.

Happy to hear that it's not as bad as it was with earlier versions of VS.

It may have to do with the fact that I'm using win2d, and I have a feeling that is quite a complicated beast.

I don't rely on the designer much since it starts to fail for template bindings. Have you tried Blend for Visual Studio? Is that more reliable regarding the designer?

Yeah, that's what really pissed me off. And clearly, working with clipboard for an insanely long time on non-UWP apps, I didn't think we'd have these limitations, so yeah, I didn't read about having to wait for CoreWindow.Activated. Having said that, it's incredibly cumbersome to have to learn all these details. It's like I need to learn a whole new language altogether. Instead of being a seamless process, it seems every week I learn of something that just blows my mind.

Yes I can imagine that. Something that might be good is a transition guide from WPF to UWP. If this would exist, that would definitely save new UWP and former WPF devs a lot of time. And this wouldn't be the first time there is a transition guide. There is already a Java to C# guide, which helps a lot for Java devs.

This was when I was early testing my app, and I just wanted to give it to a colleague for some more internal testing. However, he would need to tweak some settings. And the settings were kept in the Application's LocalFolder. This is different for every user, so my take was -- let me just keep this simple and copy it to the clipboard. Then when he starts the app, he'll then go to "This PC", paste the location, and edit a settings file there (now, I know how I could have simply opened the app in Explorer, but at that time, I did not). Which ended up crashing, and me investigating and cursing for a few good hours.

Oh I see. If one doesn't think about opening the folder, copying the folder path to clipboard is a solution. For testing purposes this is quite smart.

Didn't knew that WPF had such a big performance draw back compared to UWP.

WPF wasn't optimized for DirectX - when pixel shaders and masks come into play, it ends up being very slow. Porting to UWP/win2d made the app 3-4 times faster. That's insanely noticeable.

That's weird. I would have expected there to be something wrong. Why would VS talk about release dll's when you are running debug.

Yeah, my point exactly.

But isn't the code you are using also an API to set the window size?

What I mean, you use Preferred...Size, but you are not guaranteed it will happen. As when using WPF, you're guaranteed when you set position/size, it will actually happen.

Not surprising when it's called "PreferredLaunchViewSize" 😅
Just a bit inconvenient that there is no way to set this after launch.

This is beyond inconvenient - it's insanely inconvenient. Basically, I can not resize my app once it started. And yes, I would like my app to have different "modes" of operation (like, Basic/Advanced) -based on that, I would want to take more or less space - I can't do it. Do you think the user will be ok with "Changes will happen only after restart"?

I don't rely on the designer much since it starts to fail for template bindings. Have you tried Blend for Visual Studio? Is that more reliable regarding the designer?

I should have been more specific - the VS doesn't crash when editing xaml - it crashes when launching the app; basically, I assume it happens exactly at deployment, since you just see the big "x" on the (uwp) app for like 10 seconds, and at that point I know it hangs. At which point I can wait another 45-60 seconds and see that VS will crash, or just close VS from Task Manager.

Yes I can imagine that. Something that might be good is a transition guide from WPF to UWP.

Yes, that would be very helpful.

Oh I see. If one doesn't think about opening the folder, copying the folder path to clipboard is a solution. For testing purposes this is quite smart.

Thanks ;) Well it would have been smart, had it actually worked :)

@chingucoding

Sometimes async is a bit annoying, however in most cases async methods have a reason to be async, since you do not want to block the UI on operations such as network or file operations. Having said that, you can use the following methods to run your async method synchronously

Let me give you one more reason i hate async - this just happened to me now (basically, it's a bug report from a user). Initially, I could not figure it out for the life of me.

Long story short - on a button click, I open a file picker. Which, you guessed it, is async.

So, the user double clicked it (with about 100 ms pause between the clicks). Surely, this opened 2 file pickers.

Now, clearly I can fix this, but this would never happen, had the initial function was synchronous (and of course, this will never happen in WPF).

This is beyond inconvenient - it's insanely inconvenient. Basically, I can not resize my app once it started. And yes, I would like my app to have different "modes" of operation (like, Basic/Advanced) -based on that, I would want to take more or less space - I can't do it. Do you think the user will be ok with "Changes will happen only after restart"?

Well "insanely inconvenient" may be for apps that need to enforce certain sizes, but in most cases apps do not need to resize themselves. How should an app choose which size is currently appropriate for the users use case? If the user has a need to make it smaller or bigger, than the user is the first to notice that. Especially since he know best where other open windows are and where space would be available to not block other windows from being visible.

If you have a basic and advanced mode, you may change the min preferred size if the app will definitely not work when being to small. But in my opinion it would be very irritating for me if programs would start resizing themselves (and luckily no program does this so far).

I can't do it. Do you think the user will be ok with "Changes will happen only after restart"?

If resizing is that important, a user can do it themselves. However this "changes will happen only after restart" is not uncommon, so it is partially acceptable in my opinion.

So, the user double clicked it (with about 100 ms pause between the clicks). Surely, this opened 2 file pickers.

Why exactly did it open the file picker twice? Did the event handler trigger twice? Than this is not an issue caused by async but by the fact that the event handler did not block the UI from receiving additional events from the respective button.

Long story short - on a button click, I open a file picker. Which, you guessed it, is async.

Yes it's async because you do not want to block your whole thread while the user is navigating his drive and picking the folder. The call is finished when the user has finished picking a file/folder, and you get the chosen file as result.

In my opinion it is better to not block the thread on such operations since you never know how long they will actually take. If you block the UI thread because of that, your app becomes unresponsive as long as a file picker is open, which IMO is not a good UX.

Let me start by respectfully saying this: we'll never agree on anything.

Clearly you're thinking from a web perspective, and you simply don't see anything as "desktop". I know you mean well, but you're just not thinking "desktop" until you've developed something complicated - when it comes to desktop. And I believe you haven't.

Well "insanely inconvenient" may be for apps that need to enforce certain sizes, but in most cases apps do not need to resize themselves. How should an app choose which size is currently appropriate for the users use case? If the user has a need to make it smaller or bigger, than the user

Are you seriously asking this? Isn't an application supposed to help the user? And then if the user is not ok with the app's size he can then resize. But the app should be able to say, based on what it's supposed to accomplish, this is the size I should be running at. Lets say, Photoshop - will always prefer to run full screen, because it's got a lot of info to show to the user.

If you have a basic and advanced mode, you may change the min preferred size if the app will definitely not work when being to small. But in my opinion it would be very irritating for me if programs would start resizing themselves (and luckily no program does this so far).

If they did, you didn't even think about it. Wizards sometimes run at smaller sizes, and then when the wizard finishes, the app may go full screen.

I can't do it. Do you think the user will be ok with "Changes will happen only after restart"?

If resizing is that important, a user can do it themselves. However this "changes will happen only after restart" is not uncommon, so it is partially acceptable in my opinion.

And have a bad start-up experience, because I show a window that looks good only a certain size - and Windows just says "Oh, but I'll show the app as I want".

Why exactly did it open the file picker twice? Did the event handler trigger twice? Than this is not an issue caused by async but by the fact that the event handler did not block the UI from receiving additional events from the respective button.

Are you honestly doing this? Show me how a code snipped where you've done this consciously.

In my opinion it is better to not block the thread on such operations since you never know how long they will actually take. If you block the UI thread because of that, your app becomes unresponsive as long as a file picker is open, which IMO is not a good UX.

How does WPF handle this? It handles it correctly. The UI doesn't block, but the app does block at that call - so the above would never happen in WPF

Let me start by respectfully saying this: we'll never agree on anything.

If this is your view on this discussion, I am sorry about that.

Clearly you're thinking from a web perspective, and you simply don't see anything as "desktop". I know you mean well, but you're just not thinking "desktop" until you've developed something complicated - when it comes to desktop. And I believe you haven't.

I think a more accurate description would be: I am coming from a background where devs don't have access to anything and you are coming from a background where devs have access to every OS resource.

If they did, you didn't even think about it. Wizards sometimes run at smaller sizes, and then when the wizard finishes, the app may go full screen.

Yes wizards run at smaller sizes BUT most wizards (including the Visual Studio 2019 Startup "Wizard") close themselves and then start the real program. They do not "morph" into the actual application.

It's worth noting that some wizards also aren't new windows but rather just popups, with the actual application being in the background.

And have a bad start-up experience, because I show a window that looks good only a certain size - and Windows just says "Oh, but I'll show the app as I want".

You make it look like Windows is just ignoring your code all the time, while it is clear when it will ignore that (taken from documentation of "PreferredLaunchViewSize"):

This property only has an effect when the app is launched on a desktop device that is not in Tablet mode.

So it only works on desktop in non tablet mode. But does it make sense on other devices to actually request sizes? Do you expect your app to run on X-Box or Holo Lens, and have you optimized for such devices? If not, than this limitation shouldn't be bothering you that much.

Are you honestly doing this? Show me how a code snipped where you've done this consciously.

No I am not, I was just trying to point the fact out that you blame "async" for something that is not related to that. If the users clicks on a button twice, the clicked event gets triggered twice.

How does WPF handle this? It handles it correctly. The UI doesn't block, but the app does block at that call - so the above would never happen in WPF

I am fairly certain if you run code in the UI thread and it takes time to complete, than you are blocking the UI thread in WPF.

Hi, I'm the dev lead for Windows SDK and Windows Runtime infrastructure on the Windows OS team.

This is a great discussion with a lot of detail and conversation. Someone brought this conversation a few days ago, and I'm looking forward to reading through it, but it may still take a few days before I get to it. I will read the whole thing, though, and try to give you some more detailed answers or follow up as best I can.

This probably isn't the best place for winrt general issues. You can either raise issues in the Microsoft developer forums, or for Windows Runtime issues specifically, you can open an issue in https://github.com/microsoft/xlang. Our team reviews incoming issues there on a regular basis. Issues filed in github will get to my team faster, but have less tracking. If your feedback requires OS changes, keeping the OS work in sync with a filed github issue is a manual process. On the other hand, forum feedback follows the work across teams and the organization, and is less likely to get disconnected form actual work done based on the feedback.

Thanks again for the lively discussion. I'll post again on this issue soon.

Ben Kuhn
Microsoft

Hi Ben,

Hi, I'm the dev lead for Windows SDK and Windows Runtime infrastructure on the Windows OS team.

This is a great discussion with a lot of detail and conversation. Someone brought this conversation a few days ago, and I'm looking forward to reading through it, but it may still take a few days before I get to it. I will read the whole thing, though, and try to give you some more detailed answers or follow up as best I can.

Awesome - look forward to your reply(ies)!

Since I'm the original poster, if you have any questions / anything is unclear, please let me know and I'll do my best to clarify.

This probably isn't the best place for winrt general issues. You can either raise issues in the Microsoft developer forums, or for Windows Runtime issues specifically, you can open an issue in https://github.com/microsoft/xlang.

Agreed it's not the best place, the issue is people don't know where to post.

If you say we should post to https://github.com/microsoft/xlang, I'll definitely post there from now on.

Best,
John

First, let me call out a few things that I’m not going to address.

• There’s a lot of great discussion about Windowing, window position, etc. near the bottom of the thread. That’s probably still a little off topic for WinUI, but closer to home. I’d like to let the WinUI folks parse the feedback about window position, full screen, etc. and help redirect. @StephenLPeters, can you help out with this?

• I’m not going to touch VS feedback. There’s a healthy forum for discussing VS quality and performance. Though I have taken note of the discussion that the story for developing Windows apps from Visual Studio has become a bit more complex and muddled.

• WPF. I have a love hate relationship with WPF. It’s useful, and mostly good. When I read the comment about nested clicks on the file picker it made me laugh though. Because there are some quirks in WPF that have given me real headaches. Like the fact that when you drag in WPF, the drag messages double-dispatches in a nested message sometimes, so that you’re actually doing a modal drag inside a modal drag. You usually never notice. Usually. But I still like WPF. 😉

Second, @verelpode: This made me laugh. Mind if I hang on to this one?
“I believe that you can't handle the direct truth, therefore I'll handle you with thick fluffy cotton gloves, and pack you in bubble wrap"

Ok, now on to real topics.

WinRT vs. UWP vs. .NET – some background

The Windows Runtime is really two things rolled into one, packed up in another, and really misunderstood.

The Windows Runtime type system is really, in a sense, COM V2. It’s the spiritual next step in the progression from triggering interrupts, to calling Win32, to calling COM APIs. The type system is in some ways slightly less expressive in COM, but in most ways a substantial superset. It was designed originally to address exactly one problem: how do we make it easier for developers using .NET or other languages to call WinRT APIs without having to wait for VS to make nice wrappers in the .NET framework.

Then there’s the API library. We did some great things here, and some silly things. We might have got a bit carried away with some of the async stuff. If you program with C++ /WinRT, you can significantly mitigate this. If you’re not on the UI thread, you just grab the result and it’ll block and complete syncronously. .NET may also make this easier now, but I write less .NET code these days, and I’m less certain about the current state of things. We did a few other things that didn’t work as planned, too. I won’t list them all. We’ve made some improvements though.

The UWP application model jumped into winrt with both feet. It meant we could write OS APIs once and make them easy to access from JS-based apps, .NET apps and native apps. That by itself was goodness. Taking away all the other Win32 APIs wasn’t so good. We still have some documentation work to do, but there are far more classic Win32 APIs that can be used in store apps now. Long story short, we created an entirely new app platform with a small user base on new devices, didn’t let you bring your existing code, and not a lot of people showed up. We know. That’s why we’re fixing it, bit by bit. We got a lot right too, and are working our way slowly but steadily towards a best of both worlds approach. A declarative install system is, in most ways, a wonderful thing.

Code portability between UWP apps and desktop apps was also touched on in this thread. Because the UWP model diverged so much, there are a number of pain points. We’re addressing them as quickly as practical. Some take time, or require “major breaks”. For instance, we use different names for the CRT DLLs. We put together a mitigation, the VC forwarders package, but the real fix will be to eventually remove the distinction in a future version of the CRT, which inherently requires renaming the files and a major breaking change. We intentionally do this infrequently because it is disruptive.

WinRT itself is increasingly moving it’s tooling open source, and although not well known, most of WinRT is available to desktop apps. XAML was the big gap. XAML Islands were a step in the right direction, but I’m far more excited about WinUI.

Feedback for specific APIs

For a number of these, I’m going to ask that you file feedback if this is your issue. I’ll help promote the issue to the right team. Different teams in Windows are each responsible for their own APIs, and it’ll be most effective if you file in feedback hub. This connects the feedback with a real human and story. It also allows you to track the feedback. You can help each other a bit by adding to feedback that others file as appropriate. Try to pick an appropriate category. If not clear, you can use “developer feedback” -> API Feedback

Filesystem APIs for modern apps are painfully and unexpectedly slow

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
We’ve heard this feedback, both from customers and our own teams building applications. I wish I had more I can share at this time. For now all I can say, unfortunately, is “we know”.

BroadSystemAccess API / capability is not practical as implemented.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Please submit a feedback hub item and send me the link. I’ll personally promote it and hand it to the right owner. An 80% falloff rate is not good. I understand the point about it being a red flag for users as well. IF, the file APIs were fast enough, it sounds like future access list would mitigate at least some of the pain, but might not be as ‘slick’ as what you have now. But then, you’re in between a rock and a hard place. To be magical the way you’re doing it now, you need the user to let you see everything. Their password spreadsheet, their mail folder, their browser cache, etc. You may be trustworthy, but your app should make users pause and think about how much they trust you before handing over their world.

I understand that the idea of closing the app and restarting is an awkward step. This seems like the type of thing that should at least be sorted out on first launch. Please file a separate feedback item. Same offer. I’ll promote and deliver.

With regard to whether future access list can access subfolders, I’ve gone ahead and created a documentation issue for the page. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. It’s worth noting that since the doc pages are on github, you can file issues on docs or propose changes to the contents as well.

Dragging file into apps doesn’t allow write access: Same offer about feedback hub. Please file, and I’ll route accordingly.

Creating apps for sideloading outside MS store

The takeaway that I got here is that moch of the issue is a doc issue, but it touches on another key aspect. As some of our tooling has moved to github projects and open source, the documentation has moved with it, and that makes it harder to use the Windows documentation as a one stop shop for everything. I’ll raise this issue internally both with regard to the specific issue around the .appinstaller file and discuss more generally with our content team about how to better address this.

You also noted a specific issue about needing to route through the server to debug. That you should file as an issue against the existing github project.

New Certificate issue & Private Distribution

This is a little closer to home from me (my larger team also handles aspects of application installation. I’d still appreciate a feedback hub issue on this that I can work from.

WinRT type system impacts ability to deliver great APIs & libraries

The inability to overload on type name is by design. Until we rethink how javscript (how about Node / V8? Would that be interesting?) apps access WinRT APIs, we won’t be ready to revisit this. The other issue around properties and NaN is in a separate issue that has some good discussion, so I won’t wade into it in this response.

Feedback Hub should prompt when abandoning to prevent accidental deletion of content

Yeah, I’ll +1 that. Please file it. There’s a category in feedback hub under apps for… feedback hub. That's so meta.

Async APIs are still out of hand, and seem awkward for things that shouldn’t be async

Yep. This continues to be a topic of debate internally as well. There’s some fine balance between nannying and encouraging good behavior that we haven’t quite hit yet. Please continue to file feedback on specific APIs that you’d love to see be synchronous.

There are no good audio APIs on WinRT

I’m not an audio expert. Feel free to file in feedback hub, but I’m also going to call in a lifeline here and do some asking around.

Clipboard Pains

I have to start with a Mae Culpa here. Our clipboard access model was designed in the Win8 era, when we were being super-protective of the user. I coded most of it. There are good reasons to be protective of the clipboard. Users put all sorts of sensitive data on the clipboard, while an app that can overwrite the clipboard could also do harm by attempting to exploit weaknesses in other apps that might have more access. The Win32 clipboard APIs also enable some pretty powerful behaviors that could be abused. Hence the clipboard limits access unless your app is in the foreground or attached to a debugger, and tightens up what you can put on the clipboard a bit (in ways you should never notice unless you’re really trying).

That said, a notification that’s being interacted with seems like it should be allowed clipboard access. This would require special handling because of how Windows and foreground is counted, I think, but doesn’t seem beyond reasonable. Please file under API feedback and I’ll promote that issue into the bug database as well.

Wrapping up

I hope that’s helpful. I’ll track the thread and follow up on the issues above as noted if you get them filed.

Out of respect for the WinUI team, who already have plenty on their hands, please let this thread wind down and focus on just the WinUI & Windowing aspects raised in this thread. Since this one is so long and meandering, it may be helpful to tease them out into separate, smaller issues. I’ll leave this open for a few days for you all to file feedback and drop comments in with links, then I’ll close this thread out.

If you do want to dive into WinRT type system discussions more, the xlang project is a good place to start. For specific Windows API behaviors, feedback hub is a better choice. It does have a comment system as well, now, so hopefully that helps.

Thanks again for a great discussion and all the detailed feedback about so many topics.

Ben Kuhn
Microsoft

Your app wouldn't close if you presented file picker(s) that let the user choose what they want to give your app access to.

I cannot stress enough how important this is as a user. I don't want to give any app access to everything, but if you ask for an oddball location _and it makes_ sense I'll grant access.

@BenJKuhn Thanks for the detailed answer. Very very much appreciated!

• WPF. I have a love hate relationship with WPF. It’s useful, and mostly good. When I read the comment about nested clicks on the file picker it made me laugh though. Because there are some quirks in WPF that have given me real headaches. Like the fact that when you drag in WPF, the drag messages double-dispatches in a nested message sometimes, so that you’re actually doing a modal drag inside a modal drag. You usually never notice. Usually. But I still like WPF. 😉

I totally agree. I'm not an advocate for WPF, I've hit the limits of WPF loooong time ago. That's the reason I moved to UWP. Stability-wise, WPF seems way more stable.

WinRT vs. UWP vs. .NET – some background

Then there’s the API library. We did some great things here, and some silly things. We might have got a bit carried away with some of the async stuff.

You can say that again :)

Code portability between UWP apps and desktop apps was also touched on in this thread [...] but the real fix will be to eventually remove the distinction in a future version of the CRT, which inherently requires renaming the files and a major breaking change.

Any ETA? .Net 5?

Filesystem APIs for modern apps are painfully and unexpectedly slow

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
We’ve heard this feedback, both from customers and our own teams building applications. I wish I had more I can share at this time. For now all I can say, unfortunately, is “we know”.

So far, I have a workaround - far from ideal, but for now I'm ok - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment-575987737

BroadSystemAccess API / capability is not practical as implemented.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Please submit a feedback hub item and send me the link. I’ll personally promote it and hand it to the right owner. An 80% falloff rate is not good. I understand

Will do, I hope to get to it over the weekend.

the point about it being a red flag for users as well. IF, the file APIs were fast enough, it sounds like future access list would mitigate at least some of the

Yes, if StorageFile/Folder API would be as fast as System.IO (or at least comparable), it would mitigate it. It's not for lack of trying - I've done everything outlined in the docs.

pain, but might not be as ‘slick’ as what you have now. But then, you’re in between a rock and a hard place. To be magical the way you’re doing it now, you need the user to let you see everything. Their password spreadsheet, their mail folder, their browser cache, etc. You may be trustworthy, but your app should make users pause and think about how much they trust you before handing over their world.

I totally understand all this. And I agree with you. My pain point is the current implementation of all this. I've already rewritten most of the UI dealing with this (several times).

Having said that, here are my ideas for improvement:

• "Select Folder" could be a bit more helpful - I could specify the files I'm interested in, and it could highlight to the user the folders that contain it
• Clipboard - if user puts some files/folders in clipboard, and then goes back to my app, I should automatically have access to those (perhaps you can add a "ClipboardFilesAndFolders" capability)
• drag-and-drop of files/folders - that should automatically give me access to those files (why would the user drop them in my app otherwise?)

I understand that the idea of closing the app and restarting is an awkward step. This seems like the type of thing that should at least be sorted out on first launch. Please file a separate feedback item. Same offer. I’ll promote and deliver.

Got it, thanks - over the weekend.

Dragging file into apps doesn’t allow write access: Same offer about feedback hub. Please file, and I’ll route accordingly.

Right, will do - the thing about dragging files into apps. I haven't actually tried it yet:

1. does it work with both files and folders?
2. do I get access to the .Path ?
3. Is it persistent (I assume not)?
4. Do I need to hang on to the StorageFile/Folder, or recreating it later from .Path will work (assuming the answer to 2. is YES)?

Creating apps for sideloading outside MS store

The takeaway that I got here is that moch of the issue is a doc issue, but it touches on another key aspect. As some of our tooling has moved to github projects and open source, the documentation has moved with it, and that makes it harder to use the Windows documentation as a one stop shop for everything. I’ll raise this issue internally both with regard to the specific issue around the .appinstaller file and discuss more generally with our content team about how to better address this.

Yeah, that would be awesome!

Personally, I have figured it out for my app. It's keeping me from doing some other advanced stuff I'd like to do (like, have a win32 app to launch, since I'm afraid how the whole .appinstaller file would need to change).

But, to me, this should be a part of the Visual Studio "Publish" process. You should create an .appinstaller for me (since getting all those dependency names right is far from trivial, and any updates to the dependencies -> here we go again). It should also create a readme.txt file, in which it should explain what I need to upload to my server, and also tell me that I can't use the .appinstaller locally, it needs to be downloaded from the server (when testing)

You also noted a specific issue about needing to route through the server to debug. That you should file as an issue against the existing github project.

I don't remember what that issue was :)

Feedback Hub should prompt when abandoning to prevent accidental deletion of content

Yeah, I’ll +1 that. Please file it. There’s a category in feedback hub under apps for… feedback hub. That's so meta.

Right :)

Async APIs are still out of hand, and seem awkward for things that shouldn’t be async

Yep. This continues to be a topic of debate internally as well. There’s some fine balance between nannying and encouraging good behavior that we haven’t quite hit yet. Please continue to file feedback on specific APIs that you’d love to see be synchronous.

Hehe, that's a loong list ;)

1. It starts with basic properties on StorageFolder/File; StorageFile.GetFileFromPathAsync (+ similar for Folder).
2. Loading thumbnails (StorageFile.GetThumbnailAsync
3. Loading of bitmaps. This is especially painful, since it got carried into other libs (such as win2d), and I've hit insane thresholds - like, loading of a simple bitmap (which should take <20ms), to last 5 seconds or so. Clearly there's some locking behind the scenes, but no one know what/why/when. And yeah, my laptop is a rocket.

I haven't kept track of a lot of other APIs, a quick search on my project shows 326 uses -- I've trimmed that down a lot, since a lot of things on my end need to be synchronous.

The above are my main top pains, from the top of my head. From now on, I'll create a doc, and add to it :)

There are no good audio APIs on WinRT

I’m not an audio expert. Feel free to file in feedback hub, but I’m also going to call in a lifeline here and do some asking around.

I'm not sure if/how this will ever be solved. The easiest thing would be to lax the requirements or something, so that naudio (https://github.com/naudio/NAudio) can be properly ported to UWP. To be clear, it can be compiled to UWP out of the box, but it's useless because most of the userful stuff is #ifdef-ed out.

To be clear, I'm not complaining about sound API on UWP - which is totally fine, but I need more. Namely, the ability to interpret sound waves and the like (which naudio allows).

I've done a port of naudio, where I pretty much removed all #ifdefs - it works, but my app won't ever make it into the MS store - and I'm fine with that.

Clipboard Pains

[...] That said, a notification that’s being interacted with seems like it should be allowed clipboard access. This would require special handling because of how Windows and foreground is counted, I think, but doesn’t seem beyond reasonable. Please file under API feedback and I’ll promote that issue into the bug database as well.

Sounds good, will do.

Thanks!

@jtorjo Would you be so kind to also include issue #1893 (Proposal: File-system access: Provide a user-friendly way to request permission to access specific file locations) in your Feedback Hub items about the File system (in case you didn't plan that already, I think you listed the underlying issue above). I'm afraid I already have a bunch of other items to file so if you could cover this one when you tackle the File System that would be great :)

Of course, I would still file it if adding it to the Feedback Hub would be inconvenient for you!

@Felix-Dev I'll do my best! Will keep you posted!

Dragging file into apps doesn’t allow write access: Same offer about feedback hub. Please file, and I’ll route accordingly.

Right, will do - the thing about dragging files into apps.

This was actually supposed to be the note about opening from a shell context menu. Sorry for the confusion.

@BenJKuhn In light of this Github repo being a much better place to have discussions for specific WinRT proposals than the Feedback Hub place (based on developer sentiment expressed multiple times in this repo over the last 12 months): Would it be fine to just post a quick proposal summary on Feedback Hub with a link to the much more in depth proposal located in this repo (for now, as there is no specific UWP app model fedback platform which has the confidence of the developer community I am aware of)? I have seen proposals being further refined with other community input here so the specific team at Microsoft would have a direct link to the developing proposal.

@Felix-Dev For specific proposals, I honestly think it's best to start submitting them to Feedback Hub tagged as "Developer Platform > API Feedback."

Looking through the recent feedback filed under that filter, it seems like not very much specific feedback has been added. I only saw 30 items (at most) filed under that filter. However, engineers have responded to feedback there recently.

I'm calling on the community to file their API feedback through Feedback Hub as tagged above, and we'll start to see it flourish as an option to submit API feedback once the proposals become better.

I think @BenJKuhn will agree with me.

I just noticed my response has become quite long, so take this as a forewarning 😅

@duke7553 We have a situation here where the community should use two different platforms for their UWP platform feedback. Specifc API requests like (please add parameter x to method y, or add a method to do z) should be filed in the Feedback Hub at least (though they should probably posted in an additional place too). However, issues/proposals more complex than that (up to going to the very core of the UWP) platform should definitely be posted somewhere else other than the Feedback Hub in its current form. It's fine to post a short summary on the Feedback Hub but for anything else, Feedback Hub just isn't the platform right now. Read below for more details as to why.

In its current state, the Feedback Hub is just not looked positively at by the many active members of the development community based on their sentiment expressed in this very repo and other places like Twitter time and time again. Issues singled out here for example are:

• The (perceived) lack of engagement by the Windows Dev teams (I just looked at the recent filed API feedback as well and a lot of issues there show up with 0 comments and zero official reply as of right now, especially regarding issues 2 months and older).
• Community engagement for specific issues/proposals is quite low (up-votes, comments).
• The overall UI/UX of the Feedback Hub which really makes it quite hard to have engaging feedback disccusions with the team and community. On this, some folks on the WinUI team stated they also agree with the community here.
• Finally, it is just so much easier on Github right now to add supporting media files like images or GIFs to a proposal to help visualize it. I will just leave this image here directly taken from the Feedback Hub when filing an issue:
  

I did not use Feedback Hub before to file development platform specific issues and looking at it right now, seeing how issues there are received by the community (nearly zero community engagement!), the Windows dev teams and its overall structure, I have to say this single WinUI repo is superior to the Feedback Hub in basically every aspect (ease of proposal creation/community engagement/availability of MS developers/...).

It's not even close, honestly.

Especially when it comes to community involvement. I cannot stress enough how exceptional the community input has been in this repo here and has massively driven forward and improved so many issues/proposals. All of that great community input would be gone if filed in the current Feedback Hub alone.

And about responses by the dev team to my UWP app model issues created here, I will just say this: In many cases like this one I got timely feedback with the note that a work item has been created internally. What more can I ask for? Contrast that with the sentiment of many devs whol feel their issues will go nowhere at all if filed in the Feedback Hub. And I can see where they are coming from by just looking at the Feedback Hub right now.

@BenJKuhn
The teams at MS need to seriously step up their UWP feedback platform and until I've seen those improvements I will always use this repo here too as long as permitted by the WinUI team. Feedback Hub currently has rock bottom standing in the eyes of many Windows developers and a post overnight won't suddenly change that situation. It's a start but much more is needed to fundamentally revert the negative impressions many devs will get when speaking about the Feedback Hub (or other MS specific developer feedback platforms like the previously shut down UserVoice for UWP). Given the many disappointing experiences many UWP/Windows developers got when dealing with Feedback Hub or other past feedback platforms, I - on this matter - strongly believe the Windows Dev & feedback teams need to step up first and foremost instead of pleading to the devs to return (without much - if any - visible improvements to show). I recognize this is quite a harsh view, but if you actually look at the many responses by devs given in this repo and many other feedback platforms over the years, you will easily see there is real frustration in the development community.

I don't wan't to be just harsh here though as both sides will need each other to create a vibrant and fruitful feedback platform providing high satisfaction values for both Microsoft and the developer community. As a compromise, I have been suggesting in my post above to post UWP issues here in this repo where they can be actively discussed with the community and post a short summary with a link to the github thread included in the Feedback Hub. Besides all of the advantages this would have for the community I've listed above, the added link will also give the Windows Dev teams a look at the many different views present in this community and even catch many small ideas which will probably never get filed in the Feedback Hub but can be found in many of the comments here.

I will end this post with a screenshot taken from the Feedback Hub's Developer Platform -> API Feedback section:

PS: I will use this post to give my sincere thanks to the WinUI team again that they agreed to open up their repository to host issues which are not related to WinUI at all but instead aim to address fundamental issues developers are seeing in the UWP. Thank you, WinUI team!

@BenJKuhn

Here's the feedback hub issues I've created

BroadSystemAccess API / capability is not practical as implemented. https://aka.ms/AA804aq

BroadSystemAccess API / should not restart app when user allows broad system access https://aka.ms/AA7zpe3

Clipboard should work at all times. https://aka.ms/AA804ce

File-system access: Provide a user-friendly way to request permission to access specific file locations https://aka.ms/AA804cp (for @Felix-Dev )

There are no good audio APIs on WinRT https://aka.ms/AA804d0

Async APIs are still out of hand, and seem awkward for things that shouldn’t be async https://aka.ms/AA804d3

Other things I've created

More detail - should allow more characters https://aka.ms/AA7zws5

Choose a category - make this easier https://aka.ms/AA804cd

Things I'm not sure about

Drag and drop of files/folders - I haven't personally tested it. Namely, I'm not curious about the drag and drop part, which is not very hard to implement. I'm curious if it actually works when user drops files/folders on a UWP control. Do I have read-only access (which would be enough for me)? Could I add these files/folders to FutureAccessList?

I'm curious if anyone has tested/used this successfully, since there's not that much info online.

Feedback hub

Feedback hub is not a pleasant experience. For one thing, the issues I add don't show up on "My Feedback" for a while - I need to close and restart the app. It doesn't remember my last selection. I can't write too much text, no way to drop a file, and/or clipboard images. So pretty much I'm in full agreement with @Felix-Dev - it's really hard to understand where to post issues (other than, from now on will post to xlang).

@BenJKuhn Here is the Feedback Hub link for the specific toast notification issue having access to the clipboard when interacted with by the user: https://aka.ms/AA7zx69

Thanks everyone for the great discussion. I've routed each of the platform issues that you've filed to the appropriate teams. To set expectations accordingly, let me draw an analogy from job hunting: it's a bit like getting past screening and getting straight to the interview in the hiring process. From here, each issue is in the hands of the right team to investigate and prioritize.

I appreciate the effort you've made to report these issues, and will continue to track them as teams review them. I hope you'll each continue to engage with us on the issues you encounter, and I'll do my best to support you in improving the application developer experience on Windows.

Thanks,

Ben Kuhn

@jtorjo could you share the WACK report for the UWP port of NAudio you built?

This data would help us evaluate what restrictions we'd need to relax so that NAudio could make it through Store certification.

@mikebattista I've attached the WACK. Please take into account only the naudio issues.

Clearly, the issues from log4net would be cool to solve too, even though I assume by forking log4net and removing those calls, I should be fine. However, it's weird that they show up, since I'm pretty sure we're never actually called. Anyway...

FindFirstFileExFromApp - this should (and in fact exists) - it should definitely not be flagged.

You can ignore the EnumChildWindows/EnumWindows - I can #ifdef them out.

ValidationResult.zip

Thanks! We will evaluate the Supported API failures. I have reached out to the audio team to get their input on potentially relaxing any restrictions here.

@mikebattista awesome, thanks! Looking quite forward to this :)

@jtorjo regarding the drag and drop scenario:

1. does it work with both files and folders?
   It should and does for many apps and tests, if you find otherwise, then please file a bug on that.
2. do I get access to the .Path ?
   Maybe - If there is a real file system path to back the storage item, then yes. (things like the shell libraries don't actually have a real file system path)
3. Is it persistent (I assume not)?
   No, the app can make it persistent by adding it to the Future Access list.
4. Do I need to hang on to the StorageFile/Folder, or recreating it later from .Path will work (assuming the answer to 2. is YES)?
   You need to add it to the Future Access List or Most Recently Used lists, otherwise the ONLY access you have is through that one object instance, When you release that instance the access would go away.

Regarding adding video files from arbitrary locations - the system deliberately doesn't allow arbitrary access, however it is still possible for an app to handle the common case of files placed in alternate locations and users haven't updated the library to include them. The indexer and storage sense services both contain code to periodically scan the drive for details (Sizes of files etc..) and they are leveraged to locate photo and video files. An app can use the StorageLibrary APIs to determine if any such locations were found that aren't in the library already, and if so, prompt the user to add them. (This keeps the user in charge and allows for a common case scenario) Nothing will auto add all locations containing files as there's no way to determine if that's the right thing to do. [I use a number of 3D model building and rendering tools and have literally thousands of texture images I wouldn't want to show up in my photos library, for instance]

'FindFirstFileExFromApp - this should (and in fact exists) - it should definitely not be flagged.'
Totally agree all of the *FromApp APIs are designed and intended for use in app container apps. So if the tools are flagging any of them, that's a bug we need to address.

@smaillet-ms Thanks for responding here. Is work being done to improve the speed of the Windows.Storage APIs? We've been waiting on an answer for a very long time. I'd be willing to sign an NDA to use the improved APIs in my app scenario.

I currently use the FromApp implementation of FindFirstFile, but it is impossible to get item thumbnails using a FromApp API.

This level of secrecy about the work being done to improve the Windows Runtime contrasts with what has previously been shared by Microsoft engineers in the thread.

Relevant ignored feedback link: https://aka.ms/AA6dgqz

Just to add here, specific details might be protected behind a NDA but if there is work being done on this topic internally it would reassure a lot of UWP developers if MS will publicly state this (along with a general outlook when we can expect to see/hear more).

There has been a ton of work done to improve perf of storage APIs across several releases of the OS. The challenge at this point for developers is mostly in knowing which APIs to use and when.

There are many ways of doing things and many of them are totally wrong for a given application. Unfortunately, there isn't any sort of "one right true answer" as it really depends on the application and what it will do with the information it gets from the file system. The *FromApp APIs will currently give the greatest performance relative to their standard Win32 counterparts. Though as pointed out here, it doesn't have all the extra shell data like thumbnails etc.. (Which are actually expensive to acquire if they aren't available in a cache). So if your app needs to find files of interest based on name/path or extension it can do so using the *FromApp APIs, then create a StorageFile based on the name to retrieve more details. Though there's duplicated overhead in that, since the access checks are performed twice in this case. If you are trying to find only one file, that's often not an issue but redundancy on a larger scale can cost. If you use the Storage WinRT Apis with the Windows.Storage.Search.IndexerOption.OnlyUseIndexerAndOptimizeForIndexedProperties you can get REALLY fast enumeration, that falls back to a fully realized storage item underneath on demand, which has a perf hit but is lower than creating an item from a path as that needs to include additional access checks. The downside is that it doesn't work if the user has disabled the indexer for the location in question.

If you are populating a UI, like a photos/media type app then the BulkAccess classes are probably your best bet as they are geared towards usage scenarios in UI with virtualization etc.. so they can provide data to the UI quickly and feed more data on an as needed basis as the user scrolls through content.

Like I said, lot's of trade offs. Obviously, we've got work to do in figuring out how to document the process of evaluating what the best fit will be for a given app. We also continue to evaluate places where we can achieve the greatest general improvements without breaking existing apps.

WinRT is a big surface and not owned by a single team at MS, each team evaluates their priorities for each release and may or may not publish their plans ahead of time. Personally, I'd love to see things get to where we have Zero Overhead with respect to Win32 APIs in or out of the app container. Obviously we aren't at that point now and I can't make any promises we'll get there, business priorities and plans on a project as big as Windows with as many end users as we have is a complex process involving tough/hard choices at all levels. (Not to mention various technical challenges that can get in the way...)

@smaillet-ms

@jtorjo regarding the drag and drop scenario:

1. does it work with both files and folders?
   It should and does for many apps and tests, if you find otherwise, then please file a bug on that.
2. do I get access to the .Path ?
   Maybe - If there is a real file system path to back the storage item, then yes. (things like the shell libraries don't actually have a real file system path)
3. Is it persistent (I assume not)?
   No, the app can make it persistent by adding it to the Future Access list.
4. Do I need to hang on to the StorageFile/Folder, or recreating it later from .Path will work (assuming the answer to 2. is YES)?
   You need to add it to the Future Access List or Most Recently Used lists, otherwise the ONLY access you have is through that one object instance, When you release that instance the access would go away.

Sounds good. Will implement this in my app at some point.

[...] The indexer and storage sense services both contain code to periodically scan the drive for details (Sizes of files etc..) and they are leveraged to locate photo and video files. An app can use the StorageLibrary APIs to determine if any such locations were found that aren't in the library already, and if so, prompt the user to add them.

I ain't got anything against this, but this looks an added complication to my app. Have you heard of anyone actually using this?

Right now, I need to figure out a thousand ways to deal with all sorts of issues when it comes to StorageFolder/File , and this is just an extra one. It simply puts the burden, once again, on me, the developer.

'FindFirstFileExFromApp - this should (and in fact exists) - it should definitely not be flagged.'
Totally agree all of the *FromApp APIs are designed and intended for use in app container apps. So if the tools are flagging any of them, that's a bug we need to address.

Agreed.

@smaillet-ms

There has been a ton of work done to improve perf of storage APIs across several releases of the OS. The challenge at this point for developers is mostly in knowing which APIs to use and when.

I'm sorry to say, but this doesn't sound very reassuring.

In the WPF days, I would simply use System.IO, do any file/folder queries I want, in an insanely easy way, and not worry about speed at all. I would just know - it works. 4000 files, 10000 files - it simply works.

There are many ways of doing things and many of them are totally wrong for a given application.

That pretty much says - the APIs shouldn't even exist in the first place.

Unfortunately, there isn't any sort of "one right true answer" as it really depends on the application and what it will do with the information it gets from the file system. The *FromApp APIs will currently give the greatest performance relative to their standard Win32 counterparts.

That is true for sure. While I have already wrapped the *FromApp API in a nice-to-use class (for my own scenario), this is what MS should do as well - present this in a nice and easy to use API - a simple C# wrapper that will very likely cover 98% of the use cases.

I would do it myself, but I don't have the time. I can happily share my simple class and someone can take it from there.

Though as pointed out here, it doesn't have all the extra shell data like thumbnails etc.. (Which are actually expensive to acquire if they aren't available in a cache).

Agreed - I'm already doing this separately (asking for thumbnails on a different thread) - A query API for this would do wonders. Basically, I would ask for thumbnails in bulk. And I could get an IAsyncEnumerable.

Once again, MS can create a simple API for this, and for now, just do a .GetThumbnailAsync on each file. Then give us the API, and then you can later improve on it(s speed).

So if your app needs to find files of interest based on name/path or extension it can do so using the *FromApp APIs, then create a StorageFile based on the name to retrieve more details. Though there's duplicated overhead in that, since the access checks are performed twice in this case.

On the plus side, a lot of info is already present in the *FromApp API - creation time, last access time, last write time, file size.

If you are trying to find only one file, that's often not an issue but redundancy on a larger scale can cost. If you use the Storage WinRT Apis with the Windows.Storage.Search.IndexerOption.OnlyUseIndexerAndOptimizeForIndexedProperties you can get REALLY fast enumeration, that falls back to a fully realized storage item underneath on demand, which has a perf hit but is lower than creating an item from a path as that needs to include additional access checks. The downside is that it doesn't work if the user has disabled the indexer for the location in question.

This has several drawbacks - first of all, in my tests, it was faster than non-indexed files, but not that fast. I think it was 3x-5x faster, but that's still about 10x-50x slower that *FromApp. That is INSANELY SLOW. On top of that, I can't really tell my users to check the "All files to have context indexed in addition to file properties", it's simply his option. And probably a lot of users simply leave that unchecked.

In fact, Windows should automatically figure out the used files and index those folders - it's very likely gonna matter a lot for media files (video/photo/music) and for documents.

If you are populating a UI, like a photos/media type app then the BulkAccess classes are probably your best bet as they are geared towards usage scenarios in UI with virtualization etc.. so they can provide data to the UI quickly and feed more data on an as needed basis as the user scrolls through content.

Honestly, I wasn't even aware this existed - I'm looking at it as we speak.
However, if I understand this correctly, this is just a bit of syntactic sugar, as it will suffer from the same performance issues as IStorageQuery.

And those performance issues are huuuge. They are so huge, that basically, for roughly 1000 files, the first file is retrieved after 9-10 seconds. In other words, once you start enumerating the result, it will block for 9-10 seconds before doing anything. I'm assuming the same would have using FileInformationFactory, only that the UI will be responsive during that time.

WinRT is a big surface and not owned by a single team at MS, each team evaluates their priorities for each release and may or may not publish their plans ahead of time. Personally, I'd love to see things get to where we have Zero Overhead with respect to Win32 APIs in or out of the app container.

Well, a lot of us too ;) I do understand that WinRT is a big big part of Windows, and that different parts are scattered across different teams.

It's not very comforting for us to not publicly see the vision MS has for WinRT. To not have a timeline as to what/when/if happens.

To me, speed of dealing with Files/Folders is simply paramount. How can someone trust WinRT/UWP, when doing something as simple as enumerating the files in a folder can take so long? And finding out how to improve that comes down to "will i be lucky enough for my google search to run into the *FromApp API"?

I don't want to come across as ungrateful -- I really appreciate your taking the time and outlining all of this to us. Thank you!

@BenJKuhn Someone (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297) filed another ticket about the The "New certificate" issue here --> https://aka.ms/AA8bw9v

On the really bad side -- i tried to access this, and it tells me I don't have access to view this ticket. This really doesn't help with the credibility of "Feedback Hub".

Why do you allow for sideloading outside MS store, but make it close to impossible to actually do it?

Actually, that's not true. You can't upload your application to MS Store and use appinstaller as alternative way to install app. My app was banned for that during certification.
MS Store Policies:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101-distinct-function--value-accurate-representation

10.1.5
Your app may promote or distribute software only through the Microsoft Store.

After I have had to remove appinstaller file from my server, users can use MS Store again to install my app. I understand - rules are rules, even I can't get reason for them. But it's really disappointing, when I know a lot of applications, which are distributed through store and appinstaller (Unigram) or chocolatey (new MS Terminal).

Why do you allow for sideloading outside MS store, but make it close to impossible to actually do it?

Actually, that's not true. You can't upload your application to MS Store and use appinstaller as alternative way to install app. My app was banned for that during certification.
MS Store Policies:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101-distinct-function--value-accurate-representation

I'm not sure we're talking about the same thing here - in this day and age, I simply can't come up with a single reason to need or want the MS Store. My beef with it was it's insanely hard to develop an app and then deploy it outside the MS store.