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

51–60 of 187 posts

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

#51

Post by molteanu »

userbinator wrote: post #8

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

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

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

#52

Post by majkinetor »

kristiandupont wrote: post #49

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

None that I could found in a huge time. Finally, I did this:

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

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

#53

Post by hestefisk »

64738 wrote: post #35
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)…

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

ACDSee was thee shit, mate

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

#54

Post by eps »

kumarharsh wrote: post #13
userbinator wrote: post #8

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

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.

55 MB is an absolute fuckton.

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.

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

#55

Post by melenaos »

userbinator wrote: post #16
EpicBlackCrayon wrote: post #11

Interesting note, the author of this project is still in high school.

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…

Developing on the windows API is an unproductive way of creating apps, especially for the beginner developer.

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.

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

#56

Post by V-2 »

Doubl wrote: post #33
wvenable wrote: post #9

Earlier quoted context omitted.

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.

Text-searching the Settings often hangs on me, too (on more than one machine).

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

#57

Post by alkonaut »

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.

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

#58

Post by noisem4ker »

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…

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

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

#60

Post by kilburn »

hexomancer wrote: post #38
ComputerGuru wrote: post #21

Earlier quoted context omitted.

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…

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

Post reply on HN