Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be
github.com
github.com
I mean, it is ridiculous. I have disabled antialiasing so most GUI text uses crisp aliased fonts as i like them. Then i open the settings app and it ignores the setting while using some font rendering with blurry antialiasing without even subpixel antialiasing. If i open an Explorer window (with, e.g., Win+E), it uses the settings i've set and has antialiasing disabled but if go to the address bar (This PC) and type "Control Panel" and press enter to open it, it uses antialiasing and this time it is subpixel antialiasing! WTF!
And the cherry on top? There is a "View by:" (Category, Large Icons, Small Icons) list at the top right where the "View by:" text is not antialiased (as i have set it), but the selected option right next to it uses subpixel antialiasing!
Come on.
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.
Ctrl + alt + up sets it to default rotation so far as I remember.
Maybe there’s some sort of hybrid approach with keybindings for the power users and the blocky menu for more casual access.
Microsoft have never been able to show the restraint that Apple have when it comes to this stuff.
Microsoft most assuredly has a plan.
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.
https://docs.microsoft.com/en-us/windows/uwp/design/style/sp...
This is Apple- or Gnome-level pretentiousness: "that use case doesn't fit our brand, let's act like it's not there".
One of the more annoying pattern in it is hiding stuff that's unavailable. I have a cheap 2-in-1 Windows computer I use as my sidearm, and it tends to lose or gain the tablet mode screen autorotation setting every other Windows Update. Only after I realized what's going on, I stopped feeling gaslighted by the Settings app.
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:
if(tabInstance.AlwaysPresentCommands.isEnabled == true)
{
tabInstance.AlwaysPresentCommands.isEnabled = true;
}
else
{
tabInstance.AlwaysPresentCommands.isEnabled = false;
}
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.
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.
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.)
That said, the bloat is real.
And with that it is still only 4.27MB+6.81MB = 11.08MB on my system. So yeah, the bloat is real no matter how you look at it.
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 ...
So many people just don't understand the scale of these things.
I stopped using LviewPro probably 8, or 10 years ago, but always wished I knew of a replacement that was so efficient. I see that IrfanView also does quite a bit more. I think I have a new favorite!
Now, if you'll pardon me, I need to drop the author a kind note. :)
Windows could be so better with their old Windows 2000 style, without all those design jumps around.
And IMO WinAPI not being hardware accelerated (although i think some parts of it, like filling and blitting, are hardware accelerated) isn't really a big issue - if anything, requiring hardware acceleration from you UI might be a hint that you are making it a bit too flashy. But that might be me preferring plain and compact UIs like those made with Win32 as opposed to website/mobile-like stuff.
[1]: https://en.wikipedia.org/wiki/C%2B%2B/WinRT
[2]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
[3]: https://docs.microsoft.com/en-us/windows/apps/desktop/modern...
I mention this because Delphi and Lazarus are quite high level environments to work with with rich frameworks and libraries yet you can create very lightweight applications with them (the executables will be a bit fat compared to what you can do with pure C/C++ or even pure Free Pascal, especially with Lazarus, but resource consumption is still low).
You do not need to use C/C++ with pure Win32 API to create lightweight applications and even if you use those there are frameworks that allow for easier development (e.g. WTL, Win++ or libui to mention some).
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.
no, had to build a few apps where this was requested only for branding purposes.
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.
I’ve run into a related behavior on iOS where I really dig some color palette while viewing in inverse colors and want to take a screenshot to capture it. The screenshot is “helpfully” stored as not-inverted color thereby stymying my efforts.
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.
// silly hack to get the tab control into a good state.
// it gets confused when ...
// and this seems to fix it.
Having said that, the code is still quite bad but maybe it was auto generated by a ui builder or refactoring tool.
Sadly, I have seen 'senior' engineers write much worse code than this...
Optimizing for size may be less of a priority when a developer is focused on creating a positive user experience and adding useful features. Obsessive optimization of factors that users don't care about can lead to crappy applications — see quite a few open source GUI applications as an example.
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...
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 .
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.
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.
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.
Powershell even limiting to 2.0 which never changes would be way better.
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.
And since you're so young: don't get too attached to a tech if you consider it a dead end or not ready for primetime.
Personally, I'd go for a Qt app next, if you like desktop apps.
I’d recommend pursuing that route if you’re frustrated by UWP app limitations or performance.
Full disclosure: I work at Microsoft on the Windows team.
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.
I highly disagree, especially since things like the very useful http://www.winprog.org/tutorial/ exist.
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):
https://docs.microsoft.com/en-us/windows/uwp/get-started/cre...
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
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.
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/
Second, we don't have to do a naive update every single time a file is changed. We can amortize the cost by updating the parent folder sizes only when the file size is changed by a significant amount since last update (say, 10%). And we can do this process recursively is the parent directories. This was it only takes O(1) time to update folder metadata for each file operation and all the metadata are accurate within 10%.
Also I don't see how drives and hard linked files are any different than regular files in this context.
Filesystem (and low-level in general) stuff must consider worst cases. There is a lot of software out there doing weird things. For instance, npm created a very deep folder hierarchy for a long time (so deep it messed up some path length restrictions in fact).
One way or another the worst case is going to be hit. And then what? The entire computer grinds to a halt? How is the user supposed to discover why?
> We can amortize the cost by updating the parent folder sizes only when the file size is changed by a significant amount since last update (say, 10%).
So you have a log file inside a folder. Because it just keeps growing line by line then the folder's size is never updated. Now you have many Gb's of log file in that folder, and the folder says it is using "4Kbytes".
Moreover, this propagates upwards the filesystem. In the end, your root drive has a "folder size" of X but its actual usage is Y >> X. How is that not going to confuse everyone?
Put in another way, who is going to trust the X number ever? Why would you pay all that accounting penalty for every write to every file to end up with a half-asset broken-by-design feature?
> Also I don't see how drives and hard linked files are any different than regular files in this context.
They are different in that they exist in multiple folders at the same time (so they would trigger multiple size-updating branches).
You misunderstood what I meant. I didn't mean we should only update if a single change is significant. I meant we only update when the cumulative changes since last update is significant. An example:
Let's say we create a 1mb file. The next time the file is changed, we only update the parent if the change is more than 10% (the new size is greater than 1.1mb or less than 0.9mb). For example if it is a log file and each line is 100 bytes, we update the parent after 1000 new lines (even though the 1000th line is still only 100 bytes). (of course the number of lines before the update depends on the size of the file, so if we had a 1GB log file, we would update after 1000000 new lines).
It is trivial to prove that the estimate is never off by a factor of more than 10% (even for the parent folders). So this is not a "half-assed broken-by-design feature" since it provides strong guarantees in bounds and at least in my personal day-to-day usage, I almost never care about the exact size of a folder but want to have a rough idea of how large it is.
This really boils down to a caching problem, and well, there's a reason it's one of the two hard computer science problems..
The same place we store the rest of the file attributes?
I think my design does make a lot of sense but you are actively trying to not understand it.
Then there are the complex situations (this is just a small sample I can come up with right on the spot):
What happens when a file is hard-linked under the same ancestor folder? Should its size be counted once or twice?
How do you even know the parents of a file at write time? Current (unix) filesystems only store folder -> [inodes], where an inode in that list may be referenced by other folders. There is just no inode -> folder(s) where it is stored mapping that I know of.
And then there are bind-mounts (similar to "folder hard-links" but not quite), special files/devices, etc.
All in all, it is a huge mess for a questionable benefit. What actual use cases are just not possible without this feature?
[1] https://eclecticlight.co/2019/02/06/how-big-is-that-folder-w...
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.
[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251...
https://antibody-software.com/web/software/software/wiztree-...
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.
[0]: https://wiki.winehq.org/Developer_FAQ#Who_can.27t_contribute...
I bet 99% of Wine core developers have at least skimmed through the Windows 2000 leak at some point.
If you could stand up in a court room and truthfully say "I've never seen the source code I am accused of copying" it would be to your benefit.
I do not think the chances of me implementing something so similar to something I have read before such that it would constitute copyright infringement are very high. I usually can't even remember the exact way I wrote some piece of code months ago myself, let alone something I read...
Whether or not this makes any sense, I don't know. I'm also not a lawyer, but I believe this principal is important for clean-room reverse engineering as well.
And yes, clean room design is a bit more extreme in that regard (which is probably something companies/individuals do if they expect a high risk of litigation, as it probably makes it a lot easier to prove that there is no copyright infringement, and certainly not willful infringement)
So, the requirement for Wine and ReactOS mentioned in the other comments is probably not unreasonable.
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?
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.
- ranger / sunflower on *nix - total commander on win
Sunflower is cross-platform and IMO great, if only it continues to be developed:
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.
This is unlikely to end up on my image server.
For example: if I delete a huge local folder it cannot take longer than rd /q /s. Currently explorer will just grind to a halt if you remove more than 100k files - and you don’t even need node to end up in that situation.
There's nothing better and faster than a two-panel system with a super-fast built-in editor / viewer.
Great to see how this sort of thing could feel.