I was thinking about how Windows Explorer is limited and requires plugins for its cloud features.
Being naturally web-aware, I think it could make sense, perhaps, to have Edge Chromium to have enough resources to make it not only possible, but a better experience to be able to browse local files, bringing in tow all the web browser goodies such as sandboxing and extensibility to the file manager.
Call it "Edge File Manager" if you will.
Edge File Manager would be web-aware, making it possible for a more direct path and deeper integration with e.g. Sharepoint and OneDrive, and a more unified experience.
If it makes sense, a legacy "Classic File Manager" would open a tab which just loads Windows Explorer - or it would just keep existing standalone.
If all stars align, the hypothetical Edge File Manager would not limit itself by the obnoxious Windows API MAX_PATH = 260 constant, allowing for longer file names.
That constant is super annoying, requiring frequent renaming of business documents - even though NTFS can have 32,767 character long file names.
For all legacy apps, Windows File Manager would still be there, dutifully observing the 260 character limit, while the modern Edge File Manager would require apps to be aware of the APIs which allow for longer file paths.
Hi @Tiago Freire, we tried something like this in our Windows Tabbed Sets feature. I believe that the feature was eventually cut as it did not solve the problem in a sufficiently understandable way. Thank you for the feedback, and we will certainly capture it. Thanks - Elliot
I believe that to have enough resources and the right hooks, to achieve the best results, it would have to be a concerted effort across teams, so it can become a significant upgrade to the Windows OS, leverage OneDrive for cloud sync in a smarter way, and be buddy-buddy with Microsoft Office as well. MAX_PATH = 260 is a very important constant, deeply set in as the first block of a Jenga Tower, and will not move for the foreseeable future. It causes significant impact and ramifications towards many design choices and apps, and since backwards compatibility cannot be broken, I can only see that it must be worked around with other, more modern APIs. And along with this, bring a full-fledged cloud-aware file manager. Just like eventually MS makes choices to supersede older code bases for more modern ones, I see from my humble point of view of a consumer that the simplest approach in this case would be to provide a modern file manager based on modern technologies, while retaining the old one for compatibility with less fear of tripping over old code and breaking backwards compatibility because they are separate code bases.