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.
It’s a classic case of ease of use without experience vs speed with experience. Unfortunately, the former is the one that seems to win out with the masses.
Maybe there’s some sort of hybrid approach with keybindings for the power users and the blocky menu for more casual access.
The lack of keyboard shortcuts and tabbing means any setting I have to change repeatedly is a bunch of hard-to-automate clicks. (Namely, plugging into a new monitor and rotating it, since the Ctrl+Alt+UpArrow doesn't work any more.)
I agree. In addition, to me anyway, the settings app is kind of hideous. It follows some weird design principles and UI colors that don't even match the rest of the Win10 UI (even the new parts)! I would have expected to see something like explorer.exe - kind of a modern version of the older Win7 era UI principles.
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.
Windows is still arguably the best OS for doing productive work on the tablet, so I'm personally very happy Microsoft is still developing it in this direction. That said, compared to old Control Panel, the Settings app is a loss in utility.
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.
They are rare compared to every other desktop/laptop computer, they still have touchpads and really why would you smear your screen with your sweaty fingers when you can avoid that?
That is really an indictment of the sorry state of PC trackpads. When I use my partner's MacBook with its pixel-perfect, glass trackpad, I never feel wanting a touchscreen.
Sure, i actually have one (well, kinda, i have a GPD Win which has a touch screen although i still prefer to use the joystick to move the mouse even if it s a bit slower) but optimizing the UI for the rare case doesn't make much sense to me.
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.
Everyone seems to have their own definitions of what is or isn't "dead" or what is or isn't UWP, but as far as Windows native development is concerned, they are still producing new versions of WinUI with new features and new versions of Windows are still adding new WinRT APIs. https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
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.
Same font? How about starting with having the same font renderer that actually respects font rendering settings?
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!
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 ...
I agree to those points, and really happy that 7-Zip still fits on a floppy (when the floppy itself is dead). The bloat is real, but it's not something specific to Windows. All three platforms, plus the web, have become bloated. But picking the 50mb size as a stick to beat an app which is still maturing is too harsh, IMO.
If it was just a regular app I'd agree, but file explorer is pretty integral to the OS experience. Any bloat there cascades as multiple instances are launched or called from other applications. As a counterexample, here's XYplorer, another file explorer alternative: https://www.xyplorer.com/ which weighs in at 7MB.
True - and reports seem to be that the actual compiled code is like 18 MiB. It's the comparison to these huge android apps that got me. I could do this for android too: keepassdroid is 4 MiB, zxing barcode scanner is 0.7 MiB ...
So many people just don't understand the scale of these things.
Thank you for mentioning IrfanView. Back in the day I used to have a cracked copy of LviewPro that was always one of the 1st programs to be installed whenever I started working on a new system. It was small, fast, and I could easily flip through all the image files in a directory.
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. :)
It's probably not OP's code itself but usage of UWP. The apps you mentioned here are all written in pure Win32 API. HWND, HANDLE, HPEN, HDC, anyone? Just pure C (or pure C++) and some functions... Those were the days!
FWIW Total Commander's EXE and DLLs are around 8MB (the installer is 4.2MB) and uses around 6MB of RAM right now (for comparison, the new UWP Calculator uses 18MB of RAM). It is not written in pure C/C++ nor uses Win32 directly but instead it is written in Object Pascal/Delphi or Free Pascal/Lazarus (depending on the version you use) and uses VCL or LCL (well, it probably does use some Win32 directly too). Also runs on any Windows PC from Win95 to Win10.
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).
Our hardware tooling is all written in C++/Win32 and some MFC; it’s all tiny and light. Because factory controlling computers are (unfortunately imho but what can I do) older Windows versions (for us that is due to certification etc mostly) on weak but robust systems with little memory that need to run for years without issues/crashes. So lean, fast software, tested for memory leaks which can be restarted in very short times (downtime of the production line is expensive) is important.
Unfortunately those APIs seems to be kind of obsolete nowadays. All the nice things are with UWP. I think that WinAPI is not even hardware accelerated. That's a pity, but what can we expect, when Microsoft themselves botched WinAPI in their own products long ago.
Windows could be so better with their old Windows 2000 style, without all those design jumps around.
You can do hardware accelerated stuff atop WinAPI; many, sadly, don't seem to know it. WinRT, is exactly for that; it's the distillation of UWP, which can be used in a simple Win32 app [1] e.g. The modern, hardware-accelerated API for compositing on Windows is Visual Layer (available under `ABI::Windows::UI::Composition`) [2]; it can be used from a Win32 app written in pure C++ [3] and the C++/CX language extension is unneeded.
What nice things are with UWP? I haven't seen any UWP application i'd consider "nice" :-P.
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.
And then there's https://www.nirsoft.net/ full of useful utilities measured in tens of kilobytes... it's insane. The largest 64 bit exe is 249 232 bytes.
So it’s 4x the size of mpc-hc, did the sky really fall here? I’m not on a computer but quickly scanning the repo there’s a fair number of image assets, so I don’t really know that that’s a good proxy for “bloat”
Yeah but 7-zip's UI is small enough to be just about unusable on my 4k monitor. Sometimes drag-and-drop is broken and sometimes windows don't resize right. Maybe if they had used a good UI library instead of rolling their own stuff, they would have to spend less time chasing a bunch of little bugs and the users wouldn't have to deal with them either.
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.)
It's not just a matter of using random system functionality; I think Explorer uses the same UI code as Open/Save dialogs, in which case the UI itself necessarily lives in system DLLs. (But I'm a novice when it comes to Windows, so I could be wrong.)
Yeah, all the file tree view/list view stuff, shell namespace etc. etc. is implemented in shell32.dll, so we should probably compare with explorer.exe + shell32.dll. Everything else are basic widgets and OS interaction which clearly exists in both environments so shouldn't be counted.
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.
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.
on the other hand, just the splash screen image for whatever $modern app can be more than the space available a floppy since you need it normal size, @2x, @3x, it's in 32-bit RGBA instead of 256 color...
The fact that it needs a splash screen in the first place is because it takes too long to start because of bloat, so in a way it's a negative feedback cycle.
> The fact that it needs a splash screen in the first place is because it takes too long to start because of bloat, so in a way it's a negative feedback cycle.
no, had to build a few apps where this was requested only for branding purposes.
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.
Dumb question: Why is this behavior desired? If I take a screenshot I want an exact record of what is currently displayed. I don’t presume to be a normal user but am super curious about the “other side”.
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.
It prevents the generation of consistent screenshots and looks somewhat unprofessional. It's the same reason why product marketing shots don't have clutter on the desktop or a bunch of random applications running in the background.
No, but sometimes it seems to hide what is behind the translucency so as not to pollute the screenshot. Other times it does not seem to do this. I don't know the pattern or rationale.
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.
Yes it is, if someone doesn't care about creating bloated applications they wont care about creating good applications either - which includes said polishing.
A lack of concern for "bloating" does not entail a lack of concern for user experience.
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.
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?
I don't know how much the C# compiler optimizes code, if it does at all, but I do know that the JIT compiler is smart enough to delete this. So I came up with an awkwardly-worded response that provided information that I knew to be true.
Yes, of course it is trivially optimized out, that's still not the issue. The question is why that function (and several others) exist in the first place! Is there a bug (which is then copypasted several times) and the code is actually supposed to flip between enabled and disabled (in which case it should really be written foo = !foo)? Or something else?
C# has assignment and mentioning overloading by aliasing to getters and setters. The setter may be holding a shared lock and this pattern may make it release.
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.
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.
Older versions of Windows used the FAT filesystem rather than the current NTFS filesystem. FAT happened to get you directory size "for free" due to how it works under the hood, whereas NTFS does not (but it's faster at other things as a result). For much more detail check out this[1] post on The Old New Thing blog by Raymond Chen.
It is absolutely hideously slow on NTFS to compute the size of a directory that (recursively or not) contains thousands of files. Indeed, it is absolutely hideously slow on NTFS to do just about anything that needs to touch thousands of files at a time.
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.
Because it's recursive. It means a file nested a few hundred folders down needs to update each and every parent. And what about hard linked files? Directory junction points? Drives mounted as folders? It would be insane to think the performance would be acceptable.
First of all, most files are nowhere near 10 levels deep, let alone hundreds of levels.
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.
> most files are nowhere near 10 levels deep, let alone hundreds of levels.
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).
> 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".
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.
I understand your design (and yes, it would work for the simple cases). Even then, it all still boils down to whether you want the overhead of extra computations for every write to get a [lower,upper] bound on the size of what every folder contains or not.
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?
You still have to read the stored size on each parent to figure this out, at which point the optimization makes sense only if writes are significantly (at least 2x) more expensive than reads, and this is not true for most desktop PCs.
This really boils down to a caching problem, and well, there's a reason it's one of the two hard computer science problems..
If 10 files change by n bytes each, none of which reach your threshold for updating the parent individually, where are you storing the amount each file was changed since the last parent folder update until you deign it appropriate to update the parent? Your design makes no sense.
Then each time one file changes you need to read all other files in the same folder to determine if the net change satisfies the increment condition for the parent folder!
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.
Wine doesn't allow contributions from people that have seen the Windows source code[0]. I'm not sure of other projects with similar restrictions though.
I did not expect this to be such a controversial point, but I am referring to the fact that even having seen the source code would make me a legal risk to employers and open source projects. Whether this is ridiculous or not is not my point, it’s the reality I live in.
Here's the thing though: suppose you have worked for some previous employer, and seen their proprietary codebase. By your logic, you'll never be able to work on anything else or for any other employer without being a legal risk to them.
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...
The code I see from my employer is indeed a risk to my employer later on, but at least I'm seeing this code legally.
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.
I'm also not a lawyer, I can indeed see it being prudent to not go looking at code you're not legally allowed to use related to what you're working on right now (I wouldn't do that). But I can't believe looking at any other code in general would "taint" you in some way.
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.
Look at the Google/Oracle case about their replicating of the Java API. There was significant debate over whether they made a clean room implementation or whether they just copied Oracle's code.
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.
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.
Does it do away with the flaws of explorer or is it just a new UI?
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.
I just wish Windows 10 explorer had a columns mode like OS X's Finder. There are a few replacements, but none of them work quite right in my experience.
Why do Windoze users have a fetish for Universal/Modern UI? Wastes half the damn screen with enormously oversized buttons and elements. A computer is a device you use a mouse and keyboard with, don't try WI dows 8(.x)-style bullshit lol if you REALLY want those batshit insanely huge buttons for your tablet or something , just have separate touch-friendly version (like Office 2013 had a touch/kbd+m switchable version)
