This is an amazing design exercise, but the thing about Win10 that really pushes my buttons is the Control Panel/Settings conundrum. Each version it seems another feature gets added into the real settings app but still needing to open an old-themed dialog to change mouse settings of all things seems odd.
It's not like mouse settings are an obscure feature. I'm not sure why a higher emphasis on cohesiveness isn't noted.
What you might be missing is some complex technical reason why the mouse control panel cannot be easily migrated. For example, a lot of drivers integrate their own tabs into the mouse control panel for features.
The slow migration from control panel to settings is actually, in my opinion, one of the better ways Microsoft has done software development. We aren't waiting 5 years for them to migrate 20 years of settings and we aren't stuck with a limited version 1.0 product without sufficient features.
I don't get people's enthusiasm for the settings app, I find control panel the faster way of achieving almost everything. Settings is slow and sometimes you circuitously end up where control panel world have sent you directly, e.g. when you want to change network adapter settings.
In the touch-enabled world of devices Metro was envisioned for, yes, mouse settings should no longer be relevant. Meanwhile, in the real world, Windows phone died, just one colleague I know uses Windows on a tablet, yet Microsoft is still attempting to replace the control panel with an optimized-for-touch-only app.
This is Apple- or Gnome-level pretentiousness: "that use case doesn't fit our brand, let's act like it's not there".
I don’t see them now that I’ve moved to New Orleans but when I was in Seattle I saw a lot of people using Surfaces in cafes and regularly poking at their screens with a finger. I don’t think this was necessarily a dogfood thing either, I was rarely in Redmond.
The bit-by-bit migration of control panel to settings is iterative if not anything else. Else you'd need to wait years for them to migrate all things.
Still, I don't believe everything is eligible for migration. Take the network adapter TCP/IP settings, I don't a migration happening for that. I don't think UWP is suitable for such information density. And in my opinion the UWP panel is less discoverable.
I agree. I would have been fine if the new control panel superseded the old version but since Win8 we have this schizophrenic situation where we have two control panels that both have features the other version doesn't have. Win10 is a little better but you still need the old panel for plenty
of things.
I think the settings app is just a poor imitation of the Mac preferences panel. Preferences panel gives the appearance of the major settings, all in one place. You can only have one module, like network, or printers, selected at one time. Settings app tries to do something similar, but for some reason this is more frustrating on Windows than MacOS.
About the only thing I use the settings app for are Windows updates. Everything else, I start from the run menu if I know the command or launch from the control panel. Because invariably the legacy control panel applet exposes features I need, and the settings app is rudimentary.
Microsoft should be embarrassed at this mess. I suppose they'll eventually almost complete the settings app before moving onto something they consider better. I don't know what's necessary to fix it, and likely it's far more involved that I can imagine, but Microsoft has resources at their disposal that would be the envy of all but the largest companies.
Rather than rolling this out piecemeal, over the course of however many years, they could have just gotten it right all at once. What we have now is just sloppy, a beta-quality looking mishmash. It reminds me of the old days of Linux on the desktop with various apps running different gui toolkits.
I'm sure this situation exists for justifiable reasons, but I don't have to like the end result even when fixing it is difficult and expensive.
It's funny to see the gradient in the title bar, contrasting with the bland borderless-sea-of-whiteness of the rest of the UI.
> FilesUwp.Package_0.5.0.0_x64.zip 54.4 MB
Nearly 55MB, compressed, for something that attempts to mimic some of the functionality of the regular explorer.exe, is quite frankly ridiculous. I don't have a system to check right now, but I believe even latest Windows 10 has an explorer.exe < 5MB (uncompressed), and it certainly seems to have a lot more functionality than this one. A peek at the code gives a hint as to why... the first file I look at is this
It seems that everything "UWP" I come across follows the same trend: a lot of code, a lot of resource consumption, some flashy "modern" UI, yet very little in the way of actual functionality.
The author is a student, so I think we can give them a pass. Besides, the code gets compiled! It's hardly as if that if statement is contributing to bulking out the executable to 55MB.
UWP apps tend to be pretty big, especially when compared to Win32/whatever Explorer is written in. That has very little to do with the author and much to do with the framework.
It's a little dispiriting to see this as the top HN comment on a high schooler's project .
You're just talking about 'explorer.exe' being 5 mb? You're discounting the numerous DLLs which the explorer uses, or even other shared resources which are used system-wide.
And 55 MB for a native app is paltry. Even the 'Google' app on Android is 285 MB, the Gallery app of OnePlus is 70 MB.
Your standards are unfortunately warped by modern trends. Almost all popular apps are hugely bloated because the developers just don't care, the focus is on UI re-design and feature churn and the illusion of ease of development. Some counter examples (compressed installer size for convenience):
7-zip for 64-bit windows: 1.4 MiB
Winamp 5.8: 7.8 MiB
mpc-hc: 13.5 MiB (open source media player with many built-in codecs)
irfan-view: 3.4 MiB (image viewer/utility)
uTorrent: 2.3 MiB
Sysinternals Process Monitor: 1 MiB
For a truly native application, which doesn't pack a huge run-time or dependency tree, that's the expected size range. Now, it's true, it seems no one does that anymore ...
You're discounting the numerous DLLs which the explorer uses, or even other shared resources which are used system-wide.
I see this argument brought up in demoscene discussions ("your .exe is 4KB but it uses several GB of system libraries and device drivers!") and the rebuttal is the same: I'm assuming this UWP one itself makes use of other system DLLs too, like any other Windows application will, so the comparison is between 5MB + shared and 55MB + shared.
Even the 'Google' app on Android is 285 MB
Android is a whole other story altogether. The bloat is endemic there, and emulating that is not at all something to be proud of. Windows applications can be far more efficient, as Windows' own explorer.exe shows (and even that is probably not anywhere close to "perfection", but the difference is already enormous.)
For a native app of Windows Explorer kind that doesn't pack massive resources, 5-10 Megs is a reasonable size.
Heck, you are forgetting than something like 3D Studio MAX originially fit on a set of floppies and I can assure you it could do FAR more than "the Gallery app" whatever the heck that poor thing is.
The bundle also seems to include dependencies for multiple architectures and PDBs for debugging. Files.dll which would contain most of the application is ~18MB. And since it does not seem to be a managed dll, it has probably been AOT compiled and likely contains the original bytecode in addition to the native machine code.
The code has many 'smells' indeed but was written by a high schooler. If you take that into account it's really quite commendable how polished and thought-out the app is.
Sadly, I have seen 'senior' engineers write much worse code than this...
Thank you for your useless driveby code review for a student project on a third party site that could have been an educational pull request to the author.
I've checked WindowsApps folder once, and there were a ton of apps with an old version (x86, x64, noarch) and a new version (once again all the architectures). In total 6 (!) versions of the same application, each taking up to 60MB. Code quality has dropped significantly as well, Settings, Taskbar, Mail crash and lag.
It's because Microsoft heavily promotes the development of UWP apps these days, there are less and less programmers able and willing to spend their time writing Win32 apps, and as you can see even on HN, there are less and less people able to appreciate their effort, even among programmers.
I’m curious why it matters to you. 55MB is a trivially inexpensive amount of storage and bandwidth in 2019. It simply doesn’t make a practical difference to the vast majority of people who will use this whether it’s 55MB or 5MB.
I'd suspect the executable size has more to do with bundled libraries rather than the author having written multiple megabytes worth of if statements...
This isn't production code published by Microsoft, it's an "enthusiast's take" written by a student learning to code. Most of my college colleagues couldn't make it through FizzBuzz.
Hopefully a bright new programmer doesn't get discouraged by getting smacked down in the top comment on hacker news.
Storage is actually pretty cheap. Only RAM usage matters now. So 55mb is not that much of a big deal now. But this is an attempt by the author. No one is forcing you to use this. I dont know whats the point of being so negative to someone's efforts.
I dont know whats the point of being so negative to someone's efforts.
The author is given a very clear indication that this is not a good direction, and hopefully changes direction quickly. He actually replied to another comment I made where I gave some advice (https://news.ycombinator.com/item?id=20130696), and said he continued working on it because of "overwhelmingly-positive community feedback", despite already being aware of the limitations of UWP. Maybe if he encountered a bunch of "UWP sucks, go Win32!" comments back then, he might've come up with something far more interesting and useful.
In other words, you can blame this idiotic "positivity culture" every time you see something half-assed, bloated, or just plain broken, or when huge mistakes are made because everyone was all smiles and happiness, and no one said NO until it was too late...
This is unnecessarily negative. I’d imagine all UWP apps are that big, and who knows how much explorer.exe functionality is in DLLs you’re not counting. The author can’t help it if modern frameworks are bloated crap.
I would like to take this opportunity to recommend that everyone who is into C#/.NET Core and high-performance Windows UX development take a look at the following: https://github.com/prasannavl/WinApi
I was able to get a workable demo app going in just a few minutes using their Win32 approach. Seems very promising to me for purposes of building native-levels of performance into windows apps using managed C#. The performance statistics published on the repository seem fantastical, but I can believe it now that I've played around with a few of their demos.
> a lot of code, a lot of resource consumption, some flashy "modern" UI, yet very little in the way of actual functionality.
Ah, The Perils of JavaSchools right there.
I agree with your comment. That code is beyond horrible, and it keeps on and on. Take a look at the other trending project on HN, Open Source Electronics Lab for $30. It has some nasty surprises on it's own, code-wise.
Huh? The function is a no-op. The compiler should optimize it into nothingness, but optimization is not the point here. Or was that an attempt at humor?
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.
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.
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.
If you open the properties of a folder, you can see how long it can take to calculate the size of a folder.
This is a feature I've never really needed - what is your scenario for needing this at a glance? When I'm chasing large files that need deleting due to free space pressure I typically use something like the following https://windirstat.net/
you can see how long it can take to calculate the size of a folder
On older Windows (95, 98, XP) I've never had it take an unacceptably long time, and that was with a regular HDD. With an SSD and the large file caches which are possible with today's machines with lots of RAM, it should be even faster.
Besides, it's not as if the operation needs to be synchronous; the sizes can be calculated and displayed when they're ready. Having an option to show them would be useful, and those who don't need it/don't like the extra disk activity could leave it off.
Note that if you parse the MFT itself you can calculate this info for the entire drive in the time explorer can calculate it for a single folder. I know there is some overhead with the official api of course and it needs to support other filesystems but we really needed a way to iterate directories faster just to gather this kind of info. There are several disk space utilization / treesize apps and file search apps that take advantage of the speed you get by bypassing the API.
Since Windows 98, we used Idoswin (https://www.idoswin.de/) which always calculated directory sizes in the background. It showed the sizes of directories it already calculated and made the field empty for every folder where the size was not ready yet. Usually the small directories are ready first and only the big (>1gb and many files) take a few seconds. This is done in the background and therefore doesn't disrupt your workflow at all.
Another method would be to make it midnight-commander style: add a button which will calculate & display the sizes of the directories.
So the time to calculate it is not really an issue.
Use-cases are exactly cleaning up space and roughly calculating backup sizes/sizes of folders I want to copy at a single glance. You could also ask: why do we need to display the size of files in the explorer. The reasons are roughly the same.
I use xyplorer, which has a toggle feature for always displaying the folder sizes, and a keyboard shortcut (shift-F5) to display them for the current folder until changed.
This combination seems to work just fine, I don't usually need folder sizes, so I keep the toggle off, and just hit shift-F5 if I really need to see them.
The Mac has been able to do this since what, System 7.5 in 1995? Yeah it can take a while to calculate but on a modern SSD it's not a problem. If you don't like the performance hit it's an option that defaults to off.
That's one of my favorite Directory Opus features. Especially since you can make it on demand, in case you don't want to always have directory sizes calculated while browsing.
I thought for a moment Microsoft had uploaded some new Windows Explorer source code and got excited... I guess that tells you how different an era we live in. It wouldn’t be a huge leap.
The screenshots look nice, though. I can’t say I am really a huge fan of UWP UIs on desktop... but this looks alright.
As awesome as the Win2k source leak probably is from an educational standpoint, I don’t want to taint myself with illegal source code. I hope they eventually decide to open source more things, even if it was just older things.
The ability to explore isn't just Explorer's namesake but what makes is a good tool. Orienting yourself in Explorer is largely done through the tree on the side... which is missing in this rewrite?
The low-contrast sidebar and flat colors sure look like they belong in Windows 10. But what about the features? The README doesn't mention any features. If anything, a flat-looking screenshot these days makes me instantly suspect that the product might be lacking in features.
Explorer/Finder/File Manager is one type of app I wish someone would make a nice Electron version of. It's more or less the last piece of platform-specific software I use.
I currently switch back and forth from MacOS and Windows and I dislike what both have to offer. I used to be ok with Explorer but somewhere around Windows 8 they "improved" it in several ways that made it alien to me. I hate Finder, the fact that there is no simple way to copy the current path is just completely beyond me, and the fact that enter means rename will never make sense to me either.
I know that there are a number of cross-platform "commander" apps that I could use but though I was addicted to the original (Norton Commander), I don't much care for that paradigm anymore. Does anyone know of other good alternatives?
In a file manager, integration with the system is important, which means that a dozen or two integration features should be implemented for each platform, aside from the internal differences in working with files. And that Electron is likely out.
In addition, a file manager is pretty much a productivity app, so it has to be muscle-memory-level fast.
But alas, there doesn't seem to be anything cross-platform of this sort there.
Double Commander enjoys popularity and is cross-platform, but dunno how it feels on Windows. On Mac, it's decent though hasn't got much in the aforementioned integration department.
opt cmd c will copy the current path or selected file/dir to the clipboard
iirc
enter is rename because it came from a time when it was viewed as own self-contained app that did one thing - organized files on your profile and floppy.
Readit News
The slow migration from control panel to settings is actually, in my opinion, one of the better ways Microsoft has done software development. We aren't waiting 5 years for them to migrate 20 years of settings and we aren't stuck with a limited version 1.0 product without sufficient features.
This is Apple- or Gnome-level pretentiousness: "that use case doesn't fit our brand, let's act like it's not there".
Still, I don't believe everything is eligible for migration. Take the network adapter TCP/IP settings, I don't a migration happening for that. I don't think UWP is suitable for such information density. And in my opinion the UWP panel is less discoverable.
This may be true but it doesn't speak well for UWP.
Microsoft have never been able to show the restraint that Apple have when it comes to this stuff.
Microsoft most assuredly has a plan.
About the only thing I use the settings app for are Windows updates. Everything else, I start from the run menu if I know the command or launch from the control panel. Because invariably the legacy control panel applet exposes features I need, and the settings app is rudimentary.
Microsoft should be embarrassed at this mess. I suppose they'll eventually almost complete the settings app before moving onto something they consider better. I don't know what's necessary to fix it, and likely it's far more involved that I can imagine, but Microsoft has resources at their disposal that would be the envy of all but the largest companies.
Rather than rolling this out piecemeal, over the course of however many years, they could have just gotten it right all at once. What we have now is just sloppy, a beta-quality looking mishmash. It reminds me of the old days of Linux on the desktop with various apps running different gui toolkits.
I'm sure this situation exists for justifiable reasons, but I don't have to like the end result even when fixing it is difficult and expensive.
> FilesUwp.Package_0.5.0.0_x64.zip 54.4 MB
Nearly 55MB, compressed, for something that attempts to mimic some of the functionality of the regular explorer.exe, is quite frankly ridiculous. I don't have a system to check right now, but I believe even latest Windows 10 has an explorer.exe < 5MB (uncompressed), and it certainly seems to have a lot more functionality than this one. A peek at the code gives a hint as to why... the first file I look at is this
https://github.com/duke7553/files-uwp/blob/master/Files%20UW...
and the first thing I see is not exactly confidence-inspiring:
...WTF.It seems that everything "UWP" I come across follows the same trend: a lot of code, a lot of resource consumption, some flashy "modern" UI, yet very little in the way of actual functionality.
UWP apps tend to be pretty big, especially when compared to Win32/whatever Explorer is written in. That has very little to do with the author and much to do with the framework.
It's a little dispiriting to see this as the top HN comment on a high schooler's project .
And 55 MB for a native app is paltry. Even the 'Google' app on Android is 285 MB, the Gallery app of OnePlus is 70 MB.
7-zip for 64-bit windows: 1.4 MiB
Winamp 5.8: 7.8 MiB
mpc-hc: 13.5 MiB (open source media player with many built-in codecs)
irfan-view: 3.4 MiB (image viewer/utility)
uTorrent: 2.3 MiB
Sysinternals Process Monitor: 1 MiB
For a truly native application, which doesn't pack a huge run-time or dependency tree, that's the expected size range. Now, it's true, it seems no one does that anymore ...
I see this argument brought up in demoscene discussions ("your .exe is 4KB but it uses several GB of system libraries and device drivers!") and the rebuttal is the same: I'm assuming this UWP one itself makes use of other system DLLs too, like any other Windows application will, so the comparison is between 5MB + shared and 55MB + shared.
Even the 'Google' app on Android is 285 MB
Android is a whole other story altogether. The bloat is endemic there, and emulating that is not at all something to be proud of. Windows applications can be far more efficient, as Windows' own explorer.exe shows (and even that is probably not anywhere close to "perfection", but the difference is already enormous.)
For a native app of Windows Explorer kind that doesn't pack massive resources, 5-10 Megs is a reasonable size.
Heck, you are forgetting than something like 3D Studio MAX originially fit on a set of floppies and I can assure you it could do FAR more than "the Gallery app" whatever the heck that poor thing is.
And these applications are not using "numerous DLLs" - just two files: app.exe and sciter.dll (and that one can be linked statically into executable).
So "yes", 50 Mb for an Explorer thing is too much.
Sadly, I have seen 'senior' engineers write much worse code than this...
This isn't production code published by Microsoft, it's an "enthusiast's take" written by a student learning to code. Most of my college colleagues couldn't make it through FizzBuzz.
Hopefully a bright new programmer doesn't get discouraged by getting smacked down in the top comment on hacker news.
The author is given a very clear indication that this is not a good direction, and hopefully changes direction quickly. He actually replied to another comment I made where I gave some advice (https://news.ycombinator.com/item?id=20130696), and said he continued working on it because of "overwhelmingly-positive community feedback", despite already being aware of the limitations of UWP. Maybe if he encountered a bunch of "UWP sucks, go Win32!" comments back then, he might've come up with something far more interesting and useful.
In other words, you can blame this idiotic "positivity culture" every time you see something half-assed, bloated, or just plain broken, or when huge mistakes are made because everyone was all smiles and happiness, and no one said NO until it was too late...
I was able to get a workable demo app going in just a few minutes using their Win32 approach. Seems very promising to me for purposes of building native-levels of performance into windows apps using managed C#. The performance statistics published on the repository seem fantastical, but I can believe it now that I've played around with a few of their demos.
Ah, The Perils of JavaSchools right there.
I agree with your comment. That code is beyond horrible, and it keeps on and on. Take a look at the other trending project on HN, Open Source Electronics Lab for $30. It has some nasty surprises on it's own, code-wise.
Having said that, the code is still quite bad but maybe it was auto generated by a ui builder or refactoring tool.
Dead Comment
https://news.ycombinator.com/item?id=19873198
https://news.ycombinator.com/item?id=19883351
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.
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.
This is especially true today that the ui standars envolve in such fast pace.
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.
Deleted Comment
This is a feature I've never really needed - what is your scenario for needing this at a glance? When I'm chasing large files that need deleting due to free space pressure I typically use something like the following https://windirstat.net/
On older Windows (95, 98, XP) I've never had it take an unacceptably long time, and that was with a regular HDD. With an SSD and the large file caches which are possible with today's machines with lots of RAM, it should be even faster.
Besides, it's not as if the operation needs to be synchronous; the sizes can be calculated and displayed when they're ready. Having an option to show them would be useful, and those who don't need it/don't like the extra disk activity could leave it off.
Another method would be to make it midnight-commander style: add a button which will calculate & display the sizes of the directories.
So the time to calculate it is not really an issue. Use-cases are exactly cleaning up space and roughly calculating backup sizes/sizes of folders I want to copy at a single glance. You could also ask: why do we need to display the size of files in the explorer. The reasons are roughly the same.
This combination seems to work just fine, I don't usually need folder sizes, so I keep the toggle off, and just hit shift-F5 if I really need to see them.
The screenshots look nice, though. I can’t say I am really a huge fan of UWP UIs on desktop... but this looks alright.
https://github.com/microsoft/winfile
...and it compiles to a nice small and fast ~300KB executable, in contrast to their open-sourced and significantly less efficient UWP calculator:
https://github.com/microsoft/calculator
I believe the old leaked Win2k source has much of the explorer.exe source, if you're really curious.
What an affront to computing modern UI design is.
I currently switch back and forth from MacOS and Windows and I dislike what both have to offer. I used to be ok with Explorer but somewhere around Windows 8 they "improved" it in several ways that made it alien to me. I hate Finder, the fact that there is no simple way to copy the current path is just completely beyond me, and the fact that enter means rename will never make sense to me either.
I know that there are a number of cross-platform "commander" apps that I could use but though I was addicted to the original (Norton Commander), I don't much care for that paradigm anymore. Does anyone know of other good alternatives?
In addition, a file manager is pretty much a productivity app, so it has to be muscle-memory-level fast.
For desktop software recommendations in established genres, AlternativeTo is a good source: https://alternativeto.net/software/windows-explorer/
But alas, there doesn't seem to be anything cross-platform of this sort there.
Double Commander enjoys popularity and is cross-platform, but dunno how it feels on Windows. On Mac, it's decent though hasn't got much in the aforementioned integration department.
- ranger / sunflower on *nix - total commander on win
Sunflower is cross-platform and IMO great, if only it continues to be developed:
http://sunflower-fm.org/
iirc
enter is rename because it came from a time when it was viewed as own self-contained app that did one thing - organized files on your profile and floppy.
Deleted Comment