Discussion: Opportunities to add value to WinRT #1856
Comments
msft-github-bot
added
the
needs-triage
|
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. |
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.
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). |
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. |
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? |
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. |
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). |
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). |
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. |
Thanks :) |
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: |
|
Hi @jesbis, Thanks for looking at my issues!
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.
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.
Cool!
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.
Can I suggest the WinRT topics I mentioned here? Thanks again! |
@jesbis |
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 Repetition of Nokia's catastrophic mistakeWinRT/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 ChangesMicrosoft 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 codeMicrosoft 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 For another example of "out of touch with reality", look at the design of |
|
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. |
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:
(p.s. The fact that, for a file, to get its properties, I need to call an async function, still makes me twitch)
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. [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.
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.
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
Yes, totally agree. Back in 2016-2017, I wouldn't even touch UWP.
That is beyond sad, to say the least ... Why of why would we want JS interoperability?
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.
Yup, we do...
Agreed 100%.
Yes, there are clearly awesome people at MS that are listening. Lets hope we can turn this around... |
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. 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: 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. |
Yes it is!
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):
Agreed. Indeed, playing system sounds, which in WPF is like 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
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.
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
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....
100% agreed! |
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. |
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!
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.
You can say that again :)
Any ETA? .Net 5?
So far, I have a workaround - far from ideal, but for now I'm ok - #1465 (comment)
Will do, I hope to get to it over the weekend.
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:
Got it, thanks - over the weekend.
Right, will do - the thing about dragging files into apps. I haven't actually tried it yet:
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)
I don't remember what that issue was :)
Right :)
Hehe, that's a loong list ;)
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 :)
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.
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! |
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:
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 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! |
Here's the feedback hub issues I've createdBroadSystemAccess 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 createdMore detail - should allow more characters https://aka.ms/AA7zws5 Choose a category - make this easier https://aka.ms/AA804cd Things I'm not sure aboutDrag 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 hubFeedback 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 |
|
@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. |
|
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:
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.' |
|
@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...) |
Sounds good. Will implement this in my app at some point.
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.
Agreed. |
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.
That pretty much says - the APIs shouldn't even exist in the first place.
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.
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).
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.
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.
Honestly, I wasn't even aware this existed - I'm looking at it as we speak. 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.
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". |
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.
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). |
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. |
I am only downvoting because the app should not close. |
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
and others
Discussion: Opportunities to add value to WinRT
Why am I writing here? Because it's the only place I think (and hope!) someone will actually listen...
I've been developing Windows apps for as long as I know myself (22.5 years). But in the last few months, while porting an app from WPF to UWP I've constantly found myself, to put it mildly, just wanting to give it all up.
So lets start with the positive:
For the WinRT side, lets start with the positive:
But on the negative side, the following are beyond blockers - if there was a word stronger than blocker, these would be it:
The Querying for files API Is Beyond slow
https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
This has been known for years. It's simply beyond my capability to understand how this hasn't been fixed by now. How can you possibly develop non-trivial apps when we have this issue? I've spent days working around this issue, and none of my solutions properly fix it. They alleviate it a bit, but the issue still remains. And who's suffering because of this? Me, because my users think my app is slow...
The broadSystemAccess API
https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html (see my answer to that question)
I'm not gonna critique the whole "I need to request full HDD access" (which is stupid, anyway). I will critique this, which is beyond stupid:
The point 4. is simply beyond stupidity - it's the worst UI design flow anyone could come up with.
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.
Creating apps for sideloading outside MS store
https://docs.microsoft.com/answers/questions/4027/uwp-cant-install-signed-application-non-ms-storeco.html
This is beyond insane - it's like everyone at MS doesn't want people to create apps to distribute outside the MS store. And, to develop for MS store is like running on a bike with cuffs on your legs. Why do you allow for sideloading outside MS store, but make it close to impossible to actually do it?
The .appinstaller file, that I spent countless hours to finally find a solution and have it actually work, this should be part of the "Deploy" process - Visual Studio should auto generate it. And document it -- there's a small doc somewhere on github that I spent quite a while to find. This should be in the docs!
Also, creating .appinstaller files - is something I found out the hard way - you create the file, put it on the server, download it from there, and then execute it. Modifying it locally and running it will be ignored. This is not written anywhere, something I had to find the (really) hard way.
The "New certificate" issue
https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html
This is what made me snap. How can anyone in their right mind think that when I create a new certificate for the same company, and I deploy my UWP app with it, it will be seen by Windows as another app?
How can I explain that to my users? Oh, you just updated my app, and lost ALL YOUR SETTINGS. How can this happen?
Or even worse, the user will see two apps with the same name, same icon -> how can he know which is which?
Clearly there are countless other issues (like, compilation times are insanely slow!), but they simply pale in comparison to the above. The fact that us, developers, have simply no say in this is very very very sad. We'll slowly move where someone will listen... Which sadly, doesn't seem to be MS anymore...
And a bonus:
Interoperability: Zero
The restrictions of WinRT are so antiquated and stupid, they're beyond my capability to understand them. Not even when you were targeting mobile as well, did they make sense. Let alone now -- Please Microsoft, understand this: BEFORE I will make my app run on a thousand platforms (Hololens, Xbox, whatever), I want to develop a desktop app. STOP WITH THE LIMITATIONS.
I'm one of the very very few that actually tried to develop a UWP app - most people give up really really fast, but I didn't have that luxury, because I need win2d.
The text was updated successfully, but these errors were encountered: