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

171–180 of 187 posts

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

#171

Post by thrower123 »

melenaos wrote: post #55
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…

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.

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.

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

#172

Post by ComputerGuru »

hexomancer wrote: post #89
kilburn wrote: post #60

Earlier quoted context omitted.

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

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

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.

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

#173

Post by [deleted] »

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…

[deleted]

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

#174

Post by hexomancer »

ComputerGuru wrote: post #172
hexomancer wrote: post #89

Earlier quoted context omitted.

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

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.

> where are you storing the amount each file was changed since the last parent folder update

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.

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

#175

Post by hexomancer »

gregmac wrote: post #149
hexomancer wrote: post #89

Earlier quoted context omitted.

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

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

Nope. We only have to read the parent of the last changed folder. Plus, any filesystem worth its salts already caches the frequently used parts.

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

#176

Post by kilburn »

hexomancer wrote: post #89
kilburn wrote: post #60

Earlier quoted context omitted.

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

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

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?

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

#177

Post by bscphil »

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.

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.

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

#178

Post by michrassena »

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

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

#179

Post by chris_wot »

clmul wrote: post #119
chris_wot wrote: post #90

Earlier quoted context omitted.

It means that if you read the Win2k source code, any code you write could well be challenged as a copyright infringement.

This seems like a really silly point of view: it would be similar to saying that anyone ever reading a novel would not be able to write their own.

You might want to look up clean room engineering.

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

#180

Post by ComputerGuru »

hexomancer wrote: post #174
ComputerGuru wrote: post #172

Earlier quoted context omitted.

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.

> where are you storing the amount each file was changed since the last parent folder update 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 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!
Post reply on HN