If the author is reading this, here's some advice for you: I encourage you to start learning pure Win32 and enjoy the benefits of extreme compatibility (you can create a single .exe that works on anything starting from Windows 95, depending on the exact set of features you want) as well as highly efficient native code. It's what made Microsoft and the Windows platform great in the first place, and it will continue to be the "real Windows API" that has lasted through all the other churning trends.
I started with Win16 (and before that was DOS, so not much to speak of in the way of UI), moved to Win32, and basically stayed there while ignoring all the other newer and more short-lived stuff that came and went.
Thanks for addressing me with this recommendation. As you may have guessed, I'm the developer of Files UWP. I really have a great deal of respect for those who take the time to learn the guts of the Windows API which simultaneously teaches one how Windows itself works. I won't deny it. There is certainly something pretty great to learning a subsystem written under Gates himself.
Further, there have been many instances where I've grown quite tired of the limitations surrounding UWP. Just this evening, I discovered we simply can't check the maximized/minimized state of the app windows. While this limitation probably dates back to Win 8, this functionality is taken for granted by Win32 devs. Don't get me started on how slow some of the Windows.Storage APIs are compared to that of Win32.
Because of these reasons, I'll kindly admit to you guys that a file explorer application probably SHOULD be written using completely-native Windows APIs. I can't deny the UX improvements brought by Fluent Design to controls have been great, but I'm NOT blinded by my own ignorance. UWP (in it's current state) is not ready for adoption. In fact, I started work on Files last year with no real knowledge of what an API was. (My knowledge of programming concepts has come a long way since then) Come February 2019, I posted the project to Reddit with the intention of abandoning it, but I was blown away by the overwhelmingly-positive community feedback to the point where I continued work on the project. I almost feel obligated to, at the very least, maintain it.
It's much better to invest their time on learning programming rather how to possition a button and where to listen for click messages.
Ironically, MS's own "get started with UWP" tutorial involves nearly no code, but lots of messing around with a GUI (without really understanding what's happening and why):
Win32 is one of the few UI paradigms that it makes sense to invest in. It will never die, and you will get exposed to a whole slate of historical patterns that all the new stuff is based on or built in reaction to.
It will never die but you might not find anyone interested in it. We are shifting to a Marketplace app era and I think that you cannot create a marketplace app with Win32 (I might be wrong here).
Even if you could create a Marketplace app with Win32 api it would be a nightmare to create a responsive UI to support multiple monitor sizes.
I have worked really hard to create responsive UI with Win32 and the result was barely acceptable but with UPF or HTML it's such an easy task, it all come out natural
This is why I wrote the Tron project (https://old.reddit.com/r/TronScript) in batch. It's a huge pain, but batch ALWAYS works and doesn't change, unlike PowerShell v1/2/3/etc. More work, but works on everything from XP to 10 v.whatever.
In batch! The thing that always asks you if you want to terminate the batch job :-) are you familiar with/did you consider WScript? You can write JScript which is a lot nicer and still works on older machines...
I second this, and also recommend using Cygwin/gcc to build it with. Then you can bypass most Windows horseshit altogether, and maybe just run it on a real operating system under Wine.
Wow, the screenshots really look incredibly polished, not just for a high school project. Actually, if you told me that this was some preview uploaded by Microsoft, I may have been fooled.
Yes, I do share the criticism about UWP. The author seems to be very aware of the limitations, though. Figuring that stuff out for yourself is a great thing. Choose anything as your underlying technology, and only move on to the next thing as you realize that your current stack really is the limiting factor.
No, I probably don’t want a UWP Explorer. And still, figuring out what Explorer would look like if it was invented today is an exciting exercise in getting to know the platform (and might get you noticed by Microsoft eventually, who knows).
Yes, someone pointed out that code quality is mediocre. That’s a good thing. The author is focusing on the GUI part right now, and they are getting things done. Write bad code today and you will write good code tomorrow, it takes practice. Write no code today and you may never write any relevant code.
As someone who loved tinkering with all sorts of technology since early childhood, and thinking and theorizing about UI and UX, I never really accomplished much in this field. Before I could, I would always question the value of the project, the quality of my output, and the superiority of the underlying tech stack. Classic example of choice paralysis and “perfect being the greatest enemy of good”. Today, I am doing something entirely different for money, and more often than I like to admit, that still makes me sad, given my everlasting enthusiasm for tech.
