- 02 Dec. 2003 - 14:51:
Blueprint for a new explorer
Apologies and warning: this is a very long post.
The one sole program that everyone uses is a file explorer. Windows Explorer, the default one, is halfway between genius and madness. Before you all start ranting and raving about how crap it is, consider this: it has full extension possibilities. Simple options, such as static icons, tooltips and context menu entries can be changed in the registry. More in-depth changes can be accomplished by writing Shell Extension dlls, of which I'm no stranger. Windows Explorer has a huge amount of tweaking and extensibility potential.
However, it's simply not enough. Basic flaws, the overcomplication of simple changes, and the sheer ugliness of it press people to use alternative file explorers.
Alternative file explorers can be divided into two groups : those who emulate explorer, and those who don't. The ones that do (2xExplorer for example) are more powerful, but because they rely on the same dataset as explorer (same registry entries, same COM interfaces), they inherently suffer the same flaws. Plus, because they are emulating
something (and a not-completely-documented something), they will always be slower.
The other breed of explorers do everything from scratch, not relying on the windows shell dataset. They're few and far between, often little more than GUI front-ends to the command prompt world of "DIR" and "CD". They are rarely extensible, and nowhere near as extensible as explorer.
I want this to end.
I envision a new file explorer, MORE powerful than explorer.exe, MORE extensible, MORE user-friendly, and definately BETTER documented. It doesn't exist, so I want to make it.
This is obviously a huge task. I'd like to know if anyone (hopefully I'll have to fight you off) would be interested in such a project. I don't just need coders, I need all people with an interest and a desire to make this happen. Before coding, we need structure, architecture, design, and above all ideas
Here's what I have so far:
file-classes dataset (instead of those registry entries)
- XML Database
- Simple text, easy to edit
- Can be stored in multiple files and loaded on demand
- Compatible with everything
- Offers inheritance
- eg: "GIF file" is-a "Image file" is-a "File"
"Image File" offers options to preview, edit in photoshop, ..., image dimensions, ...
"File" offers file size, cut/copy/paste, ...
- This means that programs such as photoshop install their options on "Image Files", and all image files inherit those attributes, which they can override, of course [eg. Make Paint the default program for .bmp]
- Properties/Actions are not hard-coded
- Each property or action will have a language-independant ID ("Standard.Copy" or "File.Size"). The querying and interpretation of this data is left up to the displaying application. If the "explorer" window wants to have a context menu with "copy" in it, it will Check the file-object supports "Standard.Copy",  Read the language string for "Standard.Copy" from the local language file,  Display the string with whatever skin the user wants.
The interface must be fully 100% user-configurable. This means toolbars, menus, status bars can be shown/hidden/moved/changed. It must be skinnable. The file display must support webview-type display - one display file for each view - "tile", "details", "thumbnail", and whatever else. These views are not fixed, limited or required (adding a view file enables that view, deleting it removes it - simple).
I've given a lot of thought to the actual display area. The obvious solution would be to use HTML. This way, each "view" would be little more than an XSL stylesheet, interpreting the data. However HTML has its own problems, which is why I thought that a specific xml-based display langauge should be developed. It should not in any way try to replace HTML, but emulate parts of it (remember this display langauge must support skins). Yeah, remember I did
admit this was a huge project!
Of course, once this "skin-enabled" display language is done, it doesn't have to be limited to this project - other apps could of course be written with it.
Anyway, that's enough for now. What do y'all think?