Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

github.com

Post reply on HN
Print view View original

31–40 of 187 posts

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#31

Post by kaetemi »

maxxxxx wrote: post #7
MH15 wrote: post #3

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 note…

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.

At the very least, can we have the same font size on the control panels... This junk that's inherited from Windows 8 has random huge fonts all over.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#32

Post by kumarharsh »

ploxiln wrote: post #24
kumarharsh wrote: post #13

Earlier quoted context omitted.

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)…

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#33

Post by Doubl »

wvenable wrote: post #9
MH15 wrote: post #3

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 note…

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…

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#34

Post by ploxiln »

kumarharsh wrote: post #32
ploxiln wrote: post #24

Earlier quoted context omitted.

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)…

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.

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#35

Post by 64738 »

ploxiln wrote: post #24
kumarharsh wrote: post #13

Earlier quoted context omitted.

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)…

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. :)

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#36

Post by Bjartr »

userbinator wrote: post #27
potentialverand wrote: post #10

Earlier quoted context omitted.

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…

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.

[1] http://blogs.msdn.com/b/oldnewthing/archive/2011/12/26/10251...

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#38

Post by hexomancer »

ComputerGuru wrote: post #21
Causality1 wrote: post #15

Earlier quoted context omitted.

I don't see why the size of the folder couldn't be written to the folder's metadata every time the folder contents are modified.

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.

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#39

Post by mehrdadn »

vocatus_gate wrote: post #30
userbinator wrote: post #16

Earlier quoted context omitted.

Starting early is good, but I think he may have gotten sucked into the UWP hype: 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 th…

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...

Re: Files UWP: An enthusiast’s take on what Windows File Explorer explorer should be

#40

Post by ken »

Causality1 wrote: post #15
potentialverand wrote: post #10

Earlier quoted context omitted.

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/

I don't see why the size of the folder couldn't be written to the folder's metadata every time the folder contents are modified.

It certainly can. Apple does this in APFS. They call it "fast directory sizing": https://arstechnica.com/gadgets/2017/09/macos-10-13-high-sie...
Post reply on HN